为 Pod 配置集群 - 使用 Pod | 节点 | OpenShift Container Platform 4.17

配置 Pod 重启后的行为
限制 Pod 可用的带宽
了解如何使用 Pod 中断预算来指定必须启动的 Pod 数量
- 使用 Pod 中断预算指定必须启动的 Pod 数量
- 指定不健康 Pod 的驱逐策略
使用关键 Pod 防止 Pod 删除
在使用具有大量文件的持久卷时减少 Pod 超时

作为管理员，您可以为 Pod 创建和维护一个高效的集群。

通过保持集群高效，您可以为使用此类工具的开发人员提供更好的环境，例如 Pod 退出时执行的操作、确保始终运行所需的 Pod 数量、何时重启一次性运行的 Pod、限制 Pod 可用的带宽以及如何在中断期间保持 Pod 运行。

配置 Pod 重启后的行为

Pod 重启策略决定了当该 Pod 中的容器退出时 OpenShift Container Platform 如何响应。此策略适用于该 Pod 中的所有容器。

可能的值为

Always - 连续尝试重启 Pod 中成功退出的容器，并使用指数退避延迟（10 秒、20 秒、40 秒），最大延迟为 5 分钟。默认值为 Always。
OnFailure - 尝试使用指数退避延迟（10 秒、20 秒、40 秒），最大延迟为 5 分钟，重启 Pod 中失败的容器。
Never - 不尝试重启 Pod 中退出的或失败的容器。Pod 会立即失败并退出。

Pod 绑定到节点后，将永远不会绑定到其他节点。这意味着需要一个控制器才能使 Pod 在节点故障后存活。

条件控制器类型重启策略

条件	控制器类型	重启策略
预计会终止的 Pod（例如批处理计算）	作业	`OnFailure` 或 `Never`
预计不会终止的 Pod（例如 Web 服务器）	副本控制器	`Always`.
必须每台机器运行一个的 Pod	守护进程集	任意

预计会终止的 Pod（例如批处理计算）

作业

OnFailure 或 Never

预计不会终止的 Pod（例如 Web 服务器）

副本控制器

Always.

必须每台机器运行一个的 Pod

守护进程集

任意

如果 Pod 上的容器失败并且重启策略设置为 OnFailure，则 Pod 保留在节点上，并重启容器。如果您不希望容器重启，请使用 Never 的重启策略。

如果整个 Pod 失败，OpenShift Container Platform 将启动一个新的 Pod。开发人员必须处理应用程序可能在新的 Pod 中重启的可能性。特别是，应用程序必须处理由先前运行引起的临时文件、锁、不完整的输出等。

Kubernetes 架构期望云提供商提供可靠的端点。当云提供商宕机时，kubelet 会阻止 OpenShift Container Platform 重启。

如果底层云提供商端点不可靠，请不要使用云提供商集成安装集群。像在无云环境中一样安装集群。不建议在已安装的集群中启用或禁用云提供商集成。

有关 OpenShift Container Platform 如何将重启策略与失败的容器一起使用的详细信息，请参阅 Kubernetes 文档中的示例状态。

限制 Pod 可用的带宽

您可以将服务质量流量整形应用于 Pod，并有效地限制其可用的带宽。出站流量（来自 Pod）由策略控制，该策略只会丢弃超过配置速率的数据包。入站流量（到 Pod）由整形排队的数据包处理，以有效地处理数据。您对 Pod 设置的限制不会影响其他 Pod 的带宽。

步骤

要限制 Pod 上的带宽

编写一个对象定义 JSON 文件，并使用 kubernetes.io/ingress-bandwidth 和 kubernetes.io/egress-bandwidth 注释指定数据流量速度。例如，要将 Pod 出站和入站带宽都限制为 10M/s

受限的 Pod 对象定义

{
    "kind": "Pod",
    "spec": {
        "containers": [
            {
                "image": "openshift/hello-openshift",
                "name": "hello-openshift"
            }
        ]
    },
    "apiVersion": "v1",
    "metadata": {
        "name": "iperf-slow",
        "annotations": {
            "kubernetes.io/ingress-bandwidth": "10M",
            "kubernetes.io/egress-bandwidth": "10M"
        }
    }
}

使用对象定义创建 Pod
```
$ oc create -f <file_or_dir_path>
```

了解如何使用 Pod 中断预算来指定必须启动的 Pod 数量

Pod 中断预算允许在操作期间（例如，为了维护而清空节点）对 Pod 指定安全约束。

PodDisruptionBudget 是一个 API 对象，它指定了必须同时启动的最小副本数或百分比。在项目中设置这些内容在节点维护（例如缩减集群规模或集群升级）期间很有帮助，并且仅在自愿驱逐（而不是节点故障）时才有效。

PodDisruptionBudget 对象的配置包含以下关键部分：

标签选择器，它是对一组 Pod 的标签查询。
可用性级别，它指定了必须同时可用的 Pod 的最小数量：
- minAvailable 是即使在中断期间也必须始终可用的 Pod 数量。
- maxUnavailable 是在中断期间可以不可用的 Pod 数量。

Available 指的是具有条件 Ready=True 的 Pod 数量。Ready=True 指的是能够服务请求并应添加到所有匹配服务的负载均衡池中的 Pod。

maxUnavailable 为 0% 或 0，或 minAvailable 为 100% 或等于副本数量是允许的，但可能会阻止节点被清空。

OpenShift Container Platform 中所有机器配置池的 maxUnavailable 默认设置为 1。建议不要更改此值，并一次更新一个控制平面节点。不要将此值更改为控制平面池的 3。

您可以使用以下命令检查所有项目中的 Pod 中断预算：

$ oc get poddisruptionbudget --all-namespaces

以下示例包含一些特定于 AWS 上 OpenShift Container Platform 的值。

示例输出

NAMESPACE                              NAME                                    MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
openshift-apiserver                    openshift-apiserver-pdb                 N/A             1                 1                     121m
openshift-cloud-controller-manager     aws-cloud-controller-manager            1               N/A               1                     125m
openshift-cloud-credential-operator    pod-identity-webhook                    1               N/A               1                     117m
openshift-cluster-csi-drivers          aws-ebs-csi-driver-controller-pdb       N/A             1                 1                     121m
openshift-cluster-storage-operator     csi-snapshot-controller-pdb             N/A             1                 1                     122m
openshift-cluster-storage-operator     csi-snapshot-webhook-pdb                N/A             1                 1                     122m
openshift-console                      console                                 N/A             1                 1                     116m
#...

当系统中至少运行着 minAvailable 个 Pod 时，PodDisruptionBudget 被认为是健康的。超过此限制的每个 Pod 都可以被驱逐。

根据您的 Pod 优先级和抢占设置，即使满足 Pod 中断预算要求，低优先级 Pod 也可能被移除。

指定 Pod 中断预算中必须启动的 Pod 数量

您可以使用 PodDisruptionBudget 对象来指定必须同时启动的副本的最小数量或百分比。

步骤

配置 Pod 中断预算

创建一个 YAML 文件，其中包含类似于以下的对象定义

apiVersion: policy/v1 (1)
kind: PodDisruptionBudget
metadata:
  name: my-pdb
spec:
  minAvailable: 2  (2)
  selector:  (3)
    matchLabels:
      name: my-pod

1	`PodDisruptionBudget` 是 `policy/v1` API 组的一部分。
2	必须同时可用的 Pod 的最小数量。这可以是整数，也可以是指定百分比的字符串，例如 `20%`。
3	对一组资源的标签查询。`matchLabels` 和 `matchExpressions` 的结果是逻辑与的结果。留空此参数，例如 `selector {}`，以选择项目中的所有 Pod。

或者

apiVersion: policy/v1 (1)
kind: PodDisruptionBudget
metadata:
  name: my-pdb
spec:
  maxUnavailable: 25% (2)
  selector: (3)
    matchLabels:
      name: my-pod

1	`PodDisruptionBudget` 是 `policy/v1` API 组的一部分。
2	可以同时不可用的 Pod 的最大数量。这可以是整数，也可以是指定百分比的字符串，例如 `20%`。
3	对一组资源的标签查询。`matchLabels` 和 `matchExpressions` 的结果是逻辑与的结果。留空此参数，例如 `selector {}`，以选择项目中的所有 Pod。

运行以下命令将对象添加到项目

$ oc create -f </path/to/file> -n <project_name>

指定不健康 Pod 的驱逐策略

当您使用 Pod 中断预算 (PDB) 指定必须同时可用的 Pod 数量时，您还可以定义如何考虑将不健康 Pod 驱逐的标准。

您可以选择以下策略之一：

IfHealthyBudget

只有在受保护的应用程序没有中断的情况下，才能驱逐尚未处于健康状态的正在运行的 Pod。

AlwaysAllow

无论是否满足 Pod 中断预算中的标准，都可以驱逐尚未处于健康状态的正在运行的 Pod。此策略可以帮助驱逐故障应用程序，例如 Pod 停留在 CrashLoopBackOff 状态或未能报告 Ready 状态的应用程序。

建议在 PodDisruptionBudget 对象中将 unhealthyPodEvictionPolicy 字段设置为 AlwaysAllow，以支持在节点 drain 期间驱逐行为异常的应用程序。默认行为是在 drain 继续之前等待应用程序 Pod 变为健康状态。

步骤

创建一个 YAML 文件，该文件定义一个 PodDisruptionBudget 对象并指定不健康 Pod 的驱逐策略。
示例 pod-disruption-budget.yaml 文件
```
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: my-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      name: my-pod
  unhealthyPodEvictionPolicy: AlwaysAllow (1)
```
1 选择 IfHealthyBudget 或 AlwaysAllow 作为不健康 Pod 的驱逐策略。当 unhealthyPodEvictionPolicy 字段为空时，默认为 IfHealthyBudget。
运行以下命令创建 PodDisruptionBudget 对象：
```
$ oc create -f pod-disruption-budget.yaml
```

使用设置了 AlwaysAllow 不健康 Pod 驱逐策略的 PDB，您现在可以 drain 节点并驱逐受此 PDB 保护的故障应用程序的 Pod。

其他资源

使用关键 Pod 防止 Pod 删除

许多核心组件对于完全功能的集群至关重要，但是它们运行在常规集群节点上而不是主节点上。如果关键附加组件被驱逐，集群可能无法正常工作。

标记为关键的 Pod 不允许被驱逐。

步骤

要使 Pod 成为关键 Pod：

创建 Pod spec 或编辑现有 Pod 以包含 system-cluster-critical 优先级类。
```
apiVersion: v1
kind: Pod
metadata:
  name: my-pdb
spec:
  template:
    metadata:
      name: critical-pod
    priorityClassName: system-cluster-critical (1)
# ...
```
1 从节点中绝不应驱逐的 Pod 的默认优先级类。

或者，您可以为对集群很重要但如有必要可以移除的 Pod 指定 system-node-critical。
创建 Pod
```
$ oc create -f <file-name>.yaml
```

使用具有大量文件的持久卷时减少 Pod 超时

如果存储卷包含许多文件（约 1,000,000 个或更多），您可能会遇到 Pod 超时。

当挂载卷时，OpenShift Container Platform 会递归地更改每个卷内容的所有权和权限以匹配 Pod 的 securityContext 中指定的 fsGroup，这可能会导致此问题。对于大型卷，检查和更改所有权和权限可能非常耗时，从而导致 Pod 启动速度非常慢。

您可以通过应用以下解决方法之一来减少此延迟：

使用安全上下文约束 (SCC) 跳过卷的 SELinux 重新标记。
使用 SCC 内的 fsGroupChangePolicy 字段来控制 OpenShift Container Platform 检查和管理卷的所有权和权限的方式。
使用集群资源覆盖运算符自动应用 SCC 以跳过 SELinux 重新标记。
使用运行时类跳过卷的 SELinux 重新标记。

有关信息，请参阅在 OpenShift 中使用具有大量文件的持久卷时，为什么 Pod 无法启动或花费过长时间才能达到“就绪”状态？。

为 Pod 配置 OpenShift Container Platform 集群