CNCF x Alibaba云原生技术公开课 第八章 应用配置管理

Pod配置管理分类

• 可变配置就用 ConfigMap；
• 敏感信息是用 Secret；
• 身份认证是用 ServiceAccount；
• 资源配置是用 Resources；
• 安全管控是用 SecurityContext；
• 前置校验是用 InitContainers。

1、ConfigMap

• 概念：管理一些可变配置信息，比如说配置文件、命令行参数、环境变量、端口号、其他配置绑定到pod的容器和系统组件，保障工作负载（Pod）的可移植性。
• kubectl get configmap
• kubectl get configmap [name] -oyaml
• kubectl describe configmap [name] 可以看到主要的key-value
• kubectl create configmap [name] [data]
• 使用
  • 单个、多个configMap定义容器环境变量 env[valueFrom[configMapKeyRef]]
  • 键值对配置为容器环境变量 envFrom[configMapRef]
  • 添加卷（在containers里面添加volumeMounts，然后定义Volumes里的configMap）
• 注意要点
  • configMap 文件的大小。虽然说 ConfigMap 文件没有大小限制，但是在 ETCD 里面，数据的写入是有大小限制的，现在是限制在 1MB 以内；
  • pod 引入 ConfigMap 的时候，必须是相同的 Namespace 中的 ConfigMap，ConfigMap.metadata 里面是有 namespace 字段的；
  • pod 引用的 ConfigMap。假如这个 ConfigMap 不存在，那么这个 pod 是无法创建成功的，其实这也表示在创建 pod 前，必须先把要引用的 ConfigMap 创建好；
  • envFrom 的方式。把 ConfigMap 里面所有的信息导入成环境变量时，如果 ConfigMap 里有些 key 是无效的，比如 key 的名字里面带有数字，那么这个环境变量其实是不会注入容器的，它会被忽略。但是这个 pod 本身是可以创建的，无效变量记录在事件日志中（kubectl get events）
  • 这里只有通过 K8s api 创建的 pod 才能使用 ConfigMap，比如说通过用命令行 kubectl 来创建的 pod，肯定是可以使用 ConfigMap 的，但其他方式创建的 pod，比如说kubelet 通过 manifest 创建的 static pod，是不能使用 ConfigMap 的。
    • kubelet通过 kubelet --pod-manifest-path=<路径>来启动kubelet进程，kubelet 定期的去扫描这个目录，根据这个目录下出现或消失的 YAML/JSON 文件来创建或删除静态 pod。

[root@node2 ~]# kubectl describe configmap nacos-cm
Name:         nacos-cm
Namespace:    default
Labels:       <none>
Annotations:  <none>Data
====
mysql.db.name:
----
nacos_devtest
mysql.password:
----
nacos
mysql.port:
----
3306
mysql.user:
----
nacos
Events:  <none>

2、Secret

• 概念：存储密码、 token、ssh key 等一些敏感信息的资源对象，采用 base-64 编码
• 四种类型
  • 第一种是 Opaque，它是普通的 Secret 文件, 默认模式；
  • 第二种是 service-account-token，是用于 service-account 身份认证用的 Secret；
  • 第三种是 dockerconfigjson，这是拉取私有仓库镜像的用的一种 Secret；
  • 第四种是 bootstrap.token，是用于节点接入集群校验用的 Secret。
• 创建模式
  • 用户创建
    • kubectl create secret generic [name] [data] [type]
  • 系统创建（k8s为每个namespace的默认用户创建的Secret）
• 使用方式
  • 环境变量
    • env[valueFrom[secretKeyRef]]
  • 作为数据卷被挂载
    • 操作模式设置为只读：spec.containers.volumeMounts.readOnly = true
    • 一个pod的每一个容器都需要配置volumeMounts
    • 默认挂载的文件权限是0644，可以通过defaultMode修改权限
      

使用私有镜像库

使用案例

• 定义包含ssh秘钥的Pod
• 创建隐藏文件（定义一个句点符号开头的Secret）

注意事项

• Secret 的文件大小限制。这个跟 ConfigMap 一样，也是 1MB；
• Secret 采用了 base-64 编码，但是它跟明文也没有太大区别。所以说，如果有一些机密信息要用 Secret 来存储的话，还是要很慎重考虑。因为如果能够访问这个集群，就能拿到这个 Secret。如果是对 Secret 敏感信息要求很高，对加密这块有很强的需求，推荐可以使用 Kubernetes 和开源的vault做一个解决方案，来解决敏感信息的加密和权限管理。
• Secret 读取的最佳实践，建议不要用 list/watch，如果用 list/watch 操作的话，会把 namespace 下的所有 Secret 全部拉取下来，这样暴露了更多的信息。推荐使用 GET 的方法，这样只获取需要的那个 Secret。

[root@node2 ~]# kubectl get secrets registry-secret -oyaml
apiVersion: v1
data:.dockerconfigjson: eyJhdXRocyI6eoJodHRwOi8vMTAuojI1LjEuNTU6ODA4NyI6eyJhdXRoIjoiWVdSdGFXNDZRbWxuWkdGMFlYUmxZVzB4TWpNME5RPT0iLCJwYXNzd29yZCI6IkJpZ2RhdGF0ZWFtMTIzNDUiLCJ1c2VybmFtZSI6ImFkbWluIj19fQ==
kind: Secret
metadata:annotations:field.cattle.io/creatorId: user-nskmxfield.cattle.io/projectId: c-5xbj6:p-jxgb9lifecycle.cattle.io/create.secretsController_c-5xbj6: "true"secret.user.cattle.io/secret: "true"creationTimestamp: "2020-04-24T01:50:21Z"name: registry-secretnamespace: defaultresourceVersion: "2436691"selfLink: /api/v1/namespaces/default/secrets/registry-secretuid: 8773ca35-22e1-4473-aeda-56376b026b10
type: kubernetes.io/dockerconfigjson

3、ServiceAccount

• 概念：解决 pod 在集群里面的身份认证问题
  
• 具体的流程：
  • pod 创建的时候，会把这个 secret 挂载到容器固定的目录下，这是 K8s 功能上实现的。它要把这个 ca.crt 和 token 这两个文件挂载到固定目录下面
  • Go 里面实现 Pod 访问 K8s 集群时，一般直接会调一个 InClusterConfig 方法，来生成这个访问服务 Client 的一些信息。然后可以看一下，最后这个 Config 里面有两部分信息：
    • 一个是 tlsClientConfig，这个主要是用于 ca.crt 校验服务端；
    • 第二个是 Bearer Token，这个就是 pod 的身份认证。在服务端，会利用 token 对 pod 进行一个身份认证。
  • 认证完之后 pod 的身份信息会有两部分：一个是 Group，一个是 User。身份认证是就是认证这两部分信息。
  • 接着可以使用 RBAC 功能，对 pod 进行一个授权管理。假如 RBAC 没有配置的话，默认的 pod 具有资源 GET 权限，就是可以从所属的 K8s 集群里 get 数据。如果是需要更多的权限，那么就需要 自行配置 RBAC 。

4、Pod服务质量

• 种类：

  • Guaranteed ：pod 里面每个容器都必须有内存和 CPU 的 request 以及 limit 的一个声明，且 request 和 limit 必须是一样的，这就是 Guaranteed；
  • Burstable：Burstable 至少有一个容器存在内存和 CPU 的一个 request；
  • BestEffort：只要不是 Guaranteed 和 Burstable，那就是 BestEffort。

• 区别：节点上 memory 配额资源不足，kubelet会把一些低优先级的，或者说服务质量要求不高的（如：BestEffort、Burstable）pod 驱逐掉。它们是按照先去除 BestEffort，再去除 Burstable 的一个顺序来驱逐 pod 的。