这是本节的多页打印视图。 点击此处打印.

返回本页常规视图.

配置

Kubernetes 为配置 Pods 提供的资源。

1 - 配置最佳实践

本文档重点介绍并整合了整个用户指南、入门文档和示例中介绍的配置最佳实践。

这是一份不断改进的文件。 如果您认为某些内容缺失但可能对其他人有用，请不要犹豫，提交 Issue 或提交 PR。

一般配置提示

  • 定义配置时，请指定最新的稳定 API 版本。
  • 在推送到集群之前，配置文件应存储在版本控制中。 这允许您在必要时快速回滚配置更改。 它还有助于集群重新创建和恢复。
  • 使用 YAML 而不是 JSON 编写配置文件。虽然这些格式几乎可以在所有场景中互换使用，但 YAML 往往更加用户友好。
  • 只要有意义，就将相关对象分组到一个文件中。 一个文件通常比几个文件更容易管理。 请参阅guestbook-all-in-one.yaml 文件作为此语法的示例。
  • 另请注意，可以在目录上调用许多kubectl命令。 例如，你可以在配置文件的目录中调用kubectl apply。
  • 除非必要，否则不指定默认值：简单的最小配置会降低错误的可能性。
  • 将对象描述放在注释中，以便更好地进行内省。

“Naked”Pods 与 ReplicaSet，Deployment 和 Jobs

  • 如果可能，不要使用独立的 Pods（即，未绑定到 ReplicaSet 或 Deployment 的 Pod）。 如果节点发生故障，将不会重新调度独立的 Pods。

Deployment 既可以创建一个 ReplicaSet 来确保预期个数的 Pod 始终可用，也可以指定替换 Pod 的策略（例如 RollingUpdate）。 除了一些显式的 restartPolicy: Never 场景外，Deployment 通常比直接创建 Pod 要好得多。Job 也可能是合适的选择。

服务

  • 在创建相应的后端工作负载（Deployment 或 ReplicaSet），以及在需要访问它的任何工作负载之前创建 服务。 当 Kubernetes 启动容器时，它提供指向启动容器时正在运行的所有服务的环境变量。 例如，如果存在名为 foo 的服务，则所有容器将在其初始环境中获得以下变量。

    FOO_SERVICE_HOST=<the host the Service is running on>
FOO_SERVICE_PORT=<the port the Service is running on>

这确实意味着在顺序上的要求 - 必须在 Pod 本身被创建之前创建 Pod 想要访问的任何 Service， 否则将环境变量不会生效。DNS 没有此限制。

  • 一个可选（尽管强烈推荐）的集群插件 是 DNS 服务器。DNS 服务器为新的 Services 监视 Kubernetes API，并为每个创建一组 DNS 记录。 如果在整个集群中启用了 DNS，则所有 Pods 应该能够自动对 Services 进行名称解析。
  • 除非绝对必要，否则不要为 Pod 指定 hostPort。 将 Pod 绑定到hostPort时，它会限制 Pod 可以调度的位置数，因为每个 <hostIP, hostPort, protocol>组合必须是唯一的。 如果您没有明确指定 hostIP 和 protocol，Kubernetes 将使用 0.0.0.0 作为默认 hostIP 和 TCP 作为默认 protocol。

如果您只需要访问端口以进行调试，则可以使用 apiserver proxy或 kubectl port-forward。

如果您明确需要在节点上公开 Pod 的端口，请在使用 hostPort 之前考虑使用 NodePort 服务。

  • 避免使用 hostNetwork，原因与 hostPort 相同。
  • 当您不需要 kube-proxy 负载均衡时，使用 无头服务
    (ClusterIP 被设置为 None)以便于服务发现。

使用标签

  • 定义并使用标签来识别应用程序 或 Deployment 的 语义属性，例如{ app: myapp, tier: frontend, phase: test, deployment: v3 }。 你可以使用这些标签为其他资源选择合适的 Pod； 例如，一个选择所有 tier: frontend Pod 的服务，或者 app: myapp 的所有 phase: test 组件。 有关此方法的示例，请参阅guestbook 。

通过从选择器中省略特定发行版的标签，可以使服务跨越多个 Deployment。 当你需要不停机的情况下更新正在运行的服务，可以使用Deployment。

Deployment 描述了对象的期望状态，并且如果对该规范的更改被成功应用， 则 Deployment 控制器以受控速率将实际状态改变为期望状态。

  • 您可以操纵标签进行调试。 由于 Kubernetes 控制器（例如 ReplicaSet）和服务使用选择器标签来匹配 Pod， 从 Pod 中删除相关标签将阻止其被控制器考虑或由服务提供服务流量。 如果删除现有 Pod 的标签，其控制器将创建一个新的 Pod 来取代它。 这是在"隔离"环境中调试先前"活跃"的 Pod 的有用方法。 要以交互方式删除或添加标签，请使用 kubectl label。

容器镜像

imagePullPolicy和镜像标签会影响 kubelet 何时尝试拉取指定的镜像。

  • imagePullPolicy: IfNotPresent：仅当镜像在本地不存在时才被拉取。
  • imagePullPolicy: Always：每次启动 Pod 的时候都会拉取镜像。
  • imagePullPolicy 省略时，镜像标签为 :latest 或不存在，其值自动被设置为 Always。注意，如果镜像标签的值发生改变，imagePullPolicy 的值不会被更新为 IfNotPresent。
  • imagePullPolicy 省略时，指定镜像标签并且不是 :latest，其值自动被设置为 IfNotPresent。注意，如果镜像标签的值之后被移除或者修改为 latest，imagePullPolicy 的值不会被更新为 Always。
  • imagePullPolicy: Never：假设镜像已经存在本地，不会尝试拉取镜像。
说明： 要确保容器始终使用相同版本的镜像，你可以指定其 摘要， 例如 sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2。 摘要唯一地标识出镜像的指定版本，因此除非您更改摘要值，否则 Kubernetes 永远不会更新它。
说明： 在生产中部署容器时应避免使用 :latest 标记，因为这样更难跟踪正在运行的镜像版本，并且更难以正确回滚。
说明： 只要镜像仓库是可访问的，底层镜像驱动程序的缓存语义能够使即便 imagePullPolicy: Always 的配置也很高效。 例如，对于 Docker，如果镜像已经存在，则拉取尝试很快，因为镜像层都被缓存并且不需要下载。

使用 kubectl

  • 使用 kubectl apply -f <directory>。 它在 <directory> 中的所有 .yaml、.yml 和 .json 文件中查找 Kubernetes 配置，并将其传递给 apply。

2 - ConfigMap

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

ConfigMap 将您的环境配置信息和 容器镜像 解耦，便于应用配置的修改。

注意：

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

动机

使用 ConfigMap 来将你的配置数据和应用程序代码分开。

比如，假设你正在开发一个应用，它可以在你自己的电脑上（用于开发）和在云上 （用于实际流量）运行。 你的代码里有一段是用于查看环境变量 DATABASE_HOST，在本地运行时， 你将这个变量设置为 localhost，在云上，你将其设置为引用 Kubernetes 集群中的 公开数据库组件的 服务。

这让你可以获取在云中运行的容器镜像，并且如果有需要的话，在本地调试完全相同的代码。

ConfigMap 在设计上不是用来保存大量数据的。在 ConfigMap 中保存的数据不可超过 1 MiB。如果你需要保存超出此尺寸限制的数据，你可能希望考虑挂载存储卷 或者使用独立的数据库或者文件服务。

ConfigMap 对象

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

ConfigMap 的名字必须是一个合法的 DNS 子域名。

data 或 binaryData 字段下面的每个键的名称都必须由字母数字字符或者 -、_ 或 . 组成。在 data 下保存的键名不可以与在 binaryData 下 出现的键名有重叠。

从 v1.19 开始，你可以添加一个 immutable 字段到 ConfigMap 定义中，创建 不可变更的 ConfigMap。

ConfigMaps 和 Pods

你可以写一个引用 ConfigMap 的 Pod 的 spec，并根据 ConfigMap 中的数据 在该 Pod 中配置容器。这个 Pod 和 ConfigMap 必须要在同一个 名字空间 中。

这是一个 ConfigMap 的示例，它的一些键只有一个值，其他键的值看起来像是 配置的片段格式。

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

你可以使用四种方式来使用 ConfigMap 配置 Pod 中的容器：

  1. 在容器命令和参数内
  2. 容器的环境变量
  3. 在只读卷里面添加一个文件，让应用来读取
  4. 编写代码在 Pod 中运行，使用 Kubernetes API 来读取 ConfigMap

这些不同的方法适用于不同的数据使用方式。 对前三个方法，kubelet 使用 ConfigMap 中的数据在 Pod 中启动容器。

第四种方法意味着你必须编写代码才能读取 ConfigMap 和它的数据。然而， 由于你是直接使用 Kubernetes API，因此只要 ConfigMap 发生更改，你的 应用就能够通过订阅来获取更新，并且在这样的情况发生的时候做出反应。 通过直接进入 Kubernetes API，这个技术也可以让你能够获取到不同的名字空间 里的 ConfigMap。

下面是一个 Pod 的示例，它通过使用 game-demo 中的值来配置一个 Pod：

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"

ConfigMap 不会区分单行属性值和多行类似文件的值，重要的是 Pods 和其他对象 如何使用这些值。

上面的例子定义了一个卷并将它作为 /config 文件夹挂载到 demo 容器内， 创建两个文件，/config/game.properties 和 /config/user-interface.properties， 尽管 ConfigMap 中包含了四个键。 这是因为 Pod 定义中在 volumes 节指定了一个 items 数组。 如果你完全忽略 items 数组，则 ConfigMap 中的每个键都会变成一个与 该键同名的文件，因此你会得到四个文件。

使用 ConfigMap

ConfigMap 可以作为数据卷挂载。ConfigMap 也可被系统的其他组件使用，而 不一定直接暴露给 Pod。例如，ConfigMap 可以保存系统中其他组件要使用 的配置数据。

ConfigMap 最常见的用法是为同一命名空间里某 Pod 中运行的容器执行配置。 你也可以单独使用 ConfigMap。

比如，你可能会遇到基于 ConfigMap 来调整其行为的 插件 或者 operator。

在 Pod 中将 ConfigMap 当做文件使用

  1. 创建一个 ConfigMap 对象或者使用现有的 ConfigMap 对象。多个 Pod 可以引用同一个 ConfigMap。
  2. 修改 Pod 定义，在 spec.volumes[] 下添加一个卷。 为该卷设置任意名称，之后将 spec.volumes[].configMap.name 字段设置为对 你的 ConfigMap 对象的引用。
  3. 为每个需要该 ConfigMap 的容器添加一个 .spec.containers[].volumeMounts[]。 设置 .spec.containers[].volumeMounts[].readOnly=true 并将 .spec.containers[].volumeMounts[].mountPath 设置为一个未使用的目录名， ConfigMap 的内容将出现在该目录中。
  4. 更改你的镜像或者命令行，以便程序能够从该目录中查找文件。ConfigMap 中的每个 data 键会变成 mountPath 下面的一个文件名。

下面是一个将 ConfigMap 以卷的形式进行挂载的 Pod 示例：

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: mypod
    image: redis
    volumeMounts:
    - name: foo
      mountPath: "/etc/foo"
      readOnly: true
  volumes:
  - name: foo
    configMap:
      name: myconfigmap

你希望使用的每个 ConfigMap 都需要在 spec.volumes 中被引用到。

如果 Pod 中有多个容器，则每个容器都需要自己的 volumeMounts 块，但针对 每个 ConfigMap，你只需要设置一个 spec.volumes 块。

被挂载的 ConfigMap 内容会被自动更新

当卷中使用的 ConfigMap 被更新时，所投射的键最终也会被更新。 kubelet 组件会在每次周期性同步时检查所挂载的 ConfigMap 是否为最新。 不过，kubelet 使用的是其本地的高速缓存来获得 ConfigMap 的当前值。 高速缓存的类型可以通过 KubeletConfiguration 结构 的 ConfigMapAndSecretChangeDetectionStrategy 字段来配置。

ConfigMap 既可以通过 watch 操作实现内容传播（默认形式），也可实现基于 TTL 的缓存，还可以直接经过所有请求重定向到 API 服务器。 因此，从 ConfigMap 被更新的那一刻算起，到新的主键被投射到 Pod 中去，这一 时间跨度可能与 kubelet 的同步周期加上高速缓存的传播延迟相等。 这里的传播延迟取决于所选的高速缓存类型 （分别对应 watch 操作的传播延迟、高速缓存的 TTL 时长或者 0）。

以环境变量方式使用的 ConfigMap 数据不会被自动更新。 更新这些数据需要重新启动 Pod。

不可变更的 ConfigMap

FEATURE STATE: Kubernetes v1.21 [stable]

Kubernetes 特性 不可变更的 Secret 和 ConfigMap 提供了一种将各个 Secret 和 ConfigMap 设置为不可变更的选项。对于大量使用 ConfigMap 的 集群（至少有数万个各不相同的 ConfigMap 给 Pod 挂载）而言，禁止更改 ConfigMap 的数据有以下好处：

  • 保护应用，使之免受意外（不想要的）更新所带来的负面影响。
  • 通过大幅降低对 kube-apiserver 的压力提升集群性能，这是因为系统会关闭 对已标记为不可变更的 ConfigMap 的监视操作。

此功能特性由 ImmutableEphemeralVolumes 特性门控 来控制。你可以通过将 immutable 字段设置为 true 创建不可变更的 ConfigMap。 例如：

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

一旦某 ConfigMap 被标记为不可变更，则 无法 逆转这一变化，，也无法更改 data 或 binaryData 字段的内容。你只能删除并重建 ConfigMap。 因为现有的 Pod 会维护一个对已删除的 ConfigMap 的挂载点，建议重新创建 这些 Pods。

接下来

3 - Secret

Secret 对象类型用来保存敏感信息，例如密码、OAuth 令牌和 SSH 密钥。 将这些信息放在 secret 中比放在 Pod 的定义或者 容器镜像 中来说更加安全和灵活。 参阅 Secret 设计文档 获取更多详细信息。

Secret 是一种包含少量敏感信息例如密码、令牌或密钥的对象。 这样的信息可能会被放在 Pod 规约中或者镜像中。 用户可以创建 Secret，同时系统也创建了一些 Secret。

注意：

Kubernetes Secret 默认情况下存储为 base64-编码的、非加密的字符串。 默认情况下，能够访问 API 的任何人，或者能够访问 Kubernetes 下层数据存储（etcd） 的任何人都可以以明文形式读取这些数据。 为了能够安全地使用 Secret，我们建议你（至少）：

  1. 为 Secret 启用静态加密；
  2. 启用 或配置 RBAC 规则来限制对 Secret 的读写操作。 要注意，任何被允许创建 Pod 的人都默认地具有读取 Secret 的权限。

Secret 概览

要使用 Secret，Pod 需要引用 Secret。 Pod 可以用三种方式之一来使用 Secret：

Secret 对象的名称必须是合法的 DNS 子域名。 在为创建 Secret 编写配置文件时，你可以设置 data 与/或 stringData 字段。 data 和 stringData 字段都是可选的。data 字段中所有键值都必须是 base64 编码的字符串。如果不希望执行这种 base64 字符串的转换操作，你可以选择设置 stringData 字段，其中可以使用任何字符串作为其取值。

Secret 的类型

在创建 Secret 对象时，你可以使用 Secret 资源的 type 字段，或者与其等价的 kubectl 命令行参数（如果有的话）为其设置类型。 Secret 的类型用来帮助编写程序处理 Secret 数据。

Kubernetes 提供若干种内置的类型，用于一些常见的使用场景。 针对这些类型，Kubernetes 所执行的合法性检查操作以及对其所实施的限制各不相同。

内置类型用法
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 对象的 type 字段设置一个非空的字符串值，你也可以定义并使用自己 Secret 类型。如果 type 值为空字符串，则被视为 Opaque 类型。 Kubernetes 并不对类型的名称作任何限制。不过，如果你要使用内置类型之一， 则你必须满足为该类型所定义的所有要求。

Opaque Secret

当 Secret 配置文件中未作显式设定时，默认的 Secret 类型是 Opaque。 当你使用 kubectl 来创建一个 Secret 时，你会使用 generic 子命令来标明 要创建的是一个 Opaque 类型 Secret。 例如，下面的命令会创建一个空的 Opaque 类型 Secret 对象：

kubectl create secret generic empty-secret
kubectl get secret empty-secret

输出类似于

NAME           TYPE     DATA   AGE
empty-secret   Opaque   0      2m6s

DATA 列显示 Secret 中保存的数据条目个数。 在这个例子种，0 意味着我们刚刚创建了一个空的 Secret。

服务账号令牌 Secret

类型为 kubernetes.io/service-account-token 的 Secret 用来存放标识某 服务账号的令牌。使用这种 Secret 类型时，你需要确保对象的注解 kubernetes.io/service-account-name 被设置为某个已有的服务账号名称。 某个 Kubernetes 控制器会填写 Secret 的其它字段，例如 kubernetes.io/service-account.uid 注解以及 data 字段中的 token 键值，使之包含实际的令牌内容。

下面的配置实例声明了一个服务账号令牌 Secret：

apiVersion: v1
kind: Secret
metadata:
  name: secret-sa-sample
  annotations:
    kubernetes.io/service-account.name: "sa-name"
type: kubernetes.io/service-account-token
data:
  # 你可以像 Opaque Secret 一样在这里添加额外的键/值偶对
  extra: YmFyCg==

Kubernetes 在创建 Pod 时会自动创建一个服务账号 Secret 并自动修改你的 Pod 以使用该 Secret。该服务账号令牌 Secret 中包含了访问 Kubernetes API 所需要的凭据。

如果需要，可以禁止或者重载这种自动创建并使用 API 凭据的操作。 不过，如果你仅仅是希望能够安全地访问 API 服务器，这是建议的工作方式。

参考 ServiceAccount 文档了解服务账号的工作原理。你也可以查看 Pod 资源中的 automountServiceAccountToken 和 serviceAccountName 字段文档，了解 从 Pod 中引用服务账号。

Docker 配置 Secret

你可以使用下面两种 type 值之一来创建 Secret，用以存放访问 Docker 仓库 来下载镜像的凭据。

  • kubernetes.io/dockercfg
  • kubernetes.io/dockerconfigjson

kubernetes.io/dockercfg 是一种保留类型，用来存放 ~/.dockercfg 文件的 序列化形式。该文件是配置 Docker 命令行的一种老旧形式。 使用此 Secret 类型时，你需要确保 Secret 的 data 字段中包含名为 .dockercfg 的主键，其对应键值是用 base64 编码的某 ~/.dockercfg 文件的内容。

类型 kubernetes.io/dockerconfigjson 被设计用来保存 JSON 数据的序列化形式， 该 JSON 也遵从 ~/.docker/config.json 文件的格式规则，而后者是 ~/.dockercfg 的新版本格式。 使用此 Secret 类型时，Secret 对象的 data 字段必须包含 .dockerconfigjson 键，其键值为 base64 编码的字符串包含 ~/.docker/config.json 文件的内容。

下面是一个 kubernetes.io/dockercfg 类型 Secret 的示例：

apiVersion: v1
kind: Secret
metadata:
  name: secret-dockercfg
type: kubernetes.io/dockercfg
data:
  .dockercfg: |
        "<base64 encoded ~/.dockercfg file>"
说明：

如果你不希望执行 base64 编码转换，可以使用 stringData 字段代替。

当你使用清单文件来创建这两类 Secret 时，API 服务器会检查 data 字段中是否 存在所期望的主键，并且验证其中所提供的键值是否是合法的 JSON 数据。 不过，API 服务器不会检查 JSON 数据本身是否是一个合法的 Docker 配置文件内容。

kubectl create secret docker-registry secret-tiger-docker \
  --docker-username=tiger \
  --docker-password=pass113 \
  --docker-email=tiger@acme.com

上面的命令创建一个类型为 kubernetes.io/dockerconfigjson 的 Secret。 如果你对 data 字段中的 .dockerconfigjson 内容进行转储，你会得到下面的 JSON 内容，而这一内容是一个合法的 Docker 配置文件。

{
  "auths": {
    "https://index.docker.io/v1/": {
      "username": "tiger",
      "password": "pass113",
      "email": "tiger@acme.com",
      "auth": "dGlnZXI6cGFzczExMw=="
    }
  }
}

基本身份认证 Secret

kubernetes.io/basic-auth 类型用来存放用于基本身份认证所需的凭据信息。 使用这种 Secret 类型时，Secret 的 data 字段必须包含以下两个键：

  • username: 用于身份认证的用户名；
  • password: 用于身份认证的密码或令牌。

以上两个键的键值都是 base64 编码的字符串。 当然你也可以在创建 Secret 时使用 stringData 字段来提供明文形式的内容。 下面的 YAML 是基本身份认证 Secret 的一个示例清单：

apiVersion: v1
kind: Secret
metadata:
  name: secret-basic-auth
type: kubernetes.io/basic-auth
stringData:
  username: admin
  password: t0p-Secret

提供基本身份认证类型的 Secret 仅仅是出于用户方便性考虑。 你也可以使用 Opaque 类型来保存用于基本身份认证的凭据。 不过，使用内置的 Secret 类型的有助于对凭据格式进行归一化处理，并且 API 服务器确实会检查 Secret 配置中是否提供了所需要的主键。

SSH 身份认证 Secret

Kubernetes 所提供的内置类型 kubernetes.io/ssh-auth 用来存放 SSH 身份认证中 所需要的凭据。使用这种 Secret 类型时，你就必须在其 data （或 stringData） 字段中提供一个 ssh-privatekey 键值对，作为要使用的 SSH 凭据。

下面的 YAML 是一个 SSH 身份认证 Secret 的配置示例：

apiVersion: v1
kind: Secret
metadata:
  name: secret-ssh-auth
type: kubernetes.io/ssh-auth
data:
  # 此例中的实际数据被截断
  ssh-privatekey: |
          MIIEpQIBAAKCAQEAulqb/Y ...

提供 SSH 身份认证类型的 Secret 仅仅是出于用户方便性考虑。 你也可以使用 Opaque 类型来保存用于 SSH 身份认证的凭据。 不过，使用内置的 Secret 类型的有助于对凭据格式进行归一化处理，并且 API 服务器确实会检查 Secret 配置中是否提供了所需要的主键。

注意： SSH 私钥自身无法建立 SSH 客户端与服务器端之间的可信连接。 需要其它方式来建立这种信任关系，以缓解“中间人（Man In The Middle）” 攻击，例如向 ConfigMap 中添加一个 known_hosts 文件。

TLS Secret

Kubernetes 提供一种内置的 kubernetes.io/tls Secret 类型，用来存放证书 及其相关密钥（通常用在 TLS 场合）。 此类数据主要提供给 Ingress 资源，用以终结 TLS 链接，不过也可以用于其他 资源或者负载。当使用此类型的 Secret 时，Secret 配置中的 data （或 stringData）字段必须包含 tls.key 和 tls.crt 主键，尽管 API 服务器 实际上并不会对每个键的取值作进一步的合法性检查。

下面的 YAML 包含一个 TLS Secret 的配置示例：

apiVersion: v1
kind: Secret
metadata:
  name: secret-tls
type: kubernetes.io/tls
data:
  # 此例中的数据被截断
  tls.crt: |
        MIIC2DCCAcCgAwIBAgIBATANBgkqh ...
  tls.key: |
        MIIEpgIBAAKCAQEA7yn3bRHQ5FHMQ ...

提供 TLS 类型的 Secret 仅仅是出于用户方便性考虑。 你也可以使用 Opaque 类型来保存用于 TLS 服务器与/或客户端的凭据。 不过，使用内置的 Secret 类型的有助于对凭据格式进行归一化处理，并且 API 服务器确实会检查 Secret 配置中是否提供了所需要的主键。

当使用 kubectl 来创建 TLS Secret 时，你可以像下面的例子一样使用 tls 子命令：

kubectl create secret tls my-tls-secret \
  --cert=path/to/cert/file \
  --key=path/to/key/file

这里的公钥/私钥对都必须事先已存在。用于 --cert 的公钥证书必须是 .PEM 编码的 （Base64 编码的 DER 格式），且与 --key 所给定的私钥匹配。 私钥必须是通常所说的 PEM 私钥格式，且未加密。对这两个文件而言，PEM 格式数据 的第一行和最后一行（例如，证书所对应的 --------BEGIN CERTIFICATE----- 和 -------END CERTIFICATE----）都不会包含在其中。

启动引导令牌 Secret

通过将 Secret 的 type 设置为 bootstrap.kubernetes.io/token 可以创建 启动引导令牌类型的 Secret。这种类型的 Secret 被设计用来支持节点的启动引导过程。 其中包含用来为周知的 ConfigMap 签名的令牌。

启动引导令牌 Secret 通常创建于 kube-system 名字空间内，并以 bootstrap-token-<令牌 ID> 的形式命名；其中 <令牌 ID> 是一个由 6 个字符组成 的字符串，用作令牌的标识。

以 Kubernetes 清单文件的形式，某启动引导令牌 Secret 可能看起来像下面这样：

apiVersion: v1
kind: Secret
metadata:
  name: bootstrap-token-5emitj
  namespace: kube-system
type: bootstrap.kubernetes.io/token
data:
  auth-extra-groups: c3lzdGVtOmJvb3RzdHJhcHBlcnM6a3ViZWFkbTpkZWZhdWx0LW5vZGUtdG9rZW4=
  expiration: MjAyMC0wOS0xM1QwNDozOToxMFo=
  token-id: NWVtaXRq
  token-secret: a3E0Z2lodnN6emduMXAwcg==
  usage-bootstrap-authentication: dHJ1ZQ==
  usage-bootstrap-signing: dHJ1ZQ==

启动引导令牌类型的 Secret 会在 data 字段中包含如下主键：

  • token-id：由 6 个随机字符组成的字符串，作为令牌的标识符。必需。
  • token-secret：由 16 个随机字符组成的字符串，包含实际的令牌机密。必需。
  • description：供用户阅读的字符串，描述令牌的用途。可选。
  • expiration：一个使用 RFC3339 来编码的 UTC 绝对时间，给出令牌要过期的时间。可选。
  • usage-bootstrap-<usage>：布尔类型的标志，用来标明启动引导令牌的其他用途。
  • auth-extra-groups：用逗号分隔的组名列表，身份认证时除被认证为 system:bootstrappers 组之外，还会被添加到所列的用户组中。

上面的 YAML 文件可能看起来令人费解，因为其中的数值均为 base64 编码的字符串。 实际上，你完全可以使用下面的 YAML 来创建一个一模一样的 Secret：

apiVersion: v1
kind: Secret
metadata:
  # 注意 Secret 的命名方式
  name: bootstrap-token-5emitj
  # 启动引导令牌 Secret 通常位于 kube-system 名字空间
  namespace: kube-system
type: bootstrap.kubernetes.io/token
stringData:
  auth-extra-groups: "system:bootstrappers:kubeadm:default-node-token"
  expiration: "2020-09-13T04:39:10Z"
  # 此令牌 ID 被用于生成 Secret 名称
  token-id: "5emitj"
  token-secret: "kq4gihvszzgn1p0r"
  # 此令牌还可用于 authentication （身份认证）
  usage-bootstrap-authentication: "true"
  # 且可用于 signing （证书签名）
  usage-bootstrap-signing: "true"

创建 Secret

有几种不同的方式来创建 Secret：

编辑 Secret

你可以通过下面的命令编辑现有的 Secret：

kubectl edit secrets mysecret

这一命令会打开默认的编辑器，允许你更新 data 字段中包含的 base64 编码的 Secret 值：

# Please edit the object below. Lines beginning with a '#' will be ignored,
# and an empty file will abort the edit. If an error occurs while saving this file will be
# reopened with the relevant failures.
#
apiVersion: v1
data:
  username: YWRtaW4=
  password: MWYyZDFlMmU2N2Rm
kind: Secret
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: { ... }
  creationTimestamp: 2016-01-22T18:41:56Z
  name: mysecret
  namespace: default
  resourceVersion: "164619"
  uid: cfee02d6-c137-11e5-8d73-42010af00002
type: Opaque

使用 Secret

Secret 可以作为数据卷被挂载，或作为环境变量 暴露出来以供 Pod 中的容器使用。它们也可以被系统的其他部分使用，而不直接暴露在 Pod 内。 例如，它们可以保存凭据，系统的其他部分将用它来代表你与外部系统进行交互。

在 Pod 中使用 Secret 文件

在 Pod 中使用存放在卷中的 Secret：

  1. 创建一个 Secret 或者使用已有的 Secret。多个 Pod 可以引用同一个 Secret。
  2. 修改你的 Pod 定义，在 spec.volumes[] 下增加一个卷。可以给这个卷随意命名， 它的 spec.volumes[].secret.secretName 必须是 Secret 对象的名字。
  3. 将 spec.containers[].volumeMounts[] 加到需要用到该 Secret 的容器中。 指定 spec.containers[].volumeMounts[].readOnly = true 和 spec.containers[].volumeMounts[].mountPath 为你想要该 Secret 出现的尚未使用的目录。
  4. 修改你的镜像并且／或者命令行，让程序从该目录下寻找文件。 Secret 的 data 映射中的每一个键都对应 mountPath 下的一个文件名。

这是一个在 Pod 中使用存放在挂载卷中 Secret 的例子：

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: mypod
    image: redis
    volumeMounts:
    - name: foo
      mountPath: "/etc/foo"
      readOnly: true
  volumes:
  - name: foo
    secret:
      secretName: mysecret

您想要用的每个 Secret 都需要在 spec.volumes 中引用。

如果 Pod 中有多个容器，每个容器都需要自己的 volumeMounts 配置块， 但是每个 Secret 只需要一个 spec.volumes。

您可以打包多个文件到一个 Secret 中，或者使用的多个 Secret，怎样方便就怎样来。

将 Secret 键名映射到特定路径

我们还可以控制 Secret 键名在存储卷中映射的的路径。 你可以使用 spec.volumes[].secret.items 字段修改每个键对应的目标路径：

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: mypod
    image: redis
    volumeMounts:
    - name: foo
      mountPath: "/etc/foo"
      readOnly: true
  volumes:
  - name: foo
    secret:
      secretName: mysecret
      items:
      - key: username
        path: my-group/my-username

将会发生什么呢：

  • username Secret 存储在 /etc/foo/my-group/my-username 文件中而不是 /etc/foo/username 中。
  • password Secret 没有被映射

如果使用了 spec.volumes[].secret.items，只有在 items 中指定的键会被映射。 要使用 Secret 中所有键，就必须将它们都列在 items 字段中。 所有列出的键名必须存在于相应的 Secret 中。否则，不会创建卷。

Secret 文件权限

你还可以指定 Secret 将拥有的权限模式位。如果不指定，默认使用 0644。 你可以为整个 Secret 卷指定默认模式；如果需要，可以为每个密钥设定重载值。

例如，您可以指定如下默认模式：

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: mypod
    image: redis
    volumeMounts:
    - name: foo
      mountPath: "/etc/foo"
  volumes:
  - name: foo
    secret:
      secretName: mysecret
      defaultMode: 256

之后，Secret 将被挂载到 /etc/foo 目录，而所有通过该 Secret 卷挂载 所创建的文件的权限都是 0400。

请注意，JSON 规范不支持八进制符号，因此使用 256 值作为 0400 权限。 如果你使用 YAML 而不是 JSON，则可以使用八进制符号以更自然的方式指定权限。

注意，如果你通过 kubectl exec 进入到 Pod 中，你需要沿着符号链接来找到 所期望的文件模式。例如，下面命令检查 Secret 文件的访问模式：

kubectl exec mypod -it sh

cd /etc/foo
ls -l

输出类似于：

total 0
lrwxrwxrwx 1 root root 15 May 18 00:18 password -> ..data/password
lrwxrwxrwx 1 root root 15 May 18 00:18 username -> ..data/username

沿着符号链接，可以查看文件的访问模式：

cd /etc/foo/..data
ls -l

输出类似于：

total 8
-r-------- 1 root root 12 May 18 00:18 password
-r-------- 1 root root  5 May 18 00:18 username

你还可以使用映射，如上一个示例，并为不同的文件指定不同的权限，如下所示：

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: mypod
    image: redis
    volumeMounts:
    - name: foo
      mountPath: "/etc/foo"
  volumes:
  - name: foo
    secret:
      secretName: mysecret
      items:
      - key: username
        path: my-group/my-username
        mode: 511

在这里，位于 /etc/foo/my-group/my-username 的文件的权限值为 0777。 由于 JSON 限制，必须以十进制格式指定模式，即 511。

请注意，如果稍后读取此权限值，可能会以十进制格式显示。

使用来自卷中的 Secret 值

在挂载了 Secret 卷的容器内，Secret 键名显示为文件名，并且 Secret 的值 使用 base-64 解码后存储在这些文件中。 这是在上面的示例容器内执行的命令的结果：

ls /etc/foo/

输出类似于：

username
password

cat /etc/foo/username

输出类似于：

admin

cat /etc/foo/password

输出类似于：

1f2d1e2e67df

容器中的程序负责从文件中读取 secret。

挂载的 Secret 会被自动更新

当已经存储于卷中被使用的 Secret 被更新时，被映射的键也将终将被更新。 组件 kubelet 在周期性同步时检查被挂载的 Secret 是不是最新的。 但是，它会使用其本地缓存的数值作为 Secret 的当前值。

缓存的类型可以使用 KubeletConfiguration 结构 中的 ConfigMapAndSecretChangeDetectionStrategy 字段来配置。 它可以通过 watch 操作来传播（默认），基于 TTL 来刷新，也可以 将所有请求直接重定向到 API 服务器。 因此，从 Secret 被更新到将新 Secret 被投射到 Pod 的那一刻的总延迟可能与 kubelet 同步周期 + 缓存传播延迟一样长，其中缓存传播延迟取决于所选的缓存类型。 对应于不同的缓存类型，该延迟或者等于 watch 传播延迟，或者等于缓存的 TTL， 或者为 0。

说明： 使用 Secret 作为子路径卷挂载的容器 不会收到 Secret 更新。

以环境变量的形式使用 Secrets

将 Secret 作为 Pod 中的环境变量使用：

  1. 创建一个 Secret 或者使用一个已存在的 Secret。多个 Pod 可以引用同一个 Secret。
  2. 修改 Pod 定义，为每个要使用 Secret 的容器添加对应 Secret 键的环境变量。 使用 Secret 键的环境变量应在 env[x].valueFrom.secretKeyRef 中指定 要包含的 Secret 名称和键名。
  3. 更改镜像并／或者命令行，以便程序在指定的环境变量中查找值。

这是一个使用来自环境变量中的 Secret 值的 Pod 示例：

apiVersion: v1
kind: Pod
metadata:
  name: secret-env-pod
spec:
  containers:
  - name: mycontainer
    image: redis
    env:
      - name: SECRET_USERNAME
        valueFrom:
          secretKeyRef:
            name: mysecret
            key: username
      - name: SECRET_PASSWORD
        valueFrom:
          secretKeyRef:
            name: mysecret
            key: password
  restartPolicy: Never

使用来自环境变量的 Secret 值

在一个以环境变量形式使用 Secret 的容器中，Secret 键表现为常规的环境变量，其中 包含 Secret 数据的 base-64 解码值。这是从上面的示例在容器内执行的命令的结果：

echo $SECRET_USERNAME

输出类似于：

admin

echo $SECRET_PASSWORD

输出类似于：

1f2d1e2e67df

Secret 更新之后对应的环境变量不会被更新

如果某个容器已经在通过环境变量使用某 Secret，对该 Secret 的更新不会被 容器马上看见，除非容器被重启。有一些第三方的解决方案能够在 Secret 发生 变化时触发容器重启。

不可更改的 Secret

FEATURE STATE: Kubernetes v1.21 [stable]

Kubernetes 的特性 不可变的 Secret 和 ConfigMap 提供了一种可选配置， 可以设置各个 Secret 和 ConfigMap 为不可变的。 对于大量使用 Secret 的集群（至少有成千上万各不相同的 Secret 供 Pod 挂载）， 禁止变更它们的数据有下列好处：

  • 防止意外（或非预期的）更新导致应用程序中断
  • 通过将 Secret 标记为不可变来关闭 kube-apiserver 对其的监视，从而显著降低 kube-apiserver 的负载，提升集群性能。

这个特性通过 ImmutableEmphemeralVolumes 特性门控 来控制，从 v1.19 开始默认启用。 你可以通过将 Secret 的 immutable 字段设置为 true 创建不可更改的 Secret。 例如：

apiVersion: v1
kind: Secret
metadata:
  ...
data:
  ...
immutable: true
说明：

一旦一个 Secret 或 ConfigMap 被标记为不可更改，撤销此操作或者更改 data 字段的内容都是 不 可能的。 只能删除并重新创建这个 Secret。现有的 Pod 将维持对已删除 Secret 的挂载点 - 建议重新创建这些 Pod。

使用 imagePullSecret

imagePullSecrets 字段中包含一个列表，列举对同一名字空间中的 Secret 的引用。 你可以使用 imagePullSecrets 将包含 Docker（或其他）镜像仓库密码的 Secret 传递给 kubelet。kubelet 使用此信息来替你的 Pod 拉取私有镜像。 关于 imagePullSecrets 字段的更多信息，请参考 PodSpec API 文档。

手动指定 imagePullSecret

你可以阅读容器镜像文档 以了解如何设置 imagePullSecrets。

设置自动附加 imagePullSecrets

您可以手动创建 imagePullSecret，并在 ServiceAccount 中引用它。 使用该 ServiceAccount 创建的任何 Pod 和默认使用该 ServiceAccount 的 Pod 将会将其的 imagePullSecret 字段设置为服务帐户的 imagePullSecret 值。 有关该过程的详细说明，请参阅 将 ImagePullSecrets 添加到服务帐户。

详细说明

限制

Kubernetes 会验证 Secret 作为卷来源时所给的对象引用确实指向一个类型为 Secret 的对象。因此，Secret 需要先于任何依赖于它的 Pod 创建。

Secret API 对象处于某名字空间 中。它们只能由同一命名空间中的 Pod 引用。

每个 Secret 的大小限制为 1MB。这是为了防止创建非常大的 Secret 导致 API 服务器 和 kubelet 的内存耗尽。然而，创建过多较小的 Secret 也可能耗尽内存。 更全面得限制 Secret 内存用量的功能还在计划中。

kubelet 仅支持从 API 服务器获得的 Pod 使用 Secret。 这包括使用 kubectl 创建的所有 Pod，以及间接通过副本控制器创建的 Pod。 它不包括通过 kubelet --manifest-url 标志，--config 标志或其 REST API 创建的 Pod（这些不是创建 Pod 的常用方法）。

以环境变量形式在 Pod 中使用 Secret 之前必须先创建 Secret，除非该环境变量被标记为可选的。 Pod 中引用不存在的 Secret 时将无法启动。

使用 secretKeyRef 时，如果引用了指定 Secret 不存在的键，对应的 Pod 也无法启动。

对于通过 envFrom 填充环境变量的 Secret，如果 Secret 中包含的键名无法作为 合法的环境变量名称，对应的键会被跳过，该 Pod 将被允许启动。 不过这时会产生一个事件，其原因为 InvalidVariableNames，其消息中包含被跳过的无效键的列表。 下面的示例显示一个 Pod，它引用了包含 2 个无效键 1badkey 和 2alsobad。

kubectl get events

输出类似于：

LASTSEEN   FIRSTSEEN   COUNT     NAME            KIND      SUBOBJECT                         TYPE      REASON
0s         0s          1         dapi-test-pod   Pod                                         Warning   InvalidEnvironmentVariableNames   kubelet, 127.0.0.1      Keys [1badkey, 2alsobad] from the EnvFrom secret default/mysecret were skipped since they are considered invalid environment variable names.

Secret 与 Pod 生命周期的关系

通过 API 创建 Pod 时，不会检查引用的 Secret 是否存在。一旦 Pod 被调度，kubelet 就会尝试获取该 Secret 的值。如果获取不到该 Secret，或者暂时无法与 API 服务器建立连接， kubelet 将会定期重试。kubelet 将会报告关于 Pod 的事件，并解释它无法启动的原因。 一旦获取到 Secret，kubelet 将创建并挂载一个包含它的卷。在 Pod 的所有卷被挂载之前， Pod 中的容器不会启动。

使用案例

案例：以环境变量的形式使用 Secret

创建一个 Secret 定义：

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
data:
  USER_NAME: YWRtaW4=
  PASSWORD: MWYyZDFlMmU2N2Rm

生成 Secret 对象：

kubectl apply -f mysecret.yaml

使用 envFrom 将 Secret 的所有数据定义为容器的环境变量。 Secret 中的键名称为 Pod 中的环境变量名称：

apiVersion: v1
kind: Pod
metadata:
  name: secret-test-pod
spec:
  containers:
    - name: test-container
      image: k8s.gcr.io/busybox
      command: [ "/bin/sh", "-c", "env" ]
      envFrom:
      - secretRef:
          name: mysecret
  restartPolicy: Never

案例：包含 SSH 密钥的 Pod

创建一个包含 SSH 密钥的 Secret：

kubectl create secret generic ssh-key-secret \
  --from-file=ssh-privatekey=/path/to/.ssh/id_rsa \
  --from-file=ssh-publickey=/path/to/.ssh/id_rsa.pub

输出类似于：

secret "ssh-key-secret" created

你也可以创建一个带有包含 SSH 密钥的 secretGenerator 字段的 kustomization.yaml 文件。

注意： 发送自己的 SSH 密钥之前要仔细思考：集群的其他用户可能有权访问该密钥。 你可以使用一个服务帐户，分享给 Kubernetes 集群中合适的用户，这些用户是你要分享的。 如果服务账号遭到侵犯，可以将其收回。

现在我们可以创建一个 Pod，令其引用包含 SSH 密钥的 Secret，并通过存储卷来使用它：

apiVersion: v1
kind: Pod
metadata:
  name: secret-test-pod
  labels:
    name: secret-test
spec:
  volumes:
  - name: secret-volume
    secret:
      secretName: ssh-key-secret
  containers:
  - name: ssh-test-container
    image: mySshImage
    volumeMounts:
    - name: secret-volume
      readOnly: true
      mountPath: "/etc/secret-volume"

容器中的命令运行时，密钥的片段可以在以下目录找到：

/etc/secret-volume/ssh-publickey
/etc/secret-volume/ssh-privatekey

然后容器可以自由使用 Secret 数据建立一个 SSH 连接。

案例：包含生产/测试凭据的 Pod

下面的例子展示的是两个 Pod。 一个 Pod 使用包含生产环境凭据的 Secret，另一个 Pod 使用包含测试环境凭据的 Secret。

你可以创建一个带有 secretGenerator 字段的 kustomization.yaml 文件，或者执行 kubectl create secret：

kubectl create secret generic prod-db-secret \
  --from-literal=username=produser \
  --from-literal=password=Y4nys7f11

输出类似于：

secret "prod-db-secret" created

kubectl create secret generic test-db-secret \
  --from-literal=username=testuser \
  --from-literal=password=iluvtests

输出类似于：

secret "test-db-secret" created
说明：

特殊字符（例如 $、\、*、= 和 !）会被你的 Shell解释，因此需要转义。 在大多数 Shell 中，对密码进行转义的最简单方式是用单引号（'）将其括起来。 例如，如果您的实际密码是 S!B\*d$zDsb，则应通过以下方式执行命令：

kubectl create secret generic dev-db-secret --from-literal=username=devuser --from-literal=password='S!B\*d$zDsb='

您无需对文件中的密码（--from-file）中的特殊字符进行转义。

创建 pod ：

$ cat <<EOF > pod.yaml
apiVersion: v1
kind: List
items:
- kind: Pod
  apiVersion: v1
  metadata:
    name: prod-db-client-pod
    labels:
      name: prod-db-client
  spec:
    volumes:
    - name: secret-volume
      secret:
        secretName: prod-db-secret
    containers:
    - name: db-client-container
      image: myClientImage
      volumeMounts:
      - name: secret-volume
        readOnly: true
        mountPath: "/etc/secret-volume"
- kind: Pod
  apiVersion: v1
  metadata:
    name: test-db-client-pod
    labels:
      name: test-db-client
  spec:
    volumes:
    - name: secret-volume
      secret:
        secretName: test-db-secret
    containers:
    - name: db-client-container
      image: myClientImage
      volumeMounts:
      - name: secret-volume
        readOnly: true
        mountPath: "/etc/secret-volume"
EOF

将 Pod 添加到同一个 kustomization.yaml 文件

$ cat <<EOF >> kustomization.yaml
resources:
- pod.yaml
EOF

通过下面的命令应用所有对象

kubectl apply -k .

两个容器都会在其文件系统上存在以下文件，其中包含容器对应的环境的值：

/etc/secret-volume/username
/etc/secret-volume/password

请注意，两个 Pod 的规约配置中仅有一个字段不同；这有助于使用共同的 Pod 配置模板创建 具有不同能力的 Pod。

您可以使用两个服务账号进一步简化基本的 Pod 规约：

  1. 名为 prod-user 的服务账号拥有 prod-db-secret
  2. 名为 test-user 的服务账号拥有 test-db-secret

然后，Pod 规约可以缩短为：

apiVersion: v1
kind: Pod
metadata:
  name: prod-db-client-pod
  labels:
    name: prod-db-client
spec:
  serviceAccount: prod-db-client
  containers:
  - name: db-client-container
    image: myClientImage

案例：Secret 卷中以句点号开头的文件

你可以通过定义以句点开头的键名，将数据“隐藏”起来。 例如，当如下 Secret 被挂载到 secret-volume 卷中：

apiVersion: v1
kind: Secret
metadata:
  name: dotfile-secret
data:
  .secret-file: dmFsdWUtMg0KDQo=
---
apiVersion: v1
kind: Pod
metadata:
  name: secret-dotfiles-pod
spec:
  volumes:
  - name: secret-volume
    secret:
      secretName: dotfile-secret
  containers:
  - name: dotfile-test-container
    image: k8s.gcr.io/busybox
    command:
    - ls
    - "-l"
    - "/etc/secret-volume"
    volumeMounts:
    - name: secret-volume
      readOnly: true
      mountPath: "/etc/secret-volume"

卷中将包含唯一的叫做 .secret-file 的文件。 容器 dotfile-test-container 中，该文件处于 /etc/secret-volume/.secret-file 路径下。

说明： 以点号开头的文件在 ls -l 的输出中会被隐藏起来； 列出目录内容时，必须使用 ls -la 才能看到它们。

案例：Secret 仅对 Pod 中的一个容器可见

考虑一个需要处理 HTTP 请求、执行一些复杂的业务逻辑，然后使用 HMAC 签署一些消息的应用。 因为应用程序逻辑复杂，服务器中可能会存在一个未被注意的远程文件读取漏洞， 可能会将私钥暴露给攻击者。

解决的办法可以是将应用分为两个进程，分别运行在两个容器中： 前端容器，用于处理用户交互和业务逻辑，但无法看到私钥； 签名容器，可以看到私钥，响应来自前端（例如通过本地主机网络）的简单签名请求。

使用这种分割方法，攻击者现在必须欺骗应用程序服务器才能进行任意的操作， 这可能比使其读取文件更难。

最佳实践

客户端使用 Secret API

当部署与 Secret API 交互的应用程序时，应使用 鉴权策略， 例如 RBAC，来限制访问。

Secret 中的值对于不同的环境来说重要性可能不同。 很多 Secret 都可能导致 Kubernetes 集群内部的权限越界（例如服务账号令牌） 甚至逃逸到集群外部。 即使某一个应用程序可以就所交互的 Secret 的能力作出正确抉择，但是同一命名空间中 的其他应用程序却可能不这样做。

由于这些原因，在命名空间中 watch 和 list Secret 的请求是非常强大的能力， 是应该避免的行为。列出 Secret 的操作可以让客户端检查该命名空间中存在的所有 Secret。 在群集中 watch 和 list 所有 Secret 的能力应该只保留给特权最高的系统级组件。

需要访问 Secret API 的应用程序应该针对所需要的 Secret 执行 get 请求。 这样，管理员就能限制对所有 Secret 的访问，同时为应用所需要的 实例设置访问允许清单 。

为了获得高于轮询操作的性能，客户端设计资源时，可以引用 Secret，然后对资源执行 watch 操作，在引用更改时重新检索 Secret。 此外，社区还存在一种 “批量监控” API 的提案，允许客户端 watch 独立的资源，该功能可能会在将来的 Kubernetes 版本中提供。

安全属性

保护

因为 Secret 对象可以独立于使用它们的 Pod 而创建，所以在创建、查看和编辑 Pod 的流程中 Secret 被暴露的风险较小。系统还可以对 Secret 对象采取额外的预防性保护措施， 例如，在可能的情况下避免将其写到磁盘。

只有当某节点上的 Pod 需要用到某 Secret 时，该 Secret 才会被发送到该节点上。 Secret 不会被写入磁盘，而是被 kubelet 存储在 tmpfs 中。 一旦依赖于它的 Pod 被删除，Secret 数据的本地副本就被删除。

同一节点上的很多个 Pod 可能拥有多个 Secret。 但是，只有 Pod 所请求的 Secret 在其容器中才是可见的。 因此，一个 Pod 不能访问另一个 Pod 的 Secret。

同一个 Pod 中可能有多个容器。但是，Pod 中的每个容器必须通过 volumeeMounts 请求挂载 Secret 卷才能使卷中的 Secret 对容器可见。 这一实现可以用于在 Pod 级别构建安全分区。

在大多数 Kubernetes 发行版中，用户与 API 服务器之间的通信以及 从 API 服务器到 kubelet 的通信都受到 SSL/TLS 的保护。 通过这些通道传输时，Secret 受到保护。

FEATURE STATE: Kubernetes v1.13 [beta]

你可以为 Secret 数据开启静态加密， 这样 Secret 数据就不会以明文形式存储到etcd 中。

风险

  • API 服务器上的 Secret 数据以纯文本的方式存储在 etcd 中，因此：
    • 管理员应该为集群数据开启静态加密（要求 v1.13 或者更高版本）。
    • 管理员应该限制只有 admin 用户能访问 etcd；
    • API 服务器中的 Secret 数据位于 etcd 使用的磁盘上；管理员可能希望在不再使用时擦除/粉碎 etcd 使用的磁盘
    • 如果 etcd 运行在集群内，管理员应该确保 etcd 之间的通信使用 SSL/TLS 进行加密。
  • 如果您将 Secret 数据编码为 base64 的清单（JSON 或 YAML）文件，共享该文件或将其检入代码库，该密码将会被泄露。 Base64 编码不是一种加密方式，应该视同纯文本。
  • 应用程序在从卷中读取 Secret 后仍然需要保护 Secret 的值，例如不会意外将其写入日志或发送给不信任方。
  • 可以创建使用 Secret 的 Pod 的用户也可以看到该 Secret 的值。即使 API 服务器策略不允许用户读取 Secret 对象，用户也可以运行 Pod 导致 Secret 暴露。
  • 目前，任何节点的 root 用户都可以通过模拟 kubelet 来读取 API 服务器中的任何 Secret。 仅向实际需要 Secret 的节点发送 Secret 数据才能限制节点的 root 账号漏洞的影响， 该功能还在计划中。

接下来

4 - 为容器管理资源

当你定义 Pod 时可以选择性地为每个 容器设定所需要的资源数量。 最常见的可设定资源是 CPU 和内存（RAM）大小；此外还有其他类型的资源。

当你为 Pod 中的 Container 指定了资源 请求 时，调度器就利用该信息决定将 Pod 调度到哪个节点上。 当你还为 Container 指定了资源 约束 时，kubelet 就可以确保运行的容器不会使用超出所设约束的资源。 kubelet 还会为容器预留所 请求 数量的系统资源，供其使用。

请求和约束

如果 Pod 运行所在的节点具有足够的可用资源，容器可能（且可以）使用超出对应资源 request 属性所设置的资源量。不过，容器不可以使用超出其资源 limit 属性所设置的资源量。

例如，如果你将容器的 memory 的请求量设置为 256 MiB，而该容器所处的 Pod 被调度到一个具有 8 GiB 内存的节点上，并且该节点上没有其他 Pods 运行，那么该容器就可以尝试使用更多的内存。

如果你将某容器的 memory 约束设置为 4 GiB，kubelet （和 容器运行时） 就会确保该约束生效。 容器运行时会禁止容器使用超出所设置资源约束的资源。 例如：当容器中进程尝试使用超出所允许内存量的资源时，系统内核会将尝试申请内存的进程终止， 并引发内存不足（OOM）错误。

约束值可以以被动方式来实现（系统会在发现违例时进行干预），或者通过强制生效的方式实现 （系统会避免容器用量超出约束值）。不同的容器运行时采用不同方式来实现相同的限制。

说明：

如果某 Container 设置了自己的内存限制但未设置内存请求，Kubernetes 自动为其设置与内存限制相匹配的请求值。类似的，如果某 Container 设置了 CPU 限制值但未设置 CPU 请求值，则 Kubernetes 自动为其设置 CPU 请求 并使之与 CPU 限制值匹配。

资源类型

CPU 和内存都是资源类型。每种资源类型具有其基本单位。 CPU 表达的是计算处理能力，其单位是 Kubernetes CPUs。 内存的单位是字节。 如果你使用的是 Kubernetes v1.14 或更高版本，则可以指定巨页（Huge Page）资源。 巨页是 Linux 特有的功能，节点内核在其中分配的内存块比默认页大小大得多。

例如，在默认页面大小为 4KiB 的系统上，你可以指定约束 hugepages-2Mi: 80Mi。 如果容器尝试分配 40 个 2MiB 大小的巨页（总共 80 MiB ），则分配请求会失败。

说明：

你不能过量使用 hugepages- * 资源。 这与 memory 和 cpu 资源不同。

CPU 和内存统称为计算资源，或简称为资源。 计算资源的数量是可测量的，可以被请求、被分配、被消耗。 它们与 API 资源 不同。 API 资源（如 Pod 和 Service）是可通过 Kubernetes API 服务器读取和修改的对象。

Pod 和 容器的资源请求和约束

Pod 中的每个容器都可以指定以下的一个或者多个值：

  • spec.containers[].resources.limits.cpu
  • spec.containers[].resources.limits.memory
  • spec.containers[].resources.limits.hugepages-<size>
  • spec.containers[].resources.requests.cpu
  • spec.containers[].resources.requests.memory
  • spec.containers[].resources.requests.hugepages-<size>

尽管请求和限制值只能在单个容器上指定，我们仍可方便地计算出 Pod 的资源请求和约束。 Pod 对特定资源类型的请求/约束值是 Pod 中各容器对该类型资源的请求/约束值的总和。

Kubernetes 中的资源单位

CPU 的含义

CPU 资源的约束和请求以 cpu 为单位。

Kubernetes 中的一个 cpu 等于云平台上的 1 个 vCPU/核和裸机 Intel 处理器上的 **1 个超线程 **。

你也可以表达带小数 CPU 的请求。spec.containers[].resources.requests.cpu 为 0.5 的 Container 肯定能够获得请求 1 CPU 的容器的一半 CPU 资源。表达式 0.1 等价于表达式 100m， 可以看作 “100 millicpu”。有些人说成是“一百毫 cpu”，其实说的是同样的事情。 具有小数点（如 0.1）的请求由 API 转换为 100m；最大精度是 1m。 因此，或许你应该优先考虑使用 100m 的形式。

CPU 总是按绝对数量来请求的，不可以使用相对数量； 0.1 的 CPU 在单核、双核、48 核的机器上的意义是一样的。

内存的含义

内存的约束和请求以字节为单位。你可以使用以下后缀之一以一般整数或定点数字形式来表示内存： E、P、T、G、M、k。你也可以使用对应的 2 的幂数：Ei、Pi、Ti、Gi、Mi、Ki。 例如，以下表达式所代表的是大致相同的值：

128974848、129e6、129M、123Mi

下面是个例子。

以下 Pod 有两个 Container。每个 Container 的请求为 0.25 cpu 和 64MiB（226 字节）内存， 每个容器的资源约束为 0.5 cpu 和 128MiB 内存。 你可以认为该 Pod 的资源请求为 0.5 cpu 和 128 MiB 内存，资源限制为 1 cpu 和 256MiB 内存。

apiVersion: v1
kind: Pod
metadata:
  name: frontend
spec:
  containers:
  - name: app
    image: images.my-company.example/app:v4
    env:
    - name: MYSQL_ROOT_PASSWORD
      value: "password"
    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 如何调度

当你创建一个 Pod 时，Kubernetes 调度程序将为 Pod 选择一个节点。 每个节点对每种资源类型都有一个容量上限：可为 Pod 提供的 CPU 和内存量。 调度程序确保对于每种资源类型，所调度的容器的资源请求的总和小于节点的容量。 请注意，尽管节点上的实际内存或 CPU 资源使用量非常低，如果容量检查失败， 调度程序仍会拒绝在该节点上放置 Pod。 当稍后节点上资源用量增加，例如到达请求率的每日峰值区间时，节点上也不会出现资源不足的问题。

带资源约束的 Pod 如何运行

当 kubelet 启动 Pod 中的 Container 时，它会将 CPU 和内存约束信息传递给容器运行时。

当使用 Docker 时：

  • spec.containers[].resources.requests.cpu 先被转换为可能是小数的基础值，再乘以 1024。 这个数值和 2 的较大者用作 docker run 命令中的 --cpu-shares 标志的值。

  • spec.containers[].resources.limits.cpu 先被转换为 millicore 值，再乘以 100。 其结果就是每 100 毫秒内容器可以使用的 CPU 时间总量。在此期间（100ms），容器所使用的 CPU 时间不会超过它被分配的时间。

    说明： 默认的配额（Quota）周期为 100 毫秒。CPU 配额的最小精度为 1 毫秒。

  • spec.containers[].resources.limits.memory 被转换为整数值，作为 docker run 命令中的 --memory 参数值。

如果 Container 超过其内存限制，则可能会被终止。如果容器可重新启动，则与所有其他类型的 运行时失效一样，kubelet 将重新启动容器。

如果一个 Container 内存用量超过其内存请求值，那么当节点内存不足时，容器所处的 Pod 可能被逐出。

每个 Container 可能被允许也可能不被允许使用超过其 CPU 约束的处理时间。 但是，容器不会由于 CPU 使用率过高而被杀死。

要确定 Container 是否会由于资源约束而无法调度或被杀死，请参阅疑难解答 部分。

监控计算和内存资源用量

Pod 的资源使用情况是作为 Pod 状态的一部分来报告的。

如果为集群配置了可选的 监控工具， 则可以直接从 指标 API 或者监控工具获得 Pod 的资源使用情况。

本地临时存储

FEATURE STATE: Kubernetes v1.10 [beta]

节点通常还可以具有本地的临时性存储，由本地挂接的可写入设备或者有时也用 RAM 来提供支持。 “临时（Ephemeral）”意味着对所存储的数据不提供长期可用性的保证。

Pods 通常可以使用临时性本地存储来实现缓冲区、保存日志等功能。 kubelet 可以为使用本地临时存储的 Pods 提供这种存储空间，允许后者使用 emptyDir 类型的 卷将其挂载到容器中。

kubelet 也使用此类存储来保存 节点层面的容器日志， 容器镜像文件、以及运行中容器的可写入层。

注意： 如果节点失效，存储在临时性存储中的数据会丢失。 你的应用不能对本地临时性存储的性能 SLA（例如磁盘 IOPS）作任何假定。

作为一种 beta 阶段功能特性，Kubernetes 允许你跟踪、预留和限制 Pod 可消耗的临时性本地存储数量。

本地临时性存储的配置

Kubernetes 有两种方式支持节点上配置本地临时性存储：

采用这种配置时，你会把所有类型的临时性本地数据（包括 emptyDir 卷、可写入容器层、容器镜像、日志等）放到同一个文件系统中。 作为最有效的 kubelet 配置方式，这意味着该文件系统是专门提供给 Kubernetes （kubelet）来保存数据的。

kubelet 也会生成 节点层面的容器日志， 并按临时性本地存储的方式对待之。

kubelet 会将日志写入到所配置的日志目录（默认为 /var/log）下的文件中； 还会针对其他本地存储的数据使用同一个基础目录（默认为 /var/lib/kubelet）。

通常，/var/lib/kubelet 和 /var/log 都是在系统的根文件系统中。kubelet 的设计也考虑到这一点。

你的集群节点当然可以包含其他的、并非用于 Kubernetes 的很多文件系统。

你使用节点上的某个文件系统来保存运行 Pods 时产生的临时性数据：日志和 emptyDir 卷等。你可以使用这个文件系统来保存其他数据（例如：与 Kubernetes 无关的其他系统日志）；这个文件系统还可以是根文件系统。

kubelet 也将 节点层面的容器日志 写入到第一个文件系统中，并按临时性本地存储的方式对待之。

同时你使用另一个由不同逻辑存储设备支持的文件系统。在这种配置下，你会告诉 kubelet 将容器镜像层和可写层保存到这第二个文件系统上的某个目录中。

第一个文件系统中不包含任何镜像层和可写层数据。

当然，你的集群节点上还可以有很多其他与 Kubernetes 没有关联的文件系统。

kubelet 能够度量其本地存储的用量。实现度量机制的前提是：

  • LocalStorageCapacityIsolation 特性门控 被启用（默认状态），并且
  • 你已经对节点进行了配置，使之使用所支持的本地临时性储存配置方式之一

如果你的节点配置不同于以上预期，kubelet 就无法对临时性本地存储的资源约束实施限制。

说明： kubelet 会将 tmpfs emptyDir 卷的用量当作容器内存用量，而不是本地临时性存储来统计。

为本地临时性存储设置请求和约束值

你可以使用 ephemeral-storage 来管理本地临时性存储。 Pod 中的每个 Container 可以设置以下属性：

  • spec.containers[].resources.limits.ephemeral-storage
  • spec.containers[].resources.requests.ephemeral-storage

ephemeral-storage 的请求和约束值是按字节计量的。你可以使用一般整数或者定点数字 加上下面的后缀来表达存储量：E、P、T、G、M、K。 你也可以使用对应的 2 的幂级数来表达：Ei、Pi、Ti、Gi、Mi、Ki。 例如，下面的表达式所表达的大致是同一个值：

128974848, 129e6, 129M, 123Mi

在下面的例子中，Pod 包含两个 Container。每个 Container 请求 2 GiB 大小的本地临时性存储。 每个 Container 都设置了 4 GiB 作为其本地临时性存储的约束值。 因此，整个 Pod 的本地临时性存储请求是 4 GiB，且其本地临时性存储的约束为 8 GiB。

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"
  - name: log-aggregator
    image: images.my-company.example/log-aggregator:v6
    resources:
      requests:
        ephemeral-storage: "2Gi"
      limits:
        ephemeral-storage: "4Gi"

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

当你创建一个 Pod 时，Kubernetes 调度器会为 Pod 选择一个节点来运行之。 每个节点都有一个本地临时性存储的上限，是其可提供给 Pods 使用的总量。 欲了解更多信息，可参考 节点可分配资源 节。

调度器会确保所调度的 Containers 的资源请求总和不会超出节点的资源容量。

临时性存储消耗的管理

如果 kubelet 将本地临时性存储作为资源来管理，则 kubelet 会度量以下各处的存储用量：

  • emptyDir 卷，除了 tmpfs emptyDir 卷
  • 保存节点层面日志的目录
  • 可写入的容器镜像层

如果某 Pod 的临时存储用量超出了你所允许的范围，kubelet 会向其发出逐出（eviction）信号，触发该 Pod 被逐出所在节点。

就容器层面的隔离而言，如果某容器的可写入镜像层和日志用量超出其存储约束， kubelet 也会将所在的 Pod 标记为逐出候选。

就 Pod 层面的隔离而言，kubelet 会将 Pod 中所有容器的约束值相加，得到 Pod 存储约束的总值。如果所有容器的本地临时性存储用量总和加上 Pod 的 emptyDir 卷的用量超出 Pod 存储约束值，kubelet 也会将该 Pod 标记为逐出候选。

注意：

如果 kubelet 没有度量本地临时性存储的用量，即使 Pod 的本地存储用量超出其约束值也不会被逐出。

不过，如果用于可写入容器镜像层、节点层面日志或者 emptyDir 卷的文件系统中可用空间太少， 节点会为自身设置本地存储不足的污点 标签。 这一污点会触发对那些无法容忍该污点的 Pods 的逐出操作。

关于临时性本地存储的配置信息，请参考这里

kubelet 支持使用不同方式来度量 Pod 的存储用量：

kubelet 按预定周期执行扫描操作，检查 emptyDir 卷、容器日志目录以及可写入容器镜像层。

这一扫描会度量存储空间用量。

说明：

在这种模式下，kubelet 并不检查已删除文件所对应的、仍处于打开状态的文件描述符。

如果你（或者容器）在 emptyDir 卷中创建了一个文件，写入一些内容之后再次打开 该文件并执行了删除操作，所删除文件对应的 inode 仍然存在，直到你关闭该文件为止。 kubelet 不会将该文件所占用的空间视为已使用空间。

FEATURE STATE: Kubernetes v1.15 [alpha]

项目配额（Project Quota）是一个操作系统层的功能特性，用来管理文件系统中的存储用量。 在 Kubernetes 中，你可以启用项目配额以监视存储用量。 你需要确保节点上为 emptyDir 提供存储的文件系统支持项目配额。 例如，XFS 和 ext4fs 文件系统都支持项目配额。

说明： 项目配额可以帮你监视存储用量，但无法对存储约束执行限制。

Kubernetes 所使用的项目 ID 始于 1048576。 所使用的 IDs 会注册在 /etc/projects 和 /etc/projid 文件中。 如果该范围中的项目 ID 已经在系统中被用于其他目的，则已占用的项目 IDs 也必须注册到 /etc/projects 和 /etc/projid 中，这样 Kubernetes 才不会使用它们。

配额方式与目录扫描方式相比速度更快，结果更精确。当某个目录被分配给某个项目时， 该目录下所创建的所有文件都属于该项目，内核只需要跟踪该项目中的文件所使用的存储块个数。 如果某文件被创建后又被删除，但对应文件描述符仍处于打开状态， 该文件会继续耗用存储空间。配额跟踪技术能够精确第记录对应存储空间的状态， 而目录扫描方式会忽略被删除文件所占用的空间。

如果你希望使用项目配额，你需要：

  • 在 kubelet 配置中使用 featureGates 字段 或者使用 --feature-gates 命令行参数 启用 LocalStorageCapacityIsolationFSQuotaMonitoring=true 特性门控 。

  • 确保根文件系统（或者可选的运行时文件系统）启用了项目配额。所有 XFS 文件系统都支持项目配额。 对 extf 文件系统而言，你需要在文件系统尚未被挂载时启用项目配额跟踪特性：

    # 对 ext4 而言，在 /dev/block-device 尚未被挂载时执行下面操作
sudo tune2fs -O project -Q prjquota /dev/block-device

  • 确保根文件系统（或者可选的运行时文件系统）在挂载时项目配额特性是被启用了的。 对于 XFS 和 ext4fs 而言，对应的挂载选项称作 prjquota。

扩展资源（Extended Resources）

扩展资源是 kubernetes.io 域名之外的标准资源名称。 它们使得集群管理员能够颁布非 Kubernetes 内置资源，而用户可以使用他们。

使用扩展资源需要两个步骤。首先，集群管理员必须颁布扩展资源。 其次，用户必须在 Pod 中请求扩展资源。

管理扩展资源

节点级扩展资源

节点级扩展资源绑定到节点。

设备插件管理的资源

有关如何颁布在各节点上由设备插件所管理的资源，请参阅 设备插件。

其他资源

为了颁布新的节点级扩展资源，集群操作员可以向 API 服务器提交 PATCH HTTP 请求， 以在集群中节点的 status.capacity 中为其配置可用数量。 完成此操作后，节点的 status.capacity 字段中将包含新资源。 kubelet 会异步地对 status.allocatable 字段执行自动更新操作，使之包含新资源。 请注意，由于调度器在评估 Pod 是否适合在某节点上执行时会使用节点的 status.allocatable 值， 在更新节点容量使之包含新资源之后和请求该资源的第一个 Pod 被调度到该节点之间， 可能会有短暂的延迟。

示例：

这是一个示例，显示了如何使用 curl 构造 HTTP 请求，公告主节点为 k8s-master 的节点 k8s-node-1 上存在五个 example.com/foo 资源。

curl --header "Content-Type: application/json-patch+json" \
--request PATCH \
--data '[{"op": "add", "path": "/status/capacity/example.com~1foo", "value": "5"}]' \
http://k8s-master:8080/api/v1/nodes/k8s-node-1/status
说明： 在前面的请求中，~1 是在 patch 路径中对字符 / 的编码。 JSON-Patch 中的操作路径的值被视为 JSON-Pointer 类型。 有关更多详细信息，请参见 IETF RFC 6901 第 3 节。

集群层面的扩展资源

集群层面的扩展资源并不绑定到具体节点。 它们通常由调度器扩展程序（Scheduler Extenders）管理，这些程序处理资源消耗和资源配额。

你可以在调度器策略配置 中指定由调度器扩展程序处理的扩展资源。

示例：

下面的调度器策略配置标明集群层扩展资源 "example.com/foo" 由调度器扩展程序处理。

  • 仅当 Pod 请求 "example.com/foo" 时，调度器才会将 Pod 发送到调度器扩展程序。
  • ignoredByScheduler 字段指定调度器不要在其 PodFitsResources 断言中检查 "example.com/foo" 资源。
{
  "kind": "Policy",
  "apiVersion": "v1",
  "extenders": [
    {
      "urlPrefix":"<extender-endpoint>",
      "bindVerb": "bind",
      "managedResources": [
        {
          "name": "example.com/foo",
          "ignoredByScheduler": true
        }
      ]
    }
  ]
}

使用扩展资源

就像 CPU 和内存一样，用户可以在 Pod 的规约中使用扩展资源。 调度器负责资源的核算，确保同时分配给 Pod 的资源总量不会超过可用数量。

说明： 扩展资源取代了非透明整数资源（Opaque Integer Resources，OIR）。 用户可以使用 kubernetes.io （保留）以外的任何域名前缀。

要在 Pod 中使用扩展资源，请在容器规范的 spec.containers[].resources.limits 映射中包含资源名称作为键。

说明： 扩展资源不能过量使用，因此如果容器规范中同时存在请求和约束，则它们的取值必须相同。

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

示例：

下面的 Pod 请求 2 个 CPU 和 1 个 "example.com/foo"（扩展资源）。

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: myimage
    resources:
      requests:
        cpu: 2
        example.com/foo: 1
      limits:
        example.com/foo: 1

PID 限制

进程 ID（PID）限制允许对 kubelet 进行配置，以限制给定 Pod 可以消耗的 PID 数量。 有关信息，请参见 PID 限制。

疑难解答

我的 Pod 处于悬决状态且事件信息显示 failedScheduling

如果调度器找不到该 Pod 可以匹配的任何节点，则该 Pod 将保持未被调度状态， 直到找到一个可以被调度到的位置。每当调度器找不到 Pod 可以调度的地方时， 会产生一个事件，如下所示：

kubectl describe pod frontend | grep -A 3 Events

Events:
  FirstSeen LastSeen   Count  From          Subobject        PathReason        Message
  36s       5s         6      {scheduler}  FailedScheduling  Failed for reason PodExceedsFreeCPU and possibly others

在上述示例中，由于节点上的 CPU 资源不足，名为 “frontend” 的 Pod 无法被调度。 由于内存不足（PodExceedsFreeMemory）而导致失败时，也有类似的错误消息。 一般来说，如果 Pod 处于悬决状态且有这种类型的消息时，你可以尝试如下几件事情：

  • 向集群添加更多节点。
  • 终止不需要的 Pod，为悬决的 Pod 腾出空间。
  • 检查 Pod 所需的资源是否超出所有节点的资源容量。例如，如果所有节点的容量都是cpu：1， 那么一个请求为 cpu: 1.1 的 Pod 永远不会被调度。

你可以使用 kubectl describe nodes 命令检查节点容量和已分配的资源数量。 例如：

kubectl describe nodes e2e-test-node-pool-4lw4

Name:            e2e-test-node-pool-4lw4
[ ... 这里忽略了若干行以便阅读 ...]
Capacity:
 cpu:                               2
 memory:                            7679792Ki
 pods:                              110
Allocatable:
 cpu:                               1800m
 memory:                            7474992Ki
 pods:                              110
[ ... 这里忽略了若干行以便阅读 ...]
Non-terminated Pods:        (5 in total)
  Namespace    Name                                  CPU Requests  CPU Limits  Memory Requests  Memory Limits
  ---------    ----                                  ------------  ----------  ---------------  -------------
  kube-system  fluentd-gcp-v1.38-28bv1               100m (5%)     0 (0%)      200Mi (2%)       200Mi (2%)
  kube-system  kube-dns-3297075139-61lj3             260m (13%)    0 (0%)      100Mi (1%)       170Mi (2%)
  kube-system  kube-proxy-e2e-test-...               100m (5%)     0 (0%)      0 (0%)           0 (0%)
  kube-system  monitoring-influxdb-grafana-v4-z1m12  200m (10%)    200m (10%)  600Mi (8%)       600Mi (8%)
  kube-system  node-problem-detector-v0.1-fj7m3      20m (1%)      200m (10%)  20Mi (0%)        100Mi (1%)
Allocated resources:
  (Total limits may be over 100 percent, i.e., overcommitted.)
  CPU Requests    CPU Limits    Memory Requests    Memory Limits
  ------------    ----------    ---------------    -------------
  680m (34%)      400m (20%)    920Mi (12%)        1070Mi (14%)

在上面的输出中，你可以看到如果 Pod 请求超过 1120m CPU 或者 6.23Gi 内存，节点将无法满足。

通过查看 Pods 部分，你将看到哪些 Pod 占用了节点上的资源。

可供 Pod 使用的资源量小于节点容量，因为系统守护程序也会使用一部分可用资源。 NodeStatus 的 allocatable 字段给出了可用于 Pod 的资源量。 有关更多信息，请参阅 节点可分配资源。

可以配置 资源配额 功能特性 以限制可以使用的资源总量。 如果与名字空间配合一起使用，就可以防止一个团队占用所有资源。

我的容器被终止了

你的容器可能因为资源紧张而被终止。要查看容器是否因为遇到资源限制而被杀死， 请针对相关的 Pod 执行 kubectl describe pod：

kubectl describe pod simmemleak-hra99

Name:                           simmemleak-hra99
Namespace:                      default
Image(s):                       saadali/simmemleak
Node:                           kubernetes-node-tf0f/10.240.216.66
Labels:                         name=simmemleak
Status:                         Running
Reason:
Message:
IP:                             10.244.2.75
Replication Controllers:        simmemleak (1/1 replicas created)
Containers:
  simmemleak:
    Image:  saadali/simmemleak
    Limits:
      cpu:                      100m
      memory:                   50Mi
    State:                      Running
      Started:                  Tue, 07 Jul 2015 12:54:41 -0700
    Last Termination State:     Terminated
      Exit Code:                1
      Started:                  Fri, 07 Jul 2015 12:54:30 -0700
      Finished:                 Fri, 07 Jul 2015 12:54:33 -0700
    Ready:                      False
    Restart Count:              5
Conditions:
  Type      Status
  Ready     False
Events:
  FirstSeen                         LastSeen                         Count  From                              SubobjectPath                       Reason      Message
  Tue, 07 Jul 2015 12:53:51 -0700   Tue, 07 Jul 2015 12:53:51 -0700  1      {scheduler }                                                          scheduled   Successfully assigned simmemleak-hra99 to kubernetes-node-tf0f
  Tue, 07 Jul 2015 12:53:51 -0700   Tue, 07 Jul 2015 12:53:51 -0700  1      {kubelet kubernetes-node-tf0f}    implicitly required container POD   pulled      Pod container image "k8s.gcr.io/pause:0.8.0" already present on machine
  Tue, 07 Jul 2015 12:53:51 -0700   Tue, 07 Jul 2015 12:53:51 -0700  1      {kubelet kubernetes-node-tf0f}    implicitly required container POD   created     Created with docker id 6a41280f516d
  Tue, 07 Jul 2015 12:53:51 -0700   Tue, 07 Jul 2015 12:53:51 -0700  1      {kubelet kubernetes-node-tf0f}    implicitly required container POD   started     Started with docker id 6a41280f516d
  Tue, 07 Jul 2015 12:53:51 -0700   Tue, 07 Jul 2015 12:53:51 -0700  1      {kubelet kubernetes-node-tf0f}    spec.containers{simmemleak}         created     Created with docker id 87348f12526a

在上面的例子中，Restart Count: 5 意味着 Pod 中的 simmemleak 容器被终止并重启了五次。

你可以使用 kubectl get pod 命令加上 -o go-template=... 选项来获取之前终止容器的状态。

kubectl get pod -o go-template='{{range.status.containerStatuses}}{{"Container Name: "}}{{.name}}{{"\r\nLastState: "}}{{.lastState}}{{end}}'  simmemleak-hra99

Container Name: simmemleak
LastState: map[terminated:map[exitCode:137 reason:OOM Killed startedAt:2015-07-07T20:58:43Z finishedAt:2015-07-07T20:58:43Z containerID:docker://0e4095bba1feccdfe7ef9fb6ebffe972b4b14285d5acdec6f0d3ae8a22fad8b2]]

你可以看到容器因为 reason:OOM killed 而被终止，OOM 表示内存不足（Out Of Memory）。

接下来

5 - 使用 kubeconfig 文件组织集群访问

使用 kubeconfig 文件来组织有关集群、用户、命名空间和身份认证机制的信息。kubectl 命令行工具使用 kubeconfig 文件来查找选择集群所需的信息，并与集群的 API 服务器进行通信。

说明： 用于配置集群访问的文件称为 kubeconfig 文件。这是引用配置文件的通用方法。这并不意味着有一个名为 kubeconfig 的文件

默认情况下，kubectl 在 $HOME/.kube 目录下查找名为 config 的文件。 您可以通过设置 KUBECONFIG 环境变量或者设置 --kubeconfig参数来指定其他 kubeconfig 文件。

有关创建和指定 kubeconfig 文件的分步说明，请参阅 配置对多集群的访问。

支持多集群、用户和身份认证机制

假设您有多个集群，并且您的用户和组件以多种方式进行身份认证。比如：

  • 正在运行的 kubelet 可能使用证书在进行认证。
  • 用户可能通过令牌进行认证。
  • 管理员可能拥有多个证书集合提供给各用户。

使用 kubeconfig 文件，您可以组织集群、用户和命名空间。您还可以定义上下文，以便在集群和命名空间之间快速轻松地切换。

上下文（Context）

通过 kubeconfig 文件中的 context 元素，使用简便的名称来对访问参数进行分组。每个上下文都有三个参数：cluster、namespace 和 user。默认情况下，kubectl 命令行工具使用 当前上下文 中的参数与集群进行通信。

选择当前上下文

kubectl config use-context

KUBECONFIG 环境变量

KUBECONFIG 环境变量包含一个 kubeconfig 文件列表。 对于 Linux 和 Mac，列表以冒号分隔。对于 Windows，列表以分号分隔。 KUBECONFIG 环境变量不是必要的。 如果 KUBECONFIG 环境变量不存在，kubectl 使用默认的 kubeconfig 文件，$HOME/.kube/config。

如果 KUBECONFIG 环境变量存在，kubectl 使用 KUBECONFIG 环境变量中列举的文件合并后的有效配置。

合并 kubeconfig 文件

要查看配置，输入以下命令：

kubectl config view

如前所述，输出可能来自 kubeconfig 文件，也可能是合并多个 kubeconfig 文件的结果。

以下是 kubectl 在合并 kubeconfig 文件时使用的规则。

  1. 如果设置了 --kubeconfig 参数，则仅使用指定的文件。不进行合并。此参数只能使用一次。

    否则，如果设置了 KUBECONFIG 环境变量，将它用作应合并的文件列表。根据以下规则合并 KUBECONFIG 环境变量中列出的文件：

    • 忽略空文件名。
    • 对于内容无法反序列化的文件，产生错误信息。
    • 第一个设置特定值或者映射键的文件将生效。
    • 永远不会更改值或者映射键。示例：保留第一个文件的上下文以设置 current-context。示例：如果两个文件都指定了 red-user，则仅使用第一个文件的 red-user 中的值。即使第二个文件在 red-user 下有非冲突条目，也要丢弃它们。

有关设置 KUBECONFIG 环境变量的示例，请参阅 设置 KUBECONFIG 环境变量。

否则，使用默认的 kubeconfig 文件， $HOME/.kube/config，不进行合并。

  1. 根据此链中的第一个匹配确定要使用的上下文。

    1. 如果存在，使用 --context 命令行参数。
    2. 使用合并的 kubeconfig 文件中的 current-context。

这种场景下允许空上下文。

  1. 确定集群和用户。此时，可能有也可能没有上下文。根据此链中的第一个匹配确定集群和用户，这将运行两次：一次用于用户，一次用于集群。

    1. 如果存在，使用命令行参数：--user 或者 --cluster。
    2. 如果上下文非空，从上下文中获取用户或集群。

这种场景下用户和集群可以为空。

  1. 确定要使用的实际集群信息。此时，可能有也可能没有集群信息。基于此链构建每个集群信息；第一个匹配项会被采用：

    1. 如果存在：--server、--certificate-authority 和 --insecure-skip-tls-verify，使用命令行参数。
    2. 如果合并的 kubeconfig 文件中存在集群信息属性，则使用它们。
    3. 如果没有 server 配置，则配置无效。

  1. 确定要使用的实际用户信息。使用与集群信息相同的规则构建用户信息，但每个用户只允许一种身份认证技术：

    1. 如果存在：--client-certificate、--client-key、--username、--password 和 --token，使用命令行参数。
    2. 使用合并的 kubeconfig 文件中的 user 字段。
    3. 如果存在两种冲突技术，则配置无效。
  1. 对于仍然缺失的任何信息，使用其对应的默认值，并可能提示输入身份认证信息。

文件引用

kubeconfig 文件中的文件和路径引用是相对于 kubeconfig 文件的位置。 命令行上的文件引用是相对于当前工作目录的。 在 $HOME/.kube/config 中，相对路径按相对路径存储，绝对路径按绝对路径存储。

接下来

6 - Pod 优先级与抢占

FEATURE STATE: Kubernetes v1.14 [stable]

Pods 可以有优先级（Priority）。 优先级体现的是当前 Pod 与其他 Pod 相比的重要程度。如果 Pod 无法被调度，则 调度器会尝试抢占（逐出）低优先级的 Pod，从而使得悬决的 Pod 可被调度。

警告：

在一个并非所有用户都可信任的集群中，一个有恶意的用户可能创建优先级最高的 Pod，从而导致其他 Pod 被逐出或者无法调度。 管理员可以使用 ResourceQuota 来避免用户创建高优先级的 Pod。

参考限制默认使用的优先级类 以了解更多细节。

如何使用优先级和抢占

要使用优先级和抢占特性：

  1. 添加一个或多个 PriorityClasses 对象

  2. 创建 Pod 时设置其 priorityClassName 为所添加的 PriorityClass 之一。 当然你也不必一定要直接创建 Pod；通常你会在一个集合对象（如 Deployment）的 Pod 模板中添加 priorityClassName。

关于这些步骤的详细信息，请继续阅读。

说明： Kubernetes 发行时已经带有两个 PriorityClasses：system-cluster-critical 和 system-node-critical。 这些优先级类是公共的，用来 确保关键组件总是能够先被调度.

如何禁用抢占

注意： 关键 Pod 依赖调度器抢占机制以在集群资源压力较大时得到调度。 因此，不建议禁用抢占。
说明： 在 Kubernetes 1.15 及之后版本中，如果特性门控 NonPreemptingPriority 被启用， 则 PriorityClass 对象可以选择设置 preemptionPolicy: Never。 这样就会避免属于该 PriorityClass 的 Pod 抢占其他 Pod。

抢占能力是通过 kube-scheduler 的标志 disablePreemption 来控制的，该标志默认为 false。 如果你在了解上述提示的前提下仍希望禁用抢占，可以将 disablePreemption 设置为true。

这一选项只能通过组件配置来设置，无法通过命令行选项这种较老的形式设置。 下面是禁用抢占的组件配置示例：

apiVersion: kubescheduler.config.k8s.io/v1alpha1
kind: KubeSchedulerConfiguration
algorithmSource:
  provider: DefaultProvider

...

disablePreemption: true

PriorityClass

PriorityClass 是一种不属于任何名字空间的对象，定义的是从优先级类名向优先级整数值的映射。 优先级类名称用 PriorityClass 对象的元数据的 name 字段指定。 优先级整数值在必须提供的 value 字段中指定。 优先级值越大，优先级越高。 PriorityClass 对象的名称必须是合法的 DNS 子域名 且不可包含 system- 前缀。

PriorityClass 对象可以设置数值小于等于 10 亿的 32 位整数。 更大的数值保留给那些通常不可被抢占或逐出的系统 Pod。 集群管理员应该为每个优先级值映射创建一个 PriorityClass 对象。

PriorityClass 对象还有两个可选字段：globalDefault 和 description。 前者用来表明此 PriorityClass 的数值应该用于未设置 priorityClassName 的 Pod。 系统中只能存在一个 globalDefault 设为真的 PriorityClass 对象。 如果没有 PriorityClass 对象的 globalDefault 被设置，则未设置 priorityClassName 的 Pod 的优先级为 0。

description 字段可以设置任意字符串值。其目的是告诉用户何时该使用该 PriorityClass。

关于 Pod 优先级与现有集群的说明

  • 如果你要升级一个不支持 Pod 优先级的集群，现有 Pod 的有效优先级都被视为 0。

  • 向集群中添加 globalDefault 设置为 true 的 PriorityClass 不会改变现有 Pod 的优先级。新添加的 PriorityClass 值仅适用于 PriorityClass 被添加之后 新建的 Pod。

  • 如果你要删除 PriorityClass，则使用所删除的 PriorityClass 名称的现有 Pod 都 不会受影响，但是你不可以再创建使用该 PriorityClass 名称的新 Pod。

PriorityClass 示例

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority
value: 1000000
globalDefault: false
description: "This priority class should be used for XYZ service pods only."

非抢占式的 PriorityClass

FEATURE STATE: Kubernetes v1.15 [alpha]

配置 preemptionPolicy: Never 的 Pod 在调度队列中会被放在低优先级的 Pod 的前面，但是它们不可以抢占其他 Pod。 非抢占 Pod 会在调度队列中等待调度，直到有足够空闲资源时才被调度。 非抢占 Pod 与其他 Pod 一样，也受调度器回退（Back-off）机制影响。 换言之，如果调度器尝试调度这些 Pod 时发现它们无法调度，它们会被再次尝试，并且 重试的频率会被降低，这样可以使得其他优先级较低的 Pod 有机会在它们之前被调度。

非抢占 Pod 仍有可能被其他高优先级的 Pod 抢占。

preemptionPolicy 默认取值为 PreemptLowerPriority，这会使得该 PriorityClass 的 Pod 能够抢占低优先级的 Pod（这也是当前的默认行为）。 如果 preemptionPolicy 被设置为 Never，则该 PriorityClass 下的 Pod 都是非抢占的。

使用 preemptionPolicy 字段要求启用 NonPreemptingPriority 特性门控。

一种示例应用场景是数据科学负载。 用户可能希望所提交的 Job 比其他负载的优先级都高，但又不希望因为抢占运行中的 Pod 而丢弃现有工作。 只要集群中"自然地"释放出足够的资源，配置了 preemptionPolicy: Never 的高优先级 Job 可以在队列中其他 Pod 之前获得调度机会。

非抢占 PriorityClass 示例

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority-nonpreempting
value: 1000000
preemptionPolicy: Never
globalDefault: false
description: "This priority class will not cause other pods to be preempted."

Pod 优先级

在已经创建了一个或多个 PriorityClass 对象之后，你就可以创建 Pod 并在其规约中 指定这些 PriorityClass 的名字之一。优先级准入控制器使用 priorityClassName 字段来填充优先级整数值。如果所指定优先级类不存在，则 Pod 被拒绝。

下面的 YAML 是一个 Pod 配置，使用了前面例子中创建的 PriorityClass。 优先级准入控制器检查 Pod 的规约并将 Pod 优先级解析为 1000000。

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    env: test
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
  priorityClassName: high-priority

优先级对 Pod 调度顺序的影响

当集群启用了 Pod 优先级时，调度器会基于 Pod 的优先级来排序悬决的 Pod。 新 Pod 会被放在调度队列中较低优先级的其他悬决 Pod 前面。 因此，优先级较高的 Pod 在其调度需求被满足的前提下会比优先级低的 Pod 先被调度。 如果优先级较高的 Pod 无法被调度，调度器会继续尝试调度其他较低优先级的 Pod。

抢占

Pod 被创建时会被放入一个队列中等待调度。调度器从队列中选择 Pod，尝试将其调度到某 Node 上。 如果找不到能够满足 Pod 所设置需求的 Node，就会触发悬决 Pod 的抢占逻辑。 假定 P 是悬决的 Pod，抢占逻辑会尝试找到一个这样的节点，在该节点上移除一个或者多个 优先级比 P 低的 Pod 后，P 就可以被调度到该节点。如果调度器能够找到这样的节点， 该节点上的一个或者多个优先级较低的 Pod 就会被逐出。当被逐出的 Pod 从该节点上 消失时，P 就可以调度到此节点。

暴露给用户的信息

当 Pod P 在节点 N 上抢占了一个或多个 Pod 时，Pod P 的状态中的nominatedNodeName 字段 会被设置为节点 N 的名字。此字段有助于调度器跟踪为 P 所预留的资源，同时也给用户提供了其集群中发生的抢占的信息。

请注意，Pod P 不一定会被调度到其 "nominated node（提名节点）"。 当选定的 Pod 被抢占时，它们都会有其体面终止时限（Graceful Termination Period）。 如果在调度器等待选定的（被牺牲的）Pod 终止期间有新的节点可用，调度器会使用其他 节点来调度 Pod P。因此，Pod 中的 nominatedNodeName 和 nodeName 并不总是相同。 此外，如果调度器抢占了节点 N 上的 Pod，但接下来出现优先级比 P 还高的 Pod 要被 调度，则调度器会把节点 N 让给新的优先级更高的 Pod。如果发生了这种情况，调度器 会清除 Pod P 的 nominatedNodeName。通过清除操作，调度器使得 Pod P 可以尝试 抢占别的节点上的 Pod。

抢占的局限性

抢占牺牲者的体面终止期限

当 Pod 被抢占时，做出牺牲的 Pod 仍有各自的 体面终止期限。 这些 Pod 可以在给定的期限内结束其工作并退出。如果它们不能及时退出则会被杀死。 这一体面终止期限带来了一个时间空隙，跨度从调度器开始抢占 Pod 的那一刻到悬决 Pod （P）可以被调度到节点（N）上的那一刻。 与此同时，调度器还要继续调度其他悬决的 Pod。 随着被抢占的 Pod 退出或终止，调度器尝试继续尝试调度悬决队列中的 Pod。 因此，从调度器抢占被牺牲的 Pod 到 Pod P 被调度，中间通常存在一个时间间隔。 为了缩短此时间间隔，用户可以将低优先级的 Pod 的体面终止期限设置为 0 或者较小的数字。

PodDisruptionBudget 是被支持的，但不提供保证

PodDisruptionBudget (PDB) 的存在使得应用的属主能够限制多副本应用因主动干扰而同时离线的 Pod 的个数。 Kubernetes 在抢占 Pod 时是可以支持 PDB 的，但对 PDB 的约束也仅限于尽力而为。 调度器会尝试寻找不会因为抢占而违反其 PDB 约束的 Pod 作为牺牲品，不过如果 找不到这样的待逐出 Pod，抢占行为仍会发生，低优先级的 Pod 仍会被逐出而不管 是否违反其 PDB 约束。

低优先级 Pod 间的亲和性

只有对下面的问题的回答是肯定的的时候，才会考虑在节点上执行抢占操作： "如果所有优先级低于悬决 Pod 的 Pod 都从节点上逐出，悬决 Pod 可以调度到此节点么？"

说明： 抢占操作不一定要逐出所有优先级较低的 Pod。 如果少逐出几个 Pod 而不是逐出所有较低优先级的 Pod 即可令悬决 Pod 被调度，则优先级较低的 Pod 中只有一部分会被逐出。 即便如此，对上述问题的回答仍须是肯定的。如果回答是否定的，Kubernetes 不会考虑在该节点上执行抢占操作。

如果悬决 Pod 与节点上一个或多个较低优先级的 Pod 之间存在 Pod 间亲和性关系， 那些对应的低优先级 Pod 若被逐出则无法满足此亲和性规则。 在这种场合下，调度器不会抢占节点上的任何 Pod。相反，它会尝试寻找其他节点。 调度器可能能找到也可能找不到合适的节点。 Kubernetes 并不保证悬决的 Pod 最终会被调度。

对此问题的一种解决方案是仅针对优先级相同或更高的 Pod 设置 Pod 间亲和性。

跨节点的抢占

假定当前正在考虑在节点 N 上执行抢占操作以便 Pod P 能够被调度到 N 上执行。 可是只有当另一个节点上的某个 Pod 被抢占，P 才有可能在 N 上调度执行。例如：

  • Pod P 正在考虑被调度到节点 N。
  • Pod Q 正运行在节点 N 所处区域（Zone）的另一个节点上。
  • Pod P 设置了区域范畴的与 Pod Q 的反亲和性 （topologyKey: topology.kubernetes.io/zone）。
  • Pod P 与区域中的其他 Pod 之间都不存在反亲和性关系。
  • 为了将 P 调度到节点 N 上，Pod Q 可以被抢占，但是调度器不会执行跨节点的 抢占操作。因此，Pod P 会被视为无法调度到节点 N 上执行。

如果 Pod Q 真的被从其节点上移除，Pod 间反亲和性的规则就会得到满足，Pod P 就有可能被调度到节点 N 上执行。

我们可能在将来版本中考虑添加跨节点的抢占能力。前提是在这方面有足够多的需求， 并且我们找到了性能可接受的算法。

故障排查

Pod 优先级和抢占机制可能产生一些不想看到的副作用。 下面是一些可能存在的问题以及相应的处理方法。

Pod 被不必要地抢占

抢占操作会在集群中资源压力较大，进而无法为高优先级的悬决 Pod 腾出空间时发生。 如果你不小心给某些 Pod 赋予了较高优先级，这些意外获得高优先级的 Pod 可能导致 集群中出现抢占行为。Pod 优先级是通过在其规约中的 priorityClassName 来设定的。 优先级的整数值被解析出来后会添加到 Pod 规约的 priority 字段。

要解决这一问题，你可以修改这些 Pod 的 priorityClassName 设置，使用优先级 较低的优先级类，或者将该字段留空。空的 priorityClassName 默认解析为优先级 0。

Pod 被抢占时，被抢占的 Pod 会有对应的事件被记录下来。 只有集群中无法为某 Pod 提供足够资源的时候才会发生抢占。 在出现这种情况时，也只有悬决 Pod（抢占者）的优先级高于被牺牲的 Pod 的优先级时，才会发生抢占现象。 当没有悬决 Pod，或者悬决 Pod 的优先级等于或者低于现有 Pod 时，都不应发生抢占行为。 如果在这种条件下仍然发生了抢占，请登记一个 Issue。

Pod 被抢占但抢占者未被调度

当有 Pod 被抢占时，它们会得到各自的体面终止期限（默认为 30 秒）。 如果被牺牲的 Pod 在此限期内未能终止，则 Pod 会被强制终止 一旦所有被牺牲的 Pod 都已消失不见，抢占者 Pod 就可被调度。

在抢占者 Pod 等待被牺牲的 Pod 消失期间，可能有更高优先级的 Pod 被创建，且适合 调度到同一节点。如果是这种情况，调度器会调度优先级更高的 Pod 而不是抢占者。

这是期望发生的行为：优先级更高的 Pod 应该取代优先级较低的 Pod。

高优先级的 Pod 比低优先级的 Pod 先被抢占

调度器尝试寻找可以运行悬决 Pod 的节点。如果找不到这样的节点，调度器会尝试从任一 节点上逐出优先级较低的 Pod 以运行悬决 Pod。 如果包含低优先级 Pod 的节点不适合用来运行悬决 Pod，调度器可能会选择其他的、 运行着较高优先级（相对之前所评估的节点上的 Pod 而言）的 Pod 的节点来执行抢占操作。 即使如此，被牺牲的 Pod 的优先级也必须比抢占者 Pod 的优先级低。

当有多个节点可供抢占时，调度器会选择 Pod 集合的优先级最低的节点。不过如果这些 Pod 上定义了 PodDisruptionBudget（PDB）而且如果被抢占了的话就会违反 PDB， 则调度器会选择另一个 Pod 集合优先级稍高的节点。

当存在多个节点可供抢占，但以上场景都不适用，则调度器会选择优先级最低的节点。

Pod 优先级与服务质量间关系

Pod 优先级与 QoS 类 是两个 相互独立的功能特性，其间交互之处很少，并且不存在基于 Pod QoS 类来为其设置 优先级方面的默认限制。 调度器的抢占逻辑在选择抢占目标时不会考虑 QoS 因素。 抢占考虑的是 Pod 优先级，并选择优先级最低的 Pod 作为抢占目标。 只有移除最低优先级的 Pod 尚不足以允许调度器调度抢占者 Pod 或者最低优先级的 Pod 受到 Pod 干扰预算（PDB）保护时，才会考虑抢占优先级稍高的 Pod。

唯一同时考虑 QoS 和 Pod 优先级的组件是 kubelet，体现在其 资源不足时的逐出操作。 kubelet 首先根据 Pod 对濒危资源的使用是否超出其请求值来选择要被逐出的 Pod， 接下来对这些 Pod 按优先级排序，再按其相对 Pod 的调度请求所耗用的濒危资源的用量 排序。更多细节可参阅 逐出最终用户的 Pod。

kubelet 资源不足时的逐出操作不会逐出 Pod 资源用量未超出其请求值的 Pod。 如果优先级较低的 Pod 未超出其请求值，它们不会被逐出。其他优先级较高的 且用量超出请求值的 Pod 则可能被逐出。

接下来