阿里云《云原生》公开课笔记 第八章 应用配置管理

课程文字：https://edu.aliyun.com/lesson_1651_18356?spm=5176.10731542.0.0.37a620beEfY6c7#_18356

Pod配置管理分类

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

ConfigMap 【推荐这本书《再也不踩坑的Kubernetes实战指南》】

• 概念：管理一些可变配置信息，比如说配置文件、命令行参数、环境变量、端口号、其他配置绑定到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>

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-nskmx
    field.cattle.io/projectId: c-5xbj6:p-jxgb9
    lifecycle.cattle.io/create.secretsController_c-5xbj6: "true"
    secret.user.cattle.io/secret: "true"
  creationTimestamp: "2020-04-24T01:50:21Z"
  name: registry-secret
  namespace: default
  resourceVersion: "2436691"
  selfLink: /api/v1/namespaces/default/secrets/registry-secret
  uid: 8773ca35-22e1-4473-aeda-56376b026b10
type: kubernetes.io/dockerconfigjson

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 。

Resource

• 支持三种类型：CPU、内存、临时存储（ephemeral storage）
• 注意：指定的数量必须为整数
• 配置方法：requests需求资源/limit资源临界

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 的。

SecurityContext

• 三个级别：
  • 第一个是容器级别，仅对容器生效；
  • 第二个是 pod 级别，对 pod 里所有容器生效；
  • 第三个是集群级别，就是 PSP，对集群内所有 pod 生效。
• 权限和访问控制项
  • 第一个就是通过用户 ID 和组 ID 来控制文件访问权限；
  • 第二个是 SELinux，它是通过策略配置来控制用户或者进程对文件的访问控制；
  • 第三个是特权容器；
  • 第四个是 Capabilities，它也是给特定进程来配置一个 privileged 能力；
  • 第五个是 AppArmor，它也是通过一些配置文件来控制可执行文件的一个访问控制权限，比如说一些端口的读写；
  • 第六个是一个对系统调用的控制；
  • 第七个是对子进程能否获取比父亲更多的权限的一个限制。

InitContainer

• InitContainer 和普通 container 的区别，有以下三点内容：
  • InitContainer 首先会比普通 container 先启动，并且直到所有的 InitContainer 执行成功后，普通 container 才会被启动；
  • InitContainer 之间是按定义的次序去启动执行的，执行成功一个之后再执行第二个，而普通的 container 是并发启动的；
  • InitContainer 执行成功后就结束退出，而普通容器可能会一直在执行。它可能是一个 longtime 的，或者说失败了会重启，这个也是 InitContainer 和普通 container 不同的地方。

自测题目

https://gitchat.csdn.net/columnTopic/5d7f26d749b2b1063b5208b7

Pod 中引用 ConfigMap 不正确的是：（单选题）C

• A. 环境变量
• B. 命令行参数
• C. 资源声明
• D. Volumes

如下哪些方式创建的 Pod 可以使用 ConfigMap？（多选题） AB

• A. Kubectl
• B. Dashboard
• C. kubelet mainifests
• D. kubelet url

ServiceAccount 用的 Secret 类型是哪一种？（单选题）B

• A. Opaque
• B. kubernetes.io/service-account-token
• C. kubernetes.io/dockerconfigjson
• D. bootstrap.kubernetes.io/token

应用中获取 Secret 时，推荐如下哪种方式？（单选题）C

• A. List
• B. Watch
• C. Get
• D. Post

ServiceAccount 创建完成，其对应的 Secret 信息由哪个组件更新？（单选题）B

• A. kube-apiserver
• B. kube-controller-manager
• C. kube-scheduler
• D. kubelet

下面容器资源申明合理的是：（多选题）ACD

• A.

resources:
requests:
cpu: 100m
limits:
cpu: 500m

• B.

resources:
requests:
cpu: 200m
limits:
cpu: 100m

• C.

resources:
requests:
cpu: 100m
memory: 64Mi

• D.

resources:
limits:
cpu: 100m

下面哪些是 Security Context 的设置项？（多选题）ABCD

• A. SELinux
• B. privileged
• C. Seccomp
• D. AllowPrivilegeEscalation

InitContainer 理解正确的有：（多选题） ABCD

• A. InitContainer 先于普通容器启动执行
• B. 多个 InitContainer 的执行是按定义次序串行执行，而多个普通容器是并行执行
• C. InitContainer 执行成功后就结束退出，而普通容器可以一直执行
• D. Pod 重启时，InitContainer 会再次执行

因为 ETCD 数据写入大小限制，ConfigMap 数据大小要求小于 1MB。（判断题）A

• A. TRUE
• B. FALSE

当节点磁盘空间不足时，Pod 被驱逐的顺序为: BestEffort 先于 Burstable。（判断题） A

• A. TRUE
• B. FALSE