Kubernetes专题-09、配置

配置

配置最佳实践

Configmap

ConfigMap 是一种 API 对象，用来将非机密性的数据保存到键值对中。使用时， Pod 可以将其用作环境变量、命令行参数或者存储卷中的配置文件。

注意：
ConfigMap 并不提供保密或者加密功能。 如果你想存储的数据是机密的，请使用 Secret， 或者使用其他第三方工具来保证你的数据的私密性，而不是用 ConfigMap。

使用 ConfigMap 来将你的配置数据和应用程序代码分开。
在 ConfigMap 中保存的数据不可超过 1 MiB。

ConfigMap 对象

ConfigMap 是一个 API 对象， 让你可以存储其他对象所需要使用的配置。
和其他 Kubernetes 对象都有一个 spec 不同的是，ConfigMap 使用 data 和 binaryData 字段。
这些字段能够接收键-值对作为其取值。
data 和 binaryData 字段都是可选的。data 字段设计用来保存 UTF-8 字符串，而 binaryData 则被设计用来保存二进制数据作为 base64 编码的字串。

说明： 静态 Pod 中的 spec 字段不能引用 ConfigMap 或任何其他 API 对象。

apiVersion: v1
kind: ConfigMap
metadata:
  name: game-demo
data:
  # 类属性键；每一个键都映射到一个简单的值
  player_initial_lives: "3"
  ui_properties_file_name: "user-interface.properties"

  # 类文件键
  game.properties: |
    enemy.types=aliens,monsters
    player.maximum-lives=5    
  user-interface.properties: |
    color.good=purple
    color.bad=yellow
    allow.textmode=true

apiVersion: v1
kind: Pod
metadata:
  name: configmap-demo-pod
spec:
  containers:
    - name: demo
      image: alpine
      command: ["sleep", "3600"]
      env:
        # 定义环境变量
        - name: PLAYER_INITIAL_LIVES # 请注意这里和 ConfigMap 中的键名是不一样的
          valueFrom:
            configMapKeyRef:
              name: game-demo           # 这个值来自 ConfigMap
              key: player_initial_lives # 需要取值的键
        - name: UI_PROPERTIES_FILE_NAME
          valueFrom:
            configMapKeyRef:
              name: game-demo
              key: ui_properties_file_name
      volumeMounts:
      - name: config
        mountPath: "/config"
        readOnly: true
  volumes:
  # 你可以在 Pod 级别设置卷，然后将其挂载到 Pod 内的容器中
  - name: config
    configMap:
      # 提供你想要挂载的 ConfigMap 的名字
      name: game-demo
      # 来自 ConfigMap 的一组键，将被创建为文件
      items:
      - key: "game.properties"
        path: "game.properties"
      - key: "user-interface.properties"
        path: "user-interface.properties"

ConfigMaps 和 Pods

不可变更的 ConfigMap

通过将 immutable 字段设置为 true 创建不可变更的 ConfigMap。 例如：

apiVersion: v1
kind: ConfigMap
metadata:
  ...
data:
  ...
immutable: true

Secret

Secret 是一种包含少量敏感信息例如密码、令牌或密钥的对象。 这样的信息可能会被放在 Pod 规约中或者镜像中。 使用 Secret 意味着你不需要在应用程序代码中包含机密数据。

由于创建 Secret 可以独立于使用它们的 Pod， 因此在创建、查看和编辑 Pod 的工作流程中暴露 Secret（及其数据）的风险较小。 Kubernetes 和在集群中运行的应用程序也可以对 Secret 采取额外的预防措施， 例如避免将机密数据写入非易失性存储。

Secret 类似于 ConfigMap 但专门用于保存机密数据。

Secret 的使用

Pod 可以用三种方式之一来使用 Secret：

作为挂载到一个或多个容器上的卷 中的文件。
作为容器的环境变量。
由 kubelet 在为 Pod 拉取镜像时使用。

Secret 的类型

内置类型 用法
Opaque 用户定义的任意数据
kubernetes.io/service-account-token 服务账号令牌
kubernetes.io/dockercfg ~/.dockercfg 文件的序列化形式
kubernetes.io/dockerconfigjson ~/.docker/config.json 文件的序列化形式
kubernetes.io/basic-auth 用于基本身份认证的凭据
kubernetes.io/ssh-auth 用于 SSH 身份认证的凭据
kubernetes.io/tls 用于 TLS 客户端或者服务器端的数据
bootstrap.kubernetes.io/token 启动引导令牌数据

不可更改的 Secret

apiVersion: v1
kind: Secret
metadata:
  ...
data:
  ...
immutable: true

为 Pod 和容器管理资源

可设定资源是 CPU 和内存（RAM）大小

请求和限制

资源类型

CPU 和内存统称为 计算资源，或简称为 资源。 计算资源的数量是可测量的，可以被请求、被分配、被消耗。

Pod 和 容器的资源请求和限制

spec.containers[].resources.limits.cpu
spec.containers[].resources.limits.memory
spec.containers[].resources.limits.hugepages-
spec.containers[].resources.requests.cpu
spec.containers[].resources.requests.memory
spec.containers[].resources.requests.hugepages-

Kubernetes 中的资源单位

CPU 资源单位

内存资源单位

容器资源示例

---
apiVersion: v1
kind: Pod
metadata:
  name: frontend
spec:
  containers:
  - name: app
    image: images.my-company.example/app:v4
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"
  - name: log-aggregator
    image: images.my-company.example/log-aggregator:v6
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"

带资源请求的 Pod 如何调度

Kubernetes 应用资源请求与限制的方式

在 Linux 系统上，容器运行时通常会配置内核 CGroups，负责应用并实施所定义的请求。

• CPU 限制定义的是容器可使用的 CPU 时间的硬性上限。 在每个调度周期（时间片）期间，Linux 内核检查是否已经超出该限制； 内核会在允许该 cgroup 恢复执行之前会等待。

• CPU 请求值定义的是一个权重值。如果若干不同的容器（CGroups）需要在一个共享的系统上竞争运行， CPU 请求值大的负载会获得比请求值小的负载更多的 CPU 时间。

• 内存请求值主要用于（Kubernetes）Pod 调度期间。在一个启用了 CGroup v2 的节点上， 容器运行时可能会使用内存请求值作为设置 memory.min 和 memory.low 的提示值。

• 内存限制定义的是 cgroup 的内存限制。如果容器尝试分配的内存量超出限制， 则 Linux 内核的内存不足处理子系统会被激活，并停止尝试分配内存的容器中的某个进程。 如果该进程在容器中 PID 为 1，而容器被标记为可重新启动，则 Kubernetes 会重新启动该容器。

• Pod 或容器的内存限制也适用于通过内存供应的卷，例如 emptyDir 卷。 kubelet 会跟踪 tmpfs 形式的 emptyDir 卷用量，将其作为容器的内存用量， 而不是临时存储用量。

如果某容器内存用量超过其内存请求值并且所在节点内存不足时，容器所处的 Pod 可能被逐出。

监控计算和内存资源用量

本地临时存储

本地临时性存储的配置

为本地临时性存储设置请求和限制

apiVersion: v1
kind: Pod
metadata:
  name: frontend
spec:
  containers:
  - name: app
    image: images.my-company.example/app:v4
    resources:
      requests:
        ephemeral-storage: "2Gi"
      limits:
        ephemeral-storage: "4Gi"
    volumeMounts:
    - name: ephemeral
      mountPath: "/tmp"
  - name: log-aggregator
    image: images.my-company.example/log-aggregator:v6
    resources:
      requests:
        ephemeral-storage: "2Gi"
      limits:
        ephemeral-storage: "4Gi"
    volumeMounts:
    - name: ephemeral
      mountPath: "/tmp"
  volumes:
    - name: ephemeral
      emptyDir:
        sizeLimit: 500Mi

带临时性存储的 Pods 的调度行为

临时性存储消耗的管理

扩展资源（Extended Resources）

节点级扩展资源

集群层面的扩展资源

使用扩展资源

仅当所有资源请求（包括 CPU、内存和任何扩展资源）都被满足时，Pod 才能被调度。 在资源请求无法满足时，Pod 会保持在 PENDING 状态。

PID 限制

进程 ID（PID）限制允许对 kubelet 进行配置，以限制给定 Pod 可以消耗的 PID 数量。

如果 Pod 处于悬决状态且有这种类型的消息时，你可以尝试如下几件事情：

• 向集群添加更多节点。
• 终止不需要的 Pod，为悬决的 Pod 腾出空间。
• 检查 Pod 所需的资源是否超出所有节点的资源容量。例如，如果所有节点的容量都是cpu：1， 那么一个请求为 cpu: 1.1 的 Pod 永远不会被调度。
• 检查节点上的污点设置。如果集群中节点上存在污点，而新的 Pod 不能容忍污点， 调度器只会考虑将 Pod 调度到不带有该污点的节点上。

使用 kubeconfig 文件组织集群访问

Windows 节点的资源管理