开发者学堂课程【Kubernetes 入门： 应用配置管理】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/51/detail/1014
应用配置管理
内容介绍
一、需求来源
二、ConfigMap
三、Secret
四、ServiceAccount
五、Resource
六、SecurityContext
七、InitContainer
一、需求来源
背景问题
除了依托容器镜像来定义运行的 Container，Pod还需要解决如下问题
1．不可变基础设施(容器)的可变配置
2．敏感信息的存储和使用(如:密码, token 等)
3．集群中 Pod 自我的身份认证
4．容器运行资源的配置管理
5.容器的运行安全管控
6.容器启动前置条件校验等
Pod 的配置管理
二、ConfigMap
1、ConfigMap 介绍
主要管理容器运行所需的配置文件，环境变量，命令行参数等可变配置。用于解耦容器镜像和可变配置，从而保障工作负载(Pod)的可移植性。
2、ConfigMap 创建
创建命令: kubectl create configmap [NAME] [DATA]
其中 DATA:
-指定文件或者目录
-指定键值对
3、ConfigMap 使用
ConfigMap 主要被 Pod 使用，一般用于挂载 Pod 用的配置文件，环境变量，命令行参数等。
4、ConfigMap 使用注意点
l ConfigMap 文件大小限制:1MB (ETCD 的要求)2. Pod 只能引用相同 Namespace 中的 ConfigMap
l Pod 引用的 ConfigMap 不存在时，Pod 无法创建成功。即 Pod 创建前需要先创建好 ConfigMap。
l 使用 envFrom 从 ConfigMap 来配置环境变量时，如果 ContigMap 中的某些 Kéy 放认为无效(比如 key 名称中带有数字)，该环境变量将不会注入容器，但是 Pod 口]以正常创建。
l 只有通过 k8s api 创建的 pod 才能使用 ConfigMap，其他方式创建的 pod (如manifest 创建的 static pod)不能使 ConfigMap
三、Secret
1、Secret 介绍
Secret 是在集群中用于存储密码,token 等敏感信息用的资源对象。其中的敏感数据采用 base-64 编码保存，相比存储在明文的 ConfigMap 中更规范，更安全。
Secret 主要有如下类型:
type=Opaque
type=kubernetes.io/service-account-token
type=kubernetes.io/dockerconfigjson
type=bootstrap.kubernetes.io/token
2、Secret 创建
n Secret 创建可以是用户自己创建，也有 Secret 是系统自动创建
n -比如:K8S 为每个 namespace 的默认用户(default ServiceAccount)创建的 Secret
n 手动创建命令: kubectl create secret generic [NAME] [DATA] [TYPE]
n 其中 DATA:可以指定文件/键值对
n 另外 TYPE:默认为 Opaque
3、Secret 使用
Secret 主要被 Pod 使用，一般通过 volume 挂载到指定容器目录，供容器中业务使用。另外在需要访问私有镜像仓库时，也可以引用 Secret 来实现。
4、使用私有镜像库
私有镜像仓库的信息可以通过 Secret(kubernetes.io/dockerconfigjson)存储在集群中，Pod 如果需要使用私有镜像仓库，可以通过如下两种方式来配置
l Pod.spec.imagePullSecrets 来指定 secret
l ServiceAccount 中设置 imagePullSecrets，然后自动为使用该 SA 的 Pod 注入 imagePullSecrets 信息。
5、Secret 使用的注意点
l Secret 文件大小限制:1MB
l Secret 虽然采用 base-64编码，但是可以简单解码查看原始信息。因此机密信息采用 Secret 存储仍需要慎重考虑或者 Secret 访问者进行控制。对 Secret 加密有较强需求，可以考虑结合 Kubernetes + Vault 来解决敏感信息的加密和权限管理。
l Secret 最佳实践:因为 list/watch 的一般处理将获取到 namespace 下所有 secret,因此不建议采取 list/watch 方式获取 Secret 信息。而推荐使用 GET 来获取需要的 Secret，从而减少更多 Secret 暴露的可能性。
四、ServiceAccount
1、ServiceAccount 介绍
ServiceAccount 主要用于解决 Pod 在集群中的身份认证问题。其中认证使用的授权信息，则利用前面讲到 Secret(type=kubernetes.io/service-account-token) 进行管理.
2、举例:Pod 里的应用访问它所属的 K8s 集群
实现原理:
1.Pod 创建时 Admission Controller 会根据指定的 ServiceAccount(默认为 default)把对应的 Secret 挂载到容器中固定的目录下(/var/run/secrets/kubernetes.io/serviceaccount)。(*k8s 自动实现)
2.当 Pod 访问集群时，可以默认利用 Secret 其中的 token 文件来认证 Pod 的身份。(ca.crt 用于校验服务端)参照右边代码)
3.默认 token 的认证信息为:
- Group: system:serviceaccounts:[namespace-name]
- User: system:serviceaccount:[namespace-name]:[pod-name]
五、Resource
1、容器资源配置管理支持资源类型:
-CPU:单位: millicore (1 Core=1000millicore)
- Memory:单位: Byte
- ephemeral storage(临时存储):单位: Byte
-自定义资源:配置时必须为整数
配置方法:
资源配置分为 request/limit 两种类型
- CPU:
lspec.containers[].resources.limits.cpu
spec.containers[].resources.requests.cpu
- Memory:
l spec.containers[].resources.limits.memory
spec.containers[].resources.requests.memory
- ephemeral storage(临时存储):
l spec.containers[].resources.limits.ephemeral-storage
l spec.containers[].resources.requests.ephemeral-storage
2、Pod 服务质量(QoS)配置
l 依据容器对 CPU,Memory 资源的 request/limit 需求，Pod 服务质量分类:
- Guaranteed
- Burstable
- BestEffort
l Guaranteed 定义:
- Pod 里的每个容器都必须有内存限制和请求，而且必须是一样的
- Pod 里的每个容器都必须有 CPU 限制和请求，而且必须是一样的
l Burstable 定义:
-非 Guaranteed
- Pod 里至少有一个容器有内存或者 CPU 请求
l BestEffort 定义:
-非 Guaranteed
-非 Burstable
六、Security Context
1、Security Context 介绍
Security Context 主要用于限制容器的行为，从而保障系统和其他容器的安全。
l 容器级别的 Security Context:仅对指定容器生效
l Pod 级别的 Security Context:对指定 Pod 中的所有容器生效
l Pod Security Policies(PSP):对集群内所有 Pod 生效
权限和访问控制设置项:
l Discretionary Access Control:根据用户 id 和组 id 来控制文件访问权限
l SELinux:通过 SELinux 的策略配置控制用户，进程等对文件等访问控制
l privileged:容器是否为特权模式
l Linux Capabilities:给特定进程配置 privileged 能力
l AppArmor:控制可执行文件的访问控制权限(读写文件/目录，网络端口读写等)
l Seccomp:控制进程可以操作的系统调用
l AllowPrivilegeEscalation:控制一个进程是否能比其父进程获取更多的权限
七、initContainer
1、initContainer 介绍
InitContainer 和普通 Container 的区别:
l lnitContainer 会先于普通 Container 启动执行，直到所有 InitContainer 执行成功后，普通 Container 才会被启动
l Pod 中多个 InitContainer 之间是按次序依次启动执行，而 Pod 中多个普通 Container 是并行启动
l InitContainer 执行成功后就结束退出了，而普通容器可能会一直执行或者重启(restartPolicy!=Never)
2、lnitContainer 用途:
基于 InitContainer 和普通 Container 的区别，一般 InitContainer 用于普通 Container 启动前的初始化(如配置文件准备)或者普通 Container 启动的前置条件检验(如网络连通检验)。
