2.3. 为 pod 配置 OpenShift Container Platform 集群

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

通过确保集群高效运行，您可以使用一些工具为开发人员提供更好的环境，例如，pod 退出时的行为，确保始终有所需数量的 pod 在运行，何时重启设计为只运行一次的 pod，限制 pod 可以使用的带宽，以及如何在中断时让 pod 保持运行。

2.3.1. 配置 pod 重启后的行为

pod 重启策略决定了 OpenShift Container Platform 在该 pod 中的容器退出时作出何种响应。该策略适用于 pod 中的所有容器。

可能的值有：

Always - 在 pod 被重启之前，按规定的延时值（10s，20s，40s）不断尝试重启 pod 中成功退出的容器（最长为 5 分钟）。默认值为 Always。
OnFailure - 按规定的延时值（10s，20s，40s）不断尝试重启 pod 中失败的容器，上限为 5 分钟。
Never - 不尝试重启 pod 中已退出或失败的容器。Pod 立即失败并退出。

在 pod 绑定到某个节点后，该 pod 永远不会绑定到另一个节点。这意味着，需要一个控制器才能使 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 文档中的示例状态。

2.3.2. 限制可供 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>
```

2.3.3. 了解如何使用 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。建议您不要更改这个值，且一次只更新一个 control plane 节点。对于 control plane 池，请不要将这个值改为 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。

2.3.3.1. 使用 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 的结果在逻辑上是联合的。要选择项目中的所有 pod，将此参数设置为空，如 selector {}。
或者：
```
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 的结果在逻辑上是联合的。要选择项目中的所有 pod，将此参数设置为空，如 selector {}。
运行以下命令，将对象添加到项目中：
```
$ oc create -f </path/to/file> -n <project_name>
```

2.3.3.2. 为不健康的 pod 指定驱除策略

当您使用 pod 中断预算 (PDB) 来指定必须同时有多少 pod 可用时，您还可以定义驱除不健康 pod 的条件。

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

IfHealthyBudget: 只有在保护的应用程序没有被中断时，运行的还没有处于健康状态的 pod 才能被驱除。
AlwaysAllow: 无论是否满足 pod 中断预算中的条件，运行的还没有处于健康状态的 pod 都可以被驱除。此策略可帮助驱除出现故障的应用程序，如 pod 处于 CrashLoopBackOff 状态或无法报告 Ready 状态的应用程序。
注意
建议您在 PodDisruptionBudget 对象中将 unhealthyPodEvictionPolicy 字段设置为 AlwaysAllow，以便在节点排空期间支持收集错误的应用程序。默认行为是等待应用程序 pod 处于健康状态，然后才能排空操作。

流程

创建定义 PodDisruptionBudget 对象的 YAML 文件，并指定不健康的 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，您可以排空节点并驱除受此 PDB 保护的应用程序的 pod。

其他资源

使用功能门启用功能
Kubernetes 文档中的不健康 Pod 驱除策略

2.3.4. 使用关键 pod 防止删除 pod

有不少核心组件对于集群完全正常工作而言至关重要，但它们在常规集群节点而非主节点上运行。如果一个关键附加组件被驱除，集群可能会停止正常工作。

标记为关键 (critical) 的 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
```

2.3.5. 当使用带有大量文件的持久性卷时，可以减少 pod 超时的情况

如果存储卷包含多个文件（～1,000,000 或更多），您可能会遇到 pod 超时的问题。

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

您可以通过应用以下临时解决方案之一来缩短这个延迟：

使用安全性上下文约束 (SCC) 跳过卷的 SELinux 重新标记。
使用 SCC 中的 fsGroupChangePolicy 字段来控制 OpenShift Container Platform 检查和管理卷的所有权和权限的方式。
使用 Cluster Resource Override Operator 自动应用 SCC 来跳过 SELinux 重新标记。
使用运行时类跳过卷的 SELinux 重新标记。

2.3. 为 pod 配置 OpenShift Container Platform 集群

2.3.1. 配置 pod 重启后的行为

2.3.2. 限制可供 pod 使用的带宽

2.3.3. 了解如何使用 pod 中断预算来指定必须在线的 pod 数量

2.3.3.1. 使用 pod 中断预算指定必须在线的 pod 数量

2.3.3.2. 为不健康的 pod 指定驱除策略

2.3.4. 使用关键 pod 防止删除 pod

2.3.5. 当使用带有大量文件的持久性卷时，可以减少 pod 超时的情况

学习

尝试、购买和销售

社区

关于红帽文档

让开源更具包容性

關於紅帽

Red Hat legal and privacy links

Red Hat legal and privacy links