支持控制台（Console）开发人员开始试用联系人

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 的带宽：

  1. 编写对象定义 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"
        }
    }
}

  2. 使用对象定义创建 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％ 或等于副本数，但这样设置可能会阻止节点排空操作。

您可以使用以下命令来检查所有项目的 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。

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

您可以使用 PodDisruptionBudget 对象来指定某一时间必须保持在线的副本的最小数量或百分比。

流程

配置 pod 中断预算：

  1. 使用类似以下示例的对象定义来创建 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。

  2. 运行以下命令，将对象添加到项目中： 

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

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

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

标记为关键 (critical) 的 Pod 不允许被驱除。

流程

使 pod 成为关键 pod：

  1. 创建 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。

  2. 创建 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 检查和管理卷的所有权和权限的方式。
  • 使用运行时类跳过卷的 SELinux 重新标记。

如需更多信息，请参阅在 OpenShift 中使用具有高文件计数的持久性卷时，为什么 pod 无法启动或占用大量时间来实现"Ready"状态？

Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务，以及可以信赖的内容，帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情，请参阅红帽博客.

關於紅帽

我们提供强化的解决方案，使企业能够更轻松地跨平台和环境（从核心数据中心到网络边缘）工作。

© 2024 Red Hat, Inc.