8.3. 为 pod 配置 OpenShift Container Platform 集群
作为管理员，您可以为 pod 创建和维护高效的集群。
通过确保集群高效运行，您可以使用一些工具为开发人员提供更好的环境，例如，pod 退出时的行为，确保始终有所需数量的 pod 在运行，何时重启设计为只运行一次的 pod，限制 pod 可以使用的带宽，以及如何在中断时让 pod 保持运行。
8.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（例如，批量计算） | 作业 |
|
| 不应该终止的 Pod（例如，Web 服务器） | 复制控制器 |
|
| 每台机器必须运行一个的 Pod | 守护进程集 | 任意 |
如果 pod 上的容器失败且重启策略设为 OnFailure，则 pod 会保留在该节点上并重新启动容器。如果您不希望容器重新启动，请使用 Never 重启策略。
如果整个 pod 失败，OpenShift Container Platform 会启动一个新 pod。开发人员必须解决应用程序可能会在新 pod 中重启的情况。特别是，应用程序必须处理由以往运行产生的临时文件、锁定、不完整输出等结果。
Kubernetes 架构需要来自云提供商的可靠端点。当云提供商停机时，kubelet 会防止 OpenShift Container Platform 重启。
如果底层云提供商端点不可靠，请不要使用云提供商集成来安装集群。应像在非云环境中一样安装集群。不建议在已安装的集群中打开或关闭云提供商集成。
如需详细了解 OpenShift Container Platform 如何使用与失败容器相关的重启策略，请参阅 Kubernetes 文档中的示例状态。
8.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>
8.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％ 或等于副本数，但这样设置可能会阻止节点排空操作。
您可以使用以下命令来检查所有项目的 pod 中断预算：
$ oc get poddisruptionbudget --all-namespaces
输出示例
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。
8.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
或者：
apiVersion: policy/v1 1 kind: PodDisruptionBudget metadata: name: my-pdb spec: maxUnavailable: 25% 2 selector: 3 matchLabels: name: my-pod
运行以下命令，将对象添加到项目中：
$ oc create -f </path/to/file> -n <project_name>
8.3.4. 使用关键 pod 防止删除 pod
有不少核心组件对于集群完全正常工作而言至关重要，但它们在常规集群节点而非主节点上运行。如果一个关键附加组件被驱除，集群可能会停止正常工作。
标记为关键 (critical) 的 Pod 不允许被驱除。
流程
使 pod 成为关键 pod：
创建
Podspec 或编辑现有的 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
