应用配置管理

pod配置： 

　　可变配置就用 ConfigMap；敏感信息是用 Secret；身份认证是用 ServiceAccount 这几个独立的资源来实现的；资源配置是用 Resources；安全管控是用 SecurityContext；前置校验是用 InitContainers 这几个在 spec 里面加的字段，来实现的这些配置管理。

configMap

　　ConfigMap 定义主要包括两个部分：一个是 ConfigMap 元信息， name 和 namespace 等信息；接第二个 data ，记录配置文件或者指定目录，以及直接指定键值对。

　　使用方式：环境变量、 volume 挂载

 

　　操作注意：

　　　　ETCD 里面，数据的写入限制在 1MB 以内

　　　　pod 引入 ConfigMap 的时候，必须是相同的 Namespace

　　　　pod 引用的 ConfigMap。假如这个 ConfigMap 不存在，那么这个 pod 是无法创建成功的

　　　　如果 ConfigMap 里有些 key 是无效的，比如 key 的名字里面带有数字，那么这个环境变量其实是不会注入容器的，它会被忽略。但是这个 pod 本身是可以创建的。

　　　　只有通过 K8s api 创建的 pod 才能使用 ConfigMap

　　　　ConfigMap配置的环境变量不会自动更新

secret

　　比configmap多一个type字段，指secret的类型。

　　　　第一种是 Opaque，它是普通的 Secret 文件；

　　　　第二种是 service-account-token，是用于 service-account 身份认证用的 Secret；

　　　　第三种是 dockerconfigjson，这是拉取私有仓库镜像的用的一种 Secret；

　　　　第四种是 bootstrap.token，是用于节点接入集群校验用的 Secret。

　　被 pod 来使用，一般是通过 volume 形式挂载到容器里指定的目录，然后容器里的业务进程再到目录下读取 Secret 来进行使用。另外在需要访问私有镜像仓库时，也是通过引用 Secret 来实现。

　　　　在 pod 里面，通过 imagePullSecrets 字段

　　　　在使用的 serviceaccount 里配置 imagePullSecrets

　　操作注意：

　　　　ETCD 里面，数据的写入限制在 1MB 以内

　　　　Secret 采用了 base-64 编码，但是它跟明文也没有太大区别。

　　　　推荐使用 GET 的方法，这样只获取需要的那个 Secret。

ServiceAccount 

　　用于解决 pod 在集群里面的身份认证问题，身份认证信息是存在于 Secret 里面。

　　对应的 Secret 的 data 里有两块数据，一个是 ca.crt，一个是 token。ca.crt 用于对服务端的校验，token 用于 Pod 的身份认证，它们都是用 base64 编码过的。 metadata 元信息里，关联了ServiceAccount 信息（这个 secret 被哪个 ServiceAccount 使用）。type是 service-account-token 类型。

　　pod 创建的时候，首先它会把这个 secret 挂载到容器固定的目录下，这是 K8s 功能上实现的。

　　默认的 pod 具有资源 GET 权限，就是可以从所属的 K8s 集群里 get 数据

Resource

　　容器的资源配置管理，目前内部支持类型有三种：CPU、内存，以及临时存储。

　　资源需求，一个是 request ，一个是 limits，它分别对需要的资源和资源临界进行一个声明。

　　 pod 的服务质量有三个分类，分别是 Guaranteed、Burstable 和 BestEffort。

　　　　Guaranteed ：pod 里面每个容器都必须有内存和 CPU 的 request 以及 limit 的一个声明，且 request 和 limit 必须是一样的，这就是 Guaranteed；

　　　　Burstable：Burstable 至少有一个容器存在内存和 CPU 的一个 request；

　　　　BestEffort：只要不是 Guaranteed 和 Burstable，那就是 BestEffort。

　　若节点上 配额资源不足，kubelet会把一些低优先级的，或者说服务质量要求不高的（如：BestEffort、Burstable）pod 驱逐掉。

SecurityContext

　　用于限制容器的一个行为，它能保证系统和其他容器的安全。这一块的能力不是 Kubernetes 或者容器 runtime 本身的能力，而是 Kubernetes 和 runtime 通过用户的配置，最后下传到内核里，再通过内核的机制让 SecurityContext 来生效。

InitContainer

　　InitContainer 首先会比普通 container 先启动，并且直到所有的 InitContainer 执行成功后，普通 container 才会被启动；

　　InitContainer 之间是按定义的次序去启动执行的，执行成功一个之后再执行第二个，而普通的 container 是并发启动的；

　　InitContainer 执行成功后就结束退出，而普通容器可能会一直在执行。它可能是一个 longtime 的，或者说失败了会重启，这个也是 InitContainer 和普通 container 不同的地方。