Pod

• 1: Pod 的生命周期
• 2: Pod 状况
• 3: Init 容器
• 4: 边车容器
• 5: 临时容器
• 6: 存活、就绪和启动探针
• 7: 干扰（Disruptions）
• 8: Pod QoS 类
• 9: Pod 主机名
• 10: 调度组
• 11: 静态 Pod
• 12: 用户命名空间
• 13: Downward API
• 14: 高级 Pod 配置

Pod 是可以在 Kubernetes 中创建和管理的、最小的可部署的计算单元。

Pod（就像在鲸鱼荚或者豌豆荚中）是一组（一个或多个） 容器； 这些容器共享存储、网络、以及怎样运行这些容器的规约。 Pod 中的内容总是并置（colocated）的并且一同调度，在共享的上下文中运行。 Pod 所建模的是特定于应用的“逻辑主机”，其中包含一个或多个应用容器， 这些容器相对紧密地耦合在一起。 在非云环境中，在相同的物理机或虚拟机上运行的应用类似于在同一逻辑主机上运行的云应用。

除了应用容器，Pod 还可以包含在 Pod 启动期间运行的 Init 容器。 你也可以注入临时性容器来调试正在运行的 Pod。

什么是 Pod？

说明：

为了运行 Pod，你需要提前在每个节点安装好容器运行时。

Pod 的共享上下文包括一组 Linux 名字空间、控制组（CGroup）和可能一些其他的隔离方面， 即用来隔离容器的技术。 在 Pod 的上下文中，每个独立的应用可能会进一步实施隔离。

Pod 类似于共享名字空间并共享文件系统卷的一组容器。

Kubernetes 集群中的 Pod 主要有两种用法：

• 运行单个容器的 Pod。"每个 Pod 一个容器"模型是最常见的 Kubernetes 用例； 在这种情况下，可以将 Pod 看作单个容器的包装器，并且 Kubernetes 直接管理 Pod，而不是容器。

• 运行多个协同工作的容器的 Pod。 Pod 可以封装由紧密耦合且需要共享资源的多个并置容器组成的应用。 这些位于同一位置的容器构成一个内聚单元。

  将多个并置、同管的容器组织到一个 Pod 中是一种相对高级的使用场景。 只有在一些场景中，容器之间紧密关联时你才应该使用这种模式。

  你不需要运行多个容器来扩展副本（为了弹性或容量）； 如果你需要多个副本，请参阅工作负载管理。

使用 Pod

下面是一个 Pod 示例，它由一个运行镜像 nginx:1.14.2 的容器组成。

pods/simple-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.14.2
    ports:
    - containerPort: 80

要创建上面显示的 Pod，请运行以下命令：

kubectl apply -f https://k8s.io/examples/pods/simple-pod.yaml

Pod 通常不是直接创建的，而是使用工作负载资源创建的。 有关如何将 Pod 用于工作负载资源的更多信息，请参阅使用 Pod。

用于管理 Pod 的工作负载资源

通常你不需要直接创建 Pod，甚至单实例 Pod。相反，你会使用诸如 Deployment 或 Job 这类工作负载资源来创建 Pod。 如果 Pod 需要跟踪状态，可以考虑 StatefulSet 资源。

每个 Pod 都旨在运行给定应用程序的单个实例。如果希望横向扩展应用程序 （例如，运行多个实例以提供更多的资源），则应该使用多个 Pod，每个实例使用一个 Pod。 在 Kubernetes 中，这通常被称为副本（Replication）。 通常使用一种工作负载资源及其控制器来创建和管理一组 Pod 副本。

参见 Pod 和控制器以了解 Kubernetes 如何使用工作负载资源及其控制器以实现应用的扩缩和自动修复。

Pod 天生地为其成员容器提供了两种共享资源：网络和存储。

使用 Pod

你很少在 Kubernetes 中直接创建一个个的 Pod，甚至是单实例（Singleton）的 Pod。 这是因为 Pod 被设计成了相对临时性的、用后即抛的一次性实体。 当 Pod 由你或者间接地由控制器创建时， 它被调度在集群中的节点上运行。 Pod 会保持在该节点上运行，直到 Pod 结束执行、Pod 对象被删除、Pod 因资源不足而被驱逐或者节点失效为止。

说明：

重启 Pod 中的容器不应与重启 Pod 混淆。 Pod 不是进程，而是容器运行的环境。 在被删除之前，Pod 会一直存在。

Pod 的名称必须是一个合法的 DNS 子域值， 但这可能对 Pod 的主机名产生意外的结果。为获得最佳兼容性，名称应遵循更严格的 DNS 标签规则。

Pod 操作系统

特性状态： GA since Kubernetes v1.25

你应当将 .spec.os.name 字段设置为 windows 或 linux， 以表明该 Pod 中容器所需的操作系统。目前 Kubernetes 仅支持这两种操作系统。未来，这一列表可能会扩展。

如果 .spec.os.name 的值与节点的操作系统不匹配，kubelet 将拒绝运行该 Pod。 在 Kubernetes v1.37 中，.spec.os.name 的值对 kube-scheduler 如何选择要运行 Pod 的节点没有影响。在任何有多种操作系统运行节点的集群中，你应该在每个节点上正确设置 kubernetes.io/os 标签，并根据操作系统标签为 Pod 设置 nodeSelector 字段。 kube-scheduler 将根据其他标准将你的 Pod 分配到节点， 并且可能会也可能不会成功选择合适的节点位置，其中节点操作系统适合该 Pod 中的容器。 Pod 安全标准也使用这个字段来避免强制执行与该操作系统无关的策略。

Pod 和控制器

你可以使用工作负载资源来创建和管理多个 Pod。 资源的控制器能够处理副本的管理、上线，并在 Pod 失效时提供自愈能力。 例如，如果一个节点失败，控制器注意到该节点上的 Pod 已经停止工作， 就可以创建替换性的 Pod。调度器会将替身 Pod 调度到一个健康的节点执行。

下面是一些管理一个或者多个 Pod 的工作负载资源的示例：

• Deployment
• StatefulSet
• DaemonSet

指定调度组

特性状态： Beta since Kubernetes v1.37; （默认禁用）

More information about this feature

To use this feature, you (or a cluster administrator) will need to enable the GenericWorkload feature gate for all relevant components in your cluster.

See Enable Or Disable Feature Gates for more information.

默认情况下，Kubernetes 会单独调度每一个 Pod。 然而，一些紧密耦合的应用程序需要一组 Pod 能够同时被调度，才能正确运行。

你可以使用调度组字段 （spec.schedulingGroup）将 Pod 链接到 PodGroup。 这会告诉 kube-scheduler 该 Pod 属于特定组， 使其能够为整个组应用组级协调放置决策。

Pod 模板

工作负载资源的控制器通常使用 Pod 模板（Pod Template） 来替你创建 Pod 并管理它们。

Pod 模板是包含在工作负载对象中的规范，用来创建 Pod。这类负载资源包括 Deployment、 Job 和 DaemonSet 等。

工作负载的控制器会使用负载对象中的 PodTemplate 来生成实际的 Pod。 PodTemplate 是你用来运行应用时指定的负载资源的目标状态的一部分。

创建 Pod 时，你可以在 Pod 模板中包含 Pod 中运行的容器的环境变量。

下面的示例是一个简单的 Job 的清单，其中的 template 指示启动一个容器。 该 Pod 中的容器会打印一条消息之后暂停。

apiVersion: batch/v1
kind: Job
metadata:
  name: hello
spec:
  template:
    # 这里是 Pod 模板
    spec:
      containers:
      - name: hello
        image: busybox:1.28
        command: ['sh', '-c', 'echo "Hello, Kubernetes!" && sleep 3600']
      restartPolicy: OnFailure
    # 以上为 Pod 模板

修改 Pod 模板或者切换到新的 Pod 模板都不会对已经存在的 Pod 直接起作用。 如果改变工作负载资源的 Pod 模板，工作负载资源需要使用更新后的模板来创建 Pod， 并使用新创建的 Pod 替换旧的 Pod。

例如，StatefulSet 控制器针对每个 StatefulSet 对象确保运行中的 Pod 与当前的 Pod 模板匹配。如果编辑 StatefulSet 以更改其 Pod 模板， StatefulSet 将开始基于更新后的模板创建新的 Pod。

每个工作负载资源都实现了自己的规则，用来处理对 Pod 模板的更新。 如果你想了解更多关于 StatefulSet 的具体信息， 请阅读 StatefulSet 基础教程中的更新策略。

在节点上，kubelet 并不直接监测或管理与 Pod 模板相关的细节或模板的更新，这些细节都被抽象出来。 这种抽象和关注点分离简化了整个系统的语义， 并且使得用户可以在不改变现有代码的前提下就能扩展集群的行为。

Pod 更新与替换

正如前面章节所述，当某工作负载的 Pod 模板被改变时， 控制器会基于更新的模板创建新的 Pod 对象而不是对现有 Pod 执行更新或者修补操作。

Kubernetes 并不禁止你直接管理 Pod。对运行中的 Pod 的某些字段执行就地更新操作还是可能的。不过，类似 patch 和 replace 这类更新操作有一些限制：

• Pod 的绝大多数元数据都是不可变的。例如，你不可以改变其 namespace、name、 uid 或者 creationTimestamp 字段。

• 如果 metadata.deletionTimestamp 已经被设置，则不可以向 metadata.finalizers 列表中添加新的条目。

• Pod 更新不可以改变除 spec.initContainers[*].image、spec.activeDeadlineSeconds、 spec.terminationGracePeriodSeconds、spec.tolerations 或 spec.schedulingGates 之外的字段。 对于 spec.tolerations，你只被允许添加新的条目到其中。

• 在更新 spec.activeDeadlineSeconds 字段时，以下两种更新操作是被允许的：

  1. 如果该字段尚未设置，可以将其设置为一个正数；
  2. 如果该字段已经设置为一个正数，可以将其设置为一个更小的、非负的整数。

Pod 子资源

上述更新规则适用于常规的 Pod 更新，但其他 Pod 字段可以通过子资源进行更新。

• 调整大小： resize 子资源允许更新容器资源（spec.containers[*].resources）。 更多详情参见调整容器资源大小。
• 临时容器： ephemeralContainers 子资源允许 临时容器 被添加到一个 Pod 中。 更多详情参见临时容器。
• 状态： status 子资源允许更新 Pod 状态。 这通常仅由 kubelet 和其他系统控制器使用。
• 绑定： binding 子资源允许通过 Binding 请求设置 Pod 的 spec.nodeName。 这通常仅由调度器使用。

Pod 生成

• metadata.generation 字段是唯一的。它将由系统自动设置，使得新 Pod 的 metadata.generation 为 1， 并且对 Pod 规约中可变字段的每次更新都会使 metadata.generation 增加 1。

特性状态： GA since Kubernetes v1.35

More information about this feature

This is a stable feature in Kubernetes, and has been since version v1.35. It was first available in the v1.33 release. You can no longer disable or opt out of this feature or behavior (it is locked); if you explicitly set a value for the associated feature gate PodObservedGenerationTracking, Kubernetes ignores it but does not report any error.

• observedGeneration 是在 Pod 对象的 status 部分中捕获的一个字段。 kubelet 将设置 status.observedGeneration 来追踪当前 Pod 的状态。 Pod 的 status.observedGeneration 将展示报告 Pod 状态时的 Pod 的 metadata.generation。

说明：

status.observedGeneration 字段由 kubelet 管理，外部控制器不应修改此字段。

不同的状态字段可能与当前同步循环的 metadata.generation 相关联， 或者与前一个同步循环的 metadata.generation 相关联。 关键区别在于，spec 中的变化是直接体现在 status 中，还是作为运行过程的间接结果展示。

直接状态更新

对于那些直接反映分配的 spec 的状态字段，observedGeneration 将与当前的 metadata.generation（第 N 代）相关联。

此行为适用于：

• 扩缩状态：资源扩缩操作的状态。
• 分配的资源：扩缩后分配给 Pod 的资源。
• 临时容器：当添加一个新的临时容器，并且它处于 Waiting 状态时。

间接状态更新

对于那些运行规约的间接结果的状态字段，observedGeneration 将与上一个同步循环的 metadata.generation（第 N-1 代）相关联。

此行为适用于：

• 容器镜像：ContainerStatus.ImageID 反映的是上一代的镜像，直到新的镜像被拉取并且容器被更新。
• 实际资源：在扩缩进行中，实际使用的资源仍然属于上一代请求的资源。
• 容器状态：在扩缩进行中，需要重启策略反映的是上一代的请求。
• activeDeadlineSeconds & terminationGracePeriodSeconds & deletionTimestamp：这些字段对 Pod 状态的影响是之前观察到的规约的结果。

资源共享和通信

Pod 使它的成员容器间能够进行数据共享和通信。

Pod 中的存储

一个 Pod 可以设置一组共享的存储卷。 Pod 中的所有容器都可以访问该共享卷，从而允许这些容器共享数据。 卷还允许 Pod 中的持久数据保留下来，即使其中的容器需要重新启动。 有关 Kubernetes 如何在 Pod 中实现共享存储并将其提供给 Pod 的更多信息， 请参考存储。

Pod 联网

每个 Pod 都在每个地址族中获得一个唯一的 IP 地址。 Pod 中的每个容器共享网络名字空间，包括 IP 地址和网络端口。 Pod 内的容器可以使用 localhost 互相通信。 当 Pod 中的容器与 Pod 之外的实体通信时，它们必须协调如何使用共享的网络资源（例如端口）。

在同一个 Pod 内，所有容器共享一个 IP 地址和端口空间，并且可以通过 localhost 发现对方。 他们也能通过如 SystemV 信号量或 POSIX 共享内存这类标准的进程间通信方式互相通信。 不同 Pod 中的容器的 IP 地址互不相同，如果没有特殊配置，就无法通过 OS 级 IPC 进行通信。 如果某容器希望与运行于其他 Pod 中的容器通信，可以通过 IP 联网的方式实现。

Pod 中的容器所看到的系统主机名与为 Pod 配置的 name 属性值相同。 网络部分提供了更多有关此内容的信息。

Pod 安全设置

要对 Pod 和容器设置安全约束，请使用 Pod 规约中的 securityContext 字段。 该字段使你可以精细控制 Pod 或单个容器可以执行的操作。 有关更多详细信息，请参阅 Pod 高级配置。

对于基本安全配置，你应该满足 Baseline Pod 安全标准，并以非 root 用户身份运行容器。你可以设置简单的安全上下文：

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    runAsUser: 1000
    runAsGroup: 3000
    fsGroup: 2000
  containers:
  - name: sec-ctx-demo
    image: busybox
    command: ["sh", "-c", "sleep 1h"]

有关高级安全上下文配置（包括 capabilities、seccomp 配置文件和详细安全选项）的信息， 请参阅安全概念部分。

• 要了解可以使用的内核级安全约束，请参阅 Pod 和容器的 Linux 内核安全约束。
• 要了解有关 Pod 安全上下文的更多信息， 请参阅为 Pod 或容器配置安全上下文。

资源请求和限制

配置 Pod 时，你可以选择性地指定容器所需的每种资源的数量。 最常指定的资源是 CPU 和内存（RAM）。

当你为 Pod 中的容器指定资源请求（requests）时，kube-scheduler 会使用此信息来决定将 Pod 部署在哪个节点上。

当你为容器指定资源限制（limits）时，kubelet 会强制执行这些限制，以确保正在运行的容器使用的资源量不会超过你设置的限制。

CPU 限制通过 CPU 节流机制来强制执行。 当容器接近其 CPU 限制时，内核会限制其对 CPU 的访问。 内存限制也通过内核强制执行，当容器超出其内存限制时， 内核会通过内存不足（OOM）机制终止进程。

说明：

设置 CPU 限制需要权衡利弊。 CPU 限制有助于防止“嘈杂邻居”问题，即同一节点上的单个工作负载会占用过多资源， 导致其他工作负载无法获得足够的资源的问题。这在多租户环境中尤为重要。 然而，即使节点有剩余的 CPU 资源，CPU 限制也可能导致性能下降， 从而降低对延迟敏感的工作负载的性能。 是否设置 CPU 限制取决于你的环境、工作负载特性和隔离要求。

有关资源单位、强制执行行为和配置示例的详细信息，请参阅 Pod 和容器的资源管理。

静态 Pod

静态 Pod（Static Pod） 直接由特定节点上的 kubelet 守护进程管理， 不需要 API 服务器看到它们。 尽管大多数 Pod 都是通过控制面（例如，Deployment） 来管理的，对于静态 Pod 而言，kubelet 直接监控每个 Pod，并在其失效时重启之。

静态 Pod 通常绑定到某个节点上的 kubelet。 其主要用途是运行自托管的控制面。在自托管场景中，使用 kubelet 来管理各个独立的控制面组件。

详情见静态 Pod。

包含多个容器的 Pod

Pod 被设计成支持构造内聚的服务单元的多个协作进程（形式为容器）。 Pod 中的容器被自动并置到集群中的同一物理机或虚拟机上，并可以一起进行调度。 容器之间可以共享资源和依赖、彼此通信、协调何时以及何种方式终止自身。

Kubernetes 集群中的 Pod 主要有两种用法：

• 运行单个容器的 Pod。"每个 Pod 一个容器"模型是最常见的 Kubernetes 用例； 在这种情况下，可以将 Pod 看作单个容器的包装器。Kubernetes 直接管理 Pod，而不是容器。
• 运行多个需要协同工作的容器的 Pod。 Pod 可以封装由多个紧密耦合且需要共享资源的并置容器组成的应用。 这些位于同一位置的容器可能形成单个内聚的服务单元 —— 一个容器将文件从共享卷提供给公众， 而另一个单独的边车容器则刷新或更新这些文件。 Pod 将这些容器和存储资源打包为一个可管理的实体。

例如，你可能有一个容器，为共享卷中的文件提供 Web 服务器支持，以及一个单独的 边车（Sidecar） 容器负责从远端更新这些文件，如下图所示：

有些 Pod 具有 Init 容器和 应用容器。 Init 容器默认会在启动应用容器之前运行并完成。

你还可以拥有为主应用 Pod 提供辅助服务的边车容器（例如：服务网格）。

特性状态： GA since Kubernetes v1.33

More information about this feature

This is a stable feature in Kubernetes, and has been since version v1.33. It was first available in the v1.28 release. You can no longer disable or opt out of this feature or behavior (it is locked); if you explicitly set a value for the associated feature gate SidecarContainers, Kubernetes ignores it but does not report any error.

启用 SidecarContainers 特性门控（默认启用）允许你为 Init 容器指定 restartPolicy: Always。 设置重启策略为 Always 会确保设置的容器被视为边车， 并在 Pod 的整个生命周期内保持运行。 你显式定义为边车容器的容器会在主应用 Pod 之前启动，并保持运行直至 Pod 关闭。

容器探针

Probe 是由 kubelet 对容器执行的定期诊断。要执行诊断，kubelet 可以执行三种动作：

• ExecAction（借助容器运行时执行）
• TCPSocketAction（由 kubelet 直接检测）
• HTTPGetAction（由 kubelet 直接检测）

你可以参阅 Pod 的生命周期文档中的探针部分。

接下来

• 了解 Pod 生命周期。
• 了解 PodDisruptionBudget， 以及你可以如何利用它在出现干扰因素时管理应用的可用性。
• Pod 在 Kubernetes REST API 中是一个顶层资源。 Pod 对象的定义中包含了更多的细节信息。
• 博客分布式系统工具箱：复合容器模式中解释了在同一 Pod 中包含多个容器时的几种常见布局。
• 了解 Pod 拓扑分布约束。
• 阅读 Pod 高级配置以详细了解该主题。 此页面涵盖了 Pod 配置的更多方面，包括：
  • PriorityClasses（优先级类）
  • RuntimeClasses（运行时类）
  • 配置调度的高级方法：Kubernetes 决定 Pod 应在哪个节点上运行的方式。

要了解为什么 Kubernetes 会在其他资源 （如 StatefulSet 或 Deployment） 封装通用的 Pod API，相关的背景信息可以在前人的研究中找到。具体包括：

• Aurora
• Borg
• Marathon
• Omega
• Tupperware。

1 - Pod 的生命周期

本页面讲述 Pod 的生命周期。 Pod 遵循预定义的生命周期，起始于 Pending 阶段， 如果至少其中有一个主要容器正常启动，则进入 Running，之后取决于 Pod 中是否有容器以失败状态结束而进入 Succeeded 或者 Failed 阶段。

在 Pod 运行期间，kubelet 负责管理容器，并将 Pod 规约转换为容器运行时所需的指令。 此外，kubelet 还负责执行用于监控应用程序健康状况的探针。

和一个个独立的应用容器一样，Pod 也被认为是相对临时性（而不是长期存在）的实体。 Pod 会被创建、赋予一个唯一的 ID（UID）， 并被调度到节点，并在终止（根据重启策略）或删除之前一直运行在该节点。 如果一个节点死掉了，调度到该节点的 Pod 也被计划在给定超时期限结束后删除。

Pod 生命期

在 Pod 运行期间，kubelet 能够重启容器以处理一些失效场景。 在 Pod 内部，Kubernetes 跟踪不同容器的状态并确定使 Pod 重新变得健康所需要采取的动作。 这一过程是在一个轮询循环中完成的， 该循环定期将期望状态（Pod 规约）与运行中容器的实际状态进行协调。

在 Kubernetes API 中，Pod 包含规约部分和实际状态部分。 Pod 对象的状态包含了一组 Pod 状况（Conditions）。 如果应用需要的话，你也可以向其中注入自定义的就绪态信息。

Pod 在其生命周期中只会被调度一次。 将 Pod 分配到特定节点的过程称为绑定，而选择使用哪个节点的过程称为调度。 一旦 Pod 被调度并绑定到某个节点，Kubernetes 会尝试在该节点上运行 Pod。 Pod 会在该节点上运行，直到 Pod 停止或者被终止； 如果 Kubernetes 无法在选定的节点上启动 Pod（例如，如果节点在 Pod 启动前崩溃）， 那么特定的 Pod 将永远不会启动。

你可以使用 Pod 调度就绪态来延迟 Pod 的调度，直到所有的调度门控都被移除。 例如，你可能想要定义一组 Pod，但只有在所有 Pod 都被创建完成后才会触发调度。

Pod 和故障恢复

如果 Pod 中的某个容器失败，Kubernetes 可能会尝试重启特定的容器。 有关细节参阅 Pod 如何处理容器问题。

然而，Pod 也可能以集群无法恢复的方式失败，在这种情况下，Kubernetes 不会进一步尝试修复 Pod； 相反，Kubernetes 会删除 Pod 并依赖其他组件提供自动修复。

如果 Pod 被调度到某个节点而该节点之后失效， Pod 会被视为不健康，最终 Kubernetes 会删除 Pod。 Pod 无法在因节点资源耗尽或者节点维护而被驱逐期间继续存活。

Kubernetes 使用一种高级抽象来管理这些相对而言可随时丢弃的 Pod 实例， 称作控制器。

任何给定的 Pod （由 UID 定义）从不会被“重新调度（rescheduled）”到不同的节点； 相反，这一 Pod 可以被一个新的、几乎完全相同的 Pod 替换掉。 如果你创建一个替换 Pod，它甚至可以拥有与旧 Pod 相同的名称（如 .metadata.name）， 但替换 Pod 将具有与旧 Pod 不同的 .metadata.uid。

Kubernetes 不保证现有 Pod 的替换 Pod 会被调度到与被替换的旧 Pod 相同的节点。

关联的生命期

如果某物声称其生命期与某 Pod 相同，例如存储卷， 这就意味着该对象在此 Pod （UID 亦相同）存在期间也一直存在。 如果 Pod 因为任何原因被删除，甚至某完全相同的替代 Pod 被创建时， 这个相关的对象（例如这里的卷）也会被删除并重建。

Pod 阶段

Pod 的 status 字段是一个 PodStatus 对象，其中包含一个 phase 字段。

Pod 的阶段（Phase）是 Pod 在其生命周期中所处位置的简单宏观概述。 该阶段并不是对容器或 Pod 状态的综合汇总，也不是为了成为完整的状态机。

Pod 阶段的数量和含义是严格定义的。 除了本文档中列举的内容外，不应该再假定 Pod 有其他的 phase 值。

下面是 phase 可能的值：

NAMESPACE               NAME               READY   STATUS             RESTARTS   AGE
alessandras-namespace   alessandras-pod    0/1     CrashLoopBackOff   200        2d9h

从 Kubernetes 1.27 起，kubelet 会在被删除的 Pod 从 API 服务器移除之前， 将它们切换到一个终止阶段（Failed 或 Succeeded，具体取决于 Pod 容器的退出状态）， 但有两种例外情况：

• 静态 Pod （由 kubelet 直接管理，并通过{{< glossary_tooltip text="镜像 Pod" term_id="mirror-pod" >}} 来表示）
• 没有设置 finalizer 的被强制删除的 Pod

如果某节点死掉或者与集群中其他节点失联，Kubernetes 会实施一种策略，将失去的节点上运行的所有 Pod 的 phase 设置为 Failed。

容器状态

Kubernetes 会跟踪 Pod 中每个容器的状态，就像它跟踪 Pod 总体上的阶段一样。 你可以使用容器生命周期回调 来在容器生命周期中的特定时间点触发事件。

一旦调度器将 Pod 分派给某个节点，kubelet 就通过容器运行时开始为 Pod 创建容器。容器的状态有三种：Waiting（等待）、Running（运行中）和 Terminated（已终止）。

要检查 Pod 中容器的状态，你可以使用 kubectl describe pod <pod 名称>。 其输出中包含 Pod 中每个容器的状态。

每种状态都有特定的含义：

Waiting（等待）

如果容器并不处在 Running 或 Terminated 状态之一，它就处在 Waiting 状态。 处于 Waiting 状态的容器仍在运行它完成启动所需要的操作：例如， 从某个容器镜像仓库拉取容器镜像，或者向容器应用 Secret 数据等等。 当你使用 kubectl 来查询包含 Waiting 状态的容器的 Pod 时，你也会看到一个 Reason 字段，其中给出了容器处于等待状态的原因。

Running（运行中）

Running 状态表明容器正在执行状态并且没有问题发生。 如果配置了 postStart 回调，那么该回调已经执行且已完成。 如果你使用 kubectl 来查询包含 Running 状态的容器的 Pod 时， 你也会看到关于容器进入 Running 状态的信息。

Terminated（已终止）

处于 Terminated 状态的容器开始执行后，或者运行至正常结束或者因为某些原因失败。 如果你使用 kubectl 来查询包含 Terminated 状态的容器的 Pod 时， 你会看到容器进入此状态的原因、退出代码以及容器执行期间的起止时间。

如果容器配置了 preStop 回调，则该回调会在容器进入 Terminated 状态之前执行。

Pod 如何处理容器问题

Kubernetes 通过在 Pod spec 中定义的 restartPolicy 管理 Pod 内容器出现的失效。 该策略决定了 Kubernetes 如何对由于错误或其他原因而退出的容器做出反应，其顺序如下：

1. 最初的崩溃：Kubernetes 尝试根据 Pod 的 restartPolicy 立即重新启动。
2. 反复的崩溃：在最初的崩溃之后，Kubernetes 对于后续重新启动的容器采用指数级回退延迟机制， 如 restartPolicy 中所述。 这一机制可以防止快速、重复的重新启动尝试导致系统过载。
3. CrashLoopBackOff 状态：这一状态表明，对于一个给定的、处于崩溃循环、反复失效并重启的容器， 回退延迟机制目前正在生效。
4. 回退重置：如果容器成功运行了一定时间（如 10 分钟）， Kubernetes 会重置回退延迟机制，将新的崩溃视为第一次崩溃。

在实际部署中，CrashLoopBackOff 是在描述或列出 Pod 时从 kubectl 命令输出的一种状况或事件。 当 Pod 中的容器无法正常启动，并反复进入尝试与失败的循环时就会出现。

换句话说，当容器进入崩溃循环时，Kubernetes 会应用容器重启策略 中提到的指数级回退延迟机制。这种机制可以防止有问题的容器因不断进行启动失败尝试而导致系统不堪重负。

下列问题可以导致 CrashLoopBackOff：

• 应用程序错误导致的容器退出。
• 配置错误，如环境变量不正确或配置文件丢失。
• 资源限制，容器可能没有足够的内存或 CPU 正常启动。
• 如果应用程序没有在预期时间内启动服务，健康检查就会失败。
• 容器的存活探针或者启动探针返回 失败 结果，如探针部分所述。

要调查 CrashLoopBackOff 问题的根本原因，用户可以：

1. 检查日志：使用 kubectl logs <pod名称> 检查容器的日志。 这通常是诊断导致崩溃的问题的最直接方法。
2. 检查事件：使用 kubectl describe pod <pod名称> 查看 Pod 的事件， 这可以提供有关配置或资源问题的提示。
3. 审查配置：确保 Pod 配置正确无误，包括环境变量和挂载卷，并且所有必需的外部资源都可用。
4. 检查资源限制： 确保容器被分配了足够的 CPU 和内存。有时，增加 Pod 定义中的资源可以解决问题。
5. 调试应用程序：应用程序代码中可能存在错误或配置不当。 在本地或开发环境中运行此容器镜像有助于诊断应用程序的特定问题。

容器重启

当 Pod 中的某个容器停止或发生故障时，Kubernetes 可以重新启动此容器。但重启并不总是合适的；例如， Init 容器只在 Pod 启动期间运行一次（如果成功）。 你可以将重启配置为适用于所有 Pod 的策略，或者使用容器级别的配置（例如： 在你定义边车容器或定义容器级别重载时）。

容器重启与弹性

Kubernetes 项目建议遵循云原生原则，包括能够应对未预告或随意重启的弹性设计。 你可以通过让 Pod 失败并依赖自动替换， 或者通过容器级别的弹性设计来实现。 无论哪种方式，都有助于确保即使在部分故障的情况下，你的整体工作负载依然保持可用。

Pod 级别容器重启策略

Pod 的 spec 中包含一个 restartPolicy 字段，其可能取值包括 Always、OnFailure 和 Never。默认值是 Always。

restartPolicy 应用于 Pod 中的应用容器和常规的 Init 容器。 Sidecar 容器忽略 Pod 级别的 restartPolicy 字段：在 Kubernetes 中，Sidecar 被定义为 initContainers 内的一个条目，其容器级别的 restartPolicy 被设置为 Always。 对于因错误而退出的 Init 容器，如果 Pod 级别 restartPolicy 为 OnFailure 或 Always， 则 kubelet 会重新启动 Init 容器。

• Always：只要容器终止就自动重启容器。
• OnFailure：只有在容器错误退出（退出状态非零）时才重新启动容器。
• Never：不会自动重启已终止的容器。

重启行为比较

下表显示了在不同的重启策略和退出代码下容器的行为：

示例场景

以下是一些具体示例，演示了不同的重启行为：

示例 1：Web 服务器，使用 restartPolicy: Always（通常用于 Deployment）

apiVersion: v1
kind: Pod
metadata:
  name: web-server
spec:
  restartPolicy: Always  # 无论退出代码如何，容器都会重启
  containers:
  - name: nginx
    image: nginx:1.14.2
    # 如果此容器因任何原因崩溃或退出，它将被重新启动

示例 2：使用 restartPolicy: OnFailure 的批处理作业

apiVersion: batch/v1
kind: Job
metadata:
  name: data-processor
spec:
  template:
    spec:
      restartPolicy: OnFailure  # 仅当退出代码非零时才重新启动
      containers:
      - name: processor
        image: busybox:1.28
        command: ['sh', '-c', 'echo "Processing data..."; exit 0']
        # 退出代码 0：作业成功完成，无需重启
        # 退出代码 1+：容器重启以重试作业

示例 3：使用 restartPolicy: Never 执行一次性作业

apiVersion: v1
kind: Pod
metadata:
  name: migration-task
spec:
  restartPolicy: Never  # 无论退出代码如何，都不要重新启动
  containers:
  - name: migrate
    image: busybox:1.28
    command: ['sh', '-c', 'echo "Running migration..."; exit 1']
    # 即使退出代码为 1（失败），容器也不会重启
    # Pod 将保持失败状态

边车容器和重启策略

边车容器具有与常规应用容器不同的特殊重启行为：

• 边车容器忽略 Pod 级别的 restartPolicy： 它们使用自己的容器级 restartPolicy 字段，该字段始终设置为 Always

• 独立生命周期：边车容器可以独立于主应用容器重启

• 持久运行：边车容器在 Pod 的整个生命周期内持续运行，以提供支持服务

示例：带有边车容器的 Pod

apiVersion: v1
kind: Pod
metadata:
  name: app-with-sidecar
spec:
  restartPolicy: OnFailure  # 仅适用于主容器
  initContainers:
  - name: logging-sidecar    # 这是一个边车容器
    image: fluent/fluent-bit:1.8
    restartPolicy: Always    # 无论退出代码如何，边车容器始终会重新启动。
    # 在 Pod 的整个生命周期内提供日志记录服务
  containers:
  - name: main-app          # 这遵循 Pod 级别的重启策略
    image: nginx:1.14.2
    # 根据 Pod 的 OnFailure 策略，仅在失败（非零退出）时才会重启。

当 kubelet 根据配置的重启策略处理容器重启时，仅适用于同一 Pod 内替换容器并在同一节点上运行的重启。当 Pod 中的容器退出时，kubelet 会以指数级回退延迟机制（10 秒、20 秒、40 秒......）重启容器， 上限为 300 秒（5 分钟）。一旦容器顺利执行了 10 分钟， kubelet 就会重置该容器的重启延迟计时器。 Sidecar 容器和 Pod 生命周期中解释了 init containers 在指定 restartPolicy 字段时的行为。

单个容器的重启策略与规则

如果你的集群启用了 ContainerRestartRules 特性门控，你可以针对单个容器指定 restartPolicy 和 restartPolicyRules 来覆盖 Pod 重启策略。容器重启策略和规则适用于 Pod 中的应用容器以及常规的 Init 容器。

Kubernetes 原生的边车容器将其容器级别的 restartPolicy 设置为 Always。

容器重启会遵循与前文所述的 Pod 重启策略相同的指数回退机制。支持的容器重启策略有：

• Always：在任何原因的容器终止后都会自动重启容器。
• OnFailure：仅当容器因错误退出（非零退出状态）时才重启。
• Never：不自动重启已终止的容器。

此外，单个容器可以指定 restartPolicyRules。如果指定了 restartPolicyRules 字段， 则必须同时指定容器的 restartPolicy。restartPolicyRules 定义了一系列在容器退出时应用的规则。 每条规则由条件和动作组成。支持的条件是 exitCodes，用于将容器的退出码与给定值列表进行比较。 支持的动作是 Restart，表示容器将被重启。这些规则会按顺序进行评估。一旦匹配成功，立即执行相应动作。 如果没有任何规则的状况被匹配，Kubernetes 回退到容器配置的 restartPolicy。

例如，重启策略为 OnFailure 的某个 Pod 包含一个 try-once 容器。 这样可以让 Pod 仅重启某些容器：

apiVersion: v1
kind: Pod
metadata:
  name: on-failure-pod
spec:
  restartPolicy: OnFailure
  containers:
  - name: try-once-container    # 此容器只运行一次，因为 restartPolicy 设置为 Never。
    image: registry.k8s.io/busybox:1.27.2
    command: ['sh', '-c', 'echo "Only running once" && sleep 10 && exit 1']
    restartPolicy: Never     
  - name: on-failure-container  # 此容器将在失败时重启。
    image: registry.k8s.io/busybox:1.27.2
    command: ['sh', '-c', 'echo "Keep restarting" && sleep 1800 && exit 1']

下面是一个重启策略为 Always 的 Pod，其中包含一个只执行一次的 Init 容器。 如果 Init 容器失败，则 Pod 也会失败。 这样可以在初始化失败时让 Pod 失败，但在初始化成功后保持 Pod 运行：

apiVersion: v1
kind: Pod
metadata:
  name: fail-pod-if-init-fails
spec:
  restartPolicy: Always
  initContainers:
  - name: init-once      # 这个 Init 容器只尝试一次。如果失败，Pod 将失败。
    image: registry.k8s.io/busybox:1.27.2
    command: ['sh', '-c', 'echo "Failing initialization" && sleep 10 && exit 1']
    restartPolicy: Never
  containers:
  - name: main-container # 一旦初始化成功，此容器会始终被重启。
    image: registry.k8s.io/busybox:1.27.2
    command: ['sh', '-c', 'sleep 1800 && exit 0']

下面是一个重启策略为 Never 的 Pod，其中包含的容器会在遇到特定的退出码时忽略之并重启。 这种配置有助于区分可重启错误和不可重启错误：

apiVersion: v1
kind: Pod
metadata:
  name: restart-on-exit-codes
spec:
  restartPolicy: Never
  containers:
  - name: restart-on-exit-codes
    image: registry.k8s.io/busybox:1.27.2
    command: ['sh', '-c', 'sleep 60 && exit 0']
    restartPolicy: Never     # 如果指定了规则，必须同时指定容器重启策略
    restartPolicyRules:      # 仅当退出码为 42 时才重启容器
    - action: Restart
      exitCodes:
        operator: In
        values: [42]

重启规则可用于许多其他高级的生命周期管理场景。 需要注意的是，重启规则会受到不一致性影响，这一点上与常规的重启策略相同。 kubelet 重启、容器运行时垃圾收集、与控制平面的间歇性连接问题都可能导致状态丢失， 容器可能会在你预期不应被重启的情况下被再次运行。

重启所有容器

如果你的集群已启用特性门控 RestartAllContainersOnContainerExits， 你可以在容器级别的 restartPolicyRules 中指定 RestartAllContainers 作为一个动作。 当容器的退出符合包含此动作的某个规则时，整个 Pod 被终止并就地重启。

这种“就地”重启比完全删除并重新创建 Pod 提供了更高效的方式来重置 Pod 的状态。 这对于调度批处理作业或 AI/ML 训练任务这类开销高的工作负载尤其有价值。

就地重启 Pod 的工作原理

当触发 RestartAllContainers 动作时，kubelet 执行以下步骤：

1. 快速终止：Pod 中所有正在运行的容器被终止。
   配置的 terminationGracePeriodSeconds 不会生效，配置的所有 preStop 回调也不会被执行。这样可以确保快速关闭容器。

2. 保留 Pod 资源：Pod 的关键资源被保留：

   • Pod UID、IP 地址和网络命名空间
   • Pod 沙箱及所挂接的所有设备
   • 所有卷，包括 emptyDir 和挂载卷

3. 更新 Pod 状态：Pod 的状态被更新，同时 PodRestartInPlace 状况设置为 True，使重启过程可观测。

4. 完整重启序列：当所有容器终止后，将 PodRestartInPlace 状况设置为 False，然后 Pod 开始标准的启动流程：

   • Init 容器按顺序重新运行。
   • 边车和普通容器启动。

此特性的一个关键点是所有容器都会被重启，包括之前已成功完成或失败的容器。 RestartAllContainers 动作会重载所有已配置的容器级或 Pod 级别的 restartPolicy。

这种机制在需要为所有容器提供干净环境的场景中非常有用，例如：

• 当 Init 容器设置的环境可能被破坏时，此特性确保重新执行此设置过程。
• 边车容器可以监控主应用的健康状态，如果该应用进入不可恢复的状态，则触发整个 Pod 重启。

考虑一种工作负载，其中 watcher 边车负责在主应用出错时从已知良好状态重启主应用。 watcher 可以以特定代码退出，从而触发 worker Pod 的就地完整重启。

pods/restart-policy/restart-all-containers.yaml

apiVersion: v1
kind: Pod
metadata:
  name: ml-worker
spec:
  restartPolicy: Never # Pod 本身不会自动重启，除非被显式指定。
  initContainers:
  - name: setup-environment
    image: registry.k8s.io/busybox:1.27.2
    command: ['sh', '-c', 'echo "Setting up environment"']
    # 这个 Init 容器只运行一次，用于准备环境。
    # 在触发 RestartAllContainers 动作后，此容器会再次运行。
  - name: watcher-sidecar
    image: registry.k8s.io/busybox:1.27.2
    # 在真实场景中，这里通常会使用一个专用的 watcher 镜像。
    # 此命令用于模拟 watcher 以特定的退出码退出。
    command: ['sh', '-c', 'sleep 60; exit 88']
    restartPolicy: Always
    restartPolicyRules:
    - action: RestartAllContainers
      onExit:
        exitCodes:
          # 退出码 88 会触发整个 Pod 的完全重启。
          operator: In
          values: [88]
  containers:
  - name: main-application
    image: registry.k8s.io/busybox:1.27.2
    command: ['sh', '-c', 'echo "Application is running"; sleep 3600']

在此示例中：

• Pod 的整体 restartPolicy 为 Never。
• watcher-sidecar 执行命令后以退出码 88 退出。
• 退出码符合规则，触发 RestartAllContainers 动作。
• 整个 Pod（包括 setup-environment init 容器和 main-application 容器）随后就地重启。 Pod 保留其 UID、沙箱、IP 和卷。

减少容器重启延迟

启用 Alpha 特性开关 ReduceDefaultCrashLoopBackOffDecay 后， 集群中容器启动重试的初始延迟将从 10 秒减少到 1 秒， 之后每次重启延迟时间按 2 倍指数增长，直到达到最大延迟 60 秒（之前为 300 秒，即 5 分钟）。

如果你同时使用了下面介绍的 Alpha 特性 KubeletCrashLoopBackOffMax， 那么单个节点上可能会有不同的最大延迟值。

可配置的容器重启延迟

启用特性门控 KubeletCrashLoopBackOffMax 后， 你可以重新配置容器启动重试之间的最大延迟，默认值为 300 秒（5 分钟）。 此配置是针对每个节点使用 kubelet 配置进行设置的。 在你的 kubelet 配置中， 在 crashLoopBackOff 下设置 maxContainerRestartPeriod 字段，取值范围在 "1s" 到 "300s" 之间。 如上文容器重启策略所述，该节点上的延迟仍将从 10 秒开始，并在每次重启后以指数方式增加 2 倍，但现在其上限将被限制为你所配置的最大值。如果你配置的 maxContainerRestartPeriod 小于默认初始值 10 秒， 则初始延迟将被设置为配置的最大值。

参见以下 kubelet 配置示例：

# 容器重启延迟将从 10 秒开始，每次重启增加 2 倍
# 最高达到 100 秒
kind: KubeletConfiguration
crashLoopBackOff:
    maxContainerRestartPeriod: "100s"

# 容器重启之间的延迟将始终为 2 秒
kind: KubeletConfiguration
crashLoopBackOff:
    maxContainerRestartPeriod: "2s"

如果你将此特性与上文提到的 Alpha 特性 ReduceDefaultCrashLoopBackOffDecay 一起使用， 那么集群的初始退避时间和最大退避时间默认值将不再是 10 秒和 300 秒，而是 1 秒和 60 秒。 每个节点上的配置优先于 ReduceDefaultCrashLoopBackOffDecay 所设置的默认值， 即使这会导致某些节点的最大退避时间比集群中的其他节点更长。

Pod 状况

Pod 有一个 PodStatus 对象，其中包含一个 PodConditions 数组。Pod 可能通过也可能未通过其中的一些状况测试。 Kubelet 管理以下 PodCondition：

• PodScheduled：Pod 已经被调度到某节点；
• PodReadyToStartContainers：Pod 沙箱已成功创建，网络已配置，存储卷已挂载， 并且（如果请求了）任何动态资源均已分配完成；
• ContainersReady：Pod 中所有容器都已就绪；
• Initialized：所有的 Init 容器都已成功完成；
• Ready：Pod 可以为请求提供服务，并且应该被添加到对应服务的负载均衡池中。
• DisruptionTarget：由于干扰（例如抢占、驱逐或垃圾回收），Pod 即将被终止。
• PodResizePending：已请求对 Pod 进行调整大小，但尚无法应用。 详见 Pod 调整大小状态。
• PodResizeInProgress：Pod 正在调整大小中。 详见 Pod 调整大小状态。

Pod 就绪态

你的应用可以向 PodStatus 中注入额外的反馈或者信号：Pod Readiness（Pod 就绪态）。 要使用这一特性，可以设置 Pod 规约中的 readinessGates 列表，为 kubelet 提供一组额外的状况供其评估 Pod 就绪态时使用。

就绪态门控基于 Pod 的 status.conditions 字段的当前值来做决定。 如果 Kubernetes 无法在 status.conditions 字段中找到某状况， 则该状况的状态值默认为 "False"。

这里是一个例子：

kind: Pod
...
spec:
  readinessGates:
    - conditionType: "www.example.com/feature-1"
status:
  conditions:
    - type: Ready                              # 内置的 Pod 状况
      status: "False"
      lastProbeTime: null
      lastTransitionTime: 2018-01-01T00:00:00Z
    - type: "www.example.com/feature-1"        # 额外的 Pod 状况
      status: "False"
      lastProbeTime: null
      lastTransitionTime: 2018-01-01T00:00:00Z
  containerStatuses:
    - containerID: docker://abcd...
      ready: true
...

你所添加的 Pod 状况名称必须满足 Kubernetes 标签键名格式。

Pod 就绪态的状态

命令 kubectl patch 不支持修改对象的状态。 如果需要设置 Pod 的 status.conditions，应用或者 Operators 需要使用 PATCH 操作。你可以使用 Kubernetes 客户端库之一来编写代码， 针对 Pod 就绪态设置定制的 Pod 状况。

对于使用定制状况的 Pod 而言，只有当下面的陈述都适用时，该 Pod 才会被评估为就绪：

• Pod 中所有容器都已就绪；
• readinessGates 中的所有状况都为 True 值。

当 Pod 的容器都已就绪，但至少一个定制状况没有取值或者取值为 False， kubelet 将 Pod 的状况设置为 ContainersReady。

Pod 启动容器的就绪状态

在 Pod 被调度到某节点后，它需要被 kubelet 接受并且挂载所需的存储卷。 一旦这些阶段完成，Kubelet 将与容器运行时（使用容器运行时接口（Container Runtime Interface；CRI）） 一起为 Pod 生成运行时沙箱并配置网络。 如果该 Pod 使用了动态资源分配（DRA）， 这些资源也会在该阶段被一起分配。 PodReadyToStartContainers 状况被添加到 Pod 的 status.conditions 字段中。

当 kubelet 检测到 Pod 不具备配置了网络的运行时沙箱时，状况将被设置为 False。 这种情况发生在以下场景中：

• 在 Pod 生命周期的早期阶段，kubelet 还没有开始使用容器运行时为 Pod 设置沙箱时。
• 在 Pod 生命周期的末期阶段，Pod 的沙箱由于以下原因被销毁时：
  • 节点重启时 Pod 没有被驱逐
  • 对于使用虚拟机进行隔离的容器运行时，Pod 沙箱虚拟机重启时，需要创建一个新的沙箱和全新的容器网络配置。

在沙箱创建、网络配置、卷挂载以及（如有请求）动态资源分配完成之后，kubelet 会将 PodReadyToStartContainers 状况设置为 True。镜像拉取与容器创建会在此之后进行。

对于带有 Init 容器的 Pod，kubelet 会在 Init 容器成功完成后将 Initialized 状况设置为 True （这发生在运行时成功创建沙箱和配置网络之后）， 对于没有 Init 容器的 Pod，kubelet 会在创建沙箱和网络配置开始之前将 Initialized 状况设置为 True。

调整 Pod 大小

Kubernetes 支持在 Pod 创建后更改分配给 Pod 的 CPU 和内存资源。 （对于其他基础设施资源，你需要使用特定于这些资源的不同技术。） 调整 CPU 和内存资源主要有两种方法：

原地 Pod 调整大小

你可以调整 Pod 的容器级别 CPU 和内存资源，而无需重建 Pod。 这亦被称为原地 Pod 垂直扩缩。这允许你在可能避免应用程序中断的同时， 调整运行容器的资源配置。

如果你已在 Pod 级别指定了资源，也可以直接调整这些资源的大小。 更多详情，请参阅调整分配给 Pod 的 CPU 和内存资源大小。

要执行原地调整大小，你可以使用 /resize 子资源更新 Pod 的期望状态。 然后，kubelet 会尝试将新的资源值应用到运行中的容器。 Pod 状况 PodResizePending 和 PodResizeInProgress （在 Pod 状况 中描述） 指示调整大小操作的状态。有关调整大小状态的更多详情，请参见 容器调整大小状态。

就地调整大小的关键考量：

• 仅 CPU 和内存资源可以原地调整大小。
• Pod 的服务质量（QoS）类在创建时确定， 且不能通过调整大小来更改。
• 你可以使用容器规约中的 resizePolicy 配置是否需要重启容器以进行调整大小。

有关执行原地调整大小的详细说明， 请参见调整分配给容器的 CPU 和内存资源。

通过启动替代 Pod 进行调整大小

更改 Pod 资源更云原生的方法是通过管理它的工作负载资源（如 Deployment 或 StatefulSet）。 当你更新 Pod 模板中的资源规约时， 工作负载的控制器会根据其更新策略创建具有更新资源的新 Pod 并终止旧 Pod。

这种方法：

• 适用于任何 Kubernetes 版本。
• 可以更改任何 Pod 规约，而不仅仅是资源。
• 会导致 Pod 替换，因此你应该设计你的工作负载来处理计划内的干扰。 考虑使用 PodDisruptionBudget 来控制可用性。
• 要求你的 Pod 由工作负载资源管理。

你也可以使用 VerticalPodAutoscaler 来自动管理 Pod 资源建议和更新。

容器探针

Kubernetes 允许你定义探针（Probe） 来持续监测 Pod 中容器的健康状况。 探针是由 {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} 周期性地在容器上执行的一种诊断操作。为执行该诊断，kubelet 要么在容器内执行一段代码，要么发起一次网络请求。

根据探针检测结果，Kubernetes 可以重启不健康的容器，或者停止向未就绪的容器发送流量。

kubelet 可以选择性地对运行中的容器执行并响应三种探针，每种探针的作用各不相同。 有关探针机制（exec、grpc、httpGet、tcpSocket）、配置字段以及详细的使用指南， 请参见存活态、就绪态与启动探针。

启动探针

启动探针用于验证容器内的应用是否已启动。如果配置了启动探针，在启动探针成功之前， Kubernetes 不会执行存活态探针或就绪态探针，从而为应用的初始化留出时间。

这种探针仅在启动阶段执行，与周期性运行的存活态探针和就绪态探针不同。

如果启动探针失败，kubelet 会终止该容器， 并按照其重启策略对容器进行处理。

存活态探针

存活态探针决定何时重启容器。例如，存活态探针可以捕捉到死锁——即应用仍在运行但无法继续推进。 在此状态下重启容器有助于提高应用的可用性，即使存在缺陷。

如果一个容器在存活态探针上的失败次数超过了配置的容忍度，kubelet 就会重启该容器。 存活态探针不等待就绪态探针成功。如果你希望在执行存活态探针前进行等待，可以定义 initialDelaySeconds，或者使用启动探针。

就绪态探针

就绪态探针用于确定容器何时可以接收流量。 当应用需要执行耗时的初始化任务（例如建立网络连接、加载文件、预热缓存）时，它非常有用。 就绪态探针在容器生命周期的后期同样很有用，例如在从临时故障或过载中恢复时。

如果就绪态探针返回失败状态，{{< glossary_tooltip text="EndpointSlice" term_id="endpoint-slice" >}} 控制器会从所有与该 Pod 匹配的 Service 的 EndpointSlice 中移除该 Pod 的 IP 地址。

就绪态探针会在容器的整个生命周期内持续运行。

Pod 的终止

由于 Pod 所代表的是在集群中节点上运行的进程，当不再需要这些进程时允许其体面地终止是很重要的。 一般不应武断地使用 KILL 信号终止它们，导致这些进程没有机会完成清理操作。

设计的目标是令你能够请求删除进程，并且知道进程何时被终止，同时也能够确保删除操作终将完成。 当你请求删除某个 Pod 时，集群会记录并跟踪 Pod 的体面终止周期， 而不是直接强制地杀死 Pod。在存在强制关闭设施的前提下， kubelet 会尝试体面地终止 Pod。

通常 Pod 体面终止的过程为：kubelet 先发送一个带有体面超时限期的 TERM（又名 SIGTERM） 信号到每个容器中的主进程，将请求发送到容器运行时来尝试停止 Pod 中的容器。 停止容器的这些请求由容器运行时以异步方式处理。 这些请求的处理顺序无法被保证。许多容器运行时遵循容器镜像内定义的 STOPSIGNAL 值， 如果不同，则发送容器镜像中配置的 STOPSIGNAL，而不是 TERM 信号。 一旦超出了体面终止限期，容器运行时会向所有剩余进程发送 KILL 信号，之后 Pod 就会被从 API 服务器上移除。 如果 kubelet 或者容器运行时的管理服务在等待进程终止期间被重启， 集群会从头开始重试，赋予 Pod 完整的体面终止限期。

终止信号

用于终止容器的终止信号可以通过容器镜像中的 STOPSIGNAL 指令进行定义。 如果镜像中未定义终止信号，容器运行时（containerd 和 CRI-O 都是 SIGTERM） 会使用默认的终止信号来终止容器。

定义自定义终止信号

如果启用了 ContainerStopSignals 特性门控（feature gate）， 你可以通过容器的生命周期（Lifecycle）配置自定义的终止信号。 在容器生命周期中定义终止信号时，Pod 的 spec.os.name 字段必须存在。 可用的信号列表取决于 Pod 调度到的操作系统。 对于调度到 Windows 节点的 Pod，仅支持 SIGTERM 和 SIGKILL 信号。

以下是一个定义了自定义终止信号的 Pod 示例：

spec:
  os:
    name: linux
  containers:
    - name: my-container
      image: container-image:latest
      lifecycle:
        stopSignal: SIGUSR1

如果在生命周期中定义了终止信号，则会覆盖容器镜像中定义的信号。 如果容器规约中未定义终止信号，则容器将回退到默认行为。

Pod 终止流程

Pod 终止流程，如下例所示：

1. 你使用 kubectl 工具手动删除某个特定的 Pod，而该 Pod 的体面终止限期是默认值（30 秒）。

2. API 服务器中的 Pod 对象被更新，记录涵盖体面终止限期在内 Pod 的最终死期，超出所计算时间点则认为 Pod 已死（dead）。 如果你使用 kubectl describe 来查验你正在删除的 Pod，该 Pod 会显示为 "Terminating" （正在终止）。 在 Pod 运行所在的节点上：kubelet 一旦看到 Pod 被标记为正在终止（已经设置了体面终止限期），kubelet 即开始本地的 Pod 关闭过程。

   1. 如果 Pod 中的容器之一定义了 preStop 回调 且 Pod 规约中的 terminationGracePeriodSeconds 未设为 0， kubelet 开始在容器内运行该回调逻辑。默认的 terminationGracePeriodSeconds 设置为 30 秒.

      如果 preStop 回调在体面期结束后仍在运行，kubelet 将请求短暂的、一次性的体面期延长 2 秒。

   说明：

   如果 preStop 回调所需要的时间长于默认的体面终止限期，你必须修改 terminationGracePeriodSeconds 属性值来使其正常工作。

   2. kubelet 接下来触发容器运行时发送 TERM 信号给每个容器中的进程 1。

      如果 Pod 中定义了边车容器， 则存在特殊排序。否则，Pod 中的容器会在不同的时间和任意的顺序接收 TERM 信号。如果关闭顺序很重要，考虑使用 preStop 钩子进行同步（或者切换为使用边车容器）。

3. 在 kubelet 启动 Pod 的体面关闭逻辑的同时，控制平面会评估是否将关闭的 Pod 从对应的 EndpointSlice 对象中移除，过滤条件是 Pod 被对应的 Service 以某 选择算符选定。 ReplicaSet 和其他工作负载资源不再将关闭进程中的 Pod 视为合法的、能够提供服务的副本。

   关闭动作很慢的 Pod 不应继续处理常规服务请求，而应开始终止并完成对打开的连接的处理。 一些应用程序不仅需要完成对打开的连接的处理，还需要更进一步的体面终止逻辑 - 比如：排空和完成会话。

   任何正在终止的 Pod 所对应的端点都不会立即从 EndpointSlice 中被删除，EndpointSlice API 会公开一个状态来指示其处于 终止状态。 正在终止的端点始终将其 ready 状态设置为 false（为了向后兼容 1.26 之前的版本）， 因此负载均衡器不会将其用于常规流量。

   如果需要排空正被终止的 Pod 上的流量，可以将 serving 状况作为实际的就绪状态。你可以在教程 探索 Pod 及其端点的终止行为 中找到有关如何实现连接排空的更多详细信息。

强制终止 Pod

默认情况下，所有的删除操作都会附有 30 秒钟的宽限期限。 kubectl delete 命令支持 --grace-period=<seconds> 选项，允许你重载默认值， 设定自己希望的期限值。

将宽限期限强制设置为 0 意味着立即从 API 服务器删除 Pod。 如果 Pod 仍然运行于某节点上，强制删除操作会触发 kubelet 立即执行清理操作。

使用 kubectl 时，你必须在设置 --grace-period=0 的同时额外设置 --force 参数才能发起强制删除请求。

执行强制删除操作时，API 服务器不再等待来自 kubelet 的、关于 Pod 已经在原来运行的节点上终止执行的确认消息。 API 服务器直接删除 Pod 对象，这样新的与之同名的 Pod 即可以被创建。 在节点侧，被设置为立即终止的 Pod 仍然会在被强行杀死之前获得一点点的宽限时间。

如果你需要强制删除 StatefulSet 的 Pod， 请参阅从 StatefulSet 中删除 Pod 的任务文档。

Pod 关闭和边车容器

如果你的 Pod 包含一个或多个 边车容器 （重启策略为 Always 的 Init 容器），kubelet 将延迟向这些边车容器发送 TERM 信号， 直到最后一个主容器已完全终止。边车容器将按照它们在 Pod 规约中被定义的相反顺序被终止。 这样确保了边车容器继续为 Pod 中的其他容器提供服务，直到完全不再需要为止。

这意味着主容器的慢终止也会延迟边车容器的终止。 如果在终止过程完成之前宽限期已到，Pod 可能会进入强制终止阶段。 在这种情况下，Pod 中所有剩余的容器将在某个短宽限期内被同时终止。

同样地，如果 Pod 有一个 preStop 钩子超过了终止宽限期，可能会发生紧急终止。 总体而言，如果你以前使用 preStop 钩子来控制没有边车容器 的 Pod 中容器的终止顺序， 你现在可以移除这些钩子，允许 kubelet 自动管理边车容器的终止。

Pod 的垃圾收集

对于已失败的 Pod 而言，对应的 API 对象仍然会保留在集群的 API 服务器上， 直到用户或者控制器进程显式地将其删除。

Pod 的垃圾收集器（PodGC）是控制平面的控制器，它会在 Pod 个数超出所配置的阈值 （根据 kube-controller-manager 的 terminated-pod-gc-threshold 设置）时删除已终止的 Pod（阶段值为 Succeeded 或 Failed）。 这一行为会避免随着时间演进不断创建和终止 Pod 而引起的资源泄露问题。

此外，PodGC 会清理满足以下任一条件的所有 Pod：

1. 孤儿 Pod - 绑定到不再存在的节点，
2. 计划外终止的 Pod
3. 终止过程中的 Pod，绑定到有 node.kubernetes.io/out-of-service 污点的未就绪节点。

在清理 Pod 的同时，如果它们处于非终止状态阶段，PodGC 也会将它们标记为失败。 此外，PodGC 在清理孤儿 Pod 时会添加 Pod 干扰状况。参阅 Pod 干扰状况了解更多详情。

kubelet 重启期间的 Pod 行为

如果你重启 kubelet，Pod（及其容器）即使在重启过程中也会继续运行。 如果某个节点上存在正在运行的 Pod，停止或重启该节点上的 kubelet 不会在 kubelet 自身停止之前让 kubelet 停止所有本地 Pod。 如果需要停止节点上的 Pod，可以使用 kubectl drain。

检测 kubelet 重启

当 kubelet 启动时，它会检查是否已经存在一个绑定了 Pod 的 Node。 如果该 Node 的 Ready 状况保持不变， 也就是说该状况没有从 true 变为 false，Kubernetes 就会将其检测为一次 kubelet 重启。 （也可能通过其他方式重启 kubelet，例如为修复某个节点缺陷而重启；在这些情况下， Kubernetes 会选择更安全的处理方式，例如先停止再启动 kubelet。）

当 kubelet 重启时，容器状态将基于特性门控的设置以不同方式进行管理：

• 默认情况下，kubelet 在重启后不更改容器状态。 之前设置为 ready: true 状态的容器仍然保持就绪。

  如果你停止 kubelet 的时间足够长， 导致其连续多次节点心跳检查失败， 并且在重启 kubelet 之前又等待了一段时间，Kubernetes 可能会开始从该节点驱逐 Pod。 但是，即使开始发生 Pod 驱逐，Kubernetes 也不会将这些 Pod 中的单个容器标记为 ready: false。 Pod 级别的驱逐是在控制平面因心跳失败而将节点标记为 node.kubernetes.io/not-ready 之后发生的。

• 在 Kubernetes 1.37 中，你可以选择启用一种传统的行为： 在 kubelet 重启后，总是将容器的 ready 状况修改为 false。

  这种传统行为在很长一段时间内都是默认设置的，但给 Kubernetes 用户带来了一些问题， 尤其是在大规模部署场景中。虽然此特性门控允许暂时回退到这种传统行为， 但 Kubernetes 项目建议如果你遇到相关问题，应提交 Bug 报告。 ChangeContainerStatusOnKubeletRestart 特性门控 将在未来被移除。

接下来

• 动手实践为容器生命周期时间关联处理程序。
• 动手实践配置存活态、就绪态和启动探针。
• 进一步了解容器生命周期回调。
• 进一步了解边车容器。
• 关于 API 中定义的有关 Pod 和容器状态的详细规范信息， 可参阅 API 参考文档中 Pod 的 status 字段。

2 - Pod 状况

在 Kubernetes 中，许多对象都有状况（condition）。 状况是对象所代表事物的实际状态某些方面的标记。 Pod 有状况，Kubernetes Pod 状况是控制器（以及进行故障排除的人员）了解 Pod 健康状况的重要方面。

Pod 的阶段（phase）提供了 Pod 在其生命周期中所处位置的高级摘要，但单个值无法捕捉全貌。 例如，Pod 可能处于 Running 阶段，但尚未准备好提供流量。 Pod 状况通过独立跟踪 Pod 状态的多个方面来补充阶段， 例如是否已调度、其容器是否就绪、是否正在进行调整大小， 或者 Pod 是否即将由于污点而受到干扰。

Pod 状况的结构

Pod 的状态（status）包括一个 PodConditions 数组，用于指示 Pod 是否已通过某些检查点。

PodCondition 数组的每个元素都有以下字段：

内置 Pod 状况

Kubernetes 管理以下 Pod 状况：

生命周期状况：随着 Pod 经历其生命周期而设置，大致按此顺序： PodScheduled、PodReadyToStartContainers、Initialized、ContainersReady、Ready。

其他状况：响应特定操作或事件而设置： DisruptionTarget、PodResizePending、PodResizeInProgress。

除了上述内置状况外，你还可以使用 Pod 就绪门控定义自定义状况。

生命周期 Pod 状况

随着 Pod 经历其生命周期，kubelet 大致按以下顺序设置以下状况：

1. PodScheduled：Pod 已调度到节点。
2. PodReadyToStartContainers：Pod sandbox 已成功创建并配置了网络。 sandbox 和网络由容器运行时和 CNI 插件设置。
3. Initialized：所有初始容器均已成功完成。 对于没有初始容器的 Pod，此状况在 sandbox 创建之前设置为 True。
4. ContainersReady：Pod 中的所有容器都已就绪。 容器的就绪状态由其就绪探针确定（如果已配置）。
5. Ready：Pod 能够处理请求，应添加到所有匹配的 Service 的负载均衡池中。 未 Ready 的 Pod 会从 Service 端点中移除。

你可以使用 kubectl 检查 Pod 的状况：

kubectl get pod <pod-name> -o yaml

以下显示了运行中的 Pod 的 status.conditions 的样子：

status:
  conditions:
    - type: PodScheduled
      status: "True"
      lastProbeTime: null
      lastTransitionTime: "2026-03-29T08:52:21Z"
      observedGeneration: 1
    - type: PodReadyToStartContainers
      status: "True"
      lastProbeTime: null
      lastTransitionTime: "2026-04-11T06:02:16Z"
      observedGeneration: 1
    - type: Initialized
      status: "True"
      lastProbeTime: null
      lastTransitionTime: "2026-03-29T08:52:21Z"
      observedGeneration: 1
    - type: ContainersReady
      status: "True"
      lastProbeTime: null
      lastTransitionTime: "2026-04-11T06:02:45Z"
      observedGeneration: 1
    - type: Ready
      status: "True"
      lastProbeTime: null
      lastTransitionTime: "2026-04-11T06:02:45Z"
      observedGeneration: 1

PodReadyToStartContainers

Pod 在节点上调度后，需要由 kubelet 准入并挂载任何所需的存储卷。 这些阶段完成后，kubelet 与容器运行时（使用容器运行时接口（CRI）） 协作，为 Pod 设置运行时 Sandbox 并配置网络。 PodReadyToStartContainers 状况会被添加到 Pod 的 status.conditions 字段。

当 kubelet 检测到 Pod 缺少已配置网络功能的运行时沙箱（runtime sandbox）时， 该状况会被设置为 False。这种情况发生在以下场景中：

• 在 Pod 生命周期的早期，kubelet 尚未开始使用容器运行时为 Pod 设置 sandbox。
• 在 Pod 生命周期的后期，Pod sandbox 已被销毁，原因是：
  • 节点重新启动，而 Pod 未被驱逐
  • 对于使用虚拟机进行隔离的容器运行时，Pod sandbox 虚拟机重新启动，这需要创建新的 sandbox 和新的容器网络配置

运行时插件成功完成 Pod 的 sandbox 创建和网络配置后，kubelet 将 PodReadyToStartContainers 状况设置为 True。 在 PodReadyToStartContainers 状况设置为 True 后，kubelet 可以开始拉取容器镜像并创建容器。

对于具有 Init 容器的 Pod，kubelet 在 Init 容器成功完成后 （这发生在运行时插件成功创建 sandbox 和配置网络之后）将 Initialized 状况设置为 True。 对于没有初始容器的 Pod，kubelet 在 sandbox 创建和网络配置开始之前将 Initialized 状况设置为 True。

其他 Pod 状况

以下状况不是正常 Pod 生命周期进程的一部分。 它们响应特定操作或事件而设置。

DisruptionTarget

添加专用的 Pod DisruptionTarget 状况以指示 Pod 即将由于 干扰而被删除。 该状况的 reason 字段还指示 Pod 终止的以下原因之一：

PreemptionByScheduler

Pod 即将被调度器 抢占，以便容纳具有更高优先级的新 Pod。 有关更多信息，请参阅 Pod 优先级抢占。

DeletionByTaintManager

Pod 即将被 Taint Manager（kube-controller-manager 内节点生命周期控制器的一部分）删除， 原因是 Pod 不容忍的 NoExecute 污点； 请参阅基于污点的驱逐。

EvictionByEvictionAPI

Pod 已被标记为使用 Kubernetes API 驱逐。

DeletionByPodGC

绑定到不再存在的节点的 Pod 即将被 Pod 垃圾回收删除。

TerminationByKubelet

Pod 已被 kubelet 终止，原因是节点压力驱逐、 节点体面关闭或 为系统关键 Pod 进行抢占。

在所有其他干扰场景中，例如由于超过 Pod 容器限制而导致的驱逐， Pod 不会收到 DisruptionTarget 状况，因为干扰可能是由 Pod 引起的，并且会在重试时再次发生。

除了清理 Pod 外，Pod 垃圾回收器（PodGC）还会将它们标记为失败（如果它们处于非终止阶段） （另请参阅 Pod 垃圾回收）。

使用 Job（或 CronJob）时，你可能希望将这些 Pod 干扰状况用作 Job 的 Pod 失败策略的一部分。

有关更多详细信息，请参阅干扰。

PodResizePending 和 PodResizeInProgress

kubelet 更新 Pod 的状态状况以指示调整大小请求的状态：

• type: PodResizePending：kubelet 无法立即批准请求。 message 字段提供原因说明。
  • reason: Infeasible：请求的调整大小在当前节点上不可能（例如，请求的资源超过节点拥有的资源）。
  • reason: Deferred：请求的调整大小目前不可能，但以后可能变得可行（例如，如果另一个 Pod 被移除）。 kubelet 将重试调整大小。
• type: PodResizeInProgress：kubelet 已接受调整大小并分配了资源，但更改仍在应用中。 这通常很短暂，但可能根据资源类型和运行时行为花费更长时间。 执行期间的任何错误都在 message 字段中报告（以及 reason: Error）。

如果请求的调整大小被 Deferred，kubelet 将定期重试调整大小，例如当另一个 Pod 被移除或缩容时。

有关 Pod 调整大小的更多详细信息， 请参阅调整分配给容器的 CPU 和内存资源。

增强 Pod 就绪

你的应用可以将额外的反馈或信号注入 Pod 的 .status； 这称为增强 Pod 就绪。 要使用此功能，请在 Pod 的 spec 中设置 readinessGates， 以指定 kubelet 评估 Pod 就绪的其他状况列表。 然后你实现或安装一个管理这些自定义状况的控制器， kubelet 使用该控制器作为额外输入来决定 Pod 是否就绪。

就绪门由 Pod 的 status.condition 字段的当前状态确定。 如果 Kubernetes 在 Pod 的 status.conditions 字段中找不到这样的状况， 则该状况的状态默认为 "False"。

kind: Pod
...
spec:
  readinessGates:
    - conditionType: "www.example.com/feature-1"
status:
  conditions:
    - type: Ready                              # 内置的 PodCondition
      status: "False"
      lastProbeTime: null
      lastTransitionTime: 2018-01-01T00:00:00Z
    - type: "www.example.com/feature-1"        # 额外的 PodCondition
      status: "False"
      lastProbeTime: null
      lastTransitionTime: 2018-01-01T00:00:00Z
  containerStatuses:
    - containerID: docker://abcd...
      ready: true
...

你添加的 Pod 状况必须具有符合 Kubernetes 标签键格式的名称。

Pod 就绪的状态

要为 Pod 设置这些 status.conditions，应用和 operators 应使用 Pod 状态子资源的 PATCH 操作。 你可以使用 kubectl patch 和 --subresource=status， 或使用 Kubernetes 客户端库编写代码来设置自定义 Pod 状况以实现 Pod 就绪。

对于使用自定义状况的 Pod，仅当以下两个陈述都适用时，该 Pod 才被评估为就绪：

• Pod 中的所有容器都已就绪。
• readinessGates 中指定的所有状况都为 True。

当 Pod 的容器为 Ready 但至少缺少一个自定义状况或为 False 时， kubelet 将 Pod 的 Ready 状况设置为 status: "False" 及 reason: ReadinessGatesNotReady。

接下来

• 了解 Pod 生命周期。
• 了解干扰。
• 了解容器探针以及它们如何影响 Pod 就绪。
• 了解如何就地调整 Pod 资源。

3 - Init 容器

本页提供了 Init 容器的概览。Init 容器是一种特殊容器，在 Pod 内的应用容器启动之前运行。Init 容器可以包括一些应用镜像中不存在的实用工具和安装脚本。

你可以在 Pod 的规约中与用来描述应用容器的 containers 数组平行的位置指定 Init 容器。

在 Kubernetes 中，边车容器 是在主应用容器之前启动并持续运行的容器。本文介绍 Init 容器：在 Pod 初始化期间完成运行的容器。

理解 Init 容器

每个 Pod 中可以包含多个容器， 应用运行在这些容器里面，同时 Pod 也可以有一个或多个先于应用容器启动的 Init 容器。

Init 容器与普通的容器非常像，除了如下两点：

• 它们总是运行到完成。
• 每个都必须在下一个启动之前成功完成。

如果 Pod 的 Init 容器失败，kubelet 会不断地重启该 Init 容器直到该容器成功为止。 然而，如果 Pod 对应的 restartPolicy 值为 "Never"，并且 Pod 的 Init 容器失败， 则 Kubernetes 会将整个 Pod 状态设置为失败。

为 Pod 设置 Init 容器需要在 Pod 规约中添加 initContainers 字段， 该字段以 Container 类型对象数组的形式组织，和应用的 containers 数组同级相邻。 参阅 API 参考的容器章节了解详情。

Init 容器的状态在 status.initContainerStatuses 字段中以容器状态数组的格式返回 （类似 status.containerStatuses 字段）。

与普通容器的不同之处

Init 容器支持应用容器的全部字段和特性，包括资源限制、 数据卷和安全设置。 然而，Init 容器对资源请求和限制的处理稍有不同， 在下面容器内的资源共享节有说明。

常规的 Init 容器（即不包括边车容器）不支持 lifecycle、livenessProbe、readinessProbe 或 startupProbe 字段。Init 容器必须在 Pod 准备就绪之前完成运行；而边车容器在 Pod 的生命周期内继续运行， 它支持一些探针。有关边车容器的细节请参阅边车容器。

如果为一个 Pod 指定了多个 Init 容器，这些容器会按顺序逐个运行。 每个 Init 容器必须运行成功，下一个才能够运行。当所有的 Init 容器运行完成时， Kubernetes 才会为 Pod 初始化应用容器并像平常一样运行。

与边车容器的不同之处

Init 容器在主应用容器启动之前运行并完成其任务。 与边车容器不同， Init 容器不会持续与主容器一起运行。

Init 容器按顺序完成运行，等到所有 Init 容器成功完成之后，主容器才会启动。

Init 容器不支持 lifecycle、livenessProbe、readinessProbe 或 startupProbe， 而边车容器支持所有这些探针以控制其生命周期。

Init 容器与主应用容器共享资源（CPU、内存、网络），但不直接与主应用容器进行交互。 不过这些容器可以使用共享卷进行数据交换。

使用 Init 容器

因为 Init 容器具有与应用容器分离的单独镜像，其启动相关代码具有如下优势：

• Init 容器可以包含一些安装过程中应用容器中不存在的实用工具或个性化代码。 例如，没有必要仅为了在安装过程中使用类似 sed、awk、python 或 dig 这样的工具而去 FROM 一个镜像来生成一个新的镜像。

• 应用镜像的创建者和部署者可以各自独立工作，而没有必要联合构建一个单独的应用镜像。

• 与同一 Pod 中的多个应用容器相比，Init 容器能以不同的文件系统视图运行。因此，Init 容器可以被赋予访问应用容器不能访问的 Secret 的权限。

• 由于 Init 容器必须在应用容器启动之前运行完成，因此 Init 容器提供了一种机制来阻塞或延迟应用容器的启动，直到满足了一组先决条件。 一旦前置条件满足，Pod 内的所有的应用容器会并行启动。

• Init 容器可以安全地运行实用程序或自定义代码，而在其他方式下运行这些实用程序或自定义代码可能会降低应用容器镜像的安全性。 通过将不必要的工具分开，你可以限制应用容器镜像的被攻击范围。

示例

下面是一些如何使用 Init 容器的想法：

• 等待一个 Service 完成创建，通过类似如下 Shell 命令：

  for i in {1..100}; do sleep 1; if nslookup myservice; then exit 0; fi; done; exit 1
  

• 注册这个 Pod 到远程服务器，通过在命令中调用 API，类似如下：

  curl -X POST http://$MANAGEMENT_SERVICE_HOST:$MANAGEMENT_SERVICE_PORT/register -d 'instance=$(<POD_NAME>)&ip=$(<POD_IP>)'
  

• 在启动应用容器之前等一段时间，使用类似命令：

  sleep 60
  

• 克隆 Git 仓库到卷中。

• 将配置值放到配置文件中，运行模板工具为主应用容器动态地生成配置文件。 例如，在配置文件中存放 POD_IP 值，并使用 Jinja 生成主应用配置文件。

使用 Init 容器的情况

下面的例子定义了一个具有 2 个 Init 容器的简单 Pod。 第一个等待 myservice 启动， 第二个等待 mydb 启动。 一旦这两个 Init 容器都启动完成，Pod 将启动 spec 节中的应用容器。

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app.kubernetes.io/name: MyApp
spec:
  containers:
  - name: myapp-container
    image: busybox:1.28
    command: ['sh', '-c', 'echo The app is running! && sleep 3600']
  initContainers:
  - name: init-myservice
    image: busybox:1.28
    command: ['sh', '-c', "until nslookup myservice.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo waiting for myservice; sleep 2; done"]
  - name: init-mydb
    image: busybox:1.28
    command: ['sh', '-c', "until nslookup mydb.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo waiting for mydb; sleep 2; done"]

你通过运行下面的命令启动 Pod：

kubectl apply -f myapp.yaml

输出类似于：

pod/myapp-pod created

使用下面的命令检查其状态：

kubectl get -f myapp.yaml

输出类似于：

NAME        READY     STATUS     RESTARTS   AGE
myapp-pod   0/1       Init:0/2   0          6m

或者查看更多详细信息：

kubectl describe -f myapp.yaml

输出类似于：

Name:          myapp-pod
Namespace:     default
[...]
Labels:        app.kubernetes.io/name=MyApp
Status:        Pending
[...]
Init Containers:
  init-myservice:
[...]
    State:         Running
[...]
  init-mydb:
[...]
    State:         Waiting
      Reason:      PodInitializing
    Ready:         False
[...]
Containers:
  myapp-container:
[...]
    State:         Waiting
      Reason:      PodInitializing
    Ready:         False
[...]
Events:
  FirstSeen    LastSeen    Count    From                      SubObjectPath                           Type          Reason        Message
  ---------    --------    -----    ----                      -------------                           --------      ------        -------
  16s          16s         1        {default-scheduler }                                              Normal        Scheduled     Successfully assigned myapp-pod to 172.17.4.201
  16s          16s         1        {kubelet 172.17.4.201}    spec.initContainers{init-myservice}     Normal        Pulling       pulling image "busybox"
  13s          13s         1        {kubelet 172.17.4.201}    spec.initContainers{init-myservice}     Normal        Pulled        Successfully pulled image "busybox"
  13s          13s         1        {kubelet 172.17.4.201}    spec.initContainers{init-myservice}     Normal        Created       Created container init-myservice
  13s          13s         1        {kubelet 172.17.4.201}    spec.initContainers{init-myservice}     Normal        Started       Started container init-myservice

如需查看 Pod 内 Init 容器的日志，请执行：

kubectl logs myapp-pod -c init-myservice # 查看第一个 Init 容器
kubectl logs myapp-pod -c init-mydb      # 查看第二个 Init 容器

在这一刻，Init 容器将会等待至发现名称为 mydb 和 myservice 的服务。

如下为创建这些 Service 的配置文件：

---
apiVersion: v1
kind: Service
metadata:
  name: myservice
spec:
  ports:
  - protocol: TCP
    port: 80
    targetPort: 9376
---
apiVersion: v1
kind: Service
metadata:
  name: mydb
spec:
  ports:
  - protocol: TCP
    port: 80
    targetPort: 9377

创建 mydb 和 myservice 服务的命令：

kubectl apply -f services.yaml

输出类似于：

service/myservice created
service/mydb created

这样你将能看到这些 Init 容器执行完毕，随后 my-app 的 Pod 进入 Running 状态：

kubectl get -f myapp.yaml

输出类似于：

NAME        READY     STATUS    RESTARTS   AGE
myapp-pod   1/1       Running   0          9m

这个简单例子应该能为你创建自己的 Init 容器提供一些启发。 接下来节提供了更详细例子的链接。

具体行为

在 Pod 启动过程中，每个 Init 容器会在网络和数据卷初始化之后按顺序启动。 kubelet 运行依据 Init 容器在 Pod 规约中的出现顺序依次运行之。

每个 Init 容器成功退出后才会启动下一个 Init 容器。 如果某容器因为容器运行时的原因无法启动，或以错误状态退出，kubelet 会根据 Pod 的 restartPolicy 策略进行重试。 然而，如果 Pod 的 restartPolicy 设置为 "Always"，Init 容器失败时会使用 restartPolicy 的 "OnFailure" 策略。

在所有的 Init 容器没有成功之前，Pod 将不会变成 Ready 状态。 Init 容器的端口将不会在 Service 中进行聚集。正在初始化中的 Pod 处于 Pending 状态， 但会将状况 Initializing 设置为 false。

如果 Pod 重启，所有 Init 容器必须重新执行。

对 Init 容器规约的修改仅限于容器的 image 字段。 直接更改 Init 容器的 image 字段不会重启该 Pod 或触发其重新创建。如果该 Pod 尚未启动，则该更改可能会影响 Pod 的启动方式。

对于 Pod 模板，你通常可以更改 Init 容器的任何字段；更改的影响取决于 Pod 模板的使用位置。

因为 Init 容器可能会被重启、重试或者重新执行，所以 Init 容器的代码应该是幂等的。 特别地，向任何 emptyDir 卷写入数据的代码应该对输出文件可能已经存在做好准备。

Init 容器具有应用容器的所有字段。然而 Kubernetes 禁止使用 readinessProbe， 因为 Init 容器不能定义不同于完成态（Completion）的就绪态（Readiness）。 Kubernetes 会在校验时强制执行此检查。

在 Pod 上使用 activeDeadlineSeconds 和在容器上使用 livenessProbe 可以避免 Init 容器一直重复失败。 activeDeadlineSeconds 时间包含了 Init 容器启动的时间。 但建议仅在团队将其应用程序部署为 Job 时才使用 activeDeadlineSeconds， 因为 activeDeadlineSeconds 在 Init 容器结束后仍有效果。 如果你设置了 activeDeadlineSeconds，已经在正常运行的 Pod 会被杀死。

在 Pod 中的每个应用容器和 Init 容器的名称必须唯一； 与任何其它容器共享同一个名称，会在校验时抛出错误。

容器内的资源共享

在给定的 Init、边车和应用容器执行顺序下，资源使用适用于如下规则：

• 所有 Init 容器上定义的任何特定资源的 limit 或 request 的最大值，作为 Pod 有效初始 request/limit。 如果任何资源没有指定资源限制，这被视为最高限制。
• Pod 对资源的 有效 limit/request 是如下两者中的较大者：
  • 所有应用容器对某个资源的 limit/request 之和
  • 对某个资源的有效初始 limit/request
• 基于有效 limit/request 完成调度，这意味着 Init 容器能够为初始化过程预留资源， 这些资源在 Pod 生命周期过程中并没有被使用。
• Pod 的 有效 QoS 层，与 Init 容器和应用容器的一样。

配额和限制适用于有效 Pod 的请求和限制值。

Init 容器和 Linux cgroup

在 Linux 上，Pod 级别的 CGroup 资源分配基于 Pod 的有效请求和限制值，与调度程序相同。

Pod 重启的原因

Pod 重启会导致 Init 容器重新执行，主要有如下几个原因：

• Pod 的基础设施容器 (译者注：如 pause 容器) 被重启。这种情况不多见， 必须由具备 root 权限访问节点的人员来完成。

• 当 restartPolicy 设置为 Always，Pod 中所有容器会终止而强制重启。 由于垃圾回收机制的原因， Init 容器的完成记录将会丢失。

当 Init 容器的镜像发生改变或者 Init 容器的完成记录因为垃圾收集等原因被丢失时， Pod 不会被重启。这一行为适用于 Kubernetes v1.20 及更新版本。 如果你在使用较早版本的 Kubernetes，可查阅你所使用的版本对应的文档。

接下来

进一步了解以下内容：

• 创建包含 Init 容器的 Pod
• 调试 Init 容器
• kubelet 和 kubectl 的概述。
• 探针类型： 存活态探针、就绪态探针、启动探针。
• 边车容器。

4 - 边车容器

边车容器是与主应用容器在同一个 Pod 中运行的辅助容器。 这些容器通过提供额外的服务或功能（如日志记录、监控、安全性或数据同步）来增强或扩展主应用容器的功能， 而无需直接修改主应用代码。

通常，一个 Pod 中只有一个应用容器。 例如，如果你有一个需要本地 Web 服务器的 Web 应用， 则本地 Web 服务器以边车容器形式运行，而 Web 应用本身以应用容器形式运行。

Kubernetes 中的边车容器

Kubernetes 将边车容器作为 Init 容器的一个特例来实现， Pod 启动后，边车容器仍保持运行状态。 本文档使用术语"常规 Init 容器"来明确指代仅在 Pod 启动期间运行的容器。

如果你的集群启用了 SidecarContainers 特性门控 （该特性自 Kubernetes v1.29 起默认启用），你可以为 Pod 的 initContainers 字段中列出的容器指定 restartPolicy。 这些可重新启动的边车（Sidecar） 容器独立于其他 Init 容器以及同一 Pod 内的主应用容器， 这些容器可以启动、停止和重新启动，而不会影响主应用容器和其他 Init 容器。

你还可以运行包含多个未标记为 Init 或边车容器的 Pod。 如果作为一个整体而言，某个 Pod 中的所有容器都要运行，但你不需要控制哪些容器先启动或停止，那么这种设置是合适的。 如果你使用的是不支持容器级 restartPolicy 字段的旧版本 Kubernetes，你也可以这样做。

应用示例

下面是一个包含两个容器的 Deployment 示例，其中一个容器是边车形式：

application/deployment-sidecar.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
  labels:
    app: myapp
spec:
  replicas: 1
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
        - name: myapp
          image: alpine:latest
          command: ['sh', '-c', 'while true; do echo "logging" >> /opt/logs.txt; sleep 1; done']
          volumeMounts:
            - name: data
              mountPath: /opt
      initContainers:
        - name: logshipper
          image: alpine:latest
          restartPolicy: Always
          command: ['sh', '-c', 'tail -F /opt/logs.txt']
          volumeMounts:
            - name: data
              mountPath: /opt
      volumes:
        - name: data
          emptyDir: {}

边车容器和 Pod 生命周期

如果创建 Init 容器时将 restartPolicy 设置为 Always， 则它将在整个 Pod 的生命周期内启动并持续运行。这对于运行与主应用容器分离的支持服务非常有帮助。

如果为此 Init 容器指定了 readinessProbe，其结果将用于确定 Pod 的 ready 状态。

由于这些容器被定义为 Init 容器，所以它们享有与其他 Init 容器相同的顺序和按序执行保证， 从而允许将边车容器与常规 Init 容器混合使用，支持复杂的 Pod 初始化流程。

与常规 Init 容器相比，在 initContainers 中定义的边车容器在启动后继续运行。 当 Pod 的 .spec.initContainers 中有多个条目时，这一点非常重要。 在边车风格的 Init 容器运行后（kubelet 将该 Init 容器的 started 状态设置为 true）， kubelet 启动 .spec.initContainers 这一有序列表中的下一个 Init 容器。 该状态要么因为容器中有一个正在运行的进程且没有定义启动探针而变为 true， 要么是其 startupProbe 成功而返回的结果。

在 Pod 终止时， kubelet 会推迟终止边车容器，直到主应用容器已完全停止。边车容器随后将按照它们在 Pod 规约中出现的相反顺序被关闭。 这种方法确保了在不再需要边车服务之前这些边车继续发挥作用，以支持 Pod 内的其他容器。

带边车容器的 Job

如果你定义 Job 时使用基于 Kubernetes 风格 Init 容器的边车容器， 各个 Pod 中的边车容器不会阻止 Job 在主容器结束后进入完成状态。

以下是一个具有两个容器的 Job 示例，其中一个是边车：

application/job/job-sidecar.yaml

apiVersion: batch/v1
kind: Job
metadata:
  name: myjob
spec:
  template:
    spec:
      containers:
        - name: myjob
          image: alpine:latest
          command: ['sh', '-c', 'echo "logging" > /opt/logs.txt']
          volumeMounts:
            - name: data
              mountPath: /opt
      initContainers:
        - name: logshipper
          image: alpine:latest
          restartPolicy: Always
          command: ['sh', '-c', 'tail -F /opt/logs.txt']
          volumeMounts:
            - name: data
              mountPath: /opt
      restartPolicy: Never
      volumes:
        - name: data
          emptyDir: {}

与应用容器的区别

边车容器与同一 Pod 中的应用容器并行运行。不过边车容器不执行主应用逻辑，而是为主应用提供支持功能。

边车容器具有独立的生命周期。它们可以独立于应用容器启动、停止和重启。 这意味着你可以更新、扩展或维护边车容器，而不影响主应用。

边车容器与主容器共享相同的网络和存储命名空间。这种共存使它们能够紧密交互并共享资源。

从 Kubernetes 的角度来看，边车容器的体面终止（Graceful Termination）相对不那么重要。 当其他容器耗尽了分配的体面终止时间后，边车容器将在尚未完成体面终止时间的情况下接收到 SIGTERM 信号，随后是 SIGKILL 信号。 因此，在 Pod 终止时，边车容器退出码不为 0（0 表示成功退出）是正常的， 通常应该被外部工具忽略。

与 Init 容器的区别

边车容器与主容器并行工作，扩展其功能并提供附加服务。

边车容器与主应用容器同时运行。它们在整个 Pod 的生命周期中都处于活动状态，并且可以独立于主容器启动和停止。 与 Init 容器不同， 边车容器支持探针来控制其生命周期。

边车容器可以直接与主应用容器交互，因为与 Init 容器一样， 它们总是与应用容器共享相同的网络，并且还可以选择共享卷（文件系统）。

Init 容器在主容器启动之前停止，因此 Init 容器无法与 Pod 中的应用容器交换消息。 所有数据传递都是单向的（例如，Init 容器可以将信息放入 emptyDir 卷中）。

变更边车容器的镜像不会导致 Pod 重启，但会触发容器重启。

容器内的资源共享

假如执行顺序为 Init 容器、边车容器和应用容器，则关于资源用量适用以下规则：

• 所有 Init 容器上定义的任何特定资源的 limit 或 request 的最大值，作为 Pod 有效初始 request/limit。 如果任何资源没有指定资源限制，则被视为最高限制。
• Pod 对资源的 有效 limit/request 是如下两者中的较大者：
  • 所有应用容器对某个资源的 limit/request 之和
  • Init 容器中对某个资源的有效 limit/request
• 系统基于有效的 limit/request 完成调度，这意味着 Init 容器能够为初始化过程预留资源， 而这些资源在 Pod 的生命周期中不再被使用。
• Pod 的 有效 QoS 级别，对于 Init 容器和应用容器而言是相同的。

配额和限制适用于 Pod 的有效请求和限制值。

边车容器和 Linux Cgroup

在 Linux 上，Pod Cgroup 的资源分配基于 Pod 级别的有效资源请求和限制，这一点与调度器相同。

接下来

• 了解如何采用边车容器。
• 阅读关于原生边车容器的博文。
• 阅读如何创建具有 Init 容器的 Pod。
• 了解探针类型： 存活态探针、就绪态探针、启动探针。
• 了解 Pod 开销。

5 - 临时容器

本页面概述了临时容器：一种特殊的容器，该容器在现有 Pod 中临时运行，以便完成用户发起的操作，例如故障排查。 你会使用临时容器来检查服务，而不是用它来构建应用程序。

了解临时容器

Pod 是 Kubernetes 应用程序的基本构建块。 由于 Pod 是一次性且可替换的，因此一旦 Pod 创建，就无法将容器加入到 Pod 中。 取而代之的是，通常使用 Deployment 以受控的方式来删除并替换 Pod。

有时有必要检查现有 Pod 的状态。例如，对于难以复现的故障进行排查。 在这些场景中，可以在现有 Pod 中运行临时容器来检查其状态并运行任意命令。

什么是临时容器？

临时容器与其他容器的不同之处在于，它们缺少对资源或执行的保证，并且永远不会自动重启， 因此不适用于构建应用程序。 临时容器使用与常规容器相同的 ContainerSpec 节来描述，但许多字段是不兼容和不允许的。

• 临时容器没有端口配置，因此像 ports、livenessProbe、readinessProbe 这样的字段是不允许的。
• Pod 资源分配是不可变的，因此 resources 配置是不允许的。
• 有关允许字段的完整列表，请参见 EphemeralContainer 参考文档。

临时容器是使用 API 中的一种特殊的 ephemeralcontainers 处理器进行创建的， 而不是直接添加到 pod.spec 段，因此无法使用 kubectl edit 来添加一个临时容器。

与常规容器一样，将临时容器添加到 Pod 后，将不能更改或删除临时容器。

临时容器的用途

当由于容器崩溃或容器镜像不包含调试工具而导致 kubectl exec 无用时， 临时容器对于交互式故障排查很有用。

尤其是，Distroless 镜像 允许用户部署最小的容器镜像，从而减少攻击面并减少故障和漏洞的暴露。 由于 distroless 镜像不包含 Shell 或任何的调试工具，因此很难单独使用 kubectl exec 命令进行故障排查。

使用临时容器时， 启用进程名字空间共享很有帮助， 可以查看其他容器中的进程。

接下来

• 了解如何使用临时调试容器来进行调试

6 - 存活、就绪和启动探针

Kubernetes 允许你定义 探针（Probe） 来持续监控 Pod 中容器的健康状况。 探针是由 kubelet 对容器周期性执行的诊断。为执行诊断，kubelet 或是在容器内执行代码，或是发起一个网络请求。

根据探针的结果，Kubernetes 可以重启不健康的容器，或者停止向尚未就绪的容器发送流量。

探针的类型

kubelet 可以选择对运行中的容器执行三种探针，并对探针的结果作出响应；每种探针有不同的用途：

• 启动探针
• 存活探针
• 就绪探针

启动探针

启动探针（Startup Probe）用于检查容器内的应用是否已经启动。 如果配置了启动探针，Kubernetes 将在启动探针成功之前不执行存活探针或就绪探针， 从而为应用留出足够的时间完成初始化。

启动探针仅在启动时执行，不像存活探针和就绪探针那样周期性地运行。 如果启动探针失败，kubelet 将杀死容器， 容器随后将依据其重启策略进行处理。

存活探针

存活探针（Liveness Probe）决定何时重启容器。 例如，存活探针可以捕获死锁 —— 即应用在运行但无法取得进展。 在此类情况下重启容器，有助于提高应用的可用性，即使应用本身存在缺陷。

如果某容器的存活探针失败次数超过配置的容忍次数，kubelet 将重启该容器。 存活探针不会等待就绪探针成功。如果你希望在执行存活探针之前先等待， 可以定义 initialDelaySeconds，或者使用启动探针。

就绪探针

就绪探针（Readiness Probe）决定容器何时准备好接受流量。 这种探针在等待应用执行耗时的初始任务时非常有用， 例如建立网络连接、加载文件和预热缓存等。 就绪探针在容器生命周期的后期也很有用，例如从临时故障或过载中恢复时。

如果就绪探针返回失败状态， EndpointSlice 控制器会将 Pod 的 IP 地址从与该 Pod 匹配的所有 Service 的 EndpointSlice 中移除。

就绪探针在容器的整个生命周期内持续运行。

何时使用各类探针

何时使用启动探针？

对于包含启动时间较长的容器的 Pod，启动探针非常有用。你不必设置较长的存活探针时间间隔， 而是为容器启动阶段单独配置探针参数，允许使用比存活探针时间间隔更长的时间。

如果你的容器通常需要超过 \( initialDelaySeconds + failureThreshold \times periodSeconds \) 的时间启动， 你应该指定一个启动探针，对存活探针所使用的同一端点执行检查。 periodSeconds 的默认值是 10 秒。 你应将其 failureThreshold 设置得足够高，以便容器能够启动， 同时不必更改存活探针的默认值。这种设置有助于防范死锁状况。

何时使用存活探针？

如果你的容器中的进程在遇到问题或变得不健康时能够自行崩溃， 那么你不一定需要存活探针；kubelet 将根据 Pod 的 restartPolicy 自动执行正确的操作。

如果你希望容器在探针失败时被杀死并重新启动， 那么请指定一个存活探针，并将 restartPolicy 设置为 Always 或 OnFailure。

存活探针的一种常见模式是使用与就绪探针相同的低成本 HTTP 端点， 但设置较高的 failureThreshold。 这样可以确保在容器被强制杀死之前，Pod 会有一段时间被观察为未就绪状态。

何时使用就绪探针？

如果你希望仅在探针成功时才开始向 Pod 发送流量，请指定就绪探针。 就绪探针可以与存活探针相同，但规约中存在就绪探针意味着 Pod 启动时不接收任何流量， 只有在探针开始成功后才开始接收流量。

你也可以使用就绪探针让容器在维护期间将自身下线， 方法是检查一个专用于就绪检查的端点，与存活探针所使用的端点不同。

当你的应用对后端服务有强依赖时，你可以同时实现存活探针和就绪探针。 当应用自身健康时存活探针通过，但就绪探针还会检查所需的每个后端服务是否可用。 这有助于避免将流量导向只能以错误信息响应的 Pod。

对于在启动期间需要加载大量数据、配置文件或执行迁移操作的容器，请考虑使用启动探针。 不过，如果你希望区分应用已经失败和应用仍在处理启动数据这两种情况， 可能更适合使用就绪探针。

检查机制

使用探针检查容器有四种不同的方法。每个探针必须恰好定义这四种机制中的一种：

exec

在容器内执行指定的命令。如果命令以状态码 0 退出，则认为诊断成功。

grpc

使用 gRPC 执行远程过程调用。 目标应实现 gRPC 健康检查。 如果响应的 status 为 SERVING，则认为诊断成功。 更多细节参阅 gRPC 探针。

httpGet

针对 Pod IP 地址上指定端口和路径执行 HTTP GET 请求。 如果响应的状态码大于等于 200 且小于 400，则认为诊断成功。 更多细节参阅 HTTP 探针。

tcpSocket

针对 Pod IP 地址上指定端口执行 TCP 检查。 如果该端口是开放的，则认为诊断成功。 如果远程系统（容器）在打开连接后立即将其关闭，这也算作健康。 更多细节参阅 TCP 探针。

探针结果

kubelet 评估每次探针执行的结果，并据此采取相应措施。每个探针的结果有以下三种之一：

Success

容器通过了诊断。

Failure

容器未通过诊断。对于存活探针和启动探针，kubelet 会杀死容器， 容器随后依据其重启策略进行处理。 对于就绪探针，kubelet 会将容器标记为未就绪，Pod 将停止从与之匹配的 Service 接收流量。

Unknown

诊断失败（不应采取任何行动，kubelet 将继续执行进一步的检查）。

如果容器未提供某种特定探针，kubelet 始终将其结果视为 Success。 对于就绪探针，在初始延迟之前，结果被视为 Failure。

配置字段

探针有若干字段， 可用来更精确地控制启动、存活和就绪检查的行为。例如：

apiVersion: v1
kind: Pod
metadata:
  name: probe-example
spec:
  containers:
  - name: app
    image: registry.k8s.io/e2e-test-images/agnhost:2.40
    ports:
    - containerPort: 8080
    startupProbe:
      httpGet:
        path: /healthz
        port: 8080
      failureThreshold: 30
      periodSeconds: 10
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
      initialDelaySeconds: 10
      periodSeconds: 5
      timeoutSeconds: 3
      failureThreshold: 3
    readinessProbe:
      httpGet:
        path: /ready
        port: 8080
      periodSeconds: 5

initialDelaySeconds

容器启动后到启动、存活或就绪探针开始执行之间的秒数。 如果定义了启动探针，则存活探针和就绪探针的延迟在启动探针成功之前不会开始计时。 在某些较早的 Kubernetes 版本中，如果 periodSeconds 被设置为高于 initialDelaySeconds 的值， initialDelaySeconds 可能会被忽略。然而在当前版本中，initialDelaySeconds 始终被遵守， 探针只有在初始延迟之后才会启动。默认为 0 秒。最小值为 0。

periodSeconds

执行探针的频率（以秒为单位）。默认为 10 秒。最小值为 1。 当容器未就绪时，就绪探针可能在 periodSeconds 配置的间隔之外的时刻执行。 这是为了让 Pod 更快地变为就绪状态。

timeoutSeconds

探针超时时间（以秒为单位）。默认为 1 秒。最小值为 1。

successThreshold

探针在失败之后被视为成功所需的最小连续成功次数。默认值为 1。 对于存活探针和启动探针，该值必须为 1。最小值为 1。

failureThreshold

探针连续失败 failureThreshold 次之后，Kubernetes 认为整体检查已失败： 容器未就绪/未健康/不存活。默认为 3。最小值为 1。 对于启动探针或存活探针的情形，如果至少有 failureThreshold 个探针失败， Kubernetes 会将容器视为不健康，并触发该特定容器的重启。 kubelet 会遵从该容器的 terminationGracePeriodSeconds 设置。 对于失败的就绪探针，kubelet 会继续运行检查失败的容器并继续运行更多探针； 由于检查失败，kubelet 会将 Pod 的 Ready 状况设置为 false。

terminationGracePeriodSeconds

为 kubelet 配置一个宽限期，用于在触发关闭失败容器与强制容器运行时停止该容器之间等待。 默认值为继承 Pod 层面的 terminationGracePeriodSeconds 值（如果未指定则为 30 秒），最小值为 1。 更多细节参阅探针层面的 terminationGracePeriodSeconds。

探针层面的 terminationGracePeriodSeconds

在 1.25 及以上版本中，用户可以将探针层面的 terminationGracePeriodSeconds 作为探针规约的一部分来设置。 当 Pod 层面和探针层面的 terminationGracePeriodSeconds 都被设置时， kubelet 将使用探针层面的值。

在设置 terminationGracePeriodSeconds 时，请注意以下几点：

• 如果 Pod 上存在探针层面的 terminationGracePeriodSeconds 字段， kubelet 始终会遵守该字段。
• 如果你的现有 Pod 设置了 terminationGracePeriodSeconds 字段， 并且你不再希望使用按探针配置的终止宽限期，你必须删除这些现有的 Pod。

例如：

spec:
  terminationGracePeriodSeconds: 3600  # Pod 级别
  containers:
  - name: test
    image: ...

    ports:
    - name: liveness-port
      containerPort: 8080

    livenessProbe:
      httpGet:
        path: /healthz
        port: liveness-port
      failureThreshold: 1
      periodSeconds: 60
      # 复写 Pod 级别 terminationGracePeriodSeconds
      terminationGracePeriodSeconds: 60

探针层面的 terminationGracePeriodSeconds 不能为就绪探针设置。 API 服务器将拒绝这种设置。

探针机制详解

HTTP 探针

HTTP 探针可以在 httpGet 上设置以下额外字段：

• host：要连接的主机名，默认为 Pod IP。你可能更希望在 httpHeaders 中设置 Host。
• scheme：用于连接主机的协议（HTTP 或 HTTPS）。默认为 "HTTP"。
• path：HTTP 服务器上要访问的路径。默认为 "/"。
• httpHeaders：请求中要设置的自定义标头。HTTP 允许重复的标头。
• port：要在容器上访问的端口的名称或编号。编号必须在 1 到 65535 之间。
• protocol：探针请求所使用的协议。默认为 HTTP1。 设置为 HTTP2 后将通过 HTTP/2 明文（h2c）进行探测。要求启用 H2CContainerProbe 特性门控。

对于 HTTP 探针，kubelet 向指定的端口和路径发送 HTTP 请求来执行检查。 kubelet 会将探针发送到 Pod 的 IP 地址， 除非地址被 httpGet 中的可选 host 字段覆盖。 如果 scheme 字段被设置为 HTTPS，kubelet 会发送 HTTPS 请求并跳过证书验证。 在大多数场景下，你不需要设置 host 字段。 下面是一个需要设置的场景：假设容器监听 127.0.0.1，且 Pod 的 hostNetwork 字段为 true。 此时 httpGet 下的 host 应被设置为 127.0.0.1。 如果你的 Pod 依赖虚拟主机（这可能是更常见的情况）， 你不应使用 host，而是应该在 httpHeaders 中设置 Host 标头。

对于 HTTP 探针，除了必需的 Host 标头之外，kubelet 还会发送两个请求标头：

• User-Agent，默认值为 kube-probe/1.37， 其中 1.37 是 kubelet 的版本。
• Accept，默认值为 */*。

你可以通过为探针定义 httpHeaders 来覆盖这些标头。例如：

livenessProbe:
  httpGet:
    httpHeaders:
      - name: Accept
        value: application/json

startupProbe:
  httpGet:
    httpHeaders:
      - name: User-Agent
        value: MyUserAgent

你也可以通过将其设置为空值来移除这两个标头。

livenessProbe:
  httpGet:
    httpHeaders:
      - name: Accept
        value: ""

startupProbe:
  httpGet:
    httpHeaders:
      - name: User-Agent
        value: ""

你可以通过将 protocol 字段设置为 HTTP2，配置 HTTP 探针使用 HTTP/2 明文（h2c）。 当 protocol 设置为 HTTP2 时，kubelet 将使用 h2c（基于明文 TCP 的 HTTP/2），而非 HTTP/1.1。 默认 protocol 为 HTTP1。 设置 protocol: HTTP2 要求 scheme: HTTP（默认值）；API 服务器会拒绝 protocol: HTTP2 与 scheme: HTTPS 的组合。 详情参见将 HTTP/2 明文（h2c）用于 HTTP 探针。

重定向处理

当 kubelet 使用 HTTP 探测容器时，只有当重定向目标是同一主机时才会跟随重定向。 这包括将协议从 HTTP 更改为 HTTPS 的重定向， 即使探针被配置为 scheme: HTTP。

如果重定向到不同的主机名，kubelet 不会跟随该重定向。 此时，kubelet 会将探针视为成功，并记录一个 ProbeWarning 事件。

如果 kubelet 跟随重定向并累计收到 11 次或以上的重定向， 探针被视为成功并记录一个 ProbeWarning 事件。例如：

Events:
  Type     Reason        Age                     From               Message
  ----     ------        ----                    ----               -------
  Normal   Scheduled     29m                     default-scheduler  Successfully assigned default/httpbin-7b8bc9cb85-bjzwn to daocloud
  Normal   Pulling       29m                     kubelet            Pulling image "docker.io/kennethreitz/httpbin"
  Normal   Pulled        24m                     kubelet            Successfully pulled image "docker.io/kennethreitz/httpbin" in 5m12.402735213s
  Normal   Created       24m                     kubelet            Created container httpbin
  Normal   Started       24m                     kubelet            Started container httpbin
 Warning  ProbeWarning  4m11s (x1197 over 24m)  kubelet            Readiness probe warning: Probe terminated redirects

TCP 探针

对于 TCP 探针，kubelet 在节点上而不是在 Pod 中建立探测连接， 这意味着你不能在 host 参数中使用服务名称，因为 kubelet 无法解析它。

gRPC 探针

如果你的应用实现了 gRPC 健康检查协议， 你可以配置 Kubernetes 使用该协议来执行应用启动、存活或就绪检查。

下面是一个清单示例：

pods/probe/grpc-liveness.yaml

apiVersion: v1
kind: Pod
metadata:
  name: etcd-with-grpc
spec:
  containers:
  - name: etcd
    image: registry.k8s.io/etcd:3.5.1-0
    command: [ "/usr/local/bin/etcd", "--data-dir",  "/var/lib/etcd", "--listen-client-urls", "http://0.0.0.0:2379", "--advertise-client-urls", "http://127.0.0.1:2379", "--log-level", "debug"]
    ports:
    - containerPort: 2379
    livenessProbe:
      grpc:
        port: 2379
      initialDelaySeconds: 10

要使用 gRPC 探针，必须配置 port。 如果你想区分不同类型的探针和针对不同特性的探针，可以使用 service 字段。 你可以将 service 设置为 liveness， 并让你的 gRPC 健康检查端点对此请求作出与设置 service 为 readiness 时不同的响应。 这使你能够使用同一端点完成不同种类的容器健康检查，而不必监听两个不同的端口。 如果你想指定自己的自定义服务名称并同时指定一种探针类型， Kubernetes 项目建议你使用将两者连接起来的名称。 例如：myservice-liveness（使用 - 作为分隔符）。

配置问题（例如：端口或服务不正确、未实现健康检查协议）被视为探针失败，类似于 HTTP 和 TCP 探针。

你可以通过将 mode 字段设置为 TLS，配置 gRPC 探针通过 TLS 连接。 当 mode 设置为 TLS 时，kubelet 将使用带 InsecureSkipVerify 的 TLS（不验证服务器证书）。 默认 mode 为 Plaintext。 详情参见对 gRPC 探针使用 TLS。

接下来

• 学习如何配置存活、就绪和启动探针。
• 关于探针相关字段的完整规约，参阅 API 参考： Pod、 Container、 Probe

7 - 干扰（Disruptions）

本指南针对的是希望构建高可用性应用的应用所有者，他们有必要了解可能发生在 Pod 上的干扰类型。

文档同样适用于想要执行自动化集群操作（例如升级和自动扩展集群）的集群管理员。

自愿干扰和非自愿干扰

Pod 不会消失，除非有人（用户或控制器）将其销毁，或者出现了不可避免的硬件或软件系统错误。

我们把这些不可避免的情况称为应用的非自愿干扰（Involuntary Disruptions）。例如：

• 节点下层物理机的硬件故障
• 集群管理员错误地删除虚拟机（实例）
• 云提供商或虚拟机管理程序中的故障导致的虚拟机消失
• 内核错误
• 节点由于集群网络隔离从集群中消失
• 由于节点资源不足导致 Pod 被驱逐。

除了资源不足的情况，大多数用户应该都熟悉这些情况；它们不是特定于 Kubernetes 的。

我们称其他情况为自愿干扰（Voluntary Disruptions）。 包括由应用所有者发起的操作和由集群管理员发起的操作。 典型的应用所有者的操作包括：

• 删除 Deployment 或其他管理 Pod 的控制器
• 更新了 Deployment 的 Pod 模板导致 Pod 重启
• 直接删除 Pod（例如，因为误操作）

集群管理员操作包括：

• 腾空（drain）节点进行修复或升级。
• 从集群中腾空节点以缩小集群（了解节点自动扩缩）。
• 从节点中移除一个 Pod，以允许其他 Pod 使用该节点。

这些操作可能由集群管理员直接执行，也可能由集群管理员所使用的自动化工具执行， 或者由集群托管提供商自动执行。

咨询集群管理员或联系云提供商，或者查询发布文档，以确定是否为集群启用了任何资源干扰源。 如果没有启用，可以不用创建 Pod Disruption Budgets（Pod 干扰预算）。

处理干扰

以下是减轻非自愿干扰的一些方法：

• 确保 Pod 在请求中给出所需资源。
• 如果需要更高的可用性，请复制应用。 （了解有关运行多副本的无状态 和有状态应用的信息。）
• 为了在运行复制应用时获得更高的可用性，请跨机架（使用 反亲和性） 或跨区域（如果使用多区域集群）扩展应用。

自愿干扰的频率各不相同。在一个基本的 Kubernetes 集群中，没有自愿干扰（只有用户触发的干扰）。 然而，集群管理员或托管提供商可能运行一些可能导致自愿干扰的额外服务。 例如，节点软更新可能导致自愿干扰。 另外，集群（节点）自动缩放的某些实现可能导致碎片整理和紧缩节点的自愿干扰。 集群管理员或托管提供商应该已经记录了各级别的自愿干扰（如果有的话）。 有些配置选项，例如在 Pod 规约中使用 PriorityClasses 也会产生自愿（和非自愿）的干扰。

干扰预算

即使你会经常引入自愿性干扰，Kubernetes 提供的功能也能够支持你运行高度可用的应用。

作为一个应用的所有者，你可以为每个应用创建一个 PodDisruptionBudget（PDB）。 PDB 将限制在同一时间因自愿干扰导致的多副本应用中发生宕机的 Pod 数量。 例如，基于票选机制的应用希望确保运行中的副本数永远不会低于票选所需的数量。 Web 前端可能希望确保提供负载的副本数量永远不会低于总数的某个百分比。

集群管理员和托管提供商应该使用遵循 PodDisruptionBudgets 的接口 （通过调用Eviction API）， 而不是直接删除 Pod 或 Deployment。

例如，kubectl drain 命令可以用来标记某个节点即将停止服务。 运行 kubectl drain 命令时，工具会尝试驱逐你所停服的节点上的所有 Pod。 kubectl 代表你所提交的驱逐请求可能会暂时被拒绝， 所以该工具会周期性地重试所有失败的请求， 直到目标节点上的所有的 Pod 都被终止，或者达到配置的超时时间。

PDB 指定应用可以容忍的副本数量（相当于应该有多少副本）。 例如，具有 .spec.replicas: 5 的 Deployment 在任何时间都应该有 5 个 Pod。 如果 PDB 允许其在某一时刻有 4 个副本，那么驱逐 API 将允许同一时刻仅有一个（而不是两个）Pod 自愿干扰。

使用标签选择器来指定构成应用的一组 Pod，这与应用的控制器（Deployment、StatefulSet 等） 选择 Pod 的逻辑一样。

Pod 的“预期”数量由管理这些 Pod 的工作负载资源的 .spec.replicas 参数计算出来的。 控制平面通过检查 Pod 的 .metadata.ownerReferences 来发现关联的工作负载资源。

PDB 无法防止非自愿干扰； 但它们确实计入预算。

由于应用的滚动升级而被删除或不可用的 Pod 确实会计入干扰预算， 但是工作负载资源（如 Deployment 和 StatefulSet）在进行滚动升级时不受 PDB 的限制。 应用更新期间的故障处理方式是在对应的工作负载资源的 spec 中配置的。

建议在你的 PodDisruptionBudget 中将 不健康 Pod 驱逐策略 设置为 AlwaysAllow 以支持在节点腾空期间驱逐行为不当的应用程序。 默认行为是等待应用程序 Pod 变得健康， 然后才能继续执行腾空。

当使用驱逐 API 驱逐 Pod 时，Pod 会被体面地 终止， 期间会参考 PodSpec 中的 terminationGracePeriodSeconds 配置值。

PodDisruptionBudget 例子

假设集群有 3 个节点，node-1 到 node-3。集群上运行了一些应用。 其中一个应用有 3 个副本，分别是 pod-a，pod-b 和 pod-c。 另外，还有一个不带 PDB 的无关 pod pod-x 也同样显示出来。 最初，所有的 Pod 分布如下：

3 个 Pod 都是 deployment 的一部分，并且共同拥有同一个 PDB，要求 3 个 Pod 中至少有 2 个 Pod 始终处于可用状态。

例如，假设集群管理员想要重启系统，升级内核版本来修复内核中的缺陷。 集群管理员首先使用 kubectl drain 命令尝试腾空 node-1 节点。 命令尝试驱逐 pod-a 和 pod-x。操作立即就成功了。 两个 Pod 同时进入 terminating 状态。这时的集群处于下面的状态：

Deployment 控制器观察到其中一个 Pod 正在终止，因此它创建了一个替代 Pod pod-d。 由于 node-1 被封锁（cordon），pod-d 落在另一个节点上。 同样其他控制器也创建了 pod-y 作为 pod-x 的替代品。

（注意：对于 StatefulSet 来说，pod-a（也称为 pod-0）需要在替换 Pod 创建之前完全终止， 替代它的也称为 pod-0，但是具有不同的 UID。除此之外，此示例也适用于 StatefulSet。）

当前集群的状态如下：

在某一时刻，Pod 被终止，集群如下所示：

此时，如果一个急躁的集群管理员试图腾空（drain）node-2 或 node-3，drain 命令将被阻塞， 因为对于 Deployment 来说只有 2 个可用的 Pod，并且它的 PDB 至少需要 2 个。 经过一段时间，pod-d 变得可用。

集群状态如下所示：

现在，集群管理员试图腾空（drain）node-2。 drain 命令将尝试按照某种顺序驱逐两个 Pod，假设先是 pod-b，然后是 pod-d。 命令成功驱逐 pod-b，但是当它尝试驱逐 pod-d时将被拒绝，因为对于 Deployment 来说只剩一个可用的 Pod 了。

Deployment 创建 pod-b 的替代 Pod pod-e。 因为集群中没有足够的资源来调度 pod-e，drain 命令再次阻塞。集群最终将是下面这种状态：

此时，集群管理员需要增加一个节点到集群中以继续升级操作。

可以看到 Kubernetes 如何改变干扰发生的速率，根据：

• 应用需要多少个副本
• 优雅关闭应用实例需要多长时间
• 启动应用新实例需要多长时间
• 控制器的类型
• 集群的资源能力

Pod 干扰状况

Pod 会被添加一个 DisruptionTarget 状况， 用来表明该 Pod 因为发生干扰而被删除。 状况中的 reason 字段进一步给出 Pod 终止的原因，如下：

PreemptionByScheduler

Pod 将被调度器抢占， 目的是接受优先级更高的新 Pod。 要了解更多的相关信息，请参阅 Pod 优先级和抢占。

DeletionByTaintManager

由于 Pod 不能容忍 NoExecute 污点，Pod 将被 Taint Manager（kube-controller-manager 中节点生命周期控制器的一部分）删除； 请参阅基于污点的驱逐。

EvictionByEvictionAPI

Pod 已被标记为通过 Kubernetes API 驱逐。

DeletionByPodGC

绑定到一个不再存在的 Node 上的 Pod 将被 Pod 垃圾收集删除。

TerminationByKubelet

Pod 由于节点压力驱逐、 节点体面关闭 或系统关键 Pod的抢占而被 kubelet 终止。

在所有其他中断场景中，例如由于超出 [Pod 容器限制]而被驱逐，DisruptionTarget 状况不会被添加到 Pod 上， 因为中断可能是由 Pod 引起的，并且会在重试时再次发生。

在清理 Pod 的同时，如果这些 Pod 处于非终止阶段， 则 Pod 垃圾回收器 (PodGC) 也会将这些 Pod 标记为失效 （另见 Pod 垃圾回收）。

使用 Job（或 CronJob）时，你可能希望将这些 Pod 干扰状况作为 Job Pod 失效策略的一部分。

分离集群所有者和应用所有者角色

通常，将集群管理者和应用所有者视为彼此了解有限的独立角色是很有用的。这种责任分离在下面这些场景下是有意义的：

• 当有许多应用团队共用一个 Kubernetes 集群，并且有自然的专业角色
• 当第三方工具或服务用于集群自动化管理

Pod 干扰预算通过在角色之间提供接口来支持这种分离。

如果你的组织中没有这样的责任分离，则可能不需要使用 Pod 干扰预算。

如何在集群上执行干扰性操作

如果你是集群管理员，并且需要对集群中的所有节点执行干扰操作，例如节点或系统软件升级，则可以使用以下选项

• 接受升级期间的停机时间。
• 故障转移到另一个完整的副本集群。
  • 没有停机时间，但是对于重复的节点和人工协调成本可能是昂贵的。
• 编写可容忍干扰的应用和使用 PDB。
  • 不停机。
  • 最小的资源重复。
  • 允许更多的集群管理自动化。
  • 编写可容忍干扰的应用是棘手的，但对于支持容忍自愿干扰所做的工作，和支持自动扩缩和容忍非 自愿干扰所做工作相比，有大量的重叠

接下来

• 参考配置 Pod 干扰预算中的方法来保护你的应用。

• 进一步了解腾空节点的信息。

• 了解更新 Deployment 的过程，包括如何在其进程中维持应用的可用性

8 - Pod QoS 类

本页介绍 Kubernetes 中的 服务质量（Quality of Service，QoS） 类， 阐述 Kubernetes 如何根据为 Pod 中的容器指定的资源约束为每个 Pod 设置 QoS 类。 Kubernetes 依赖这种分类来决定当 Node 上没有足够可用资源时要驱逐哪些 Pod。

QoS 类

Kubernetes 对你运行的 Pod 进行分类，并将每个 Pod 分配到特定的 QoS 类中。 Kubernetes 使用这种分类来影响不同 Pod 被处理的方式。Kubernetes 基于 Pod 中容器的资源请求进行分类， 同时确定这些请求如何与资源限制相关。 这称为服务质量 (QoS) 类。 Kubernetes 基于每个 Pod 中容器的资源请求和限制为 Pod 设置 QoS 类。Kubernetes 使用 QoS 类来决定从遇到节点压力的 Node 中驱逐哪些 Pod。可选的 QoS 类有 Guaranteed、Burstable 和 BestEffort。 当一个 Node 耗尽资源时，Kubernetes 将首先驱逐在该 Node 上运行的 BestEffort Pod， 然后是 Burstable Pod，最后是 Guaranteed Pod。当这种驱逐是由于资源压力时， 只有超出资源请求的 Pod 才是被驱逐的候选对象。

Guaranteed

Guaranteed Pod 具有最严格的资源限制，并且最不可能面临驱逐。 在这些 Pod 超过其自身的限制或者没有可以从 Node 抢占的低优先级 Pod 之前， 这些 Pod 保证不会被杀死。这些 Pod 不可以获得超出其指定 limit 的资源。这些 Pod 也可以使用 static CPU 管理策略来使用独占的 CPU。

判据

Pod 被赋予 Guaranteed QoS 类的几个判据：

• Pod 中的每个容器必须有内存 limit 和内存 request，两者都必须大于零。
• 对于 Pod 中的每个容器，内存 limit 必须等于内存 request。
• Pod 中的每个容器必须有 CPU limit 和 CPU request，两者都必须大于零。
• 对于 Pod 中的每个容器，CPU limit 必须等于 CPU request。

如果 Pod 使用的是 Pod 级别资源：

• Pod 必须设置 Pod 级别的内存 limit 和内存 request，并且这两个值必须相等。
• Pod 必须设置 Pod 级别的 CPU limit 和 CPU request，并且这两个值必须相等。

Burstable

Burstable Pod 有一些基于 request 的资源下限保证，但不需要特定的 limit。 如果未指定 limit，则默认为其 limit 等于 Node 容量，这允许 Pod 在资源可用时灵活地增加其资源。 在由于 Node 资源压力导致 Pod 被驱逐的情况下，只有在所有 BestEffort Pod 被驱逐后 这些 Pod 才会被驱逐。因为 Burstable Pod 可以包括没有资源 limit 或资源 request 的容器， 所以 Burstable Pod 可以尝试使用任意数量的节点资源。

判据

Pod 被赋予 Burstable QoS 类的几个判据：

• Pod 不满足针对 QoS 类 Guaranteed 的判据。
• Pod 中至少一个容器有内存或 CPU 的 request 或 limit，或者 Pod 本身设置了 Pod 级别的内存或 CPU 的 request 或 limit。

BestEffort

BestEffort QoS 类中的 Pod 可以使用未专门分配给其他 QoS 类中的 Pod 的节点资源。 例如若你有一个节点有 16 核 CPU 可供 kubelet 使用，并且你将 4 核 CPU 分配给一个 Guaranteed Pod， 那么 BestEffort QoS 类中的 Pod 可以尝试任意使用剩余的 12 核 CPU。

如果节点遇到资源压力，kubelet 将优先驱逐 BestEffort Pod。

判据

如果 Pod 不满足 Guaranteed 或 Burstable 的判据，则它的 QoS 类为 BestEffort。 换言之，只有当 Pod 中的所有容器没有内存 limit 或内存 request，也没有 CPU limit 或 CPU request，且 Pod 本身 也没有设置任何 Pod 级别的内存或 CPU 的 limit 或 request 时， Pod 才是 BestEffort。Pod 中的容器可以请求（除 CPU 或内存之外的） 其他资源并且仍然被归类为 BestEffort。

使用 cgroup v2 的内存 QoS

内存 QoS 使用 CGroup v2 的内存控制器来管理 Kubernetes 中的内存抑制和保护。 它使用 Pod 的 QoS 类来决定应用哪些 CGroup 设置，但不会改变 Pod 的分类方式。

默认的 kubelet 配置未启用内存节流或内存保护。 要启用任一行为，请分别配置 memoryThrottlingFactor 或 memoryReservationPolicy。

内存抑制

内存节流由 kubelet 配置字段 memoryThrottlingFactor 控制。 其默认值为 nil，这意味着 kubelet 不会设置 memory.high。 要启用内存节流，请将 memoryThrottlingFactor 设置为大于 0 且小于或等于 1 的值。

对于 Burstable 级别的 Pod，kubelet 使用 memory.high 来在工作负载达到其硬限制（memory.max）之前节流内存分配。 容器的抑制阈值的计算方式为：

memory.high = requests + memoryThrottlingFactor * (limits - requests)

例如，将 memoryThrottlingFactor 设置为 0.9 时，一个 request 为 256 MiB、limit 为 1 GiB 的容器，其 memory.high 会被设置为约 947 MiB。 如果一个 Burstable Pod 没有内存限制，kubelet 会使用节点可分配内存来代替该限制。

对于 BestEffort 级别的 Pod（没有内存 request 或 limit），kubelet 会以零作为 request、以节点可分配内存代替 limit 来计算 memory.high。 Guaranteed 级别的 Pod 不会被设置 memory.high，因为其 request 等于 limit。

配置内存预留

内存预留通过 kubelet 配置字段 memoryReservationPolicy 进行控制：

• None （默认）：kubelet 不为容器和 Pod 设置 memory.min 或 memory.low。内核不会硬锁定任何内存。
• TieredReservation：kubelet 根据 Pod 的 QoS 类设置分层内存保护：
  • Guaranteed Pod：设置 memory.min 为内存请求值。内核在任何情况下都不会回收此内存。
  • Burstable Pod：设置 memory.low 为内存请求值。内核优先保留此内存，但在极端压力下可能会回收它。
  • BestEffort Pod：不设置内存保护。

例如，以下 kubelet 配置启用了系数为 0.9 的内存限流以及分层内存保护：

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
memoryThrottlingFactor: 0.9
memoryReservationPolicy: TieredReservation

你可以独立配置任一字段。省略 memoryThrottlingFactor 可使 kubelet 不设置 memory.high，或设置 memoryReservationPolicy: None 以禁用内存保护。

由于 CGroup v2 的内存保护是分层的，kubelet 还会配置祖先 CGroup。它在 kubepods 根 CGroup 上将 memory.min 设置为 Guaranteed 和 Burstable Pod 的内存 requests 之和； 在 kubepods 根 CGroup 和 Burstable QoS CGroup 上将 memory.low 设置为 Burstable Pod 的内存 requests 之和。如果没有这种祖先覆盖，按 Pod 和按容器的保护将无法生效。

禁用或回滚 Memory QoS

要禁用 Memory QoS，请将 MemoryQoS 特性门控设置为 false，确保 memoryReservationPolicy 未设置或设置为 None，然后重启 kubelet。启动时，kubelet 会将 kubepods 根 CGroup 上的 memory.min 和 memory.low、以及 Burstable QoS CGroup 上的 memory.low 重置为零。 Pod 级和容器级的 memory.min、memory.low 值可以保留，但由于对应的祖先保护为零，这些值不起作用。

当 Memory QoS 禁用时，每当容器运行时将资源配置应用到新的、重启的或原地调整大小的容器时， kubelet 会将 memory.high 设置为 max。对于已经在运行但未被重启或调整大小的容器， 其之前的 memory.high 值可以保留，直到下次重启或原地调整大小为止。

系统要求

Memory QoS 需要使用 CGroup v2 的 Linux 系统。 推荐使用 5.9 或更高版本的内核，因为在旧版本的内核上， memory.high 节流可能会触发一个已知的 livelock bug。 如果在较旧的内核上启用了 MemoryQoS 特性门控，kubelet 在启动时会记录一条警告日志。

某些行为独立于 QoS 类

某些行为独立于 Kubernetes 分配的 QoS 类。例如：

• 所有超过资源 limit 的容器都将被 kubelet 杀死并重启，而不会影响该 Pod 中的其他容器。
• 如果一个容器超出了自身的资源 request，且该容器运行的节点面临资源压力，则该容器所在的 Pod 就会成为被驱逐的候选对象。 如果出现这种情况，Pod 中的所有容器都将被终止。Kubernetes 通常会在不同的节点上创建一个替代的 Pod。

• Pod 的资源 request 等于其成员容器的资源 request 之和，Pod 的资源 limit 等于其成员容器的资源 limit 之和。
• kube-scheduler 在选择要抢占的 Pod 时不考虑 QoS 类。当集群没有足够的资源来运行你所定义的所有 Pod 时，就会发生抢占。

• QoS 类在 Pod 创建时确定，并在 Pod 的整个生命周期内保持不变。 如果你之后尝试进行一次原地资源调整， 且该调整会导致 QoS 类发生变化，则该调整请求会在准入阶段被拒绝。

接下来

• 进一步了解为 Pod 和容器管理资源。
• 进一步了解节点压力驱逐。
• 进一步了解 Pod 优先级和抢占。
• 进一步了解 Pod 干扰。
• 进一步了解如何为容器和 Pod 分配内存资源。
• 进一步了解如何为容器和 Pod 分配 CPU 资源。
• 进一步了解如何配置 Pod 的服务质量。

9 - Pod 主机名

本文讲述如何设置 Pod 的主机名、配置主机名后的潜在副作用以及底层机制。

默认 Pod 主机名

当 Pod 被创建时，其主机名（从 Pod 内部观察）来源于 Pod 的 metadata.name 值。 主机名和其对应的完全限定域名（FQDN）都会被设置为 metadata.name 值（从 Pod 的角度）。

apiVersion: v1
kind: Pod
metadata:
  name: busybox-1
spec:
  containers:
  - image: busybox:1.28
    command:
      - sleep
      - "3600"
    name: busybox

由上述清单创建的 Pod 将其主机名和完全限定域名（FQDN）设置为 busybox-1。

使用 Pod 的 hostname 和 subdomain 字段设置主机名

Pod 规约包含一个可选的 hostname 字段。 当此字段被设置时，其取值优先于 Pod 的 metadata.name，作为 Pod 的主机名（从 Pod 内部观察）。 例如，如果将 Pod 的 spec.hostname 设置为 my-host，则 Pod 的主机名会被设置为 my-host。

Pod 规约还包含一个可选的 subdomain 字段，表示 Pod 属于其命名空间中的某个子域。 如果 Pod 的 spec.hostname 设置为 foo，spec.subdomain 设置为 my-namespace 命名空间中的 bar， 则其主机名为 foo，完全限定域名（FQDN）为 foo.bar.my-namespace.svc.cluster-domain.example（从 Pod 内部观察）。

当 hostname 和 subdomain 都被设置时，集群的 DNS 服务器会基于这些字段创建 A 和/或 AAAA 记录。参考 Pod 的 hostname 和 subdomain 字段。

使用 Pod 的 setHostnameAsFQDN 字段设置主机名

当 Pod 被配置为使用完全限定域名（FQDN）时，则其主机名是短的主机名。 例如，如果 Pod 的完全限定域名是 busybox-1.busybox-subdomain.my-namespace.svc.cluster-domain.example， 那么该 Pod 内的 hostname 命令默认返回 busybox-1，而 hostname --fqdn 命令返回 FQDN。

当在 Pod 规约中同时设置了 setHostnameAsFQDN: true 和 subdomain 字段时， kubelet 会将 Pod 的 FQDN 写入该 Pod 命名空间的主机名中。 在这种情况下，hostname 和 hostname --fqdn 都会返回 Pod 的 FQDN。

Pod 的 FQDN 构建方式与前面定义的方式相同。 它由 Pod 的 spec.hostname（如果指定）或 metadata.name 字段、 spec.subdomain、namespace 名称以及集群域名后缀组成。

使用 Pod 的 hostnameOverride 设置主机名

在 Pod 规约中为 hostnameOverride 设置一个值，会导致 kubelet 无条件地将 Pod 的主机名和完全限定域名（FQDN） 都设置为 hostnameOverride 值。

hostnameOverride 字段的长度限制为 64 个字符，并且必须符合 RFC 1123 所定义的 DNS 子域名标准。

示例：

apiVersion: v1
kind: Pod
metadata:
  name: busybox-2-busybox-example-domain
spec:
  hostnameOverride: busybox-2.busybox.example.domain
  containers:
  - image: busybox:1.28
    command:
      - sleep
      - "3600"
    name: busybox

如果同时设置了 hostnameOverride 和 hostname、subdomain 字段：

• Pod 内部的主机名会被覆盖为 hostnameOverride 值。
• 集群 DNS 服务器中 Pod 的 A 和/或 AAAA 记录仍然基于 hostname 和 subdomain 字段生成。

注意：如果设置了 hostnameOverride，则你不能同时设置 hostNetwork 和 setHostnameAsFQDN 字段。 API 服务器将显式拒绝任何尝试这种组合的创建请求。

关于在 hostnameOverride 与其他字段（hostname、subdomain、setHostnameAsFQDN、hostNetwork） 组合使用时的行为详情，请参阅 KEP-4762 设计细节中的表格。

10 - 调度组

你可以将 Pod 链接到 PodGroup， 以表明该 Pod 属于一组一起调度的 Pod。 这使得调度器能够应用组级策略（如 Gang 调度），而不是将每个 Pod 独立对待。

指定调度组

当启用 GenericWorkload 特性门控时，你可以在 Pod 清单中设置 spec.schedulingGroup 字段。 此字段通过名称建立到同一名字空间中特定 PodGroup 对象的链接。

apiVersion: v1
kind: Pod
metadata:
  name: worker-0
  namespace: some-ns
spec:
  schedulingGroup:
    podGroupName: training-worker-0
  containers:
  - name: ml-worker
    image: training:v1

schedulingGroup 字段是不可变的。设置后，Pod 无法移动到不同的 PodGroup。

行为

当你设置 spec.schedulingGroup 时，调度器会查找引用的 PodGroup 并应用其中定义的调度策略：

• 如果 PodGroup 使用 basic 策略，则每个 Pod 使用标准的 Kubernetes 行为独立调度。分组用作组级标签。

• 如果 PodGroup 使用 gang 策略，则 Pod 进入"全有或全无"调度生命周期。 调度器尝试同时放置组中至少 minCount 个 Pod； 除非达到最小值，否则它们都不会绑定到节点。

当启用 CompositePodGroup 特性门控后，PodGroup 还可以指定一个父级 CompositePodGroup。 在层级化工作负载中，调度由整个组树上所定义的策略（例如多层级 Gang 调度或拓扑约束）来管控。

缺少组引用

如果 Pod 引用了不存在的 PodGroup，则该 Pod 保持 Pending 状态。 类似地，如果被引用的 PodGroup 指定了一个父级 CompositePodGroup （通过 spec.parentCompositePodGroupName），但该父级 CompositePodGroup 尚未创建，则调度不会开始，Pod 将一直保持悬决状态，直到整个组层级结构在集群中存在为止。

一旦所有必需的 PodGroup 和 CompositePodGroup 资源就绪， 调度器便会自动重新考量该 Pod。

接下来

• 了解 PodGroup API 及其生命周期。
• 阅读 CompositePodGroup API。
• 阅读 PodGroup 调度策略。
• 理解 Gang 调度算法。

11 - 静态 Pod

静态 Pod（Static Pod） 由特定节点上的 kubelet 守护进程直接管理， 而不是由 API 服务器观察和管理。 与由控制平面管理的 Pod（例如由 Deployment 管理的 Pod）不同， kubelet 会监视每个静态 Pod，并在其失败时自动重启。

静态 Pod 总是绑定到特定节点上的某个 kubelet。

静态 Pod 的主要用途是运行自托管控制平面： 换言之，使用 kubelet 来监管各个 控制平面组件。 例如，kubeadm 就使用静态 Pod 在控制平面节点上运行 kube-apiserver、kube-controller-manager、kube-scheduler 和 etcd。

镜像 Pod

kubelet 会自动尝试为每个静态 Pod 在 Kubernetes API 服务器上创建一个 镜像 Pod。 这意味着运行在某个节点上的这些 Pod 在 API 服务器中是可见的， 但你不能通过 API 服务器直接控制它们。 这些 Pod 的名称会在静态 Pod 原始名称后附加节点主机名，并以连字符作为前缀。

kubelet 会把静态 Pod 上的 标签 传播到镜像 Pod。你可以像平常一样通过 选择算符来使用这些标签。

如果你尝试使用 kubectl 从 API 服务器中删除镜像 Pod， kubelet 不会删除对应的静态 Pod。 kubelet 只会重新创建这个镜像 Pod。

限制

静态 Pod 的规约不能引用其他 API 对象， 例如 ServiceAccount、 ConfigMap 或 Secret。

静态 Pod 不支持临时容器。

静态 Pod 与 DaemonSet

如果你运行的是一个集群化 Kubernetes，并且使用静态 Pod 在每个节点上运行某个 Pod， 那么你很可能应该改用 DaemonSet。

静态 Pod 不受控制平面管理，因此不能使用 Kubernetes 的标准机制来进行发布、回滚或扩缩容。 DaemonSet 提供了这些能力，也是运行节点级工作负载的推荐方式。

静态 Pod 会在 API 服务器可用之前由 kubelet 启动， 因此它们适合用于引导控制平面组件。DaemonSet 则依赖于一个已经运行中的控制平面。

接下来

• 了解如何创建静态 Pod。
• 了解 Kubernetes 组件，以及控制平面如何使用静态 Pod。
• 了解可作为静态 Pod 替代方案的 DaemonSet。

12 - 用户命名空间

本页解释了在 Kubernetes Pod 中如何使用用户命名空间。 用户命名空间将容器内运行的用户与主机中的用户隔离开来。

在容器中以 Root 身份运行的进程可以在主机中以不同的（非 Root）用户身份运行； 换句话说，该进程在用户命名空间内的操作具有完全的权限， 但在命名空间外的操作是无特权的。

你可以使用这个功能来减少被破坏的容器对主机或同一节点中的其他 Pod 的破坏。 有几个安全漏洞被评为 高（HIGH） 或 重要（CRITICAL）， 当用户命名空间处于激活状态时，这些漏洞是无法被利用的。 预计用户命名空间也会减轻一些未来的漏洞。

准备开始

这是一个只对 Linux 有效的功能特性，且需要 Linux 支持在所用文件系统上挂载 idmap。 这意味着：

• 在节点上，你用于 /var/lib/kubelet/pods/ 的文件系统，或你为此配置的自定义目录， 需要支持 idmap 挂载。
• Pod 卷中使用的所有文件系统都必须支持 idmap 挂载。

在实践中，这意味着你最低需要 Linux 6.3，因为 tmpfs 在该版本中开始支持 idmap 挂载。 这通常是需要的，因为有几个 Kubernetes 功能特性使用 tmpfs （默认情况下挂载的服务账号令牌使用 tmpfs、Secret 使用 tmpfs 等等）。

Linux 6.3 中支持 idmap 挂载的一些比较流行的文件系统是： btrfs、ext4、xfs、fat、tmpfs、overlayfs。

此外，容器运行时及其底层 OCI 运行时必须支持用户命名空间。以下 OCI 运行时提供支持：

• crun 1.9 或更高版本（推荐 1.13+ 版本）。
• runc 1.2 或更高版本。

此外，需要在容器运行时提供支持， 才能在 Kubernetes Pod 中使用这一功能：

• containerd：2.0（及更高）版本支持容器使用用户命名空间。
• CRI-O：1.25（及更高）版本支持配置容器的用户命名空间。

你可以在 GitHub 上的 [Issue][CRI-dockerd-issue] 中查看 cri-dockerd 中用户命名空间支持的状态。

介绍

用户命名空间是一个 Linux 功能，允许你将容器中的用户映射到主机中的不同用户。 此外，在某用户命名空间中授予 Pod 的权能只在该命名空间中有效，在该命名空间之外无效。

一个 Pod 可以通过将 pod.spec.hostUsers 字段设置为 false 来选择使用用户命名空间。

kubelet 将挑选 Pod 所映射的主机 UID/GID， 并以此保证同一节点上没有两个 Pod 使用相同的方式进行映射。

pod.spec 中的 runAsUser、runAsGroup、fsGroup 等字段总是指的是容器内的用户。 这些用户将用于卷挂载（在 pod.spec.volumes 中指定）， 因此，主机上的 UID/GID 不会影响 Pod 挂载卷的读写操作。 换句话说，由 Pod 挂载卷中创建或读取的 inode，将与 Pod 未使用用户命名空间时相同。

通过这种方式，Pod 可以轻松启用或禁用用户命名空间（不会影响其卷中文件的所有权）， 并且可以通过在容器内部设置适当的用户（runAsUser、runAsGroup、fsGroup 等）， 即可与没有用户命名空间的 Pod 共享卷。这一点适用于 Pod 可挂载的任何卷， 包括 hostPath（前提是允许 Pod 挂载 hostPath 卷）。

默认情况下，当启用该功能时，有效的 UID/GID 在 0-65535 范围内。 这适用于文件和进程（runAsUser、runAsGroup 等）。

使用这个范围之外的 UID/GID 的文件将被视为属于溢出 ID， 通常是 65534（配置在 /proc/sys/kernel/overflowuid和/proc/sys/kernel/overflowgid）。 然而，即使以 65534 用户/组的身份运行，也不可能修改这些文件。

如果用配置旋钮将 0-65535 范围扩展，则上述限制适用于扩展的范围。

大多数需要以 Root 身份运行但不访问其他主机命名空间或资源的应用程序， 在用户命名空间被启用时，应该可以继续正常运行，不需要做任何改变。

了解 Pod 的用户命名空间

一些容器运行时的默认配置（如 Docker Engine、containerd、CRI-O）使用 Linux 命名空间进行隔离。 其他技术也存在，也可以与这些运行时（例如，Kata Containers 使用虚拟机而不是 Linux 命名空间）结合使用。 本页适用于使用 Linux 命名空间进行隔离的容器运行时。

在创建 Pod 时，默认情况下会使用几个新的命名空间进行隔离： 一个网络命名空间来隔离容器网络，一个 PID 命名空间来隔离进程视图等等。 如果使用了一个用户命名空间，这将把容器中的用户与节点中的用户隔离开来。

这意味着容器可以以 Root 身份运行，并将该身份映射到主机上的一个非 Root 用户。 在容器内，进程会认为它是以 Root 身份运行的（因此像 apt、yum 等工具可以正常工作）， 而实际上该进程在主机上没有权限。 你可以验证这一点，例如，如果你从主机上执行 ps aux 来检查容器进程是以哪个用户运行的。 ps 显示的用户与你在容器内执行 id 命令时看到的用户是不一样的。

这种抽象限制了可能发生的情况，例如，容器设法逃逸到主机上时的后果。 鉴于容器是作为主机上的一个非特权用户运行的，它能对主机做的事情是有限的。

此外，由于每个 Pod 上的用户将被映射到主机中不同的非重叠用户， 他们对其他 Pod 可以执行的操作也是有限的。

授予一个 Pod 的权能也被限制在 Pod 的用户命名空间内， 并且在这一命名空间之外大多无效，有些甚至完全无效。这里有两个例子：

• CAP_SYS_MODULE 若被授予一个使用用户命名空间的 Pod 则没有任何效果，这个 Pod 不能加载内核模块。
• CAP_SYS_ADMIN 只限于 Pod 所在的用户命名空间，在该命名空间之外无效。

在不使用用户命名空间的情况下，以 Root 账号运行的容器，在容器逃逸时，在节点上有 Root 权限。 而且如果某些权能被授予了某容器，这些权能在宿主机上也是有效的。 当我们使用用户命名空间时，这些都不再成立。

如果你想知道关于使用用户命名空间时的更多变化细节，请参见 man 7 user_namespaces。

设置一个节点以支持用户命名空间

默认情况下，kubelet 会分配 0-65535 范围以上的 Pod UID/GID， 这是基于主机的文件和进程使用此范围内的 UID/GID 的假设，也是大多数 Linux 发行版的标准。 此方法可防止主机的 UID/GID 与 Pod 的 UID/GID 之间出现重叠。

避免重叠对于减轻 CVE-2021-25741 等漏洞的影响非常重要， 其中 Pod 可能会读取主机中的任意文件。 如果 Pod 和主机的 UID/GID 不重叠，则 Pod 的功能将受到限制： Pod UID/GID 将与主机的文件所有者/组不匹配。

kubelet 可以对 Pod 的用户 ID 和组 ID 使用自定义范围。要配置自定义范围，节点需要具有：

• 系统中的用户 kubelet（此处不能使用任何其他用户名）。
• 已安装二进制文件 getsubids（shadow-utils 的一部分）并位于 kubelet 二进制文件的 PATH 中。
• kubelet 用户的从属 UID/GID 配置 （请参阅 man 5 subuid 和 man 5 subgid）

此设置仅收集 UID/GID 范围配置，不会更改执行 kubelet 的用户。

对于分配给 kubelet 用户的从属 ID 范围， 你必须遵循一些限制：

• 启动 Pod 的 UID 范围的从属用户 ID 必须是 65536 的倍数，并且还必须大于或等于 65536。 换句话说，Pod 不能使用 0-65535 范围内的任何 ID； kubelet 施加此限制是为了使创建意外不安全的配置变得困难。

• 从属 ID 计数必须是 65536 的倍数。

• 从属 ID 计数必须至少为 65536 x <maxPods>，其中 <maxPods> 是节点上可以运行的最大 Pod 数量。

• 你必须为用户 ID 和组 ID 分配相同的范围。如果其他用户的用户 ID 范围与组 ID 范围不一致也没关系。

• 所分配的范围不得与任何其他分配重叠。

• 从属配置必须只有一行。换句话说，你不能有多个范围。

例如，你可以定义 /etc/subuid 和 /etc/subgid 来为 kubelet 用户定义以下条目：

# 格式为：
#   name:firstID:count of IDs
# 其中：
# - firstID 是 65536 （可能的最小值）
# - ID 的数量是 110 * 65536（110 是节点上 Pod 数量的默认限制）

kubelet:65536:7208960

关于重新配置节点的注意事项

如果你有一个正在运行用户命名空间 Pod 的现有节点，并希望进行上述配置，有以下几点重要注意事项。

应当在节点上没有运行使用用户命名空间的 Pod 时再更改该配置。 在正在运行任何使用用户命名空间的 Pod 的节点上进行此项更改时， 你需要在应用配置并重启 kubelet 之前，先{{< glossary_tooltip text="腾空（Drain）" term_id="drain" >}}该节点。 在腾空节点时，请注意，DaemonSet Pod 或其他容忍了不可调度污点的 Pod 将不会被驱逐。

之所以不能有任何使用用户命名空间的 Pod 正在运行， 是因为它们可能正在使用某个 UID 区间，潜在地落在新配置的区间之外。 如果 kubelet 无法针对节点上现有的 Pod 满足新的配置，它将无法启动。

Pod 的 ID 计数

从 Kubernetes v1.33 开始，每个 Pod 的 ID 计数可以在 KubeletConfiguration 中设置。

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
userNamespaces:
  idsPerPod: 1048576

idsPerPod 的值（uint32）必须是 65536 的倍数。默认值是 65536。 此值仅适用于使用此 KubeletConfiguration 启动 kubelet 后创建的容器。 正在运行的容器不受此配置的影响。

在 Kubernetes v1.33 之前，每个 Pod 的 ID 计数被硬编码为 65536。

与 Pod 安全准入检查的集成

对于启用了用户命名空间的 Linux Pod，Kubernetes 会以受控方式放宽 Pod 安全性标准的应用。

如果你创建了使用用户命名空间的 Pod，以下的字段不会被限制， 即使在执行了 Baseline 或 Restricted Pod 安全性标准的上下文中。这种行为不会带来安全问题， 因为带有用户命名空间的 Pod 内的 root 实际上指的是容器内的用户，绝不会映射到主机上的特权用户。 以下是在这种情况下不进行检查的 Pod 字段列表：

• spec.securityContext.runAsNonRoot
• spec.containers[*].securityContext.runAsNonRoot
• spec.initContainers[*].securityContext.runAsNonRoot
• spec.ephemeralContainers[*].securityContext.runAsNonRoot
• spec.securityContext.runAsUser
• spec.containers[*].securityContext.runAsUser
• spec.initContainers[*].securityContext.runAsUser

此外，如果 Pod 处于符合 Baseline Pod 安全标准的上下文中， 则对以下字段的合法性检查也将类似地放宽：

• spec.containers[*].securityContext.procMount
• spec.initContainers[*].securityContext.procMount
• spec.ephemeralContainers[*].securityContext.procMount

如果使用 Restricted Pod 安全标准，Pod 仍然只能使用默认的或空的 procMount。

限制

当 Pod 使用用户命名空间时，不允许 Pod 使用其他主机命名空间。 特别是，如果你设置了 hostUsers: false，那么你就不可以设置如下属性：

• hostNetwork: true
• hostIPC: true
• hostPID: true

任何容器都不能使用 volumeDevices（原始块设备卷，例如 /dev/sda）。 这包括 Pod 规约中的所有容器数组：

• containers
• initContainers
• ephemeralContainers

文件系统支持

使用用户命名空间的 Pod 需要文件系统支持 idmap 挂载。 某些文件系统不支持 idmap 挂载，因此无法与用户命名空间一起使用。 在这种情况下，将会生成以下事件。请注意，警告详情取决于您使用的容器运行时。

Warning  Failed 1s kubelet Error: failed to create containerd task: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: failed to fulfil mount request: failed to set MOUNT_ATTR_IDMAP on ${your mount path} invalid argument (maybe the filesystem used doesn't support idmap mounts on this kernel?): unknown

由于 Linux NFS 客户端尚不支持 ID 映射挂载，因此无法在用户命名空间 Pod 中挂载 NFS 卷。 有关当前支持的文件系统列表，请参阅 Linux 内核的 mount_setattr(2) 手册页（https://man7.org/linux/man-pages/man2/mount_setattr.2.html）。

指标与可观测性

kubelet 会导出两项与用户命名空间相关的 Prometheus 指标：

• started_user_namespaced_pods_total：这个计数器跟踪尝试创建的、作用域为用户命名空间的 Pod 数量。
• started_user_namespaced_pods_errors_total：这个计数器跟踪创建作用域为用户命名空间的 Pod 时发生的错误次数。

接下来

• 查阅为 Pod 配置用户命名空间。

13 - Downward API

对于容器来说，在不与 Kubernetes 过度耦合的情况下，拥有关于自身的信息有时是很有用的。 Downward API 允许容器在不使用 Kubernetes 客户端或 API 服务器的情况下获得自己或集群的信息。

例如，现有应用程序假设某特定的周知的环境变量是存在的，其中包含唯一标识符。 一种方法是对应用程序进行封装，但这很繁琐且容易出错，并且违背了低耦合的目标。 更好的选择是使用 Pod 名称作为标识符，并将 Pod 名称注入到周知的环境变量中。

在 Kubernetes 中，有两种方法可以将 Pod 和容器字段暴露给运行中的容器：

• 作为环境变量
• 作为 downwardAPI 卷中的文件

这两种暴露 Pod 和容器字段的方式统称为 Downward API。

可用字段

只有部分 Kubernetes API 字段可以通过 Downward API 使用。本节列出了你可以使用的字段。

你可以使用 fieldRef 传递来自可用的 Pod 级字段的信息。在 API 层面，一个 Pod 的 spec 总是定义了至少一个 Container。 你可以使用 resourceFieldRef 传递来自可用的 Container 级字段的信息。

可通过 fieldRef 获得的信息

对于某些 Pod 级别的字段，你可以将它们作为环境变量或使用 downwardAPI 卷提供给容器。 通过这两种机制可用的字段有：

metadata.name

Pod 的名称

metadata.namespace

Pod 的命名空间

metadata.uid

Pod 的唯一 ID

metadata.annotations['<KEY>']

Pod 的注解 <KEY> 的值（例如：metadata.annotations['myannotation']）

metadata.labels['<KEY>']

Pod 的标签 <KEY> 的值（例如：metadata.labels['mylabel']）

以下信息可以通过环境变量获得，但不能作为 downwardAPI 卷 fieldRef 获得：

spec.serviceAccountName

Pod 的服务账号名称

spec.nodeName

Pod 运行时所处的节点名称

status.hostIP

Pod 所在节点的主 IP 地址

status.hostIPs

这组 IP 地址是 status.hostIP 的双协议栈版本，第一个 IP 始终与 status.hostIP 相同。

status.podIP

Pod 的主 IP 地址（通常是其 IPv4 地址）

status.podIPs

这组 IP 地址是 status.podIP 的双协议栈版本, 第一个 IP 始终与 status.podIP 相同。

以下信息可以通过 downwardAPI 卷 fieldRef 获得，但不能作为环境变量获得：

metadata.labels

Pod 的所有标签，格式为 标签键名="转义后的标签值"，每行一个标签

metadata.annotations

Pod 的全部注解，格式为 注解键名="转义后的注解值"，每行一个注解

可通过 resourceFieldRef 获得的信息

这些容器级别的字段允许你提供关于 请求和限制 的资源（如 CPU 和内存）信息。

        <div class="feature-state-notice feature-stable" title="特性门控： InPlacePodVerticalScaling">
          <span class="feature-state-name">特性状态：</span>
          <span class="feature-state-details">
           <span class="feature-state-stage">GA</span> since Kubernetes v1.35
           </span>
        </div>

        
        <div class="feature-stable">
          
          <details>
          <summary>More information about this feature</summary>
          <p>This is a stable feature in Kubernetes, and has been since version v1.35. It was first available in the v1.27 release. You can no longer disable or opt out of this feature or behavior (it is locked); if you explicitly set a value for the associated feature gate <tt>InPlacePodVerticalScaling</tt>, Kubernetes ignores it but does not report any error.</p>
          </details>

          
          </div>

resource: limits.cpu

容器的 CPU 限制值

resource: requests.cpu

容器的 CPU 请求值

resource: limits.memory

容器的内存限制值

resource: requests.memory

容器的内存请求值

resource: limits.hugepages-*

容器的巨页限制值

resource: requests.hugepages-*

容器的巨页请求值

resource: limits.ephemeral-storage

容器的临时存储的限制值

resource: requests.ephemeral-storage

容器的临时存储的请求值

资源限制的后备信息

如果没有为容器指定 CPU 和内存限制时尝试使用 Downward API 暴露该信息，那么 kubelet 默认会根据 节点可分配资源 计算并暴露 CPU 和内存的最大可分配值。

接下来

你可以阅读有关 downwardAPI 卷的内容。

你可以尝试使用 Downward API 暴露容器或 Pod 级别的信息：

• 作为环境变量
• 作为 downwardAPI 卷中的文件

14 - 高级 Pod 配置

本页涵盖高级 Pod 配置主题，包括 PriorityClass、RuntimeClass、 Pod 内的安全上下文，并介绍调度相关内容。

PriorityClass

PriorityClass 允许你设置 Pod 相对于其他 Pod 的重要性。 如果你为 Pod 分配了优先级类，Kubernetes 会根据你所指定的 PriorityClass 为该 Pod 设置 .spec.priority 字段 （你不能直接设置 .spec.priority）。如果 Pod 无法被调度，且原因是资源不足， kube-scheduler 会尝试抢占较低优先级的 Pod， 以使较高优先级的 Pod 能够被调度。

PriorityClass 是一个集群级别的 API 对象，它将优先级类名称映射到一个整数优先级值。数值越大，优先级越高。

定义 PriorityClass

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority
value: 10000
globalDefault: false
description: "Priority class for high-priority workloads"

使用 PriorityClass 指定 Pod 优先级

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx
  priorityClassName: high-priority

内置 PriorityClass

Kubernetes 提供两个内置的 PriorityClass：

• system-cluster-critical：用于对集群至关重要的系统组件。
• system-node-critical：用于对单个节点至关重要的系统组件。这是 Kubernetes 中 Pod 可以具有的最高优先级。

更多信息请参阅 Pod 优先级与抢占。

RuntimeClass

RuntimeClass 允许你为 Pod 指定底层的容器运行时。当你需要为不同类型的 Pod 指定不同的容器运行时， 例如需要不同的隔离级别或运行时特性时，这一机制非常有用。

示例 Pod

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  runtimeClassName: myclass
  containers:
  - name: mycontainer
    image: nginx

RuntimeClass 是一个集群级别的对象， 表示在某些或所有节点上可用的容器运行时。

集群管理员负责安装和配置支撑 RuntimeClass 的具体运行时。

他们可以在所有节点上设置这种特殊的容器运行时配置，也可以只在部分节点上设置。

更多信息请参阅 RuntimeClass 文档。

Pod 和容器级别的安全上下文配置

Pod 规约中的 Security context 字段提供了对 Pod 和容器安全设置的精细化控制。

Pod 范围的 securityContext

安全设置的某些方面适用于整个 Pod；对于其他方面， 你可能希望设置一个默认值，而不允许容器级别的覆盖。

以下是在 Pod 层面使用 securityContext 的示例：

示例 Pod

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:  # 此项应用到整个 Pod
    runAsUser: 1000
    runAsGroup: 3000
    fsGroup: 2000
  containers:
  - name: sec-ctx-demo
    image: registry.k8s.io/e2e-test-images/agnhost:2.45
    command: ["sh", "-c", "sleep 1h"]

容器级别的安全上下文

你可以仅为特定容器指定安全上下文。以下是一个示例：

示例 Pod

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo-2
spec:
  containers:
  - name: sec-ctx-demo-2
    image: gcr.io/google-samples/node-hello:1.0
    securityContext:
      allowPrivilegeEscalation: false
      runAsNonRoot: true
      runAsUser: 1000
      capabilities:
        drop:
        - ALL
      seccompProfile:
        type: RuntimeDefault

安全上下文选项

• 用户和组 ID：控制容器以哪个用户/组身份运行。
• Capabilities：添加或删除 Linux 权能。
• Seccomp Profile：设置安全计算配置文件。
• SELinux 选项：配置 SELinux 上下文。
• AppArmor：配置 AppArmor 配置文件以实现额外的访问控制。
• Windows 选项：配置 Windows 特定的安全设置。

更多信息请参阅为 Pod 或容器配置安全上下文。

影响 Pod 调度决策

Kubernetes 提供了多种机制来控制 Pod 被调度到哪些节点上。

节点选择算符

最简单的节点选择约束形式：

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx
  nodeSelector:
    disktype: ssd

节点亲和性

节点亲和性允许你指定规则，限制 Pod 可以被调度到哪些节点上。以下示例中的 Pod 倾向于运行在带有特定大洲标签的节点上， 选择基于 topology.kubernetes.io/zone 标签的值。

apiVersion: v1
kind: Pod
metadata:
  name: with-node-affinity
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: topology.kubernetes.io/zone
            operator: In
            values:
            - antarctica-east1
            - antarctica-west1
  containers:
  - name: with-node-affinity
    image: registry.k8s.io/pause:3.8

Pod 亲和性与反亲和性

除了节点亲和性之外，你还可以基于节点上已运行的其他 Pod 的标签来限制 Pod 可以被调度到哪些节点。 Pod 亲和性允许你指定规则，说明 Pod 应相对于其他 Pod 放置在何处。

apiVersion: v1
kind: Pod
metadata:
  name: with-pod-affinity
spec:
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: app
            operator: In
            values:
            - database
        topologyKey: topology.kubernetes.io/zone
  containers:
  - name: with-pod-affinity
    image: registry.k8s.io/pause:3.8