红帽全球峰会This documentation is for a release that is no longer maintained
See documentation for the latest supported version 3 or the latest supported version 4.节点
在 OpenShift Container Platform 中配置和管理节点
摘要
第 1 章 节点概述
1.1. 关于节点
节点是 Kubernetes 集群中的虚拟或裸机机器。Worker 节点托管您的应用容器，分组为 pod。control plane 节点运行控制 Kubernetes 集群所需的服务。在 OpenShift Container Platform 中，control plane 节点包含的不仅仅是 Kubernetes 服务，用于管理 OpenShift Container Platform 集群。
集群中有稳定健康的节点是托管应用程序的平稳运行的基础。在 OpenShift Container Platform 中，您可以通过代表节点的 Node 对象访问、管理和监控节点。使用 OpenShift CLI(oc)或 Web 控制台，您可以在节点上执行以下操作。
读取操作
通过读取操作，管理员可以或开发人员获取有关 OpenShift Container Platform 集群中节点的信息。
- 列出集群中的所有节点。
- 获取有关节点的信息，如内存和 CPU 使用量、健康状态、状态和年龄。
- 列出节点上运行的容器集。
管理操作
作为管理员，您可以通过以下几个任务轻松管理 OpenShift Container Platform 集群中的节点：
-
添加或更新节点标签。标签是应用到
Node对象的键值对。您可以使用标签控制 pod 的调度。 -
使用自定义资源定义(CRD)或
kubeletConfig对象更改节点配置。 -
配置节点以允许或禁止调度 pod。在 control plane 节点没有时，健康的 worker 节点默认
允许pod 放置。您可以通过 将 worker 节点配置为不可调度， 并可以调度 control plane 节点 来更改此默认行为。 -
使用
system-reserved设置为节点 分配资源。您可以允许 OpenShift Container Platform 自动决定节点的最佳system-reservedCPU 和内存资源，也可以手动为节点决定和设置最佳资源。 - 根据 节点上的处理器内核数和或硬限制，配置可在节点上运行的 pod 数量。
- 使用 pod 反关联性 安全地重新引导节点。
- 通过使用机器集缩减 集群来从集群中删除节点。要从裸机集群中删除节点，您必须首先排空节点上的所有 pod，然后手动删除该节点。
功能增强操作
OpenShift Container Platform 不仅允许您访问和管理节点；作为管理员，您可以在节点上执行以下任务，使集群更有效、应用友好，并为开发人员提供更好的环境。
- 使用 Node Tuning Operator 管理需要一定级别的内核调整的高性能应用程序的节点级性能优化。
- 使用守护进程集在节点上自动运行后台任务。您可以创建并使用守护进程集来创建共享存储，在每个节点上运行日志 pod，或者在所有节点上部署监控代理。
- 使用垃圾回收释放节点资源。您可以通过删除被终止的容器和任何正在运行的 pod 引用的镜像来确保节点高效运行。
- 向一组节点添加内核参数。
- 配置 OpenShift Container Platform 集群，使其有位于网络边缘（远程 worker 节点）的 worker 节点。有关在 OpenShift Container Platform 集群中使用远程 worker 节点的挑战以及一些推荐在远程 worker 节点上管理 pod 的方法，请参阅 在网络边缘使用远程 worker 节点。
1.2. 关于 pod
pod 是共同部署到一个节点上的一个或多个容器。作为集群管理员，您可以定义 pod，将其分配到准备调度和管理的健康节点上运行。只要容器正在运行，容器集就会运行。在 pod 被定义并在运行后，您无法更改它。在使用 pod 时可以执行的一些操作有：
读取操作
作为管理员，您可以通过以下任务获取项目中 pod 的信息：
- 列出与项目关联的 pod， 包括副本和重启数量、当前状态和年龄等信息。
- 查看 pod 使用量统计，如 CPU、内存和存储消耗。
管理操作
以下任务列表概述了管理员如何管理 OpenShift Container Platform 集群中的 pod。
使用 OpenShift Container Platform 中可用的高级调度功能控制 pod 调度：
- 节点对 pod 绑定规则，如 pod关联性、节点关联性 和反关联性。
- 节点标签和选择器。
- 污点和容限。
- Pod 拓扑分布限制。
- 自定义调度程序.
- 将 descheduler 配置为根据特定策略驱除 pod，以便调度程序将 pod 重新调度到更合适的节点。
- 配置 pod 控制器重启后 pod 的行为并重启策略。
- 限制 pod 上的出口和入口流量。
- 向具有 pod 模板的任何对象添加和移除卷。卷是挂载的文件系统，可供容器集中的所有容器使用。容器存储是临时的；您可以使用卷来持久保留容器数据。
功能增强操作
您可以使用 OpenShift Container Platform 中提供的各种工具和功能，更加轻松地高效地使用 pod。以下操作涉及使用这些工具和功能来更好地管理 pod。
| 操作 | 用户 | 更多信息 |
|---|---|---|
| 创建和使用横向 pod 自动缩放器。 | 开发者 | 您可以使用 pod 横向自动扩展来指定您要运行的 pod 的最小和最大数量，以及 pod 的目标 CPU 使用率或内存使用率。通过使用 pod 横向自动扩展，您可以 自动扩展 pod。 |
| 管理员和开发人员 | 作为管理员，通过监控资源和工作负载的资源要求，使用垂直 pod 自动缩放器来更好地利用集群资源。 作为开发人员，使用垂直 pod 自动缩放器，通过将 pod 调度到每个 pod 有充足资源的节点，来确保 pod 在高需求期间保持运行。 | |
| 利用设备插件提供对外部资源的访问权限。 | Administrator | 设备插件 是在节点上运行的 gRPC 服务（kubelet 外部），用于管理特定的硬件资源。您可以 部署设备插件， 以提供一致且可移植的解决方案，以便在集群中消耗硬件设备。 |
|
使用 | Administrator |
某些应用需要敏感信息，如密码和用户名。您可以使用 |
1.3. 关于容器
容器是 OpenShift Container Platform 应用的基本单元，其中包含打包的应用程序代码及其依赖项、库和二进制文件。容器提供不同环境间的一致性和多个部署目标：物理服务器、虚拟机 (VM) 和私有或公有云。
Linux 容器技术是隔离运行进程并仅限制对指定资源的访问的轻量机制。作为管理员，您可以在 Linux 容器上执行各种任务，例如：
OpenShift 容器平台提供称为 Init 容器的专用容器。在应用程序容器之前运行的 init 容器，可以包含应用程序镜像中不存在的实用程序或设置脚本。您可以在部署 pod 的其余部分之前，使用初始容器执行任务。
除了在节点、pod 和容器上执行特定任务外，您还可以使用整个 OpenShift Container Platform 集群来保持集群效率和应用程序 pod 高可用性。
第 2 章 使用 pod
2.1. 使用 pod
pod 是共同部署在同一主机上的一个或多个容器，也是可被定义、部署和管理的最小计算单元。
2.1.1. 了解 pod
对容器而言，Pod 大致相当于一个机器实例（物理或虚拟）。每个 pod 分配有自己的内部 IP 地址，因此拥有完整的端口空间，并且 pod 内的容器可以共享其本地存储和网络。
Pod 有生命周期，它们经过定义后，被分配到某一节点上运行，然后持续运行，直到容器退出或它们因为其他原因被删除为止。根据策略和退出代码，Pod 可在退出后删除，或被保留下来以启用对容器日志的访问。
OpenShift Container Platform 将 pod 基本上视为不可变；在运行期间无法更改 pod 定义。OpenShift Container Platform 通过终止现有的 pod，再利用修改后的配置和/或基础镜像重新创建 pod，从而实现更改。Pod 也被视为是可抛弃的，不会在重新创建时保持原来的状态。因此，pod 通常应通过更高级别的控制器来管理，而不直接由用户管理。
如需了解每个 OpenShift Container Platform 节点主机的最大 pod 数，请参阅“集群限制”。
不受复制控制器管理的裸机 pod 不能在节点中断时重新调度。
2.1.2. pod 配置示例
OpenShift Container Platform 使用 Kubernetes 的 pod 概念，它是共同部署在同一主机上的一个或多个容器，也是可被定义、部署和管理的最小计算单元。
以下是来自 Rails 应用的容器集定义示例：它展示了 pod 的许多特性，其中大多数已在其他主题中阐述，因此这里仅简略提及：
Pod 对象定义（YAML）
- 1
- pod 可以被“标上”一个或多个标签，然后使用这些标签在一个操作中选择和管理多组 pod。标签以键/值格式保存在
metadata散列中。 - 2
- pod 重启策略，可能的值有
Always、OnFailure和Never。默认值为Always。 - 3
- OpenShift Container Platform 为容器定义了一个安全上下文，指定是否允许其作为特权容器来运行，或者以所选用户身份运行，等等。默认上下文的限制性比较强，但管理员可以根据需要进行修改。
- 4
containers指定包括一个或多个容器定义的数组。- 5
- 容器指定在容器中挂载外部存储卷的位置。在本例中，有一个卷可用来存储对凭证的访问，该卷是根据 registry 对 OpenShift Container Platform API 发出请求所需的。
- 6
- 指定要为 pod 提供的卷。卷挂载在指定路径上。不要挂载到容器 root、
/或主机和容器中相同的任何路径。如果容器有足够权限，可能会损坏您的主机系统（如主机的/dev/pts文件）。使用/host挂载主机是安全的。 - 7
- pod 中的每个容器使用自己的容器镜像进行实例化。
- 8
- pod 对 OpenShift Container Platform API 发出请求是一种比较常见的模式，利用一个
serviceAccount字段指定 pod 在发出请求时使用哪个服务帐户用户来进行身份验证。这可以为自定义基础架构组件提供精细的访问控制。 - 9
- pod 定义了可供其容器使用的存储卷。在本例中，它为包含默认服务帐户令牌的
secret卷提供一个临时卷。如果将具有高文件数的持久性卷附加到 pod，则这些 pod 可能会失败，或者可能需要很长时间才能启动。如需更多信息，请参阅在 OpenShift 中使用具有高文件计数的持久性卷时，为什么 pod 无法启动或占用大量时间来实现"Ready"状态？
此 pod 定义不包括 OpenShift Container Platform 在 pod 创建并开始其生命周期后自动填充的属性。Kubernetes pod 文档详细介绍了 pod 的功能和用途。
2.2. 查看 pod
作为管理员，您可以查看集群中的 pod，并确定这些 pod 和整个集群的健康状态。
2.2.1. 关于 pod
OpenShift Container Platform 使用 Kubernetes 的 pod 概念，它是共同部署在同一主机上的一个或多个容器，也是可被定义、部署和管理的最小计算单元。对容器而言，Pod 大致相当于机器实例（物理或虚拟）。
您可以查看与特定项目关联的 pod 列表，或者查看 pod 的使用情况统计。
2.2.2. 查看项目中的 pod
您可以查看与当前项目关联的 pod 列表，包括副本数、当前状态、重启次数和 pod 的年龄。
流程
查看项目中的 pod：
切换到对应项目：
oc project <project-name>
$ oc project <project-name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令：
oc get pods
$ oc get podsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 例如：
oc get pods -n openshift-console
$ oc get pods -n openshift-consoleCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME READY STATUS RESTARTS AGE console-698d866b78-bnshf 1/1 Running 2 165m console-698d866b78-m87pm 1/1 Running 2 165m
NAME READY STATUS RESTARTS AGE console-698d866b78-bnshf 1/1 Running 2 165m console-698d866b78-m87pm 1/1 Running 2 165mCopy to Clipboard Copied! Toggle word wrap Toggle overflow 添加
-o wide标记来查看 pod IP 地址和 pod 所在的节点。oc get pods -o wide
$ oc get pods -o wideCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE console-698d866b78-bnshf 1/1 Running 2 166m 10.128.0.24 ip-10-0-152-71.ec2.internal <none> console-698d866b78-m87pm 1/1 Running 2 166m 10.129.0.23 ip-10-0-173-237.ec2.internal <none>
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE console-698d866b78-bnshf 1/1 Running 2 166m 10.128.0.24 ip-10-0-152-71.ec2.internal <none> console-698d866b78-m87pm 1/1 Running 2 166m 10.129.0.23 ip-10-0-173-237.ec2.internal <none>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.2.3. 查看 pod 用量统计
您可以显示 pod 的用量统计，这些统计信息为容器提供了运行时环境。这些用量统计包括 CPU、内存和存储的消耗。
先决条件
-
您必须有
cluster-reader权限才能查看用量统计。 - 必须安装 Metrics 才能查看用量统计。
流程
查看用量统计：
运行以下命令：
oc adm top pods
$ oc adm top podsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 例如：
oc adm top pods -n openshift-console
$ oc adm top pods -n openshift-consoleCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME CPU(cores) MEMORY(bytes) console-7f58c69899-q8c8k 0m 22Mi console-7f58c69899-xhbgg 0m 25Mi downloads-594fcccf94-bcxk8 3m 18Mi downloads-594fcccf94-kv4p6 2m 15Mi
NAME CPU(cores) MEMORY(bytes) console-7f58c69899-q8c8k 0m 22Mi console-7f58c69899-xhbgg 0m 25Mi downloads-594fcccf94-bcxk8 3m 18Mi downloads-594fcccf94-kv4p6 2m 15MiCopy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令，以查看带有标签的 pod 用量统计：
oc adm top pod --selector=''
$ oc adm top pod --selector=''Copy to Clipboard Copied! Toggle word wrap Toggle overflow 您必须选择过滤所基于的选择器（标签查询）。支持
=、==和!=。
2.2.4. 查看资源日志
您可以在 OpenShift CLI（oc）和 Web 控制台中查看各种资源的日志。日志从日志的尾部或末尾读取。
先决条件
- 访问 OpenShift CLI（oc）。
流程 (UI)
在 OpenShift Container Platform 控制台中，导航到 Workloads → Pods，或通过您要调查的资源导航到 pod。
注意有些资源（如构建）没有直接查询的 pod。在这种情况下，您可以在资源的 Details 页面中找到 Logs 链接。
- 从下拉菜单中选择一个项目。
- 点您要调查的 pod 的名称。
- 点击 Logs。
流程 (CLI)
查看特定 pod 的日志：
oc logs -f <pod_name> -c <container_name>
$ oc logs -f <pod_name> -c <container_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中：
-f- 可选：指定输出是否遵循要写到日志中的内容。
<pod_name>- 指定 pod 的名称。
<container_name>- 可选：指定容器的名称。当 pod 具有多个容器时，您必须指定容器名称。
例如：
oc logs ruby-58cd97df55-mww7r
$ oc logs ruby-58cd97df55-mww7rCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc logs -f ruby-57f7f4855b-znl92 -c ruby
$ oc logs -f ruby-57f7f4855b-znl92 -c rubyCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出的日志文件内容。
查看特定资源的日志：
oc logs <object_type>/<resource_name>
$ oc logs <object_type>/<resource_name>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 指定资源类型和名称。
例如：
oc logs deployment/ruby
$ oc logs deployment/rubyCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出的日志文件内容。
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 中成功退出的容器。默认值为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 文档中的示例状态。
2.3.2. 限制可供 pod 使用的带宽
您可以对 pod 应用服务质量流量控制，有效限制其可用带宽。出口流量（从 pod 传出）按照策略来处理，仅在超出配置的速率时丢弃数据包。入口流量（传入 pod 中）通过控制已排队数据包进行处理，以便有效地处理数据。您对 pod 应用的限制不会影响其他 pod 的带宽。
流程
限制 pod 的带宽：
编写对象定义 JSON 文件，并使用
kubernetes.io/ingress-bandwidth和kubernetes.io/egress-bandwidth注解指定数据流量速度。例如，将 pod 出口和入口带宽限制为 10M/s：受限
Pod对象定义Copy to Clipboard Copied! Toggle word wrap Toggle overflow 使用对象定义创建 pod：
oc create -f <file_or_dir_path>
$ oc create -f <file_or_dir_path>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.3.3. 了解如何使用 pod 中断预算来指定必须在线的 pod 数量
pod 中断预算是 Kubernetes API 的一部分，可以像其他对象类型一样通过 oc 命令进行管理。它们允许在操作过程中指定 pod 的安全约束，比如为维护而清空节点。
PodDisruptionBudget 是一个 API 对象，用于指定在某一时间必须保持在线的副本的最小数量或百分比。在项目中进行这些设置对节点维护（比如缩减集群或升级集群）有益，而且仅在自愿驱除（而非节点失败）时遵从这些设置。
PodDisruptionBudget 对象的配置由以下关键部分组成：
- 标签选择器，即一组 pod 的标签查询。
可用性级别，用来指定必须同时可用的最少 pod 的数量。
-
minAvailable是必须始终可用的 pod 的数量，即使在中断期间也是如此。 -
maxUnavailable是中断期间可以无法使用的 pod 的数量。
-
允许 maxUnavailable 为 0% 或 0，minAvailable 为 100％ 或等于副本数，但这样设置可能会阻止节点排空操作。
您可以使用以下命令来检查所有项目的 pod 中断预算：
oc get poddisruptionbudget --all-namespaces
$ oc get poddisruptionbudget --all-namespaces输出示例
NAMESPACE NAME MIN-AVAILABLE SELECTOR another-project another-pdb 4 bar=foo test-project my-pdb 2 foo=bar
NAMESPACE NAME MIN-AVAILABLE SELECTOR
another-project another-pdb 4 bar=foo
test-project my-pdb 2 foo=bar
如果系统中至少有 minAvailable 个 pod 正在运行，则 PodDisruptionBudget 被视为是健康的。超过这一限制的每个 pod 都可被驱除。
根据您的 pod 优先级与抢占设置，可能会无视 pod 中断预算要求而移除较低优先级 pod。
2.3.3.1. 使用 pod 中断预算指定必须在线的 pod 数量
您可以使用 PodDisruptionBudget 对象来指定某一时间必须保持在线的副本的最小数量或百分比。
流程
配置 pod 中断预算：
使用类似以下示例的对象定义来创建 YAML 文件：
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 或者：
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令，将对象添加到项目中：
oc create -f </path/to/file> -n <project_name>
$ oc create -f </path/to/file> -n <project_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.3.4. 使用关键 pod 防止删除 pod
有不少核心组件对于集群完全正常工作而言至关重要，但它们在常规集群节点而非主节点上运行。如果一个关键附加组件被驱除，集群可能会停止正常工作。
标记为关键 (critical) 的 Pod 不允许被驱除。
流程
使 pod 成为关键 pod：
创建
Podspec 或编辑现有的 pod，使其包含system-cluster-critical优先级类：spec: template: metadata: name: critical-pod priorityClassName: system-cluster-criticalspec: template: metadata: name: critical-pod priorityClassName: system-cluster-critical1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 绝不可从节点驱除的 pod 的默认优先级类。
此外，对于对集群而言很重要但可在必要时移除的 pod，可以指定
system-node-critical。创建 pod：
oc create -f <file-name>.yaml
$ oc create -f <file-name>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
2.4. 使用 pod 横向自动扩展自动扩展 pod
作为开发人员，您可以使用 pod 横向自动扩展 (HPA) 来指定 OpenShift Container Platform 如何根据从属于某复制控制器或部署配置的 pod 收集的指标来自动增加或缩小该复制控制器或部署配置的规模。
2.4.1. 了解 pod 横向自动扩展
您可以创建一个 pod 横向自动扩展来指定您要运行的 pod 的最小和最大数量，以及 pod 的目标 CPU 使用率或内存使用率。
在创建了 pod 横向自动扩展后，OpenShift Container Platform 会开始查询 pod 上的 CPU 和/或内存资源指标。当这些指标可用时，pod 横向自动扩展会计算当前指标使用率与所需指标使用率的比率，并相应地扩展或缩减。查询和缩放是定期进行的，但可能需要一到两分钟时间才会有可用指标。
对于复制控制器，这种缩放直接与复制控制器的副本对应。对于部署配置，缩放直接与部署配置的副本计数对应。注意，自动缩放仅应用到 Complete 阶段的最新部署。
OpenShift Container Platform 会自动考虑资源情况，并防止在资源激增期间进行不必要的自动缩放，比如在启动过程中。处于 unready 状态的 pod 在扩展时具有 0 CPU 用量，自动扩展在缩减时会忽略这些 pod。没有已知指标的 Pod 在扩展时具有 0% CPU 用量，在缩减时具有 100% CPU 用量。这在 HPA 决策过程中提供更高的稳定性。要使用这个功能，您必须配置就绪度检查来确定新 pod 是否准备就绪。
要使用 pod 横向自动扩展，您的集群管理员必须已经正确配置了集群指标。
2.4.1.1. 支持的指标
pod 横向自动扩展支持以下指标：
| 指标 | 描述 | API 版本 |
|---|---|---|
| CPU 使用率 | 已用的 CPU 内核数。可以用来计算 pod 的已请求 CPU 百分比。 |
|
| 内存使用率 | 已用内存量。可以用来计算 pod 的已请求内存百分比。 |
|
对于基于内存的自动缩放，内存用量必须与副本数呈正比增大和减小。平均而言：
- 增加副本数一定会导致每个 pod 的内存（工作集）用量总体降低。
- 减少副本数一定会导致每个 pod 的内存用量总体增高。
使用 OpenShift Container Platform Web 控制台检查应用程序的内存行为，并确保应用程序在使用基于内存的自动缩放前满足这些要求。
以下示例显示了 image-registry DeploymentConfig 对象的自动扩展。初始部署需要 3 个 pod。HPA 对象将最小值增加到 5，如果 pod 的 CPU 用量达到 75％，会将 pod 数最高增加到 7：
oc autoscale dc/image-registry --min=5 --max=7 --cpu-percent=75
$ oc autoscale dc/image-registry --min=5 --max=7 --cpu-percent=75输出示例
horizontalpodautoscaler.autoscaling/image-registry autoscaled
horizontalpodautoscaler.autoscaling/image-registry autoscaledimage-registry DeploymentConfig 对象的 HPA 示例，minReplicas 设置为 3
查看部署的新状态：
oc get dc image-registry
$ oc get dc image-registryCopy to Clipboard Copied! Toggle word wrap Toggle overflow 部署中现在有 5 个 pod:
输出示例
NAME REVISION DESIRED CURRENT TRIGGERED BY image-registry 1 5 5 config
NAME REVISION DESIRED CURRENT TRIGGERED BY image-registry 1 5 5 configCopy to Clipboard Copied! Toggle word wrap Toggle overflow
2.4.1.2. 扩展策略
autoscaling/v2beta2 API 允许您为 pod 横向自动扩展添加扩展策略。扩展策略用于控制 OpenShift Container Platform 横向自动扩展（HPA）如何扩展 pod。扩展策略允许您通过设置在指定时间段内扩展的特定数量或特定百分比来限制 HPA 扩展或缩减的速率。您还可以定义一个稳定化窗口（stabilization window），在指标有较大波动时，使用之前计算出的期望状态来控制扩展。您可以为相同的扩展方向创建多个策略，并根据更改的大小决定使用哪些策略。您还可以通过计时的迭代限制缩放。HPA 在迭代过程中扩展 pod，然后在以后的迭代中执行扩展（如果需要）。
带有扩展策略的 HPA 对象示例
- 1
- 指定扩展策略的方向，可以是
scaleDown或scaleUp。本例为缩减创建一个策略。 - 2
- 定义扩展策略。
- 3
- 决定策略是否在每次迭代过程中根据特定的 pod 数量或 pod 百分比进行扩展。默认值为
pod。 - 4
- 决定在每次迭代过程中缩放数量（pod 数量或 pod 的百分比）。在按 pod 数量进行缩减时没有默认的值。
- 5
- 决定扩展迭代的长度。默认值为
15秒。 - 6
- 按百分比缩减的默认值为 100%。
- 7
- 如果定义了多个策略，则决定首先使用哪个策略。指定
Max使用允许最多更改的策略，Min使用允许最小更改的策略，或者Disabled阻止 HPA 在策略方向进行扩展。默认值为Max。 - 8
- 决定 HPA 应该重新查看所需状态的时间周期。默认值为
0。 - 9
- 本例为扩展创建了策略。
- 10
- 根据 pod 数量进行扩展的数量。扩展 pod 数量的默认值为 4%。
- 11
- 按 pod 百分比扩展的数量。按百分比扩展的默认值为 100%。
缩减策略示例
在本例中，当 pod 的数量大于 40 时，则使用基于百分比的策略进行缩减。这个策略会产生较大变化，这是 selectPolicy 需要的。
如果有 80 个 pod 副本，在第一次迭代时 HPA 会将 pod 减少 8 个，即 80 个 pod 的 10%（根据 type: Percent 和 value: 10 参数），持续一分钟（periodSeconds: 60）。对于下一个迭代，pod 的数量为 72。HPA 计算剩余 pod 的 10% 为 7.2，这个数值被舍入到 8，这会缩减 8 个 pod。在每一后续迭代中，将根据剩余的 pod 数量重新计算要缩放的 pod 数量。当 pod 的数量低于 40 时，基于 pod 的策略会被应用，因为基于 pod 的数值会大于基于百分比的数值。HPA 每次减少 4 个 pod（type: Pod 和 value: 4），持续 30 秒（periodSeconds: 30），直到剩余 20 个副本（minReplicas）。
selectPolicy: Disabled 参数可防止 HPA 扩展 pod。如果需要，可以通过调整副本集或部署集中的副本数来手动扩展。
如果设置，您可以使用 oc edit 命令查看扩展策略：
oc edit hpa hpa-resource-metrics-memory
$ oc edit hpa hpa-resource-metrics-memory输出示例
2.4.2. 使用 Web 控制台创建 pod 横向自动扩展
在 web 控制台中，您可以创建一个 pod 横向自动扩展（HPA），用于指定要在部署上运行的 pod 的最小和最大数量。您还可以定义 pod 的目标 CPU 或内存用量。
HPA 不能添加到作为 Operator 支持服务、Knative 服务或 Helm chart 一部分的部署中。
流程
在 web 控制台中创建 HPA：
- 在 Topology 视图中，点击节点公开侧面板。
在 Actions 下拉列表中，选择 Add HorizontalPodAutoscaler 来打开 Add HorizontalPodAutoscaler 表单。
图 2.1. add HorizontalPodAutoscaler
在 Add HorizontalPodAutoscaler 表单中，定义名称、最小和最大 pod 限值、CPU 和内存用量，并点 Save。
注意如果缺少 CPU 和内存用量的值，则会显示警告。
在 web 控制台中编辑 HPA：
- 在 Topology 视图中，点击节点公开侧面板。
- 在 Actions 下拉列表中，选择 Edit HorizontalPodAutoscaler 来打开 Edit Horizontal Pod Autoscaler 表单。
- 在 Edit Horizontal Pod Autoscaler 表单中，编辑最小和最大 pod 限值以及 CPU 和内存用量，然后点 Save。
在 web 控制台中创建或编辑 pod 横向自动扩展时，您可以从 Form 视图切换到 YAML 视图。
在 web 控制台中删除 HPA：
- 在 Topology 视图中，点击节点公开侧面板。
- 在 Actions 下拉列表中，选择 Remove HorizontalPodAutoscaler。
- 在确认弹出窗口中点击 Remove 删除 HPA。
2.4.3. 使用 CLI 根据 CPU 使用率创建 pod 横向自动扩展
您可以为现有的 Deployment、DeploymentConfig、ReplicaSet、ReplicaSet 或 StatefulSet 对象创建一个 pod 横向自动扩展(HPA)，用于自动扩展与该对象关联的 pod，以维护您指定的 CPU 用量。
HPA 会在最小和最大数量之间增加和减少副本数，以保持所有 pod 的指定 CPU 使用率。
为 CPU 使用率自动扩展时，您可以使用 oc autoscale 命令，并指定要在任意给定时间运行的 pod 的最小和最大数量，以及 pod 的目标平均 CPU 使用率。如果未指定最小值，则 OpenShift Container Platform 服务器会为 pod 赋予一个默认值。要自动缩放特定 CPU 值，创建一个带有目标 CPU 和 pod 限制的 HorizontalPodAutoscaler 对象。
先决条件
要使用 pod 横向自动扩展，您的集群管理员必须已经正确配置了集群指标。您可以使用 oc describe PodMetrics <pod-name> 命令来判断是否已配置了指标。如果配置了指标，输出类似于以下示例，其中 Usage 下列出了 Cpu 和 Memory。
oc describe PodMetrics openshift-kube-scheduler-ip-10-0-135-131.ec2.internal
$ oc describe PodMetrics openshift-kube-scheduler-ip-10-0-135-131.ec2.internal输出示例
流程
为 CPU 使用率创建 pod 横向自动扩展
执行以下之一：
要根据 CPU 使用率百分比来缩放，请为现有对象创建一个
HorizontalPodAutoscaler对象：oc autoscale <object_type>/<name> \ --min <number> \ --max <number> \ --cpu-percent=<percent>
$ oc autoscale <object_type>/<name> \1 --min <number> \2 --max <number> \3 --cpu-percent=<percent>4 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例如，以下命令显示
image-registryDeploymentConfig对象的自动扩展。初始部署需要 3 个 pod。HPA 对象将最小值增加到 5，如果 pod 的 CPU 用量达到 75％，会将 pod 数最高增加到 7：oc autoscale dc/image-registry --min=5 --max=7 --cpu-percent=75
$ oc autoscale dc/image-registry --min=5 --max=7 --cpu-percent=75Copy to Clipboard Copied! Toggle word wrap Toggle overflow 要扩展特定 CPU 值，请为现有对象创建一个类似如下的 YAML 文件：
创建一个类似以下示例的 YAML 文件：
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 使用
autoscaling/v2beta2API。 - 2
- 指定此 pod 横向自动扩展对象的名称。
- 3
- 指定要缩放对象的 API 版本。
-
对于
ReplicationController，使用v1。 -
对于
DeploymentConfig，使用apps.openshift.io/v1。 -
对于
Deployment，ReplicaSet（Statefulset对象）使用apps/v1。
-
对于
- 4
- 指定对象的类型。对象必须是
Deployment、DeploymentConfig/dc、ReplicaSet/rs、ReplicationController/rc或StatefulSet。 - 5
- 指定要缩放的对象名称。对象必须存在。
- 6
- 指定缩减时的最小副本数量。
- 7
- 指定扩展时的最大副本数量。
- 8
- 对于内存使用率，使用
metrics参数。 - 9
- 为 CPU 使用率指定
cpu。 - 10
- 设置为
AverageValue。 - 11
- 使用目标 CPU 值设置为
averageValue。
创建 Pod 横向自动扩展：
oc create -f <file-name>.yaml
$ oc create -f <file-name>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
验证 pod 横向自动扩展是否已创建：
oc get hpa cpu-autoscale
$ oc get hpa cpu-autoscaleCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE cpu-autoscale ReplicationController/example 173m/500m 1 10 1 20m
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE cpu-autoscale ReplicationController/example 173m/500m 1 10 1 20mCopy to Clipboard Copied! Toggle word wrap Toggle overflow
2.4.4. 使用 CLI 根据内存使用率创建 pod 横向自动扩展对象
您可以为现有 DeploymentConfig 或 ReplicationController 对象创建一个 pod 横向自动扩展 (HPA) ，用于自动扩展与该对象关联的 pod，以便维护您指定的平均内存使用率（可以是一个直接的值，也可以是请求的内存百分比）。
HPA 增加和减少最小和最大数量之间的副本数量，以维护所有 pod 的指定内存使用率。
对于内存使用率，您可以指定 pod 的最小和最大数量，以及 pod 的目标平均内存使用率。如果未指定最小值，则 OpenShift Container Platform 服务器会为 pod 赋予一个默认值。
先决条件
要使用 pod 横向自动扩展，您的集群管理员必须已经正确配置了集群指标。您可以使用 oc describe PodMetrics <pod-name> 命令来判断是否已配置了指标。如果配置了指标，输出类似于以下示例，其中 Usage 下列出了 Cpu 和 Memory。
oc describe PodMetrics openshift-kube-scheduler-ip-10-0-129-223.compute.internal -n openshift-kube-scheduler
$ oc describe PodMetrics openshift-kube-scheduler-ip-10-0-129-223.compute.internal -n openshift-kube-scheduler输出示例
流程
根据内存使用率创建 pod 横向自动扩展：
为以下之一创建一个 YAML 文件：
要扩展特定内存值，请为现有
ReplicationController对象或复制控制器创建一个类似如下的HorizontalPodAutoscaler对象：输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 使用
autoscaling/v2beta2API。 - 2
- 指定此 pod 横向自动扩展对象的名称。
- 3
- 指定要缩放对象的 API 版本。
-
对于复制控制器，使用
v1, -
对于
DeploymentConfig对象，使用apps.openshift.io/v1。
-
对于复制控制器，使用
- 4
- 指定要缩放的对象类型，可以是
ReplicationController或DeploymentConfig。 - 5
- 指定要缩放的对象名称。对象必须存在。
- 6
- 指定缩减时的最小副本数量。
- 7
- 指定扩展时的最大副本数量。
- 8
- 对于内存使用率，使用
metrics参数。 - 9
- 为内存使用率指定
memory。 - 10
- 将类型设置为
AverageValue。 - 11
- 指定
averageValue和一个特定的内存值。 - 12
- 可选：指定一个扩展策略来控制扩展或缩减率。
要缩放一个百分比，创建一个与以下类似的
HorizontalPodAutoscaler对象：输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 使用
autoscaling/v2beta2API。 - 2
- 指定此 pod 横向自动扩展对象的名称。
- 3
- 指定要缩放对象的 API 版本。
-
对于复制控制器，使用
v1, -
对于
DeploymentConfig对象，使用apps.openshift.io/v1。
-
对于复制控制器，使用
- 4
- 指定要缩放的对象类型，可以是
ReplicationController或DeploymentConfig。 - 5
- 指定要缩放的对象名称。对象必须存在。
- 6
- 指定缩减时的最小副本数量。
- 7
- 指定扩展时的最大副本数量。
- 8
- 对于内存使用率，使用
metrics参数。 - 9
- 为内存使用率指定
memory。 - 10
- 设置
Utilization。 - 11
- 为所有 pod 指定
averageUtilization和一个目标平均内存利用率，以请求内存的百分比表示。目标 pod 必须配置内存请求。 - 12
- 可选：指定一个扩展策略来控制扩展或缩减率。
创建 Pod 横向自动扩展：
oc create -f <file-name>.yaml
$ oc create -f <file-name>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 例如：
oc create -f hpa.yaml
$ oc create -f hpa.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
horizontalpodautoscaler.autoscaling/hpa-resource-metrics-memory created
horizontalpodautoscaler.autoscaling/hpa-resource-metrics-memory createdCopy to Clipboard Copied! Toggle word wrap Toggle overflow 验证 pod 横向自动扩展是否已创建：
oc get hpa hpa-resource-metrics-memory
$ oc get hpa hpa-resource-metrics-memoryCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE hpa-resource-metrics-memory ReplicationController/example 2441216/500Mi 1 10 1 20m
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE hpa-resource-metrics-memory ReplicationController/example 2441216/500Mi 1 10 1 20mCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc describe hpa hpa-resource-metrics-memory
$ oc describe hpa hpa-resource-metrics-memoryCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.4.5. 使用 CLI 了解 pod 横向自动扩展状态条件
您可以使用设置的状态条件来判断 pod 横向自动扩展 (HPA) 是否能够缩放，以及目前是否受到某种方式的限制。
HPA 状态条件可通过 v2beta1 版的自动扩展 API 使用。
HPA 可以通过下列状态条件给予响应：
AbleToScale条件指示 HPA 是否能够获取和更新指标，以及是否有任何与退避相关的条件阻碍了缩放。-
True条件表示允许缩放。 -
False条件表示因为指定原因不允许缩放。
-
ScalingActive条件指示 HPA 是否已启用（例如，目标的副本数不为零），并且可以计算所需的指标。-
True条件表示指标工作正常。 -
False条件通常表示获取指标时出现问题。
-
ScalingLimited条件表示所需的规模由 pod 横向自动扩展限定最大或最小限制。-
True条件表示您需要提高或降低最小或最大副本数才能进行缩放。 False条件表示允许请求的缩放。oc describe hpa cm-test
$ oc describe hpa cm-testCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- pod 横向自动扩展状态消息。
-
下例中是一个无法缩放的 pod：
输出示例
下例中是一个无法获得缩放所需指标的 pod：
输出示例
Conditions: Type Status Reason Message ---- ------ ------ ------- AbleToScale True SucceededGetScale the HPA controller was able to get the target's current scale ScalingActive False FailedGetResourceMetric the HPA was unable to compute the replica count: failed to get cpu utilization: unable to get metrics for resource cpu: no metrics returned from resource metrics API
Conditions:
Type Status Reason Message
---- ------ ------ -------
AbleToScale True SucceededGetScale the HPA controller was able to get the target's current scale
ScalingActive False FailedGetResourceMetric the HPA was unable to compute the replica count: failed to get cpu utilization: unable to get metrics for resource cpu: no metrics returned from resource metrics API下例中是一个请求的自动缩放低于所需下限的 pod：
输出示例
2.4.5.1. 使用 CLI 查看 pod 横向自动扩展状态条件
您可以查看 pod 横向自动扩展 (HPA) 对 pod 设置的状态条件。
pod 横向自动扩展状态条件可通过 v2beta1 版的自动扩展 API 使用。
先决条件
要使用 pod 横向自动扩展，您的集群管理员必须已经正确配置了集群指标。您可以使用 oc describe PodMetrics <pod-name> 命令来判断是否已配置了指标。如果配置了指标，输出类似于以下示例，其中 Usage 下列出了 Cpu 和 Memory。
oc describe PodMetrics openshift-kube-scheduler-ip-10-0-135-131.ec2.internal
$ oc describe PodMetrics openshift-kube-scheduler-ip-10-0-135-131.ec2.internal输出示例
流程
要查看 pod 上的状态条件，请使用以下命令并提供 pod 的名称：
oc describe hpa <pod-name>
$ oc describe hpa <pod-name>例如：
oc describe hpa cm-test
$ oc describe hpa cm-test
这些条件会出现在输出中的 Conditions 字段里。
输出示例
2.5. 使用垂直 pod 自动扩展自动调整 pod 资源级别
OpenShift Container Platform Vertical Pod Autoscaler Operator（VPA）会自动检查 pod 中容器的运行状况和当前的 CPU 和内存资源，并根据它所了解的用量值更新资源限值和请求。VPA 使用单独的自定义资源（CR）来更新与工作负载对象关联的所有 Pod，如 Deployment、Deployment Config、StatefulSet、Job、DaemonSet、ReplicaSet 或 ReplicationController。
VPA 可帮助您了解 Pod 的最佳 CPU 和内存使用情况，并可以通过 pod 生命周期自动维护 pod 资源。
垂直 Pod 自动扩展只是一个技术预览功能。技术预览功能不被红帽产品服务等级协议 (SLA) 支持，且可能在功能方面有缺陷。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能，并有机会在开发阶段提供反馈意见。
有关红帽技术预览功能支持范围的详情，请参阅 https://access.redhat.com/support/offerings/techpreview/。
2.5.1. 关于 Vertical Pod Autoscaler Operator
Vertical Pod Autoscaler Operator（VPA）作为 API 资源和自定义资源（CR）实现。CR 决定 Vertical Pod Autoscaler Operator 对与特定工作负载对象（如守护进程集、复制控制器等）关联的 pod 执行的操作。
VPA 自动计算这些 pod 中容器的流程以及当前的 CPU 和内存使用情况，并使用这些数据来决定优化的资源限制和请求，以确保这些 pod 始终高效操作。例如，VPA 会减少请求资源超过使用资源的 pod 的资源，并为没有请求充足资源的 pod 增加资源。
VPA 每次自动删除任何与建议不兼容的 pod，以便您的应用程序可以在不需要停机的情况下继续满足请求。然后，工作负载对象使用原始资源限制和请求重新部署 pod。VPA 使用一个变异准入 webhook 来更新 pod，在 pod 被允许到节点前，具有优化的资源限制和请求。如果您不希望 VPA 删除 pod，可以查看 VPA 资源限制和请求，并根据需要手动更新 pod。
例如，您有一个 pod 使用了 CPU 的 50%，但只请求 10%。VPA 会认定该 pod 消耗的 CPU 多于请求的 CPU，并删除 pod。工作负载对象（如副本集）会重启 pod，VPA 使用推荐的资源更新新 pod。
对于开发人员，您可以使用 VPA 来帮助确保 pod 在高负载时可以继续工作，具体方法是将 pod 调度到每个 pod 具有适当资源的节点上。
管理员可以使用 VPA 来更好地利用集群资源，例如防止 pod 保留比所需的 CPU 资源更多的资源。VPA 监控实际使用的工作负载，并对资源进行调整，以确保可以满足其他工作负载的需要。VPA 还维护初始容器配置中指定的限值和请求之间的比例。
如果您停止在集群中运行 VPA，或删除特定的 VPA CR，则已由 VPA 修改的 pod 的资源请求不会改变。任何新 pod 都会根据工作负载对象中的定义获得资源，而不是之前由 VPA 提供的的建议。
2.5.2. 安装 Vertical Pod Autoscaler Operator
您可以使用 OpenShift Container Platform web 控制台安装 Vertical Pod Autoscaler Operator（VPA）。
流程
- 在 OpenShift Container Platform Web 控制台中，点击 Operators → OperatorHub。
- 从可用 Operator 列表中选择 VerticalPodAutoscaler，点 Install。
-
在 Install Operator 页面中，确保选择了 Operator 推荐的命名空间 选项。这会在
openshift-vertical-pod-autoscaler命名空间中创建 Operator。如果这个命名空间还没有存在，会自动创建它。 - 点击 Install。
列出 VPA Operator 组件来验证安装：
- 导航到 Workloads → Pods。
-
从下拉菜单中选择
openshift-vertical-pod-autoscaler项目，并验证是否运行了 4 个 pod。 - 进入 Workloads → Deployments 以验证运行了四个部署。
可选。使用以下命令在 OpenShift Container Platform CLI 中验证安装：
oc get all -n openshift-vertical-pod-autoscaler
$ oc get all -n openshift-vertical-pod-autoscalerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出显示 4 个 pod 和 4 个部署：
输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.5.3. 关于使用 Vertical Pod Autoscaler Operator
要使用 Vertical Pod Autoscaler Operator（vpa），您需要为集群中的工作负载对象创建 VPA 自定义资源（CR）。VPA 学习并应用与该工作负载对象关联的 pod 的最佳 CPU 和内存资源。您可以使用 VPA 与部署、有状态集、作业、守护进程集、副本集或复制控制器工作负载对象一起使用。VPA CR 必须与您要监控的 pod 位于同一个项目中。
您可以使用 VPA CR 关联一个工作负载对象，并指定 VPA 使用什么模式运行：
-
Auto和Recreate模式会在 pod 生命周期内自动应用 VPA 对 CPU 和内存建议。VPA 会删除项目中任何与建议不兼容的 pod。当由工作负载对象重新部署时，VPA 会在其建议中更新新 pod。 -
Initial模式仅在创建 pod 时自动应用 VPA 建议。 -
Off模式只提供推荐的资源限制和请求信息，用户可以手动应用其中的建议。off模式不会更新 pod。
您还可以使用 CR 使特定容器不受 VPA 评估和更新的影响。
例如，pod 具有以下限制和请求：
在创建了一个设置为 auto 的 VPA 后，VPA 会了解资源使用情况并删除 pod。重新部署时，pod 会使用新的资源限值和请求：
您可以使用以下命令查看 VPA 建议：
oc get vpa <vpa-name> --output yaml
$ oc get vpa <vpa-name> --output yaml几分钟后，输出显示 CPU 和内存请求的建议，如下所示：
输出示例
输出显示推荐的资源、目标、最低推荐资源、lowerBound、最高推荐资源、upperBound、以及最新资源建议和 uncappedTarget。
VPA 使用 lessBound 和 upperBound 值来确定一个 pod 是否需要更新。如果 pod 的资源请求低于 lowerBound 值，或高于 upperBound 值，则 VPA 会终止 pod，并使用 target 值重新创建 pod。
2.5.3.1. 自动应用 VPA 建议
要使用 VPA 来自动更新 pod，为特定工作负载对象创建一个 VPA CR，并将 updateMode 设置为 Auto 或 Recreate。
当为工作复杂对象创建 pod 时，VPA 会持续监控容器以分析其 CPU 和内存需求。VPA 会删除任何不满足 VPA 对 CPU 和内存的建议的 pod。重新部署后，pod 根据 VPA 建议使用新的资源限值和请求，并遵循您的应用程序的 pod 中断预算。建议被添加到 VPA CR 的 status 字段中以进行引用。
工作负载对象必须至少指定两个副本，以便 VPA 监控和更新 pod。如果工作负载对象指定一个副本，VPA 不会删除 pod 来防止应用程序停机。您可以手动删除 pod 以使用推荐的资源。
Auto 模式的 VPA CR 示例
在 VPA 可以决定推荐的资源并对新 pod 应用推荐前，pod 必须已在运行。
2.5.3.2. 在创建 pod 时自动应用 VPA 建议
要仅在 pod 首次部署时使用 VPA 来应用推荐的资源，为特定的工作负载对象创建一个 VPA CR，将 updateMode 设置为 Initial。
然后，手动删除与您要使用 VPA 建议的工作负载对象关联的 pod。在 Initial 模式中，VPA 不会删除 pod，也不会更新 pod，它会学习新的资源建议。
Initial 模式的 VPA CR 示例
在 VPA 可以决定推荐的资源并对新 pod 应用推荐前，项目中必须已有已在运行的 pod。
2.5.3.3. 手动应用 VPA 建议
要使用 VPA 来仅决定推荐的 CPU 和内存值而不进行实际的应用，对特定的工作负载创建一个 VPA CR，把 updateMode 设置为 off。
当为该工作负载对象创建 pod 时, VPA 会分析容器的 CPU 和内存需求，并在 VPA CR 的 status 字段中记录推荐。VPA 会提供新的资源建议，但不会更新 pod。
使用 Off 模式的 VPA CR 示例
您可以使用以下命令查看建议。
oc get vpa <vpa-name> --output yaml
$ oc get vpa <vpa-name> --output yaml根据建议，您可以编辑工作负载对象以添加 CPU 和内存请求，然后删除 pod 并使用推荐的资源重新部署 pod。
在 VPA 可以决定推荐的资源前，pod 必须已在运行。
2.5.3.4. 阻止容器特定容器应用 VPA 建议
如果您的工作负载对象有多个容器，且您不希望 VPA 对所有容器进行评估并进行操作，请为特定工作负载对象创建一个 VPA CR，添加一个 resourcePolicy 已使特定容器不受 VPA 的影响。
当 VPA 使用推荐的资源更新 pod 时，任何带有 resourcePolicy 的容器都不会被更新，且 VPA 不会对这些 pod 中的容器提供建议。
例如，一个 pod 有两个容器，它们有相同的资源请求和限值：
在启用一个带有 backend 排除容器设置的 VPA CR 后，VPA 终止并使用推荐的资源重新创建 pod 的行为只适用于 frontend 容器。
2.5.4. 使用 Vertical Pod Autoscaler Operator
您可以通过创建 VPA 自定义资源（CR）来使用 Vertical Pod Autoscaler Operator（VPA）。CR 指明应分析哪些 pod，并决定 VPA 应该对这些 pod 执行的操作。
流程
为特定工作负载对象创建 VPA CR:
切换到您要缩放的工作负载对象所在的项目。
创建一个 VPA CR YAML 文件：
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 指定您需要这个 VPA 管理的工作负载对象类型：
Deployment、StatefulSet、Job、DaemonSet、ReplicaSet或ReplicationController。 - 2
- 指定您希望此 VPA 管理的现有工作负载对象的名称。
- 3
- 指定 VPA 模式：
-
auto会在与控制器关联的 pod 上自动应用推荐的资源。VPA 会终止现有的 pod，并使用推荐的资源限制和请求创建新 pod。 -
recreate会在与工作负载对象关联的 pod 上自动应用推荐的资源。VPA 会终止现有的 pod，并使用推荐的资源限制和请求创建新 pod。recreate模式应该很少使用，只有在需要确保每当资源请求改变时 pod 就需要重启时才使用。 -
Initial在创建与工作负载对象关联的 pod 时自动应用推荐的资源。VPA 会学习新的资源建议，但不会更新 pod。 -
off仅为与工作负载对象关联的 pod 生成资源建议。VPA 不会更新 pod，它只会学习新的资源建议，且不会将建议应用到新 pod。
-
- 4
- 可选。指定不需要受 VPA 影响的容器，将模式设置为
Off。
创建 VPA CR:
oc create -f <file-name>.yaml
$ oc create -f <file-name>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 在一段短暂的时间后，VPA 会了解与工作负载对象关联的 pod 中容器的资源使用情况。
您可以使用以下命令查看 VPA 建议：
oc get vpa <vpa-name> --output yaml
$ oc get vpa <vpa-name> --output yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出显示 CPU 和内存请求的建议，如下所示：
输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.5.5. 卸载 Vertical Pod Autoscaler Operator
您可以从 OpenShift Container Platform 集群中删除 Vertical Pod Autoscaler Operator（VPA）。卸载后，已由现有 VPA CR 修改的 pod 的资源请求不会改变。任何新 pod 都会根据工作负载对象中的定义获得资源，而不是之前由 VPA 提供的的建议。
您可以使用 oc delete vpa <vpa-name> 命令删除特定的 VPA。在卸载垂直 pod 自动扩展时，同样的操作适用于资源请求。
删除 VPA Operator 后，建议您删除与 Operator 相关的其他组件，以避免潜在的问题。
先决条件
- 已安装 Vertical Pod Autoscaler Operator。
流程
- 在 OpenShift Container Platform web 控制台中，点击 Operators → Installed Operators。
- 切换到 openshift-vertical-pod-autoscaler 项目。
- 找到 VerticalPodAutoscaler Operator，点 Options 菜单。点击 Uninstall Operator。
- 在对话框中点 Uninstall。
- 可选： 要删除与 Operator 关联的所有操作对象，请在对话框中选择 Delete all operand instance for this operator 复选框。
- 点击 Uninstall。
可选： 使用 OpenShift CLI 删除 VPA 组件：
删除 VPA 变异 Webhook 配置：
oc delete mutatingwebhookconfigurations/vpa-webhook-config
$ oc delete mutatingwebhookconfigurations/vpa-webhook-configCopy to Clipboard Copied! Toggle word wrap Toggle overflow 列出所有 VPA 自定义资源：
oc get verticalpodautoscalercheckpoints.autoscaling.k8s.io,verticalpodautoscalercontrollers.autoscaling.openshift.io,verticalpodautoscalers.autoscaling.k8s.io -o wide --all-namespaces
$ oc get verticalpodautoscalercheckpoints.autoscaling.k8s.io,verticalpodautoscalercontrollers.autoscaling.openshift.io,verticalpodautoscalers.autoscaling.k8s.io -o wide --all-namespacesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 删除列出的 VPA 自定义资源。例如：
oc delete verticalpodautoscalercheckpoint.autoscaling.k8s.io/vpa-recommender-httpd -n my-project
$ oc delete verticalpodautoscalercheckpoint.autoscaling.k8s.io/vpa-recommender-httpd -n my-projectCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc delete verticalpodautoscalercontroller.autoscaling.openshift.io/default -n openshift-vertical-pod-autoscaler
$ oc delete verticalpodautoscalercontroller.autoscaling.openshift.io/default -n openshift-vertical-pod-autoscalerCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc delete verticalpodautoscaler.autoscaling.k8s.io/vpa-recommender -n my-project
$ oc delete verticalpodautoscaler.autoscaling.k8s.io/vpa-recommender -n my-projectCopy to Clipboard Copied! Toggle word wrap Toggle overflow 列出所有 VPA 自定义资源定义(CRD)：
oc get crd
$ oc get crdCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 删除列出的 VPA CRD：
oc delete crd verticalpodautoscalercheckpoints.autoscaling.k8s.io verticalpodautoscalercontrollers.autoscaling.openshift.io verticalpodautoscalers.autoscaling.k8s.io
$ oc delete crd verticalpodautoscalercheckpoints.autoscaling.k8s.io verticalpodautoscalercontrollers.autoscaling.openshift.io verticalpodautoscalers.autoscaling.k8s.ioCopy to Clipboard Copied! Toggle word wrap Toggle overflow 删除 CRD 会删除关联的角色、集群角色和角色绑定。但是，可能存在一些必须手动删除的集群角色。
列出任何 VPA 集群角色：
oc get clusterrole | grep openshift-vertical-pod-autoscaler
$ oc get clusterrole | grep openshift-vertical-pod-autoscalerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
openshift-vertical-pod-autoscaler-6896f-admin 2022-02-02T15:29:55Z openshift-vertical-pod-autoscaler-6896f-edit 2022-02-02T15:29:55Z openshift-vertical-pod-autoscaler-6896f-view 2022-02-02T15:29:55Z
openshift-vertical-pod-autoscaler-6896f-admin 2022-02-02T15:29:55Z openshift-vertical-pod-autoscaler-6896f-edit 2022-02-02T15:29:55Z openshift-vertical-pod-autoscaler-6896f-view 2022-02-02T15:29:55ZCopy to Clipboard Copied! Toggle word wrap Toggle overflow 删除列出的 VPA 集群角色。例如：
oc delete clusterrole openshift-vertical-pod-autoscaler-6896f-admin openshift-vertical-pod-autoscaler-6896f-edit openshift-vertical-pod-autoscaler-6896f-view
$ oc delete clusterrole openshift-vertical-pod-autoscaler-6896f-admin openshift-vertical-pod-autoscaler-6896f-edit openshift-vertical-pod-autoscaler-6896f-viewCopy to Clipboard Copied! Toggle word wrap Toggle overflow 删除 VPA Operator：
oc delete operator/vertical-pod-autoscaler.openshift-vertical-pod-autoscaler
$ oc delete operator/vertical-pod-autoscaler.openshift-vertical-pod-autoscalerCopy to Clipboard Copied! Toggle word wrap Toggle overflow
2.6. 为 pod 提供敏感数据
有些应用程序需要密码和用户名等敏感信息，但您不希望开发人员持有这些信息。
作为管理员，您可以使用 Secret 对象在不以明文方式公开的前提下提供此类信息。
2.6.1. 了解 secret
Secret 对象类型提供了一种机制来保存敏感信息，如密码、OpenShift Container Platform 客户端配置文件和私有源存储库凭证等。secret 将敏感内容与 Pod 分离。您可以使用卷插件将 secret 信息挂载到容器中，系统也可以使用 secret 代表 Pod 执行操作。
主要属性包括：
- Secret 数据可以独立于其定义来引用。
- Secret 数据卷由临时文件工具 (tmpfs) 支持，永远不会停留在节点上。
- secret 数据可以在命名空间内共享。
YAML Secret 对象定义
您必须先创建 secret，然后创建依赖于此 secret 的 Pod。
在创建 secret 时：
- 使用 secret 数据创建 secret 对象。
- 更新 pod 的服务帐户以允许引用该 secret。
-
创建以环境变量或文件（使用
secret卷）形式消耗 secret 的 pod。
2.6.1.1. secret 的类型
type 字段中的值指明 secret 的键名称和值的结构。此类型可用于强制使 secret 对象中存在用户名和密钥。如果您不想进行验证，请使用 opaque 类型，这也是默认类型。
指定以下一种类型来触发最小服务器端验证，确保 secret 数据中存在特定的键名称：
-
kubernetes.io/service-account-token。使用服务帐户令牌。 -
kubernetes.io/basic-auth。搭配基本身份验证使用。 -
kubernetes.io/ssh-auth。搭配 SSH 密钥身份验证使用。 -
kubernetes.io/tls。搭配 TLS 证书颁发机构使用。
如果您不想要验证，请指定 type: Opaque，即 secret 没有声明键名称或值需要符合任何约定。opaque secret 允许使用无结构 key:value 对，可以包含任意值。
您可以指定其他任意类型，如 example.com/my-secret-type。这些类型不是在服务器端强制执行，而是表明 secret 的创建者意在符合该类型的键/值要求。
如需不同 secret 类型的示例，请参阅使用 secret 中的代码示例。
2.6.1.2. Secret 数据密钥
Secret 密钥必须在 DNS 子域中。
2.6.2. 了解如何创建 secret
作为管理员，您必须先创建 secret，然后开发人员才能创建依赖于该 secret 的 pod。
在创建 secret 时：
创建包含您要保留 secret 的数据的 secret 对象。在以下部分中取消每个 secret 类型所需的特定数据。
创建不透明 secret 的 YAML 对象示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 使用
data或stringdata字段，不能同时使用这两个字段。更新 pod 的服务帐户以引用 secret：
使用 secret 的服务帐户的 YAML
apiVersion: v1 kind: ServiceAccount ... secrets: - name: test-secret
apiVersion: v1 kind: ServiceAccount ... secrets: - name: test-secretCopy to Clipboard Copied! Toggle word wrap Toggle overflow 创建以环境变量或文件（使用 secret 卷）形式消耗
secret的 pod：pod 的 YAML 使用 secret 数据填充卷中的文件
Copy to Clipboard Copied! Toggle word wrap Toggle overflow pod 的 YAML 使用 secret 数据填充环境变量
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 指定消耗 secret 密钥的环境变量。
构建配置的 YAML 使用 secret 数据填充环境变量
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 指定消耗 secret 密钥的环境变量。
2.6.2.1. Secret 创建限制
若要使用 secret，pod 需要引用该 secret。可以通过三种方式将 secret 用于 Pod：
- 为容器产生环境变量。
- 作为挂载到一个或多个容器上的卷中的文件。
- 在拉取 Pod 的镜像时通过 kubelet 使用。
卷类型 secret 使用卷机制将数据作为文件写入到容器中。镜像拉取 secret 使用服务帐户，将 secret 自动注入到命名空间中的所有 pod。
当模板包含 secret 定义时，模板使用提供的 secret 的唯一方法是确保验证 secret 卷源通过验证，并且指定的对象引用实际指向 Secret 类型的对象。因此，secret 需要在依赖它的任何 Pod 之前创建。确保这一点的最有效方法是通过使用服务帐户自动注入。
Secret API 对象驻留在命名空间中。它们只能由同一命名空间中的 pod 引用。
每个 secret 的大小限制为 1MB。这是为了防止创建可能会耗尽 apiserver 和 kubelet 内存的大型 secret。不过，创建许多较小的 secret 也可能会耗尽内存。
2.6.2.2. 创建不透明 secret
作为管理员，您可以创建一个不透明 secret，它允许您存储包含任意值的无结构 键：值对。
流程
在 control plane 节点上的 YAML 文件中创建
Secret对象。例如：
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 指定不透明 secret。
使用以下命令来创建
Secret对象：oc create -f <filename>.yaml
$ oc create -f <filename>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 在 pod 中使用该 secret:
- 更新 pod 的服务帐户以引用 secret，如 "Understanding how to create secrets" 部分所示。
-
创建以环境变量或文件（使用 secret 卷）形式消耗
secret的 pod，如"正在创建 secret"部分所示。
2.6.2.3. 创建服务帐户令牌 secret
作为管理员，您可以创建一个服务帐户令牌 secret，该 secret 允许您将服务帐户令牌分发到必须通过 API 进行身份验证的应用程序。
建议使用 TokenRequest API 获取绑定的服务帐户令牌，而不使用服务帐户令牌 secret。从 TokenRequest API 获取的令牌比存储在 secret 中的令牌更安全，因为它们具有绑定的生命周期，且不能被其他 API 客户端读取。
只有在无法使用 TokenRequest API 且在可读的 API 对象中存在非过期令牌时，才应创建服务帐户令牌 secret。
有关创建绑定服务帐户令牌的信息，请参阅下面的附加资源部分。
流程
在 control plane 节点上的 YAML 文件中创建
Secret对象：secret对象示例：Copy to Clipboard Copied! Toggle word wrap Toggle overflow 使用以下命令来创建
Secret对象：oc create -f <filename>.yaml
$ oc create -f <filename>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 在 pod 中使用该 secret:
- 更新 pod 的服务帐户以引用 secret，如 "Understanding how to create secrets" 部分所示。
-
创建以环境变量或文件（使用 secret 卷）形式消耗
secret的 pod，如"正在创建 secret"部分所示。
2.6.2.4. 创建基本身份验证 secret
作为管理员，您可以创建一个基本身份验证 secret，该 secret 允许您存储基本身份验证所需的凭证。在使用此 secret 类型时，Secret 对象的 data 参数必须包含以下密钥，采用 base64 格式编码：
-
用户名：用于身份验证的用户名 -
密码：用于身份验证的密码或令牌
您可以使用 stringData 参数使用明文内容。
流程
在 control plane 节点上的 YAML 文件中创建
Secret对象：secret对象示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 使用以下命令来创建
Secret对象：oc create -f <filename>.yaml
$ oc create -f <filename>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 在 pod 中使用该 secret:
- 更新 pod 的服务帐户以引用 secret，如 "Understanding how to create secrets" 部分所示。
-
创建以环境变量或文件（使用 secret 卷）形式消耗
secret的 pod，如"正在创建 secret"部分所示。
2.6.2.5. 创建 SSH 身份验证 secret
作为管理员，您可以创建一个 SSH 验证 secret，该 secret 允许您存储用于 SSH 验证的数据。在使用此 secret 类型时，Secret 对象的 data 参数必须包含要使用的 SSH 凭证。
流程
在 control plane 节点上的 YAML 文件中创建
Secret对象：secret对象示例：Copy to Clipboard Copied! Toggle word wrap Toggle overflow 使用以下命令来创建
Secret对象：oc create -f <filename>.yaml
$ oc create -f <filename>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 在 pod 中使用该 secret:
- 更新 pod 的服务帐户以引用 secret，如 "Understanding how to create secrets" 部分所示。
-
创建以环境变量或文件（使用 secret 卷）形式消耗
secret的 pod，如"正在创建 secret"部分所示。
2.6.2.6. 创建 Docker 配置 secret
作为管理员，您可以创建一个 Docker 配置 secret，该 secret 允许您存储用于访问容器镜像 registry 的凭证。
-
kubernetes.io/dockercfg。使用此机密类型存储本地 Docker 配置文件。secret对象的data参数必须包含以 base64 格式编码的.dockercfg文件的内容。 -
kubernetes.io/dockerconfigjson。使用此机密类型存储本地 Docker 配置 JSON 文件。secret对象的data参数必须包含以 base64 格式编码的.docker/config.json文件的内容。
流程
在 control plane 节点上的 YAML 文件中创建
Secret对象。Docker 配置
secret对象示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow Docker 配置 JSON
secret对象示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 使用以下命令来创建
Secret对象oc create -f <filename>.yaml
$ oc create -f <filename>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 在 pod 中使用该 secret:
- 更新 pod 的服务帐户以引用 secret，如 "Understanding how to create secrets" 部分所示。
-
创建以环境变量或文件（使用 secret 卷）形式消耗
secret的 pod，如"正在创建 secret"部分所示。
2.6.3. 了解如何更新 secret
修改 secret 值时，值（由已在运行的 pod 使用）不会动态更改。若要更改 secret，您必须删除原始 pod 并创建一个新 pod（可能具有相同的 PodSpec）。
更新 secret 遵循与部署新容器镜像相同的工作流程。您可以使用 kubectl rolling-update 命令。
secret 中的 resourceVersion 值不在引用时指定。因此，如果在 pod 启动的同时更新 secret，则将不能定义用于 pod 的 secret 版本。
目前，无法检查 Pod 创建时使用的 secret 对象的资源版本。按照计划 Pod 将报告此信息，以便控制器可以重启使用旧 resourceVersion 的 Pod。在此期间，请勿更新现有 secret 的数据，而应创建具有不同名称的新数据。
2.6.4. 关于将签名证书与 secret 搭配使用
若要与服务进行安全通信，您可以配置 OpenShift Container Platform，以生成一个签名的服务用证书/密钥对，再添加到项目中的 secret 里。
服务用证书 secret 旨在支持需要开箱即用证书的复杂中间件应用程序。它的设置与管理员工具为节点和 master 生成的服务器证书相同。
为服务用证书 secret 配置的服务 Pod 规格。
- 1
- 指定证书的名称
其他 pod 可以信任集群创建的证书（仅对内部 DNS 名称进行签名），方法是使用 pod 中自动挂载的 /var/run/secrets/kubernetes.io/serviceaccount/service-ca.crt 文件中的 CA 捆绑。
此功能的签名算法是 x509.SHA256WithRSA。要手动轮转，请删除生成的 secret。这会创建新的证书。
2.6.4.1. 生成签名证书以便与 secret 搭配使用
要将签名的服务证书/密钥对用于 pod，请创建或编辑服务以添加 service. beta.openshift.io/serving-cert-secret-name 注解，然后将 secret 添加到 pod。
流程
创建服务用证书 secret：
-
编辑服务的
Podspec。 使用您要用于 secret 的名称添加
service.beta.openshift.io/serving-cert-secret-name注解。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 证书和密钥采用 PEM 格式，分别存储在
tls.crt和tls.key中。创建服务：
oc create -f <file-name>.yaml
$ oc create -f <file-name>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 查看 secret 以确保已成功创建：
查看所有 secret 列表：
oc get secrets
$ oc get secretsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME TYPE DATA AGE my-cert kubernetes.io/tls 2 9m
NAME TYPE DATA AGE my-cert kubernetes.io/tls 2 9mCopy to Clipboard Copied! Toggle word wrap Toggle overflow 查看您的 secret 详情：
oc describe secret my-cert
$ oc describe secret my-certCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
编辑与该 secret 搭配的
Podspec。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 当它可用时，您的 Pod 就可运行。该证书对内部服务 DNS 名称
<service.name>.<service.namespace>.svc有效。证书/密钥对在接近到期时自动替换。在 secret 的
service.beta.openshift.io/expiry注解中查看过期日期，其格式为 RFC3339。注意在大多数情形中，服务 DNS 名称
<service.name>.<service.namespace>.svc不可从外部路由。<service.name>.<service.namespace>.svc的主要用途是集群内或服务内通信，也用于重新加密路由。
2.6.5. secret 故障排除
如果服务证书生成失败并显示以下信息（ 服务的 service.beta.openshift.io/serving-cert-generation-error 注解包含）：
secret/ssl-key references serviceUID 62ad25ca-d703-11e6-9d6f-0e9c0057b608, which does not match 77b6dd80-d716-11e6-9d6f-0e9c0057b60
secret/ssl-key references serviceUID 62ad25ca-d703-11e6-9d6f-0e9c0057b608, which does not match 77b6dd80-d716-11e6-9d6f-0e9c0057b60
生成证书的服务不再存在，或者具有不同的 serviceUID 。您必须删除旧 secret 并清除 service.beta.openshift.io/serving-cert-generation-error, service.beta.openshift.io/serving-cert 证书：
-generation-error -num 中的以下注解来强制重新生成
删除 secret：
oc delete secret <secret_name>
$ oc delete secret <secret_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 清除注解：
oc annotate service <service_name> service.beta.openshift.io/serving-cert-generation-error-
$ oc annotate service <service_name> service.beta.openshift.io/serving-cert-generation-error-Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc annotate service <service_name> service.beta.openshift.io/serving-cert-generation-error-num-
$ oc annotate service <service_name> service.beta.openshift.io/serving-cert-generation-error-num-Copy to Clipboard Copied! Toggle word wrap Toggle overflow
在用于移除注解的命令中，要移除的注解后面有一个 -。
2.7. 创建和使用配置映射
以下部分定义配置映射以及如何创建和使用它们。
2.7.1. 了解配置映射
许多应用程序需要使用配置文件、命令行参数和环境变量的某些组合来进行配置。在 OpenShift Container Platform 中，这些配置工件与镜像内容分离，以便使容器化应用程序可以移植。
ConfigMap 对象提供了将容器注入到配置数据的机制，同时保持容器与 OpenShift Container Platform 无关。配置映射可用于存储细粒度信息（如个别属性）或粗粒度信息（如完整配置文件或 JSON blob）。
ConfigMap API 对象包含配置数据的键值对，这些数据可在 Pod 中消耗或用于存储控制器等系统组件的配置数据。例如：
ConfigMap 对象定义
从二进制文件（如镜像）创建配置映射时，您可以使用 binaryData 字段。
可以在 Pod 中以各种方式消耗配置数据。配置映射可用于：
- 在容器中填充环境变量值
- 设置容器中的命令行参数
- 填充卷中的配置文件
用户和系统组件可以在配置映射中存储配置数据。
配置映射与 secret 类似，但设计为能更加便捷地支持与不含敏感信息的字符串配合。
配置映射限制
在 pod 中可以消耗它的内容前，必须创建配置映射。
可以编写控制器来容许缺少的配置数据。根据具体情况使用配置映射来参考各个组件。
ConfigMap 对象驻留在一个项目中。
它们只能被同一项目中的 pod 引用。
Kubelet 只支持为它从 API 服务器获取的 pod 使用配置映射。
这包括使用 CLI 创建或间接从复制控制器创建的 pod。它不包括通过 OpenShift Container Platform 节点的 --manifest-url 标记、--config 标记，或通过 REST API 创建的 pod，因为这些不是创建 pod 的通用方法。
2.7.2. 在 OpenShift Container Platform Web 控制台中创建配置映射
您可以在 OpenShift Container Platform Web 控制台中创建配置映射。
流程
以集群管理员身份创建配置映射：
-
在 Administrator 视角中，选择
Workloads→Config Maps。 - 在该页面右上方选择 Create Config Map。
- 输入配置映射的内容。
- 选择 Create。
-
在 Administrator 视角中，选择
以开发者身份创建配置映射：
-
在 Developer 视角中，选择
Config Maps。 - 在该页面右上方选择 Create Config Map。
- 输入配置映射的内容。
- 选择 Create。
-
在 Developer 视角中，选择
2.7.3. 使用 CLI 创建配置映射
您可以使用以下命令从目录、特定文件或文字值创建配置映射。
流程
创建配置映射：
oc create configmap <configmap_name> [options]
$ oc create configmap <configmap_name> [options]Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.7.3.1. 从目录创建配置映射
您可以从目录中创建配置映射。这个方法允许您使用目录中的多个文件来创建配置映射。
流程
以下示例流程概述了如何从目录中创建配置映射。
从包含一些已包含您要填充配置映射的数据的文件目录开始：
ls example-files
$ ls example-filesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
game.properties ui.properties
game.properties ui.propertiesCopy to Clipboard Copied! Toggle word wrap Toggle overflow cat example-files/game.properties
$ cat example-files/game.propertiesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow cat example-files/ui.properties
$ cat example-files/ui.propertiesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
color.good=purple color.bad=yellow allow.textmode=true how.nice.to.look=fairlyNice
color.good=purple color.bad=yellow allow.textmode=true how.nice.to.look=fairlyNiceCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输入以下命令，创建包含此目录中每个文件内容的配置映射：
oc create configmap game-config \ --from-file=example-files/$ oc create configmap game-config \ --from-file=example-files/Copy to Clipboard Copied! Toggle word wrap Toggle overflow 当
--from-file选项指向某个目录时，该目录中的每个文件都直接用于在配置映射中填充密钥，其中键的名称是文件名，键的值是文件的内容。例如，上一命令会创建以下配置映射：
oc describe configmaps game-config
$ oc describe configmaps game-configCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 您可以看到，映射中的两个键都是从命令中指定的目录中的文件名创建的。因为这些键的内容可能较大，所以
oc describe的输出只会显示键的名称及其大小。使用带有
-o选项的oc get命令以查看键的值：oc get configmaps game-config -o yaml
$ oc get configmaps game-config -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.7.3.2. 从文件创建配置映射
您可以从文件创建配置映射。
流程
以下示例流程概述了如何从文件创建配置映射。
如果从文件创建一个配置映射，您可以在不会破坏非 UTF8 数据的项中包含非 UTF8 的数据。OpenShift Container Platform 检测到二进制文件，并将该文件编码为 MIME。在服务器上，MIME 有效负载被解码并存储而不会损坏数据。
您可以多次将 --from-file 选项传递给 CLI。以下示例生成与从目录创建示例相同的结果。
通过指定特定文件来创建配置映射：
oc create configmap game-config-2 \ --from-file=example-files/game.properties \ --from-file=example-files/ui.properties$ oc create configmap game-config-2 \ --from-file=example-files/game.properties \ --from-file=example-files/ui.propertiesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 验证结果：
oc get configmaps game-config-2 -o yaml
$ oc get configmaps game-config-2 -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
您可以为从文件中导入的内容在配置映射中指定要设置的密钥。这可以通过向 --from-file 选项传递 key=value 表达式来设置。例如：
通过指定键值对来创建配置映射：
oc create configmap game-config-3 \ --from-file=game-special-key=example-files/game.properties$ oc create configmap game-config-3 \ --from-file=game-special-key=example-files/game.propertiesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 验证结果：
oc get configmaps game-config-3 -o yaml
$ oc get configmaps game-config-3 -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 这是您在前面的步骤中设置的密钥。
2.7.3.3. 从字面值创建配置映射
您可以为配置映射提供字面值。
流程
--from-literal 选项使用 key=value 语法，允许直接在命令行中提供字面值。
通过指定字面值来创建配置映射：
oc create configmap special-config \ --from-literal=special.how=very \ --from-literal=special.type=charm$ oc create configmap special-config \ --from-literal=special.how=very \ --from-literal=special.type=charmCopy to Clipboard Copied! Toggle word wrap Toggle overflow 验证结果：
oc get configmaps special-config -o yaml
$ oc get configmaps special-config -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.7.4. 使用案例： 在 pod 中使用配置映射
以下小节描述了在 pod 中消耗 ConfigMap 对象时的一些用例。
2.7.4.1. 使用配置映射在容器中填充环境变量
配置映射可用于在容器中填充各个环境变量或从构成有效环境变量名称的所有键填充容器中的环境变量。
例如，请考虑以下配置映射：
有两个环境变量的 ConfigMap
带有一个环境变量的ConfigMap
流程
您可以使用
configMapKeyRef部分在 pod 中使用此ConfigMap的键。配置为注入特定环境变量的
Pod规格示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 当此 Pod 运行时，Pod 日志包括以下输出：
SPECIAL_LEVEL_KEY=very log_level=INFO
SPECIAL_LEVEL_KEY=very log_level=INFOCopy to Clipboard Copied! Toggle word wrap Toggle overflow
示例输出中没有列出 SPECIAL_TYPE_KEY=charm，因为设置了 optional: true。
2.7.4.2. 使用配置映射为容器命令设置命令行参数
配置映射也可用于设置容器中的命令或参数的值。这可以通过 Kubernetes 替换语法 $(VAR_NAME) 来实现。请考虑以下配置映射：
流程
要将值注入容器中的命令中，您必须使用您要用作环境变量的键，如环境变量用例中的 ConfigMap 中一样。然后，您可以使用
$(VAR_NAME)语法在容器的命令中引用它们。配置为注入特定环境变量的
Pod规格示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 使用您要用作环境变量的键将值注入到容器中的命令中。
当此 pod 运行时，test-container 容器中运行的 echo 命令的输出如下：
very charm
very charmCopy to Clipboard Copied! Toggle word wrap Toggle overflow
2.7.4.3. 使用配置映射将内容注入卷
您可以使用配置映射将内容注入卷。
ConfigMap 自定义资源(CR)示例
流程
您可以使用配置映射将内容注入卷中有两个不同的选项。
使用配置映射将内容注入卷的最基本方法是在卷中填充键为文件名称的文件，文件的内容是键值：
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 包含密钥的文件。
当这个 pod 运行时，cat 命令的输出将是：
very
veryCopy to Clipboard Copied! Toggle word wrap Toggle overflow 您还可以控制投射配置映射键的卷中的路径：
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 配置映射键的路径。
当这个 pod 运行时，cat 命令的输出将是：
very
veryCopy to Clipboard Copied! Toggle word wrap Toggle overflow
2.8. 使用设备插件来利用 pod 访问外部资源
借助设备插件，您无需编写自定义代码，就能在 OpenShift Container Platform pod 中使用特定的设备类型，如 GPU、InfiniBand 或其他需要供应商专用初始化和设置的类似计算资源。
2.8.1. 了解设备插件
设备插件提供一致并可移植的解决方案，以便跨集群消耗硬件设备。设备插件通过一种扩展机制提供对这些设备的支持，从而将设备提供给容器，提供设备健康检查，并且安全地共享设备。
OpenShift Container Platform 支持设备插件 API，但设备插件容器则由各家供应商提供支持。
设备插件是在节点（kubelet 的外部）上运行的 gRPC 服务，负责管理特定的硬件资源。任何设备插件都必须支持以下远程过程调用 (RPC)：
设备插件示例
对于简单设备插件参考实现，设备管理器代码中提供了一个存根设备插件：vendor/k8s.io/kubernetes/pkg/kubelet/cm/deviceplugin/device_plugin_stub.go。
2.8.1.1. 设备插件部署方法
- 守护进程集是设备插件部署的推荐方法。
- 在启动时，设备插件会尝试在节点上的 /var/lib/kubelet/device-plugin/ 创建一个 UNIX 域套接字，以服务来自于设备管理器的 RPC。
- 由于设备插件必须管理硬件资源、主机文件系统的访问权以及套接字创建，它们必须在一个特权安全上下文中运行。
- 各种设备插件实现中提供了有关部署步骤的更多细节。
2.8.2. 了解设备管理器
设备管理器提供了一种机制，可借助称为“设备插件”的插件公告专用节点硬件资源。
您可以公告专用的硬件，而不必修改任何上游代码。
OpenShift Container Platform 支持设备插件 API，但设备插件容器则由各家供应商提供支持。
设备管理器将设备公告为外部资源。用户 pod 可以利用相同的限制/请求机制来使用设备管理器公告的设备，这一机制也用于请求任何其他扩展资源。
在启动时，设备插件通过在 /var/lib/kubelet/device-plugins/kubelet.sock 上调用 Register 将自身注册到设备管理器，再启动位于 /var/lib/kubelet/device-plugins/<plugin>.sock 的 gRPC 服务来服务设备管理器请求。
在处理新的注册请求时，设备管理器会在设备插件服务中调用 ListAndWatch 远程过程调用 (RPC)。作为响应，设备管理器通过 gRPC 流从插件中获取设备对象的列表。设备管理器对流进行持续监控，以确认插件有没有新的更新。在插件一端，插件也会使流保持开放；只要任何设备的状态有所改变，就会通过相同的流传输连接将新设备列表发送到设备管理器。
在处理新的 pod 准入请求时，Kubelet 将请求的扩展资源传递给设备管理器以进行设备分配。设备管理器在其数据库中检查，以验证是否存在对应的插件。如果插件存在并且有可分配的设备及本地缓存，则在该特定设备插件上调用 Allocate RPC。
此外，设备插件也可以执行其他几个特定于设备的操作，如驱动程序安装、设备初始化和设备重置。这些功能视具体实现而异。
2.8.3. 启用设备管理器
启用设备管理器来实现设备插件，在不更改上游代码的前提下公告专用硬件。
设备管理器提供了一种机制，可借助称为“设备插件”的插件公告专用节点硬件资源。
为您要配置的节点类型获取与静态
MachineConfigPoolCRD 关联的标签。执行以下步骤之一：查看机器配置：
oc describe machineconfig <name>
# oc describe machineconfig <name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例如：
oc describe machineconfig 00-worker
# oc describe machineconfig 00-workerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Name: 00-worker Namespace: Labels: machineconfiguration.openshift.io/role=worker
Name: 00-worker Namespace: Labels: machineconfiguration.openshift.io/role=worker1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 设备管理器所需标签。
流程
为配置更改创建自定义资源 (CR)。
设备管理器 CR 配置示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 创建设备管理器：
oc create -f devicemgr.yaml
$ oc create -f devicemgr.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
kubeletconfig.machineconfiguration.openshift.io/devicemgr created
kubeletconfig.machineconfiguration.openshift.io/devicemgr createdCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 通过确认节点上已创建了 /var/lib/kubelet/device-plugins/kubelet.sock，确保已启用了设备管理器。这是设备管理器 gRPC 服务器在其上侦听新插件注册的 UNIX 域套接字。只有启用了设备管理器，才会在 Kubelet 启动时创建此 sock 文件。
2.9. 在 pod 调度决策中纳入 pod 优先级
您可以在集群中启用 pod 优先级与抢占功能。pod 优先级指明 pod 相对于其他 pod 的重要程度，并根据这个优先级对 pod 进行队列处理。pod 抢占允许集群驱除或抢占较低优先级 pod，以便在合适的节点 pod 上没有可用空间时，可以调度优先级较高的 pod，并影响节点上资源不足驱除顺序。
要使用优先级和抢占功能，您需要创建优先级类来定义 pod 的相对权重。然后，在 pod 规格中引用优先级类，以应用这个权重来进行调度。
2.9.1. 了解 pod 优先级
当您使用 pod 优先级与抢占功能时，调度程序会根据优先级来调度待处理 pod，而待处理 pod 会放在调度队列中优先级较低的其他待处理 pod 的前面。因此，如果达到调度要求，较高优先级的 pod 可能比低优先级的 pod 更早调度。如果 pod 无法调度，调度程序会继续调度其他较低优先级 pod。
2.9.1.1. Pod 优先级类
您可以为 pod 分配一个优先级类，它是一种非命名空间的对象，用于定义从名称到优先级整数值的映射。数值越大，优先级越高。
优先级类对象可以取小于或等于 1000000000（十亿）的 32 位整数值。对于不应被抢占或驱除的关键 pod，可保留大于十亿的数值。默认情况下，OpenShift Container Platform 有两个保留优先级类，用于需要保证调度的关键系统 pod。
oc get priorityclasses
$ oc get priorityclasses输出示例
NAME VALUE GLOBAL-DEFAULT AGE cluster-logging 1000000 false 29s system-cluster-critical 2000000000 false 72m system-node-critical 2000001000 false 72m
NAME VALUE GLOBAL-DEFAULT AGE
cluster-logging 1000000 false 29s
system-cluster-critical 2000000000 false 72m
system-node-critical 2000001000 false 72msystem-node-critical - 此优先级类的值为 2000001000，用于所有不得从节点上驱除的 pod。具有此优先级类的 pod 示例有
sdn-ovs和sdn等。许多关键组件默认包括system-node-critical优先级类，例如：- master-api
- master-controller
- master-etcd
- sdn
- sdn-ovs
- sync
system-cluster-critical - 此优先级类的值是 2000000000（二十亿），用于对集群而言很重要的 pod。在某些情况下，具有此优先级类的 Pod 可以从节点中驱除。例如，配置了
system-node-critical优先级类的 pod 可以拥有优先权。不过，此优先级类确实能够保证调度。具有此优先级类的 pod 示例有 fluentd 以及 descheduler 这样的附加组件等。许多关键组件默认包括system-cluster-critical优先级类，例如：- fluentd
- metrics-server
- descheduler
- cluster-logging - 此优先级类供 Fluentd 用于确保 Fluentd pod 优先于其他应用调度到节点上。
2.9.1.2. Pod 优先级名称
拥有一个或多个优先级类后，您可以创建 pod，并在 Pod 规格中指定优先级类名称。优先准入控制器使用优先级类名称字段来填充优先级的整数值。如果没有找到给定名称的优先级类，pod 将被拒绝。
2.9.2. 了解 pod 抢占
当开发人员创建 pod 时，pod 会排入某一队列。如果开发人员为 pod 配置了 pod 优先级或抢占，调度程序会从队列中选取 pod，并尝试将 pod 调度到某个节点上。如果调度程序无法在满足 pod 的所有指定要求的适当节点上找到空间，则会为待处理 pod 触发抢占逻辑。
当调度程序在节点上抢占一个或多个 pod 时，较高优先级 Pod spec 的 nominatedNodeName 字段 将设为该节点的名称，nodename 字段也是如此。调度程序使用 nominatedNodeName 字段来跟踪为 pod 保留的资源，同时也向用户提供与集群中抢占相关的信息。
在调度程序抢占了某一较低优先级 pod 后，调度程序会尊重该 pod 的安全终止期限。如果在调度程序等待较低优先级 pod 终止过程中另一节点变为可用，调度程序会将较高优先级 pod 调度到该节点上。因此，Pod spec 的 nominatedNodeName 字段和 nodeName 字段可能会有所不同。
另外，如果调度程序在某一节点上抢占 pod 并正在等待终止，这时又有优先级比待处理 pod 高的 pod 需要调度，那么调度程序可以改为调度这个优先级更高的 pod。在这种情况下，调度程序会清除待处理 pod 的 nominatedNodeName，使该 pod 有资格调度到其他节点上。
抢占不一定从节点中移除所有较低优先级 pod。调度程序可以通过移除一部分较低优先级 pod 调度待处理 pod。
只有待处理 pod 能够调度到节点时，调度程序才会对这个节点考虑 pod 抢占。
2.9.2.1. 非抢占优先级类（技术预览）
抢占策略设置为 Never 的 Pod 会放置在较低优先级 pod 的调度队列中，但无法抢占其他 pod。等待调度的非抢占 pod 会保留在调度队列中，直到资源可用且可以调度。非抢占 pod 与其他 pod 一样，受调度程序后退避的影响。这意味着，如果调度程序尝试调度这些 pod，它们会以较低频率重试，允许在调度前调度其他优先级较低的 pod。
非抢占 pod 仍可被其他高优先级 pod 抢占。
2.9.2.2. Pod 抢占和其他调度程序设置
如果启用 pod 优先级与抢占功能，请考虑其他的调度程序设置：
- pod 优先级和 pod 中断预算
- pod 中断预算指定某一时间必须保持在线的副本的最小数量或百分比。如果您指定了 pod 中断预算，OpenShift Container Platform 会在抢占 pod 时尽力尊重这些预算。调度程序会尝试在不违反 pod 中断预算的前提下抢占 pod。如果找不到这样的 pod，则可能会无视 pod 中断预算要求而抢占较低优先级 pod。
- pod 优先级和 pod 关联性
- pod 关联性要求将新 pod 调度到与具有同样标签的其他 pod 相同的节点上。
如果待处理 pod 与节点上的一个或多个低优先级 pod 具有 pod 间关联性，调度程序就不能在不违反关联要求的前提下抢占较低优先级 pod。这时，调度程序会寻找其他节点来调度待处理 pod。但是，不能保证调度程序能够找到合适的节点，因此可能无法调度待处理 pod。
要防止这种情况，请仔细配置优先级相同的 pod 的 pod 关联性。
2.9.2.3. 安全终止被抢占的 pod
在抢占 pod 时，调度程序会等待 pod 安全终止期限到期，使 pod 能够完成工作并退出。如果 pod 在到期后没有退出，调度程序会终止该 pod。此安全终止期限会在调度程序抢占该 pod 的时间和待处理 pod 调度到节点的时间之间造成一个时间差。
要尽量缩短这个时间差，可以为较低优先级 pod 配置较短的安全终止期限。
2.9.3. 配置优先级和抢占
您可以通过创建优先级类对象并使用 Pod spec 中的 priorityClassName 将 pod 与优先级关联，以应用 pod 优先级与抢占功能。
优先级类对象示例
- 1
- 优先级类对象的名称。
- 2
- 对象的优先级值。
- 3
- 指定此优先级类是否被抢占或未抢占的可选字段。抢占策略默认为
PreemptLowerPriority，它允许该优先级类中的 pod 抢占较低优先级 pod。如果抢占策略设置为Never，则该优先级类中的 pod 就不会被抢占。 - 4
- 此可选字段指定是否应该将这个优先级类用于 pod，而不指定优先级类名。此字段默认为
false。集群中只能存在一个globalDefault设为true的优先级类。如果没有globalDefault:true的优先级类，则无优先级类名称的 pod 的优先级为零。添加具有globalDefault:true的优先级类只会影响在添加优先级类后创建的 pod，不会更改现有 pod 的优先级。 - 5
- 此可选任意文本字符串用于描述开发人员应对哪些 pod 使用这个优先级类。
流程
配置集群以使用优先级与抢占功能：
创建一个或多个优先级类：
- 指定优先级的名称和值。
-
（可选）指定优先级类的
globalDefault字段和描述。
创建
Podspec 或编辑现有的 pod 以包含优先级类的名称，如下所示：带有优先级类名称的
Pod规格示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 指定要用于此 pod 的优先级类。
创建 pod：
oc create -f <file-name>.yaml
$ oc create -f <file-name>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 您可以将优先级名称直接添加到 pod 配置或 pod 模板中。
2.10. 使用节点选择器将 pod 放置到特定节点
节点选择器指定一个键值对映射。使用节点中的自定义标签和 pod 中指定的选择器来定义规则。
若要使 pod 有资格在某一节点上运行，pod 必须具有指定为该节点上标签的键值对。
如果您在同一 pod 配置中同时使用节点关联性和节点选择器，请查看下方的重要注意事项。
2.10.1. 使用节点选择器控制 pod 放置
您可以使用节点上的 pod 和标签上的节点选择器来控制 pod 的调度位置。使用节点选择器时，OpenShift Container Platform 会将 pod 调度到包含匹配标签的节点。
您可为节点、机器集或机器配置添加标签。将标签添加到机器集可确保节点或机器停机时，新节点具有标签。如果节点或机器停机，添加到节点或机器配置的标签不会保留。
要将节点选择器添加到现有 pod 中，将节点选择器添加到该 pod 的控制对象中，如 ReplicaSet 对象、DaemonSet 对象、StatefulSet 对象、Deployment 对象或 DeploymentConfig 对象。任何属于该控制对象的现有 pod 都会在具有匹配标签的节点上重新创建。如果要创建新 pod，可以将节点选择器直接添加到 Pod 规格中。
您不能直接将节点选择器添加到现有调度的 pod 中。
先决条件
要将节点选择器添加到现有 pod 中，请确定该 pod 的控制对象。例如, router-default-66d5cf9464-m2g75 pod 由 router-default-66d5cf9464 副本集控制：
Web 控制台在 pod YAML 的 ownerReferences 下列出控制对象：
流程
通过使用机器集或直接编辑节点，为节点添加标签：
在创建节点时，使用
MachineSet对象向由机器集管理的节点添加标签：运行以下命令，将标签添加到
MachineSet对象中：oc patch MachineSet <name> --type='json' -p='[{"op":"add","path":"/spec/template/spec/metadata/labels", "value":{"<key>"="<value>","<key>"="<value>"}}]' -n openshift-machine-api$ oc patch MachineSet <name> --type='json' -p='[{"op":"add","path":"/spec/template/spec/metadata/labels", "value":{"<key>"="<value>","<key>"="<value>"}}]' -n openshift-machine-apiCopy to Clipboard Copied! Toggle word wrap Toggle overflow 例如：
oc patch MachineSet abc612-msrtw-worker-us-east-1c --type='json' -p='[{"op":"add","path":"/spec/template/spec/metadata/labels", "value":{"type":"user-node","region":"east"}}]' -n openshift-machine-api$ oc patch MachineSet abc612-msrtw-worker-us-east-1c --type='json' -p='[{"op":"add","path":"/spec/template/spec/metadata/labels", "value":{"type":"user-node","region":"east"}}]' -n openshift-machine-apiCopy to Clipboard Copied! Toggle word wrap Toggle overflow 使用
oc edit命令验证标签是否已添加到MachineSet对象中：例如：
oc edit MachineSet abc612-msrtw-worker-us-east-1c -n openshift-machine-api
$ oc edit MachineSet abc612-msrtw-worker-us-east-1c -n openshift-machine-apiCopy to Clipboard Copied! Toggle word wrap Toggle overflow MachineSet对象示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow
直接向节点添加标签：
为节点编辑
Node对象：oc label nodes <name> <key>=<value>
$ oc label nodes <name> <key>=<value>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例如，若要为以下节点添加标签：
oc label nodes ip-10-0-142-25.ec2.internal type=user-node region=east
$ oc label nodes ip-10-0-142-25.ec2.internal type=user-node region=eastCopy to Clipboard Copied! Toggle word wrap Toggle overflow 验证标签是否已添加到节点：
oc get nodes -l type=user-node,region=east
$ oc get nodes -l type=user-node,region=eastCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME STATUS ROLES AGE VERSION ip-10-0-142-25.ec2.internal Ready worker 17m v1.18.3+002a51f
NAME STATUS ROLES AGE VERSION ip-10-0-142-25.ec2.internal Ready worker 17m v1.18.3+002a51fCopy to Clipboard Copied! Toggle word wrap Toggle overflow
将匹配的节点选择器添加到 pod：
要将节点选择器添加到现有和未来的 pod，请向 pod 的控制对象添加节点选择器：
带有标签的
ReplicaSet对象示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 添加节点选择器。
要将节点选择器添加到一个特定的新 pod，直接将选择器添加到
Pod对象中：使用节点选择器的
Pod对象示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注意您不能直接将节点选择器添加到现有调度的 pod 中。
第 3 章 控制节点上的 pod 放置（调度）
3.1. 使用调度程序控制 pod 放置
Pod 调度是一个内部过程，决定新 pod 如何放置到集群内的节点上。
调度程度代码具有明确隔离，会监测创建的新 pod 并确定最适合托管它们的节点。然后，它会利用主 API 为 pod 创建 pod 至节点的绑定。
- 默认 pod 调度
- OpenShift Container Platform 附带一个默认调度程序，能满足大多数用户的需求。默认调度程序使用内置和自定义工具来决定最适合 pod 的调度程序。
- 高级 pod 调度
如果您想要更多地控制新 pod 的放置位置，可以利用 OpenShift Container Platform 高级调度功能来配置 pod，从而使 pod 能够根据要求或偏好在特定的节点上运行，或者与特定的 pod 一起运行。
3.1.1. 调度程序用例
在 OpenShift Container Platform 中调度的一个重要用例是支持灵活的关联性和反关联性策略。
3.1.1.1. 基础架构拓扑级别
管理员可以通过在节点上指定标签，为基础架构（节点）定义多个拓扑级别。例如，region=r1、zone=z1、rack=s1。
这些标签名称没有特别的含义，管理员可以自由为其基础架构级别命名，比如城市/楼宇/房间。另外，管理员可以为其基础架构拓扑定义任意数量的级别，通常三个级别比较适当（例如：regions → zone → racks）。管理员可以在各个级别上以任何组合指定关联性和反关联性规则。
3.1.1.2. 关联性
管理员应能够配置调度程序，在任何一个甚至多个拓扑级别上指定关联性。特定级别上的关联性指示所有属于同一服务的 pod 调度到属于同一级别的节点。这会让管理员确保对等 pod 在地理上不会过于分散，以此处理应用程序对延迟的要求。如果同一关联性组中没有节点可用于托管 pod，则不调度该 pod。
如果您需要更好地控制 pod 的调度位置，请参阅使用节点关联性规则控制节点上的 pod 放置，以及使用关联性和反关联性规则相对于其他 pod 放置 pod。
管理员可以利用这些高级调度功能，来指定 pod 可以调度到哪些节点，并且相对于其他 pod 来强制或拒绝调度。
3.1.1.3. 反关联性
管理员应能够配置调度程序，在任何一个甚至多个拓扑级别上指定反关联性。特定级别上的反关联性（或分散）指示属于同一服务的所有 pod 分散到属于该级别的不同节点上。这样可确保应用程序合理分布，以实现高可用性目的。调度程序尝试在所有适用的节点之间尽可能均匀地平衡服务 pod。
如果您需要更好地控制 pod 的调度位置，请参阅使用节点关联性规则控制节点上的 pod 放置，以及使用关联性和反关联性规则相对于其他 pod 放置 pod。
管理员可以利用这些高级调度功能，来指定 pod 可以调度到哪些节点，并且相对于其他 pod 来强制或拒绝调度。
3.2. 配置默认调度程序以控制 pod 放置
OpenShift Container Platform 的默认 pod 调度程序负责确定在集群的节点中放置新的 pod。它从 pod 读取数据，并尝试根据配置的策略寻找最适合的节点。它完全独立存在，作为单机或可插拔的解决方案。它不会修改 pod，只是为 pod 创建将 pod 与特定节点衔接起来的绑定。
配置调度程序策略已弃用，计划在以后的发行版本中删除。如需有关技术预览的更多信息，请参阅使用调度程序配置集调度 pod。
调度程序的策略由一组 predicates 和 priorities 来定义。如需 predicates 和 priorities 的列表，请参阅修改调度程序策略。
默认调度程序对象示例
3.2.1. 了解默认调度
现有的通用调度程序是平台默认提供的调度程序引擎，它可通过三步操作来选择托管 pod 的节点：
- 过滤节点
- 根据指定的约束或要求过滤可用的节点。这可以通过名为predicates的过滤函数列表筛选每个节点来完成。
- 排列过滤后节点列表的优先顺序
- 实现方式是让每个节点通过一系列优先级函数，以为其分配从 0 到 10 的一个分数。0 代表不适合的节点，10 则代表最适合托管该 pod。调度程序配置还可以为每个优先级函数使用简单的权重（正数值）。每个优先级函数提供的节点分数乘以权重（大多数优先级的默认权重为 1），然后将每个节点从所有优先级获得的分数相加。管理员可以使用这个权重属性，为一些优先级赋予更高的重要性。
- 选择最适合的节点
- 节点按照分数排序，系统选择分数最高的节点来托管该 pod。如果多个节点的分数相同，则随机选择其中一个。
3.2.1.1. 了解调度程序策略
调度程序的策略由一组 predicates 和 priorities 来定义。
调度程序配置文件是一个 JSON 文件，必须命名为 policy.cfg，用于指定调度程序将要考量的 predicates 和 priorities。
如果没有调度程序策略文件，则使用默认的调度程序行为。
调度程序配置文件中定义的 predicates 和 priorities 会完全覆盖默认的调度程序策略。如果需要任何默认的 predicates 和 priorities，必须在策略配置中明确指定对应的函数。
调度程序配置映射示例
- 1
GeneralPredicatespredicate 代表PodFitsResources、HostName、PodFitsHostPorts和MatchNodeSelectorpredicate。由于无法多次配置同一 predicate，所以GeneralPredicatespredicate 不能与四个代表的 predicate 之一一起使用。
3.2.2. 创建调度程序策略文件
您可以通过使用所需的 predicates 和 priorities 创建 JSON 文件来更改默认调度行为。然后，您可以通过 JSON 文件生成配置映射，并将 cluster 调度程序对象指定为使用该配置映射。
流程
配置调度程序策略：
使用所需的 predicates 和 priorities，创建一个名为
policy.cfg的 JSON 文件。调度程序 JSON 文件示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 根据调度程序 JSON 文件创建配置映射：
oc create configmap -n openshift-config --from-file=policy.cfg <configmap-name>
$ oc create configmap -n openshift-config --from-file=policy.cfg <configmap-name>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 输入配置映射的名称。
例如：
oc create configmap -n openshift-config --from-file=policy.cfg scheduler-policy
$ oc create configmap -n openshift-config --from-file=policy.cfg scheduler-policyCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
configmap/scheduler-policy created
configmap/scheduler-policy createdCopy to Clipboard Copied! Toggle word wrap Toggle overflow 编辑调度程序 Operator 自定义资源以添加配置映射：
oc patch Scheduler cluster --type='merge' -p '{"spec":{"policy":{"name":"<configmap-name>"}}}' --type=merge$ oc patch Scheduler cluster --type='merge' -p '{"spec":{"policy":{"name":"<configmap-name>"}}}' --type=merge1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 指定配置映射的名称。
例如：
oc patch Scheduler cluster --type='merge' -p '{"spec":{"policy":{"name":"scheduler-policy"}}}' --type=merge$ oc patch Scheduler cluster --type='merge' -p '{"spec":{"policy":{"name":"scheduler-policy"}}}' --type=mergeCopy to Clipboard Copied! Toggle word wrap Toggle overflow 在修改了
Scheduler配置资源后，等待openshift-kube-apiserverpod 重新部署。这可能需要几分钟。只有重新部署 pod 后，新的调度程序才会生效。通过查看
openshift-kube-scheduler命名空间中调度程序 pod 的日志，来验证已配置调度程序策略。以下命令检查由调度程序注册的 predicates 和 priorities：oc logs <scheduler-pod> | grep predicates
$ oc logs <scheduler-pod> | grep predicatesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 例如：
oc logs openshift-kube-scheduler-ip-10-0-141-29.ec2.internal | grep predicates
$ oc logs openshift-kube-scheduler-ip-10-0-141-29.ec2.internal | grep predicatesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Creating scheduler with fit predicates 'map[MaxGCEPDVolumeCount:{} MaxAzureDiskVolumeCount:{} CheckNodeUnschedulable:{} NoDiskConflict:{} NoVolumeZoneConflict:{} GeneralPredicates:{} MaxCSIVolumeCountPred:{} CheckVolumeBinding:{} MaxEBSVolumeCount:{} MatchInterPodAffinity:{} PodToleratesNodeTaints:{}]' and priority functions 'map[InterPodAffinityPriority:{} LeastRequestedPriority:{} ServiceSpreadingPriority:{} ImageLocalityPriority:{} SelectorSpreadPriority:{} EqualPriority:{} BalancedResourceAllocation:{} NodePreferAvoidPodsPriority:{} NodeAffinityPriority:{} TaintTolerationPriority:{}]'Creating scheduler with fit predicates 'map[MaxGCEPDVolumeCount:{} MaxAzureDiskVolumeCount:{} CheckNodeUnschedulable:{} NoDiskConflict:{} NoVolumeZoneConflict:{} GeneralPredicates:{} MaxCSIVolumeCountPred:{} CheckVolumeBinding:{} MaxEBSVolumeCount:{} MatchInterPodAffinity:{} PodToleratesNodeTaints:{}]' and priority functions 'map[InterPodAffinityPriority:{} LeastRequestedPriority:{} ServiceSpreadingPriority:{} ImageLocalityPriority:{} SelectorSpreadPriority:{} EqualPriority:{} BalancedResourceAllocation:{} NodePreferAvoidPodsPriority:{} NodeAffinityPriority:{} TaintTolerationPriority:{}]'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.2.3. 修改调度程序策略
您可以通过在 openshift-config 项目中创建或编辑调度程序策略配置映射来更改调度行为。在配置映射中添加和移除 predicates 和 priorities，以创建 调度程序策略。
流程
要修改当前的自定义调度，请使用以下方法之一：
编辑调度程序策略配置映射：
oc edit configmap <configmap-name> -n openshift-config
$ oc edit configmap <configmap-name> -n openshift-configCopy to Clipboard Copied! Toggle word wrap Toggle overflow 例如：
oc edit configmap scheduler-policy -n openshift-config
$ oc edit configmap scheduler-policy -n openshift-configCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 调度程序需要几分钟时间来使用更新后的策略重启 pod。
更改所用的 predicates 和 priorities：
删除调度程序策略配置映射：
oc delete configmap -n openshift-config <name>
$ oc delete configmap -n openshift-config <name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例如：
oc delete configmap -n openshift-config scheduler-policy
$ oc delete configmap -n openshift-config scheduler-policyCopy to Clipboard Copied! Toggle word wrap Toggle overflow 根据需要，编辑
policy.cfg文件来添加和移除 policies 和 predicates。例如：
vi policy.cfg
$ vi policy.cfgCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 根据调度程序 JSON 文件重新创建调度程序策略配置映射：
oc create configmap -n openshift-config --from-file=policy.cfg <configmap-name>
$ oc create configmap -n openshift-config --from-file=policy.cfg <configmap-name>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 输入配置映射的名称。
例如：
oc create configmap -n openshift-config --from-file=policy.cfg scheduler-policy
$ oc create configmap -n openshift-config --from-file=policy.cfg scheduler-policyCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
configmap/scheduler-policy created
configmap/scheduler-policy createdCopy to Clipboard Copied! Toggle word wrap Toggle overflow
3.2.3.1. 了解调度程序 predicates
predicates 是用于过滤掉不合格节点的规则。
OpenShift Container Platform 中默认提供一些 predicates。其中的一些 predicates 可以通过提供特定参数来自定义。可以组合多个 predicates 来提供更多节点过滤。
3.2.3.1.1. 静态 predicates
此类 predicates 不接受任何来自于用户的配置参数或输入。它们通过其确切的名称在调度程序配置中指定。
3.2.3.1.1.1. 默认 predicates
默认的调度程序策略包括以下 predicates：
NoVolumeZoneConflict predicate 检查区中是否有 pod 请求的卷。
{"name" : "NoVolumeZoneConflict"}
{"name" : "NoVolumeZoneConflict"}
MaxEBSVolumeCount predicate 检查可附加到 AWS 实例的最大卷数量。
{"name" : "MaxEBSVolumeCount"}
{"name" : "MaxEBSVolumeCount"}
MaxAzureDiskVolumeCount predicate 会检查 Azure 磁盘卷的最大数量。
{"name" : "MaxAzureDiskVolumeCount"}
{"name" : "MaxAzureDiskVolumeCount"}
PodToleratesNodeTaints predicate 检查 pod 是否可以容忍节点污点。
{"name" : "PodToleratesNodeTaints"}
{"name" : "PodToleratesNodeTaints"}
CheckNodeUnschedulable predicate 会检查 pod 是否可以调度到具有 Unschedulable 规格的节点。
{"name" : "CheckNodeUnschedulable"}
{"name" : "CheckNodeUnschedulable"}
CheckVolumeBinding predicate 根据卷（它请求的卷）评估 pod 是否可以适合绑定和未绑定 PVC。
- 对于绑定的 PVC， predicate 会检查给定节点是否满足对应 PV 的节点关联性。
- 对于未绑定 PVC，该 predicate 会搜索可满足 PVC 要求且给定节点满足 PV 节点关联性的可用 PV。
如果所有绑定 PVC 都有与节点兼容的 PV，且所有未绑定 PVC 都可与可用并兼容节点的 PV 匹配，该 predicate 会返回 true。
{"name" : "CheckVolumeBinding"}
{"name" : "CheckVolumeBinding"}
NoDiskConflict predicate 检查 pod 请求的卷是否可用。
{"name" : "NoDiskConflict"}
{"name" : "NoDiskConflict"}
MaxGCEPDVolumeCount predicate 检查 Google Compute Engine（GCE）持久磁盘（PD）的最大数量。
{"name" : "MaxGCEPDVolumeCount"}
{"name" : "MaxGCEPDVolumeCount"}
MaxCSIVolumeCountPred predicate 决定应将多少 Container Storage Interface(CSI)卷附加到节点，以及该数量是否超过配置的限制。
{"name" : "MaxCSIVolumeCountPred"}
{"name" : "MaxCSIVolumeCountPred"}
MatchInterPodAffinity predicate 检查 pod 关联性/反关联性规则是否允许该 pod。
{"name" : "MatchInterPodAffinity"}
{"name" : "MatchInterPodAffinity"}3.2.3.1.1.2. 其他静态 predicates
OpenShift Container Platform 还支持下列 predicates：
如果启用了 Taint Nodes By Condition 功能，则无法使用 CheckNode-* predicates。Taint Nodes By Condition 功能默认启用。
CheckNodeCondition predicate 检查 pod 是否可以调度到报告 磁盘 不足、网络不可用 或 未就绪 状况的节点。
{"name" : "CheckNodeCondition"}
{"name" : "CheckNodeCondition"}
CheckNodeLabelPresence predicate 检查节点上是否存在所有指定的标签，而不考虑其值。
{"name" : "CheckNodeLabelPresence"}
{"name" : "CheckNodeLabelPresence"}
checkServiceAffinity predicate 检查 ServiceAffinity 标签是否对于节点上调度的 pod 来说是相同的。
{"name" : "checkServiceAffinity"}
{"name" : "checkServiceAffinity"}
PodToleratesNodeNoExecuteTaints predicate 检查 pod 容限是否容忍节点 NoExecute 污点。
{"name" : "PodToleratesNodeNoExecuteTaints"}
{"name" : "PodToleratesNodeNoExecuteTaints"}3.2.3.1.2. 常规 predicates
下列常规 predicates 检查是否通过非关键 predicates 和必要 predicates 的检查。非关键 predicates 是指只有非关键 pod 必须通过检查的 predicates，而必要 predicates 是指所有 pod 都必须通过检查的 predicates。
默认调度程序策略包含常规 predicates。
非关键常规 predicates
PodFitsResources predicate 根据资源可用性（CPU、内存和 GPU 等）决定适合性。节点可以声明其资源容量，然后 pod 可以指定它们所需要的资源。适合性基于请求的资源，而非使用的资源。
{"name" : "PodFitsResources"}
{"name" : "PodFitsResources"}必要常规 predicates
PodFitsHostPorts predicate 决定节点是否有空闲端口用于请求的 pod 端口（不存在端口冲突）。
{"name" : "PodFitsHostPorts"}
{"name" : "PodFitsHostPorts"}
HostName predicate 根据 Host 参数以及与主机名称匹配的字符串来确定适合性。
{"name" : "HostName"}
{"name" : "HostName"}
MatchNodeSelector predicate 根据 pod 中定义的节点选择器（nodeSelector）查询来确定适合性。
{"name" : "MatchNodeSelector"}
{"name" : "MatchNodeSelector"}3.2.3.2. 了解调度程序优先级
优先级是根据偏好对节点进行排序的规则。
可以指定一组自定义优先级来配置调度程序。OpenShift Container Platform 中默认提供一些优先级。也可通过提供某些参数来自定义其他优先级。可将多个优先级合并，并为每个优先级赋予不同的权重来影响优先顺序。
3.2.3.2.1. 静态优先级
静态优先级不使用用户提供的配置参数，但权重除外。权重必须指定，且不能为 0 或负数。
这些是在 openshift-config 项目中的调度程序策略配置映射中指定的。
3.2.3.2.1.1. 默认优先级
默认调度程序策略包括以下优先级。每个优先级函数的权重为 1，但 NodePreferAvoidPodsPriority 除外，它的权重是 10000。
NodeAffinityPriority 优先级根据节点关联性调度偏好来排列节点的优先顺序
{"name" : "NodeAffinityPriority", "weight" : 1}
{"name" : "NodeAffinityPriority", "weight" : 1}
TaintTolerationPriority 优先级为 pod 优先选择那些在节点上具有较少 intolerable（不可容忍）污点的节点。不可容忍的污点是具有 PreferNoSchedule 键的污点。
{"name" : "TaintTolerationPriority", "weight" : 1}
{"name" : "TaintTolerationPriority", "weight" : 1}
ImageLocalityPriority 优先级优先选择已请求的 pod 容器镜像的节点。
{"name" : "ImageLocalityPriority", "weight" : 1}
{"name" : "ImageLocalityPriority", "weight" : 1}
SelectorSpreadPriority 优先级查找服务、复制控制器(RC)、复制集(RS)和与 pod 匹配的有状态的设置，然后找到与这些选择器匹配的现有 pod。调度程序优先选择具有较少现有匹配 pod 的节点。然后，它会将 pod 调度到具有与所调度 pod 的选择器匹配的 pod 数量最少的节点上。
{"name" : "SelectorSpreadPriority", "weight" : 1}
{"name" : "SelectorSpreadPriority", "weight" : 1}
InterPodAffinityPriority 计算迭代 weightedPodAffinityTerm 元素，并在节点满足对应的 PodAffinityTerm 时加上权重的总和。总和最高的节点是优先级最高的节点。
{"name" : "InterPodAffinityPriority", "weight" : 1}
{"name" : "InterPodAffinityPriority", "weight" : 1}
LeastRequestedPriority 优先级会优先选择请求资源较少的节点。它计算节点上调度的 pod 所请求的内存和 CPU 百分比，并优先选择可用/剩余容量最高的节点。
{"name" : "LeastRequestedPriority", "weight" : 1}
{"name" : "LeastRequestedPriority", "weight" : 1}
BalancedResourceAllocation 优先级会优先选择资源使用率均衡的节点。它以占容量比形式计算 CPU 和内存已使用量的差值，并基于两个指标相互接近的程度来优先选择节点。这应该始终与 LeastRequestedPriority 一同使用。
{"name" : "BalancedResourceAllocation", "weight" : 1}
{"name" : "BalancedResourceAllocation", "weight" : 1}
NodePreferAvoidPodsPriority 优先级忽略复制控制器以外的控制器拥有的 pod。
{"name" : "NodePreferAvoidPodsPriority", "weight" : 10000}
{"name" : "NodePreferAvoidPodsPriority", "weight" : 10000}3.2.3.2.1.2. 其他静态优先级
OpenShift Container Platform 还支持下列优先级：
如果没有提供优先级配置，则会为所有节点都提供一个权重为 1 优先级。建议您仅在测试环境中使用此优先级。
的 EqualPriority
{"name" : "EqualPriority", "weight" : 1}
{"name" : "EqualPriority", "weight" : 1}
MostRequestedPriority 优先级会优先选择具有最多请求资源的节点。它计算节点上调度的 pod 所请求的内存与 CPU 百分比，并根据请求量对容量的平均占比的最大值来排列优先级。
{"name" : "MostRequestedPriority", "weight" : 1}
{"name" : "MostRequestedPriority", "weight" : 1}
ServiceSpreadingPriority 优先级通过将属于同一服务的 pod 数量最大化到同一台机器来分散 pod。
{"name" : "ServiceSpreadingPriority", "weight" : 1}
{"name" : "ServiceSpreadingPriority", "weight" : 1}3.2.3.2.2. 可配置优先级
您可以在 openshift-config 命名空间中的调度程序策略配置映射中配置这些优先级，以添加可影响优先级工作的标签。
优先级函数的类型由它们所使用的参数来标识。由于它们是可配置的，因此可以组合类型相同（但配置参数不同）的多个优先级，但前提是它们的用户定义名称不同。
有关使用这些优先级的详情，请参考“修改调度程序策略”。
ServiceAntiAffinity 接受一个标签，确保将属于同一服务的 pod 正常地分散到基于标签值的一组节点。它为指定标签值相同的所有节点赋予相同的分数。它将较高的分数给予组内 pod 密度最低的节点。
例如：
在某些情况下，基于自定义标签的 ServiceAntiAffinity 参数不能按预期分散 pod。请参考此红帽解决方案。
labelPreference 参数根据指定的标签赋予优先级。如果节点上存在该标签，则该节点被赋予优先级。如果未指定标签，则为没有标签的节点赋予优先级。如果设置了带 labelPreference 参数的多个优先级，则所有优先级都必须具有相同的权重。
3.2.4. 策略配置示例
如果使用调度程序策略文件进行了指定，则如下配置会指定默认的调度程序配置。
在下方的所有示例配置中，predicates 和 priorities 函数的列表都已截断，仅包含与指定用例相关的内容。在实践中，完整/有意义的调度程序策略应当包含前文所述的大部分（若非全部）默认 predicates 和 priorities。
以下示例定义了三个拓扑级别，即 region（关联性）-> zone（关联性）-> rack（反关联性）：
以下示例定义了三个拓扑级别，即 city (affinity) → building (anti-affinity) → room (anti-affinity)：
以下示例定义了一个策略，以仅使用定义了“region”标签的节点，并且优先选择定义有“zone”标签的节点：
以下示例组合使用静态和可配置的 predicates 和 priorities：
3.3. 使用调度程序配置集调度 pod
您可以将 OpenShift Container Platform 配置为使用调度配置集将 pod 调度到集群内的节点上。
启用调度程序配置集只是一个技术预览功能。技术预览功能不被红帽产品服务等级协议 (SLA) 支持，且可能在功能方面有缺陷。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能，并有机会在开发阶段提供反馈意见。
有关红帽技术预览功能支持范围的详情，请参阅 https://access.redhat.com/support/offerings/techpreview/。
3.3.1. 关于调度程序配置集
您可以指定一个调度程序配置集来控制 pod 如何调度到节点上。
调度程序配置集是配置调度程序策略的替代方法。不要同时设置调度程序策略和调度程序配置集。如果这两个同时设置，调度程序策略将具有优先权。
可用的调度程序配置集如下：
LowNodeUtilization- 此配置集尝试在节点间平均分配 pod，以获得每个节点的资源用量较低。这个配置集提供默认的调度程序行为。
HighNodeUtilization- 此配置集会尝试将尽量多的 pod 放置到尽量少的节点。这样可最小化节点数，并且每个节点的资源使用率很高。
NoScoring- 这是一个低延迟配置集，通过禁用所有分数（score）插件来实现最快的调度周期。这可能会为更快的调度决策提供更好的要求。
3.3.2. 配置调度程序配置集
您可以将调度程序配置为使用调度程序配置集。
不要同时设置调度程序策略和调度程序配置集。如果这两个同时设置，调度程序策略将具有优先权。
先决条件
-
使用具有
cluster-admin角色的用户访问集群。
流程
编辑
Scheduler对象：oc edit scheduler cluster
$ oc edit scheduler clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow 指定在
spec.profile字段中使用的配置集：Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 设置为
LowNodeUtilization、HighNodeUtilization或NoScoring。
- 保存文件以使改变生效。
3.4. 使用关联性和反关联性规则相对于其他 pod 放置 pod
关联性是 pod 的一个属性，用于控制它们希望调度到的节点。反关联性是 pod 的一个属性，用于阻止 pod 调度到某个节点上。
在 OpenShift Container Platform 中，可以借助 pod 关联性和 pod 反关联性来根据其他 pod 上的键/值标签限制 pod 有资格调度到哪些节点。
3.4.1. 了解 pod 关联性
您可以借助 pod 关联性和 pod 反关联性来根据其他 pod 上的键/值标签限制 pod 有资格调度到哪些节点。
- 如果新 pod 上的标签选择器与当前 pod 上的标签匹配，pod 关联性可以命令调度程序将新 pod 放置到与其他 pod 相同的节点上。
- 如果新 pod 上的标签选择器与当前 pod 上的标签匹配，pod 反关联性可以阻止调度程序将新 pod 放置到与具有相同标签的 pod 相同的节点上。
例如，您可以使用关联性规则，在服务内或相对于其他服务中的 pod 来分散或聚拢 pod。如果特定服务的 pod 的性能已知会受到另一服务的 pod 影响，那么您可以利用反关联性规则，防止前一服务的 pod 调度到与后一服务的 pod 相同的节点上。或者，您可以将服务的 pod 分散到不同的节点或可用区间，以减少关联的故障。
pod 关联性规则有两种，即必要规则和偏好规则。
必须满足必要规则，pod 才能调度到节点上。偏好规则指定在满足规则时调度程序会尝试强制执行规则，但不保证一定能强制执行成功。
根据 pod 优先级和抢占设置，调度程序可能无法在不违反关联性要求的前提下为 pod 找到适合的节点。若是如此，pod 可能不会被调度。
要防止这种情况，请仔细配置优先级相同的 pod 的 pod 关联性。
您可以通过 Pod 规格文件配置 pod 关联性/反关联性。您可以指定必要规则或偏好规则，或同时指定这两种规则。如果您同时指定，节点必须首先满足必要规则，然后尝试满足偏好规则。
以下示例显示了配置了 pod 关联性和反关联性的 Pod 规格。
在本例中，pod 关联性规则指明，只有当节点至少有一个已在运行且具有键 security 和值 S1 的标签的 pod 时，pod 才可以调度到这个节点上。pod 反关联性则表示，如果节点已在运行带有键 security 和值 S2.的标签的 pod，则 pod 将偏向于不调度到该节点上。
具有 pod 关联性的 Pod 配置文件示例
具有 pod 反关联性的 Pod 配置文件示例
如果节点标签在运行时改变，使得不再满足 pod 上的关联性规则，pod 会继续在该节点上运行。
3.4.2. 配置 pod 关联性规则
以下步骤演示了一个简单的双 pod 配置，它创建一个带有某标签的 pod，以及一个使用关联性来允许随着该 pod 一起调度的 pod。
流程
创建在
Podspec 中带有特定标签的 pod:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在创建其他 pod 时，按如下所示编辑
Pod规格：-
使用
podAffinity小节配置requiredDuringSchedulingIgnoredDuringExecution参数或preferredDuringSchedulingIgnoredDuringExecution参数： 指定必须满足的键和值。如果您希望新 pod 与另一个 pod 一起调度，请使用与第一个 pod 上标签相同的
key和value参数。Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
指定一个
operator。运算符可以是In、NotIn、Exists或DoesNotExist。例如，使用运算符In来要求节点上存在该标签。 -
指定
topologyKey，这是一个预填充的 Kubernetes 标签，供系统用于表示这样的拓扑域。
-
使用
创建 pod。
oc create -f <pod-spec>.yaml
$ oc create -f <pod-spec>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
3.4.3. 配置 pod 反关联性规则
以下步骤演示了一个简单的双 pod 配置，它创建一个带有某标签的 pod，以及一个使用反关联性偏好规则来尝试阻止随着该 pod 一起调度的 pod。
流程
创建在
Podspec 中带有特定标签的 pod:Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
在创建其他 pod 时，编辑
Podspec 来设置以下参数： 使用
podAntiAffinity小节配置requiredDuringSchedulingIgnoredDuringExecution参数或preferredDuringSchedulingIgnoredDuringExecution参数：- 为节点指定一个 1 到 100 的权重。优先选择权重最高的节点。
指定必须满足的键和值。如果您希望新 pod 不与另一个 pod 一起调度，请使用与第一个 pod 上标签相同的
key和value参数。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 为偏好规则指定一个 1 到 100 的权重。
-
指定一个
operator。运算符可以是In、NotIn、Exists或DoesNotExist。例如，使用运算符In来要求节点上存在该标签。
-
指定
topologyKey，这是一个预填充的 Kubernetes 标签，供系统用于表示这样的拓扑域。 创建 pod。
oc create -f <pod-spec>.yaml
$ oc create -f <pod-spec>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
3.4.4. pod 关联性和反关联性规则示例
以下示例演示了 pod 关联性和 pod 反关联性。
3.4.4.1. Pod 关联性
以下示例演示了具有匹配标签和标签选择器的 pod 的 pod 关联性。
pod team4 具有标签
team:4。Copy to Clipboard Copied! Toggle word wrap Toggle overflow pod team4a 在
podAffinity下具有标签选择器team:4。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - team4a pod 调度到与 team4 pod 相同的节点上。
3.4.4.2. Pod 反关联性
以下示例演示了具有匹配标签和标签选择器的 pod 的 pod 反关联性。
pod pod-s1 具有标签
security:s1。Copy to Clipboard Copied! Toggle word wrap Toggle overflow pod pod-s2 在
podAntiAffinity下具有标签选择器security:s1。Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
pod pod-s2 无法调度到与
pod-s1相同的节点上。
3.4.4.3. 无匹配标签的 Pod 反关联性
以下示例演示了在没有匹配标签和标签选择器时的 pod 的 pod 关联性。
pod pod-s1 具有标签
security:s1。Copy to Clipboard Copied! Toggle word wrap Toggle overflow pod pod-s2 具有标签选择器
security:s2。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 除非节点上具有带
security:s2标签的 pod，否则不会调度 pod-s2。如果没有具有该标签的其他 pod，新 pod 会保持在待处理状态：输出示例
NAME READY STATUS RESTARTS AGE IP NODE pod-s2 0/1 Pending 0 32s <none>
NAME READY STATUS RESTARTS AGE IP NODE pod-s2 0/1 Pending 0 32s <none>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.5. 使用节点关联性规则控制节点上的 pod 放置
关联性是 pod 的一个属性，用于控制它们希望调度到的节点。
在 OpenShift Container Platform 中，节点关联性是由调度程序用来确定 pod 的可放置位置的一组规则。规则是使用节点中的自定义标签和 pod 中指定的选择器进行定义的。
3.5.1. 了解节点关联性
节点关联性允许 pod 指定与可以放置该 pod 的一组节点的关联性。节点对放置没有控制权。
例如，您可以将 pod 配置为仅在具有特定 CPU 或位于特定可用区的节点上运行。
节点关联性规则有两种，即必要规则和偏好规则。
必须满足必要规则，pod 才能调度到节点上。偏好规则指定在满足规则时调度程序会尝试强制执行规则，但不保证一定能强制执行成功。
如果节点标签在运行时改变，使得不再满足 pod 上的节点关联性规则，该 pod 将继续在这个节点上运行。
您可以通过 Pod 规格文件配置节点关联性。您可以指定必要规则或偏好规则，或同时指定这两种规则。如果您同时指定，节点必须首先满足必要规则，然后尝试满足偏好规则。
下例中的 Pod spec 包含一条规则，要求 pod 放置到具有键为 e2e-az-NorthSouth 且值为 e2e-az-North 或 e2e-az-South 的标签的节点上：
具有节点关联性必要规则的 pod 配置文件示例
下例中的节点规格包含一条偏好规则，其规定优先为 pod 选择具有键为 e2e-az-EastWest 且值为 e2e-az-East 或 e2e-az-West 的节点：
具有节点关联性偏好规则的 pod 配置文件示例
没有明确的节点反关联性概念，但使用 NotIn 或 DoesNotExist 运算符就能实现这种行为。
如果您在同一 pod 配置中同时使用节点关联性和节点选择器，请注意以下几点：
-
如果同时配置了
nodeSelector和nodeAffinity，则必须满足这两个条件时 pod 才能调度到候选节点。 -
如果您指定了多个与
nodeAffinity类型关联的nodeSelectorTerms，那么其中一个nodeSelectorTerms满足时 pod 就能调度到节点上。 -
如果您指定了多个与
nodeSelectorTerms关联的matchExpressions，那么只有所有matchExpressions都满足时 pod 才能调度到节点上。
3.5.2. 配置节点关联性必要规则
必须满足必要规则，pod 才能调度到节点上。
流程
以下步骤演示了一个简单的配置，此配置会创建一个节点，以及调度程序要放置到该节点上的 pod。
使用
oc label node命令给节点添加标签：oc label node node1 e2e-az-name=e2e-az1
$ oc label node node1 e2e-az-name=e2e-az1Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在
Podspec 中，使用nodeAffinity小节来配置requiredDuringSchedulingIgnoredDuringExecution参数：-
指定必须满足的键和值。如果希望新 pod 调度到您编辑的节点上，请使用与节点中标签相同的
key和value参数。 指定一个
operator。运算符可以是In、NotIn、Exists或DoesNotExist、Lt或Gt。例如，使用运算符In来要求节点上存在该标签：输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
-
指定必须满足的键和值。如果希望新 pod 调度到您编辑的节点上，请使用与节点中标签相同的
创建 pod：
oc create -f e2e-az2.yaml
$ oc create -f e2e-az2.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
3.5.3. 配置首选的节点关联性规则
偏好规则指定在满足规则时调度程序会尝试强制执行规则，但不保证一定能强制执行成功。
流程
以下步骤演示了一个简单的配置，此配置会创建一个节点，以及调度程序尝试放置到该节点上的 pod。
使用
oc label node命令给节点添加标签：oc label node node1 e2e-az-name=e2e-az3
$ oc label node node1 e2e-az-name=e2e-az3Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在
Podspec 中，使用nodeAffinity小节来配置preferredDuringSchedulingIgnoredDuringExecution参数：- 为节点指定一个权重，值为 1 到 100 的数字。优先选择权重最高的节点。
指定必须满足的键和值。如果希望新 pod 调度到您编辑的节点上，请使用与节点中标签相同的
key和value参数：Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
指定一个
operator。运算符可以是In、NotIn、Exists或DoesNotExist、Lt或Gt。例如，使用运算符In来要求节点上存在该标签：
创建 pod。
oc create -f e2e-az3.yaml
$ oc create -f e2e-az3.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
3.5.4. 节点关联性规则示例
以下示例演示了节点关联性。
3.5.4.1. 具有匹配标签的节点关联性
以下示例演示了具有匹配标签的节点与 pod 的节点关联性：
Node1 节点具有标签
zone:us：oc label node node1 zone=us
$ oc label node node1 zone=usCopy to Clipboard Copied! Toggle word wrap Toggle overflow pod-s1 pod 在节点关联性必要规则下具有
zone和us键/值对：cat pod-s1.yaml
$ cat pod-s1.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow pod-s1 pod 可以调度到 Node1 上：
oc get pod -o wide
$ oc get pod -o wideCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME READY STATUS RESTARTS AGE IP NODE pod-s1 1/1 Running 0 4m IP1 node1
NAME READY STATUS RESTARTS AGE IP NODE pod-s1 1/1 Running 0 4m IP1 node1Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.5.4.2. 没有匹配标签的节点关联性
以下示例演示了无匹配标签的节点与 pod 的节点关联性：
Node1 节点具有标签
zone:emea:oc label node node1 zone=emea
$ oc label node node1 zone=emeaCopy to Clipboard Copied! Toggle word wrap Toggle overflow pod-s1 pod 在节点关联性必要规则下具有
zone和us键/值对：cat pod-s1.yaml
$ cat pod-s1.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow pod-s1 pod 无法调度到 Node1 上：
oc describe pod pod-s1
$ oc describe pod pod-s1Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.6. 将 pod 放置到过量使用的节点
处于过量使用（overcommited）状态时，容器计算资源请求和限制的总和超过系统中可用的资源。过量使用常用于开发环境，因为在这种环境中可以接受以牺牲保障性能来换取功能的情况。
请求和限制可让管理员允许和管理节点上资源的过量使用。调度程序使用请求来调度容器，并提供最低服务保证。限制约束节点上可以消耗的计算资源数量。
3.6.1. 了解过量使用
请求和限制可让管理员允许和管理节点上资源的过量使用。调度程序使用请求来调度容器，并提供最低服务保证。限制约束节点上可以消耗的计算资源数量。
OpenShift Container Platform 管理员可以通过配置主控机（master）来覆盖开发人员容器上设置的请求和限制之间的比率，来控制过量使用的程度并管理节点上的容器密度。与项目一级上的用于指定限制和默认值的 LimitRange 对象一起使用，可以调整容器限制和请求以达到所需的过量使用程度。
如果没有在容器中设定限制，则这些覆盖无效。创建一个带有默认限制（基于每个独立的项目或在项目模板中）的 LimitRange 对象，以确保能够应用覆盖。
在进行这些覆盖后，容器限制和请求必须仍需要满足项目中的 LimitRange 对象的要求。这可能会导致 pod 被禁止的情况。例如，开发人员指定了一个接近最小限制的限制，然后其请求被覆盖为低于最小限制。这个问题在以后会加以解决，但目前而言，请小心地配置此功能和 LimitRange 对象。
3.6.2. 了解节点过量使用
在过量使用的环境中，务必要正确配置节点，以提供最佳的系统行为。
当节点启动时，它会确保为内存管理正确设置内核可微调标识。除非物理内存不足，否则内核应该永不会在内存分配时失败。
为确保这一行为，OpenShift Container Platform 通过将 vm.overcommit_memory 参数设置为 1 来覆盖默认操作系统设置，从而将内核配置为始终过量使用内存。
OpenShift Container Platform 还通过将 vm.panic_on_oom 参数设置为 0，将内核配置为不会在内存不足时崩溃。设置为 0 可告知内核在内存不足 (OOM) 情况下调用 oom_killer，以根据优先级终止进程
您可以通过对节点运行以下命令来查看当前的设置：
sysctl -a |grep commit
$ sysctl -a |grep commit输出示例
vm.overcommit_memory = 1
vm.overcommit_memory = 1sysctl -a |grep panic
$ sysctl -a |grep panic输出示例
vm.panic_on_oom = 0
vm.panic_on_oom = 0节点上应该已设置了上述标记，不需要进一步操作。
您还可以为每个节点执行以下配置：
- 使用 CPU CFS 配额禁用或强制实施 CPU 限制
- 为系统进程保留资源
- 为不同的服务质量等级保留内存
3.7. 使用节点污点控制 pod 放置
通过污点和容限，节点可以控制哪些 pod 应该（或不应该）调度到节点上。
3.7.1. 了解污点和容限
通过使用污点（taint），节点可以拒绝调度 pod，除非 pod 具有匹配的容限（toleration）。
您可以通过节点规格（NodeSpec）将污点应用到节点，并通过 Pod 规格（PodSpec）将容限应用到 pod。当您应用污点时，调度程序无法将 pod 放置到该节点上，除非 pod 可以容限该污点。
节点规格中的污点示例
Pod 规格中的容限示例
污点与容限由 key、value 和 effect 组成。
| 参数 | 描述 | ||||||
|---|---|---|---|---|---|---|---|
|
|
| ||||||
|
|
| ||||||
|
| effect 的值包括：
| ||||||
|
|
|
如果为 control plane 节点（也称为 master 节点）添加了一个
NoSchedule污点，则节点必须具有node-role.kubernetes.io/master=:NoSchedule污点，该污点会被默认添加。例如：
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
容限与污点匹配：
如果
operator参数设为Equal：-
key参数相同； -
value参数相同； -
effect参数相同。
-
如果
operator参数设为Exists：-
key参数相同； -
effect参数相同。
-
OpenShift Container Platform 中内置了以下污点：
-
node.kubernetes.io/not-ready：节点未就绪。这与节点状况Ready=False对应。 -
node.kubernetes.io/unreachable：节点无法从节点控制器访问。这与节点状况Ready=Unknown对应。 -
node.kubernetes.io/memory-pressure：节点存在内存压力问题。这与节点状况MemoryPressure=True对应。 -
node.kubernetes.io/disk-pressure：节点存在磁盘压力问题。这与节点状况DiskPressure=True对应。 -
node.kubernetes.io/network-unavailable：节点网络不可用。 -
node.kubernetes.io/unschedulable：节点不可调度。 -
node.cloudprovider.kubernetes.io/uninitialized：当节点控制器通过外部云提供商启动时，在节点上设置这个污点来将其标记为不可用。在云控制器管理器中的某个控制器初始化这个节点后，kubelet 会移除此污点。 node.kubernetes.io/pid-pressure：节点具有 pid 压力。这与节点状况PIDPressure=True对应。重要OpenShift Container Platform 不设置默认的 pid.available
evictionHard。
3.7.1.1. 了解如何使用容限秒数来延迟 pod 驱除
您可以通过在 Pod 规格或 MachineSet 对象中指定 tolerationSeconds 参数，指定 pod 在被驱除前可以保持与节点绑定的时长。如果将具有 NoExecute effect 的污点添加到节点，则容限污点（包含 tolerationSeconds 参数）的 pod，在此期限内 pod 不会被驱除。
输出示例
在这里，如果此 pod 正在运行但没有匹配的容限，pod 保持与节点绑定 3600 秒，然后被驱除。如果污点在这个时间之前移除，pod 就不会被驱除。
3.7.1.2. 了解如何使用多个污点
您可以在同一个节点中放入多个污点，并在同一 pod 中放入多个容限。OpenShift Container Platform 按照如下所述处理多个污点和容限：
- 处理 pod 具有匹配容限的污点。
其余的不匹配污点在 pod 上有指示的 effect：
-
如果至少有一个不匹配污点具有
NoScheduleeffect，则 OpenShift Container Platform 无法将 pod 调度到该节点上。 -
如果没有不匹配污点具有
NoScheduleeffect，但至少有一个不匹配污点具有PreferNoScheduleeffect，则 OpenShift Container Platform 尝试不将 pod 调度到该节点上。 如果至少有一个未匹配污点具有
NoExecuteeffect，OpenShift Container Platform 会将 pod 从该节点驱除（如果它已在该节点上运行），或者不将 pod 调度到该节点上（如果还没有在该节点上运行）。- 不容许污点的 Pod 会立即被驱除。
-
如果 Pod 容许污点而没有在
Pod规格中指定tolerationSeconds，则会永久保持绑定。 -
如果 Pod 容许污点，且指定了
tolerationSeconds，则会在指定的时间里保持绑定。
-
如果至少有一个不匹配污点具有
例如：
向节点添加以下污点：
oc adm taint nodes node1 key1=value1:NoSchedule
$ oc adm taint nodes node1 key1=value1:NoScheduleCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc adm taint nodes node1 key1=value1:NoExecute
$ oc adm taint nodes node1 key1=value1:NoExecuteCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc adm taint nodes node1 key2=value2:NoSchedule
$ oc adm taint nodes node1 key2=value2:NoScheduleCopy to Clipboard Copied! Toggle word wrap Toggle overflow pod 具有以下容限：
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
在本例中，pod 无法调度到节点上，因为没有与第三个污点匹配的容限。如果在添加污点时 pod 已在节点上运行，pod 会继续运行，因为第三个污点是三个污点中 pod 唯一不容许的污点。
3.7.1.3. 了解 pod 调度和节点状况（根据状况保留节点）
Taint Nodes By Condition （默认启用）可自动污点报告状况的节点，如内存压力和磁盘压力。如果某个节点报告一个状况，则添加一个污点，直到状况被清除为止。这些污点具有 NoSchedule effect；即，pod 无法调度到该节点上，除非 pod 有匹配的容限。
在调度 pod 前，调度程序会检查节点上是否有这些污点。如果污点存在，则将 pod 调度到另一个节点。由于调度程序检查的是污点而非实际的节点状况，因此您可以通过添加适当的 pod 容限，将调度程序配置为忽略其中一些节点状况。
为确保向后兼容，守护进程会自动将下列容限添加到所有守护进程中：
- node.kubernetes.io/memory-pressure
- node.kubernetes.io/disk-pressure
- node.kubernetes.io/unschedulable（1.10 或更高版本）
- node.kubernetes.io/network-unavailable（仅限主机网络）
您还可以在守护进程集中添加任意容限。
control plane 还会在具有 QoS 类的 pod 中添加 node.kubernetes.io/memory-pressure 容限。这是因为 Kubernetes 在 Guaranteed 或 Burstable QoS 类中管理 pod。新的 BestEffort pod 不会调度到受影响的节点上。
3.7.1.4. 了解根据状况驱除 pod（基于垃圾的驱除）
Taint-Based Evictions 功能默认是启用的，可以从遇到特定状况（如 not-ready 和 unreachable）的节点驱除 pod。当节点遇到其中一个状况时，OpenShift Container Platform 会自动给节点添加污点，并开始驱除 pod 以及将 pod 重新调度到其他节点。
Taint Based Evictions 具有 NoExecute 效果，不容许污点的 pod 都被立即驱除，容许污点的 pod 不会被驱除，除非 pod 使用 tolerationSeconds 参数。
tolerationSeconds 参数允许您指定 pod 保持与具有节点状况的节点绑定的时长。如果在 tolerationSections 到期后状况仍然存在，则污点会保持在节点上，并且具有匹配容限的 pod 将被驱除。如果状况在 tolerationSeconds 到期前清除，则不会删除具有匹配容限的 pod。
如果使用没有值的 tolerationSeconds 参数，则 pod 不会因为未就绪和不可访问的节点状况而被驱除。
OpenShift Container Platform 会以限速方式驱除 pod，从而防止在主控机从节点分离等情形中发生大量 pod 驱除。
默认情况下，如果给定区中超过 55% 的节点不健康，节点生命周期控制器会将该区的状态更改为 PartialDisruption，并降低 pod 驱除率。对于此状态下的小型集群（默认为 50 个节点或更小），此区中的节点不会污点，驱除也会停止。
如需更多信息，请参阅 Kubernetes 文档中的降低驱除限制。
OpenShift Container Platform 会自动为 node.kubernetes.io/not-ready 和 node.kubernetes.io/unreachable 添加容限并设置 tolerationSeconds=300，除非 Pod 配置中指定了其中任一种容限。
- 1
- 这些容限确保了在默认情况下，pod 在检测到这些节点条件问题中的任何一个时，会保持绑定 5 分钟。
您可以根据需要配置这些容限。例如，如果您有一个具有许多本地状态的应用程序，您可能希望在发生网络分区时让 pod 与节点保持绑定更久一些，以等待分区恢复并避免 pod 驱除行为的发生。
由守护进程集生成的 pod 在创建时会带有以下污点的 NoExecute 容限，且没有 tolerationSeconds:
-
node.kubernetes.io/unreachable -
node.kubernetes.io/not-ready
因此，守护进程集 pod 不会被驱除。
3.7.1.5. 容限所有污点
您可以通过添加 operator: "Exists" 容限而无需 key 和 value 参数，将节点配置为容许所有污点。具有此容限的 Pod 不会从具有污点的节点中删除。
用于容忍所有污点的Pod 规格
3.7.2. 添加污点和容限
您可以为 pod 和污点添加容限，以便节点能够控制哪些 pod 应该或不应该调度到节点上。对于现有的 pod 和节点，您应首先将容限添加到 pod，然后将污点添加到节点，以避免在添加容限前从节点上移除 pod。
流程
通过编辑
Podspec 使其包含tolerations小节来向 pod 添加容限：使用 Equal 运算符的 pod 配置文件示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例如：
使用 Exists 运算符的 pod 配置文件示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
Exists运算符不会接受一个value。
本例在
node1上放置一个键为key1且值为value1的污点，污点效果是NoExecute。通过以下命令，使用 Taint 和 toleration 组件表中描述的参数为节点添加污点：
oc adm taint nodes <node_name> <key>=<value>:<effect>
$ oc adm taint nodes <node_name> <key>=<value>:<effect>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例如：
oc adm taint nodes node1 key1=value1:NoExecute
$ oc adm taint nodes node1 key1=value1:NoExecuteCopy to Clipboard Copied! Toggle word wrap Toggle overflow 此命令在
node1上放置一个键为key1，值为value1的污点，其效果是NoExecute。注意如果为 control plane 节点（也称为 master 节点）添加了一个
NoSchedule污点，则节点必须具有node-role.kubernetes.io/master=:NoSchedule污点，该污点会被默认添加。例如：
Copy to Clipboard Copied! Toggle word wrap Toggle overflow pod 上的容限与节点上的污点匹配。具有任一容限的 pod 可以调度到
node1上。
3.7.2.1. 使用机器集添加污点和容限
您可以使用机器集为节点添加污点。与 MachineSet 对象关联的所有节点都会使用污点更新。容限对由机器集添加的污点的处理方式与直接添加到节点的污点的处理方式相同。
流程
通过编辑
Podspec 使其包含tolerations小节来向 pod 添加容限：使用
Equal运算符的 pod 配置文件示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例如：
使用
Exists运算符的 pod 配置文件示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 将污点添加到
MachineSet对象：为您想要污点的节点编辑
MachineSetYAML，也可以创建新MachineSet对象：oc edit machineset <machineset>
$ oc edit machineset <machineset>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 将污点添加到
spec.template.spec部分：机器集规格中的污点示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 本例在节点上放置一个键为
key1，值为value1的污点，污点效果是NoExecute。将机器缩减为 0:
oc scale --replicas=0 machineset <machineset> -n openshift-machine-api
$ oc scale --replicas=0 machineset <machineset> -n openshift-machine-apiCopy to Clipboard Copied! Toggle word wrap Toggle overflow 等待机器被删除。
根据需要扩展机器设置：
oc scale --replicas=2 machineset <machineset> -n openshift-machine-api
$ oc scale --replicas=2 machineset <machineset> -n openshift-machine-apiCopy to Clipboard Copied! Toggle word wrap Toggle overflow 等待机器启动。污点添加到与
MachineSet对象关联的节点上。
3.7.2.2. 使用污点和容限将用户绑定到节点
如果要指定一组节点供特定用户独占使用，为 pod 添加容限。然后，在这些节点中添加对应的污点。具有容限的 pod 被允许使用污点节点，或集群中的任何其他节点。
如果您希望确保 pod 只调度到那些污点节点，还要将标签添加到同一组节点，并为 pod 添加节点关联性，以便 pod 只能调度到具有该标签的节点。
流程
配置节点以使用户只能使用该节点：
为这些节点添加对应的污点：
例如：
oc adm taint nodes node1 dedicated=groupName:NoSchedule
$ oc adm taint nodes node1 dedicated=groupName:NoScheduleCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 通过编写自定义准入控制器，为 pod 添加容限。
3.7.2.3. 使用节点选择器和容限创建项目
您可以创建一个使用节点选择器和容限（设为注解）的项目，以控制 pod 放置到特定的节点上。然后，项目中创建的任何后续资源都会调度到与容限匹配的污点节点上。
先决条件
- 通过使用机器集或直接编辑节点，已将节点选择的标签添加到一个或多个节点上。
- 通过使用机器集或直接编辑节点，已将污点添加到一个或多个节点上。
流程
创建
Project资源定义，在metadata.annotations部分指定节点选择器和容限：project.yaml文件示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 使用
oc apply命令来创建项目：oc apply -f project.yaml
$ oc apply -f project.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
现在，<project_name> 命名空间中创建的任何后续资源都应调度到指定的节点上。
3.7.2.4. 使用污点和容限控制具有特殊硬件的节点
如果集群中有少量节点具有特殊的硬件，您可以使用污点和容限让不需要特殊硬件的 pod 与这些节点保持距离，从而将这些节点保留给那些确实需要特殊硬件的 pod。您还可以要求需要特殊硬件的 pod 使用特定的节点。
您可以将容限添加到需要特殊硬件并污点具有特殊硬件的节点的 pod 中。
流程
确保为特定 pod 保留具有特殊硬件的节点：
为需要特殊硬件的 pod 添加容限。
例如：
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 使用以下命令之一，给拥有特殊硬件的节点添加污点：
oc adm taint nodes <node-name> disktype=ssd:NoSchedule
$ oc adm taint nodes <node-name> disktype=ssd:NoScheduleCopy to Clipboard Copied! Toggle word wrap Toggle overflow 或者：
oc adm taint nodes <node-name> disktype=ssd:PreferNoSchedule
$ oc adm taint nodes <node-name> disktype=ssd:PreferNoScheduleCopy to Clipboard Copied! Toggle word wrap Toggle overflow
3.7.3. 删除污点和容限
您可以根据需要，从节点移除污点并从 pod 移除容限。您应首先将容限添加到 pod，然后将污点添加到节点，以避免在添加容限前从节点上移除 pod。
流程
移除污点和容限：
从节点移除污点：
oc adm taint nodes <node-name> <key>-
$ oc adm taint nodes <node-name> <key>-Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例如：
oc adm taint nodes ip-10-0-132-248.ec2.internal key1-
$ oc adm taint nodes ip-10-0-132-248.ec2.internal key1-Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
node/ip-10-0-132-248.ec2.internal untainted
node/ip-10-0-132-248.ec2.internal untaintedCopy to Clipboard Copied! Toggle word wrap Toggle overflow 要从 pod 移除某一容限，请编辑
Pod规格来移除该容限：Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.8. 使用节点选择器将 pod 放置到特定节点
节点选择器指定一个键/值对映射，该映射使用 pod 中指定的自定义标签和选择器定义。
要使 pod 有资格在节点上运行，pod 必须具有与节点上标签相同的键值节点选择器。
3.8.1. 关于节点选择器
您可以使用节点上的 pod 和标签上的节点选择器来控制 pod 的调度位置。使用节点选择器时，OpenShift Container Platform 会将 pod 调度到包含匹配标签的节点。
您可以使用节点选择器将特定的 pod 放置到特定的节点上，集群范围节点选择器将新 pod 放置到集群中的任何特定节点上，以及项目节点选择器，将新 pod 放置到特定的节点上。
例如，作为集群管理员，您可以创建一个基础架构，应用程序开发人员可以通过在创建的每个 pod 中包括节点选择器，将 pod 部署到最接近其地理位置的节点。在本例中，集群由五个数据中心组成，分布在两个区域。在美国，将节点标记为 us-east、us-central 或 us-west。在亚太地区（APAC），将节点标记为 apac-east 或 apac-west。开发人员可在其创建的 pod 中添加节点选择器，以确保 pod 调度到这些节点上。
如果 Pod 对象包含节点选择器，但没有节点具有匹配的标签，则不会调度 pod。
如果您在同一 pod 配置中使用节点选择器和节点关联性，则以下规则控制 pod 放置到节点上：
-
如果同时配置了
nodeSelector和nodeAffinity，则必须满足这两个条件时 pod 才能调度到候选节点。 -
如果您指定了多个与
nodeAffinity类型关联的nodeSelectorTerms，那么其中一个nodeSelectorTerms满足时 pod 就能调度到节点上。 -
如果您指定了多个与
nodeSelectorTerms关联的matchExpressions，那么只有所有matchExpressions都满足时 pod 才能调度到节点上。
- 特定 pod 和节点上的节点选择器
您可以使用节点选择器和标签控制特定 pod 调度到哪些节点上。
要使用节点选择器和标签，首先标记节点以避免 pod 被取消调度，然后将节点选择器添加到 pod。
注意您不能直接将节点选择器添加到现有调度的 pod 中。您必须标记控制 pod 的对象，如部署配置。
例如，以下
Node对象具有region: east标签：带有标识的
Node对象示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 与 pod 节点选择器匹配的标签。
pod 具有
type: user-node,region: east节点选择器：使用节点选择器的
Pod对象示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 与节点标签匹配的节点选择器。
使用示例 pod 规格创建 pod 时，它可以调度到示例节点上。
- 默认集群范围节点选择器
使用默认集群范围节点选择器时，如果您在集群中创建 pod,OpenShift Container Platform 会将默认节点选择器添加到 pod，并将该 pod 调度到具有匹配标签的节点。
例如，以下
Scheduler对象具有默认的集群范围的region=east和type=user-node节点选择器：Scheduler Operator 自定义资源示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 集群中的节点具有
type=user-node,region=east标签：Node对象示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 使用节点选择器的
Pod对象示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 当您使用示例集群中的 pod spec 创建 pod 时，该 pod 会使用集群范围节点选择器创建，并调度到标记的节点：
在标记的节点上带有 pod 的 pod 列表示例
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES pod-s1 1/1 Running 0 20s 10.131.2.6 ci-ln-qg1il3k-f76d1-hlmhl-worker-b-df2s4 <none> <none>
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES pod-s1 1/1 Running 0 20s 10.131.2.6 ci-ln-qg1il3k-f76d1-hlmhl-worker-b-df2s4 <none> <none>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注意如果您在其中创建 pod 的项目具有项目节点选择器，则该选择器优先于集群范围节点选择器。如果 pod 没有项目节点选择器，则 pod 不会被创建或调度。
- 项目节点选择器
使用项目节点选择器时，如果您在此项目中创建 pod,OpenShift Container Platform 会将节点选择器添加到 pod，并将 pod 调度到具有匹配标签的节点。如果存在集群范围默认节点选择器，则以项目节点选择器为准。
例如，以下项目具有
region=east节点选择器：Namespace对象示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下节点具有
type=user-node,region=east标签：Node对象示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 当您使用本例项目中的示例 pod 规格创建 pod 时，pod 会使用项目节点选择器创建，并调度到标记的节点：
Pod对象示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在标记的节点上带有 pod 的 pod 列表示例
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES pod-s1 1/1 Running 0 20s 10.131.2.6 ci-ln-qg1il3k-f76d1-hlmhl-worker-b-df2s4 <none> <none>
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES pod-s1 1/1 Running 0 20s 10.131.2.6 ci-ln-qg1il3k-f76d1-hlmhl-worker-b-df2s4 <none> <none>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 如果 pod 包含不同的节点选择器，则项目中的 pod 不会被创建或调度。例如，如果您将以下 Pod 部署到示例项目中，则不会创建它：
带有无效节点选择器的
Pod对象示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.8.2. 使用节点选择器控制 pod 放置
您可以使用节点上的 pod 和标签上的节点选择器来控制 pod 的调度位置。使用节点选择器时，OpenShift Container Platform 会将 pod 调度到包含匹配标签的节点。
您可为节点、机器集或机器配置添加标签。将标签添加到机器集可确保节点或机器停机时，新节点具有标签。如果节点或机器停机，添加到节点或机器配置的标签不会保留。
要将节点选择器添加到现有 pod 中，将节点选择器添加到该 pod 的控制对象中，如 ReplicaSet 对象、DaemonSet 对象、StatefulSet 对象、Deployment 对象或 DeploymentConfig 对象。任何属于该控制对象的现有 pod 都会在具有匹配标签的节点上重新创建。如果要创建新 pod，可以将节点选择器直接添加到 Pod 规格中。
您不能直接将节点选择器添加到现有调度的 pod 中。
先决条件
要将节点选择器添加到现有 pod 中，请确定该 pod 的控制对象。例如, router-default-66d5cf9464-m2g75 pod 由 router-default-66d5cf9464 副本集控制：
Web 控制台在 pod YAML 的 ownerReferences 下列出控制对象：
流程
通过使用机器集或直接编辑节点，为节点添加标签：
在创建节点时，使用
MachineSet对象向由机器集管理的节点添加标签：运行以下命令，将标签添加到
MachineSet对象中：oc patch MachineSet <name> --type='json' -p='[{"op":"add","path":"/spec/template/spec/metadata/labels", "value":{"<key>"="<value>","<key>"="<value>"}}]' -n openshift-machine-api$ oc patch MachineSet <name> --type='json' -p='[{"op":"add","path":"/spec/template/spec/metadata/labels", "value":{"<key>"="<value>","<key>"="<value>"}}]' -n openshift-machine-apiCopy to Clipboard Copied! Toggle word wrap Toggle overflow 例如：
oc patch MachineSet abc612-msrtw-worker-us-east-1c --type='json' -p='[{"op":"add","path":"/spec/template/spec/metadata/labels", "value":{"type":"user-node","region":"east"}}]' -n openshift-machine-api$ oc patch MachineSet abc612-msrtw-worker-us-east-1c --type='json' -p='[{"op":"add","path":"/spec/template/spec/metadata/labels", "value":{"type":"user-node","region":"east"}}]' -n openshift-machine-apiCopy to Clipboard Copied! Toggle word wrap Toggle overflow 使用
oc edit命令验证标签是否已添加到MachineSet对象中：例如：
oc edit MachineSet abc612-msrtw-worker-us-east-1c -n openshift-machine-api
$ oc edit MachineSet abc612-msrtw-worker-us-east-1c -n openshift-machine-apiCopy to Clipboard Copied! Toggle word wrap Toggle overflow MachineSet对象示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow
直接向节点添加标签：
为节点编辑
Node对象：oc label nodes <name> <key>=<value>
$ oc label nodes <name> <key>=<value>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例如，若要为以下节点添加标签：
oc label nodes ip-10-0-142-25.ec2.internal type=user-node region=east
$ oc label nodes ip-10-0-142-25.ec2.internal type=user-node region=eastCopy to Clipboard Copied! Toggle word wrap Toggle overflow 验证标签是否已添加到节点：
oc get nodes -l type=user-node,region=east
$ oc get nodes -l type=user-node,region=eastCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME STATUS ROLES AGE VERSION ip-10-0-142-25.ec2.internal Ready worker 17m v1.18.3+002a51f
NAME STATUS ROLES AGE VERSION ip-10-0-142-25.ec2.internal Ready worker 17m v1.18.3+002a51fCopy to Clipboard Copied! Toggle word wrap Toggle overflow
将匹配的节点选择器添加到 pod：
要将节点选择器添加到现有和未来的 pod，请向 pod 的控制对象添加节点选择器：
带有标签的
ReplicaSet对象示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 添加节点选择器。
要将节点选择器添加到一个特定的新 pod，直接将选择器添加到
Pod对象中：使用节点选择器的
Pod对象示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注意您不能直接将节点选择器添加到现有调度的 pod 中。
3.8.3. 创建默认的集群范围节点选择器
您可以组合使用 pod 上的默认集群范围节点选择器和节点上的标签，将集群中创建的所有 pod 限制到特定节点。
使用集群范围节点选择器时，如果您在集群中创建 pod,OpenShift Container Platform 会将默认节点选择器添加到 pod，并将该 pod 调度到具有匹配标签的节点。
您可以通过编辑调度程序 Operator 自定义资源（CR）来配置集群范围节点选择器。您可为节点、机器集或机器配置添加标签。将标签添加到机器集可确保节点或机器停机时，新节点具有标签。如果节点或机器停机，添加到节点或机器配置的标签不会保留。
您可以向 pod 添加额外的键/值对。但是，您无法为一个默认的键添加不同的值。
流程
添加默认的集群范围节点选择器：
编辑调度程序 Operator CR 以添加默认的集群范围节点选择器：
oc edit scheduler cluster
$ oc edit scheduler clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow 使用节点选择器的调度程序 Operator CR 示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 使用适当的
<key>:<value>对添加节点选择器。
完成此更改后，请等待重新部署
openshift-kube-apiserver项目中的 pod。这可能需要几分钟。只有重新部署 pod 后，默认的集群范围节点选择器才会生效。通过使用机器集或直接编辑节点，为节点添加标签：
在创建节点时，使用机器集向由机器集管理的节点添加标签：
运行以下命令，将标签添加到
MachineSet对象中：oc patch MachineSet <name> --type='json' -p='[{"op":"add","path":"/spec/template/spec/metadata/labels", "value":{"<key>"="<value>","<key>"="<value>"}}]' -n openshift-machine-api$ oc patch MachineSet <name> --type='json' -p='[{"op":"add","path":"/spec/template/spec/metadata/labels", "value":{"<key>"="<value>","<key>"="<value>"}}]' -n openshift-machine-api1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 为每个标识添加
<key>/<value>对。
例如：
oc patch MachineSet ci-ln-l8nry52-f76d1-hl7m7-worker-c --type='json' -p='[{"op":"add","path":"/spec/template/spec/metadata/labels", "value":{"type":"user-node","region":"east"}}]' -n openshift-machine-api$ oc patch MachineSet ci-ln-l8nry52-f76d1-hl7m7-worker-c --type='json' -p='[{"op":"add","path":"/spec/template/spec/metadata/labels", "value":{"type":"user-node","region":"east"}}]' -n openshift-machine-apiCopy to Clipboard Copied! Toggle word wrap Toggle overflow 使用
oc edit命令验证标签是否已添加到MachineSet对象中：例如：
oc edit MachineSet ci-ln-l8nry52-f76d1-hl7m7-worker-c -n openshift-machine-api
$ oc edit MachineSet ci-ln-l8nry52-f76d1-hl7m7-worker-c -n openshift-machine-apiCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 通过缩减至
0并扩展节点来重新部署与该机器集关联的节点：例如：
oc scale --replicas=0 MachineSet ci-ln-l8nry52-f76d1-hl7m7-worker-c -n openshift-machine-api
$ oc scale --replicas=0 MachineSet ci-ln-l8nry52-f76d1-hl7m7-worker-c -n openshift-machine-apiCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc scale --replicas=1 MachineSet ci-ln-l8nry52-f76d1-hl7m7-worker-c -n openshift-machine-api
$ oc scale --replicas=1 MachineSet ci-ln-l8nry52-f76d1-hl7m7-worker-c -n openshift-machine-apiCopy to Clipboard Copied! Toggle word wrap Toggle overflow 当节点就绪并可用时，使用
oc get命令验证该标签是否已添加到节点：oc get nodes -l <key>=<value>
$ oc get nodes -l <key>=<value>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例如：
oc get nodes -l type=user-node
$ oc get nodes -l type=user-nodeCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME STATUS ROLES AGE VERSION ci-ln-l8nry52-f76d1-hl7m7-worker-c-vmqzp Ready worker 61s v1.18.3+002a51f
NAME STATUS ROLES AGE VERSION ci-ln-l8nry52-f76d1-hl7m7-worker-c-vmqzp Ready worker 61s v1.18.3+002a51fCopy to Clipboard Copied! Toggle word wrap Toggle overflow
直接向节点添加标签：
为节点编辑
Node对象：oc label nodes <name> <key>=<value>
$ oc label nodes <name> <key>=<value>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例如，若要为以下节点添加标签：
oc label nodes ci-ln-l8nry52-f76d1-hl7m7-worker-b-tgq49 type=user-node region=east
$ oc label nodes ci-ln-l8nry52-f76d1-hl7m7-worker-b-tgq49 type=user-node region=eastCopy to Clipboard Copied! Toggle word wrap Toggle overflow 使用
oc get命令验证标签是否已添加到节点：oc get nodes -l <key>=<value>,<key>=<value>
$ oc get nodes -l <key>=<value>,<key>=<value>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例如：
oc get nodes -l type=user-node,region=east
$ oc get nodes -l type=user-node,region=eastCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME STATUS ROLES AGE VERSION ci-ln-l8nry52-f76d1-hl7m7-worker-b-tgq49 Ready worker 17m v1.18.3+002a51f
NAME STATUS ROLES AGE VERSION ci-ln-l8nry52-f76d1-hl7m7-worker-b-tgq49 Ready worker 17m v1.18.3+002a51fCopy to Clipboard Copied! Toggle word wrap Toggle overflow
3.8.4. 创建项目范围节点选择器
您可以组合使用项目中的节点选择器和节点上的标签，将该项目中创建的所有 pod 限制到标记的节点。
当您在这个项目中创建 pod 时，OpenShift Container Platform 会将节点选择器添加到项目中 pod，并将 pod 调度到项目中具有匹配标签的节点。如果存在集群范围默认节点选择器，则以项目节点选择器为准。
您可以通过编辑 Namespace 对象来向项目添加节点选择器，以添加 openshift.io/node-selector 参数。您可为节点、机器集或机器配置添加标签。将标签添加到机器集可确保节点或机器停机时，新节点具有标签。如果节点或机器停机，添加到节点或机器配置的标签不会保留。
如果 Pod 对象包含节点选择器，则不会调度 pod，但没有项目具有匹配的节点选择器。从该 spec 创建 pod 时，您收到类似以下消息的错误：
错误信息示例
Error from server (Forbidden): error when creating "pod.yaml": pods "pod-4" is forbidden: pod node label selector conflicts with its project node label selector
Error from server (Forbidden): error when creating "pod.yaml": pods "pod-4" is forbidden: pod node label selector conflicts with its project node label selector您可以向 pod 添加额外的键/值对。但是，您无法为一个项目键添加其他值。
流程
添加默认项目节点选择器：
创建命名空间或编辑现有命名空间，以添加
openshift.io/node-selector参数：oc edit namespace <name>
$ oc edit namespace <name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 使用适当的
<key>:<value>对添加openshift.io/node-selector。
通过使用机器集或直接编辑节点，为节点添加标签：
在创建节点时，使用
MachineSet对象向由机器集管理的节点添加标签：运行以下命令，将标签添加到
MachineSet对象中：oc patch MachineSet <name> --type='json' -p='[{"op":"add","path":"/spec/template/spec/metadata/labels", "value":{"<key>"="<value>","<key>"="<value>"}}]' -n openshift-machine-api$ oc patch MachineSet <name> --type='json' -p='[{"op":"add","path":"/spec/template/spec/metadata/labels", "value":{"<key>"="<value>","<key>"="<value>"}}]' -n openshift-machine-apiCopy to Clipboard Copied! Toggle word wrap Toggle overflow 例如：
oc patch MachineSet ci-ln-l8nry52-f76d1-hl7m7-worker-c --type='json' -p='[{"op":"add","path":"/spec/template/spec/metadata/labels", "value":{"type":"user-node","region":"east"}}]' -n openshift-machine-api$ oc patch MachineSet ci-ln-l8nry52-f76d1-hl7m7-worker-c --type='json' -p='[{"op":"add","path":"/spec/template/spec/metadata/labels", "value":{"type":"user-node","region":"east"}}]' -n openshift-machine-apiCopy to Clipboard Copied! Toggle word wrap Toggle overflow 使用
oc edit命令验证标签是否已添加到MachineSet对象中：例如：
oc edit MachineSet ci-ln-l8nry52-f76d1-hl7m7-worker-c -n openshift-machine-api
$ oc edit MachineSet ci-ln-l8nry52-f76d1-hl7m7-worker-c -n openshift-machine-apiCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重新部署与该机器集关联的节点：
例如：
oc scale --replicas=0 MachineSet ci-ln-l8nry52-f76d1-hl7m7-worker-c -n openshift-machine-api
$ oc scale --replicas=0 MachineSet ci-ln-l8nry52-f76d1-hl7m7-worker-c -n openshift-machine-apiCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc scale --replicas=1 MachineSet ci-ln-l8nry52-f76d1-hl7m7-worker-c -n openshift-machine-api
$ oc scale --replicas=1 MachineSet ci-ln-l8nry52-f76d1-hl7m7-worker-c -n openshift-machine-apiCopy to Clipboard Copied! Toggle word wrap Toggle overflow 当节点就绪并可用时，使用
oc get命令验证该标签是否已添加到节点：oc get nodes -l <key>=<value>
$ oc get nodes -l <key>=<value>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例如：
oc get nodes -l type=user-node,region=east
$ oc get nodes -l type=user-node,region=eastCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME STATUS ROLES AGE VERSION ci-ln-l8nry52-f76d1-hl7m7-worker-c-vmqzp Ready worker 61s v1.18.3+002a51f
NAME STATUS ROLES AGE VERSION ci-ln-l8nry52-f76d1-hl7m7-worker-c-vmqzp Ready worker 61s v1.18.3+002a51fCopy to Clipboard Copied! Toggle word wrap Toggle overflow
直接向节点添加标签：
编辑
Node对象以添加标签：oc label <resource> <name> <key>=<value>
$ oc label <resource> <name> <key>=<value>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例如，若要为以下节点添加标签：
oc label nodes ci-ln-l8nry52-f76d1-hl7m7-worker-c-tgq49 type=user-node region=east
$ oc label nodes ci-ln-l8nry52-f76d1-hl7m7-worker-c-tgq49 type=user-node region=eastCopy to Clipboard Copied! Toggle word wrap Toggle overflow 使用
oc get命令验证标签是否已添加到Node对象中：oc get nodes -l <key>=<value>
$ oc get nodes -l <key>=<value>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例如：
oc get nodes -l type=user-node,region=east
$ oc get nodes -l type=user-node,region=eastCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
NAME STATUS ROLES AGE VERSION ci-ln-l8nry52-f76d1-hl7m7-worker-b-tgq49 Ready worker 17m v1.18.3+002a51f
NAME STATUS ROLES AGE VERSION ci-ln-l8nry52-f76d1-hl7m7-worker-b-tgq49 Ready worker 17m v1.18.3+002a51fCopy to Clipboard Copied! Toggle word wrap Toggle overflow
3.9. 使用 pod 拓扑分布限制控制 pod 放置
您可以使用 pod 拓扑分布约束来控制 pod 在节点、区、区域或其他用户定义的拓扑域间的放置。
3.9.1. 关于 pod 拓扑分布限制
通过使用 pod 拓扑分布约束，您可以对故障域中的 pod 分布提供精细的控制，以帮助实现高可用性和更有效的资源使用。
OpenShift Container Platform 管理员可以标记节点以提供拓扑信息，如区域、区、节点或其他用户定义域。在节点上设置了这些标签后，用户才能定义 pod 拓扑分布约束，以控制 pod 在这些拓扑域中的放置。
您可以指定哪些 pod 要分组在一起，它们分散到哪些拓扑域以及可以接受的基点。只有同一命名空间中的 pod 在因为约束而分散时才会被匹配和分组。
3.9.2. 配置 pod 拓扑分布限制
以下步骤演示了如何配置 pod 拓扑扩展约束，以根据区分配与指定标签匹配的 pod。
您可以指定多个 pod 拓扑分散约束，但您必须确保它们不会相互冲突。必须满足所有 pod 拓扑分布约束才能放置 pod。
先决条件
- 集群管理员已将所需的标签添加到节点。
流程
创建
Podspec 并指定 pod 拓扑分散约束：pod-spec.yaml文件示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 两个拓扑域间的 pod 数量的最大差别。默认为
1，您不能指定0值。 - 2
- 节点标签的密钥。具有此键和相同值的节点被视为在同一拓扑中。
- 3
- 如果不满足分布式约束，如何处理 pod。默认为
DoNotSchedule，它会告诉调度程序不要调度 pod。设置为ScheduleAnyway，它仍然会调度 pod，但调度程序会优先考虑 skew 的根据情况以使集群不要出现不平衡的情况。 - 4
- 匹配此标签选择器的 Pod 在分发时被计算并识别为组，以满足约束要求。确保指定标签选择器，否则就无法匹配 pod。
- 5
- 如果您希望以后正确计数此 Pod 规格，请确保此
Podspec 也会设置其标签选择器来匹配这个标签选择器。
创建 pod：
oc create -f pod-spec.yaml
$ oc create -f pod-spec.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
3.9.3. pod 拓扑分布限制示例
以下示例演示了 pod 拓扑分散约束配置。
3.9.3.1. 单个 pod 拓扑分布约束示例
此 Pod spec 示例定义了一个 pod 拓扑分散约束。它与标记为 foo:bar 的 pod 匹配，在区间分布，指定 skew 1，并在不满足这些要求时不调度 pod。
3.9.3.2. 多个 pod 拓扑分布约束示例
此 Pod spec 示例定义了两个 pod 拓扑分布限制。标签为 foo:bar 的 pod 上的匹配，指定为 skew 1，并在不满足这些要求时不调度 pod。
第一个限制基于用户定义的标签 node 发布 pod，第二个约束根据用户定义的标签 rack 分发 pod。调度 pod 必须满足这两个限制。
3.10. 运行自定义调度程序
您可以与默认调度程序一起运行多个自定义调度程序，并配置要用于每个 pod 的调度程序。
支持在 OpenShift Container Platform 中使用自定义调度程序，但红帽不直接支持自定义调度程序的功能。
有关如何配置默认调度程序的详情，请参考配置默认调度程序来控制 pod 放置。
要使用特定的调度程序调度给定 pod，在该 Pod 的规格中指定调度程序的名称。
3.10.1. 部署自定义调度程序
要在集群中包含自定义调度程序，请在部署中包含自定义调度程序的镜像。
先决条件
-
您可以使用具有
cluster-admin角色的用户访问集群。 您有一个调度程序二进制文件。
注意有关如何创建调度程序二进制文件的信息超出了本文档的讨论范围。例如，请参阅 Kubernetes 文档中的配置多个调度程序。请注意，红帽不支持自定义调度程序的实际功能。
- 您已创建了包含调度程序二进制文件的镜像，并将其推送到 registry。
流程
创建一个包含自定义调度程序部署资源的文件：
custom-scheduler.yaml文件示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在集群中创建部署资源：
oc create -f custom-scheduler.yaml
$ oc create -f custom-scheduler.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
验证调度程序 pod 是否正在运行：
oc get pods -n kube-system
$ oc get pods -n kube-systemCopy to Clipboard Copied! Toggle word wrap Toggle overflow 自定义调度程序 pod 列为
Running：NAME READY STATUS RESTARTS AGE custom-scheduler-6cd7c4b8bc-854zb 1/1 Running 0 2m
NAME READY STATUS RESTARTS AGE custom-scheduler-6cd7c4b8bc-854zb 1/1 Running 0 2mCopy to Clipboard Copied! Toggle word wrap Toggle overflow
3.10.2. 使用自定义调度程序部署 pod
在集群中部署自定义调度程序后，您可以将 pod 配置为使用该调度程序，而不是默认调度程序。
每个调度程序具有集群中资源的单独视图。因此，每个调度程序应在自己的一组节点上运行。
如果两个或多个调度程序在同一节点上运行，它们可能会相互干扰，并在同一个节点上调度多个 pod，而不是用于的可用资源。在这种情况下，Pod 可能会因为资源不足而被拒绝。
先决条件
-
您可以使用具有
cluster-admin角色的用户访问集群。 - 自定义调度程序已在集群中部署。
流程
如果您的集群使用基于角色的访问控制 (RBAC)，将自定义调度程序名称添加到
system:kube-scheduler集群角色。编辑
system:kube-scheduler集群角色：oc edit clusterrole system:kube-scheduler
$ oc edit clusterrole system:kube-schedulerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 将自定义调度程序的名称添加到
leases和endpoints的resourceNames列表中：Copy to Clipboard Copied! Toggle word wrap Toggle overflow
创建
Pod配置并在schedulerName参数中指定自定义调度程序的名称：custom-scheduler-example.yaml文件示例Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 要使用的自定义调度程序的名称，本例中为
custom-scheduler。如果没有提供调度程序名称，pod 会自动使用默认调度程序来调度。
创建 pod：
oc create -f custom-scheduler-example.yaml
$ oc create -f custom-scheduler-example.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
输入以下命令检查 pod 是否已创建：
oc get pod custom-scheduler-example
$ oc get pod custom-scheduler-exampleCopy to Clipboard Copied! Toggle word wrap Toggle overflow custom-scheduler-examplepod 在输出中列出：NAME READY STATUS RESTARTS AGE custom-scheduler-example 1/1 Running 0 4m
NAME READY STATUS RESTARTS AGE custom-scheduler-example 1/1 Running 0 4mCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输入以下命令检查自定义调度程序是否已调度 pod：
oc describe pod custom-scheduler-example
$ oc describe pod custom-scheduler-exampleCopy to Clipboard Copied! Toggle word wrap Toggle overflow 调度程序
custom-scheduler如以下截断的输出所示：Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled <unknown> custom-scheduler Successfully assigned default/custom-scheduler-example to <node_name>
Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled <unknown> custom-scheduler Successfully assigned default/custom-scheduler-example to <node_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.11. 使用 descheduler 驱除 pod
调度程序（scheduler）被用来决定最适合托管新 pod 的节点，而 descheduler 可以用来驱除正在运行的 pod，从而使 pod 能够重新调度到更合适的节点上。
3.11.1. 关于 descheduler
您可以使用 descheduler 根据特定策略驱除 pod，以便可将 pod 重新调度到更合适的节点上。
descheduler 适合于在以下情况下 处理运行的 pod：
- 节点使用不足或过度使用。
- Pod 和节点关联性要求（如污点或标签）已更改，并且原始的调度不再适合于某些节点。
- 节点失败需要移动 pod。
- 集群中添加了新节点。
- Pod 重启的次数太多。
descheduler 不调度被驱除的 pod。调度被驱除 pod 的任务由调度程序（scheduler）执行。
当 descheduler 决定从节点驱除 pod 时，它会使用以下机制：
-
openshift-*和kube-system命名空间中的 Pod 不会被驱除。 -
priorityClassName被设置为system-cluster-critical或system-node-critical的关键 pod 不会被驱除。 - 不属于复制控制器、副本集、部署或作业一部分的静态、镜像或独立 pod 不会被驱除，因为这些 pod 不会被重新创建。
- 与守护进程集关联的 pod 不会被驱除。
- 具有本地存储的 Pod 不会被驱除。
- BestEffort pod 会在 Burstable 和 Guaranteed pod 之前被驱除。
-
具有
descheduler.alpha.kubernetes.io/evict注解的所有 pod 类型都可以被驱除。此注解用于覆盖防止驱除的检查，用户可以选择驱除哪些 pod。用户应该知道如何创建 pod 以及是否重新创建 pod。 - 对于受 Pod Disruption Budget (PDB) 限制的 pod，如果进行 deschedule 会违反 Pod disruption budget (PDB)，则 pod 不会被驱除。通过使用驱除子资源来处理 PDB 来驱除 pod 。
3.11.2. Descheduler 配置集
以下 descheduler 配置集可用：
AffinityAndTaints此配置集驱除违反了 pod 间的反关联性、节点关联性和节点污点的 pod。
它启用了以下策略：
-
RemovePodsViolatingInterPodAntiAffinity：删除违反了 pod 间的反关联性的 pod。 -
RemovePodsViolatingNodeAffinity：移除违反了节点关联性的 pod。 RemovePodsViolatingNodeTaints：移除违反了节点上的NoSchedule污点的 pod。移除具有节点关联性类型
requiredDuringSchedulingIgnoredDuringExecution的 pod。
-
TopologyAndDuplicates此配置集会驱除 pod 以努力在节点间平均分配类似的 pod 或相同拓扑域的 pod。
它启用了以下策略：
-
RemovePodsViolatingTopologySpreadConstraint：找到未平衡的拓扑域，并在DoNotSchedule约束被违反时尝试从较大的 pod 驱除 pod。 -
RemoveDuplicates：确保只有一个 pod 与同一节点上运行的副本集、复制控制器、部署或作业相关联。如果存在多个重复的 pod，则这些重复的 pod 会被驱除以更好地在集群中的 pod 分布。
-
LifecycleAndUtilization此配置集驱除长时间运行的 pod，并平衡节点之间的资源使用情况。
它启用了以下策略：
RemovePodsHavingTooManyRestarts：移除容器重启次数过多的 pod。所有容器（包括初始容器）重启总和大于 100 个的 Pod。
LowNodeUtilization：查找使用率不足的节点，并在可能的情况下从其他过度使用的节点中驱除 pod，以希望这些被驱除的 pod 可以在使用率低的节点上被重新创建。如果节点的用量低于 20%（CPU、内存和 pod 的数量）,则该节点将被视为使用率不足。
如果节点的用量超过 50%（CPU、内存和 pod 的数量）,则该节点将被视为过量使用。
PodLifeTime：驱除太老的 pod。移除时间超过 24 小时的 Pod。
3.11.3. 安装 descheduler
在默认情况下，不提供 descheduler。要启用 descheduler，您必须从 OperatorHub 安装 Kube Descheduler Operator，并启用一个或多个 descheduler 配置集。
先决条件
- 必须具有集群管理员权限。
- 访问 OpenShift Container Platform Web 控制台。
流程
- 登陆到 OpenShift Container Platform Web 控制台。
为 Kube Descheduler Operator 创建所需的命名空间。
- 进行 Administration → Namespaces，点 Create Namespace。
-
在 Name 字段中输入
openshift-kube-descheduler-operator，点 Create。
安装 Kube Descheduler Operator。
- 进入 Operators → OperatorHub。
- 在过滤框中输入 Kube Descheduler Operator。
- 选择 Kube Descheduler Operator 并点 Install。
- 在 Install Operator 页面中，选择 A specific namespace on the cluster。从下拉菜单中选择 openshift-kube-descheduler-operator 。
- 将 Update Channel 和 Approval Strategy 的值调整为所需的值。
- 点击 Install。
创建 descheduler 实例。
- 在 Operators → Installed Operators 页面中，点 Kube Descheduler Operator。
- 选择 Kube Descheduler 标签页并点 Create KubeDescheduler。
根据需要编辑设置。
-
展开 Profiles 部分，以选择要启用的一个或多个配置文件。
AffinityAndTaints配置集默认启用。单击 Add Profile 以选择其他配置文件。 -
可选： 使用 Descheduling Interval Seconds 字段更改 descheduler 运行间隔的秒数。默认值为
3600秒。
-
展开 Profiles 部分，以选择要启用的一个或多个配置文件。
- 点击 Create。
您还可以使用 OpenShift CLI(oc)稍后为 descheduler 配置配置集和设置。如果您在从 web 控制台创建 descheduler 实例时没有调整配置集，则默认启用 AffinityAndTaints 配置集。
3.11.4. 配置 descheduler 配置集
您可以配置 descheduler 使用哪些配置集来驱除 pod。
先决条件
- 集群管理员特权
流程
编辑
KubeDescheduler对象：oc edit kubedeschedulers.operator.openshift.io cluster -n openshift-kube-descheduler-operator
$ oc edit kubedeschedulers.operator.openshift.io cluster -n openshift-kube-descheduler-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow 在
spec.profiles部分指定一个或多个配置集。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 您可以启用多个配置集 ; 指定配置集的顺序并不重要。
- 保存文件以使改变生效。
3.11.5. 配置 descheduler 间隔
您可以配置 descheduler 运行之间的时间长度。默认为 3600 秒（一小时）。
先决条件
- 集群管理员特权
流程
编辑
KubeDescheduler对象：oc edit kubedeschedulers.operator.openshift.io cluster -n openshift-kube-descheduler-operator
$ oc edit kubedeschedulers.operator.openshift.io cluster -n openshift-kube-descheduler-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow 将
deschedulingIntervalSeconds字段更新为所需的值：Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 设置 descheduler 运行间隔的秒数。如果设为
0，则 descheduler 会运行一次并退出。
- 保存文件以使改变生效。
3.11.6. 卸载 descheduler
您可以通过删除 descheduler 实例并卸载 Kube Descheduler Operator 从集群中移除 descheduler。此流程还会清理 KubeDescheduler CRD 和 openshift-kube-descheduler-operator 命名空间。
先决条件
- 必须具有集群管理员权限。
- 访问 OpenShift Container Platform Web 控制台。
流程
- 登陆到 OpenShift Container Platform Web 控制台。
删除 descheduler 实例。
- 在 Operators → Installed Operators 页面中，点 Kube Descheduler Operator。
- 选择 Kube Descheduler 选项卡。
-
点 集群 条目旁的 Options 菜单
并选择 Delete KubeDescheduler。
- 在确认对话框中，点 Delete。
卸载 Kube Descheduler Operator。
- 导航到 Operators → Installed Operators，
-
点 Kube Descheduler Operator 条目
旁边的 Options 菜单，然后选择 Uninstall Operator。
- 在确认对话框中，点 Uninstall。
删除
openshift-kube-descheduler-operator命名空间。- 导航至 Administration → Namespaces。
-
在过滤器框中输入
openshift-kube-descheduler-operator。 -
点 openshift-kube-descheduler-operator 条目旁的 Options 菜单
，然后选择 Delete Namespace。
-
在确认对话框中，输入
openshift-kube-descheduler-operator并点 Delete。
删除
KubeDeschedulerCRD。- 进入 Administration → Custom Resource Definitions。
-
在过滤器框中输入
KubeDescheduler。 -
点 KubeDescheduler 条目旁的 Options 菜单
，然后选择 Delete CustomResourceDefinition。
- 在确认对话框中，点 Delete。
第 4 章 使用作业和 DaemonSet
4.1. 使用 daemonset 在节点上自动运行后台任务
作为管理员，您可以创建并使用守护进程集在 OpenShift Container Platform 集群的特定节点或所有节点上运行 pod 副本。
守护进程集确保所有（或部分）节点都运行 pod 的副本。当节点添加到集群中时，pod 也会添加到集群中。当节点从集群中移除时，这些 pod 也会通过垃圾回收而被移除。删除守护进程集会清理它创建的 pod。
您可以使用 daemonset 创建共享存储，在集群的每一节点上运行日志 pod，或者在每个节点上部署监控代理。
为安全起见，只有集群管理员才能创建守护进程集。
如需有关守护进程集的更多信息，请参阅 Kubernetes 文档。
守护进程集调度与项目的默认节点选择器不兼容。如果您没有禁用它，守护进程集会与默认节点选择器合并，从而受到限制。这会造成在合并后节点选择器没有选中的节点上频繁地重新创建 pod，进而给集群带来意外的负载。
4.1.1. 通过默认调度程序调度
守护进程集确保所有有资格的节点都运行 pod 的副本。通常，Kubernetes 调度程序会选择要在其上运行 pod 的节点。但是，以前守护进程集 pod 由守护进程集控制器创建并调度。这会引发以下问题：
-
pod 行为不一致：等待调度的普通 pod 被创建好并处于待处理状态，但守护进程集 pod 没有以
待处理的状态创建。这会给用户造成混淆。 - Pod 抢占由默认调度程序处理。启用抢占后，守护进程集控制器将在不考虑 pod 优先级和抢占的前提下做出调度决策。
OpenShift Container Platform 中默认启用 ScheduleDaemonSetPods 功能允许您使用默认调度程序而不是守护进程集控制器来调度守护进程集，具体方法是添加 NodeAffinity 术语到守护进程集 pod，而不是 .spec.nodeName 术语。然后，默认调度程序用于将 pod 绑定到目标主机。如果守护进程集的节点关联性已经存在，它会被替换掉。守护进程设置控制器仅在创建或修改守护进程集 pod 时执行这些操作，且不会对守护进程集的 spec.template 进行任何更改。
另外，node.kubernetes.io/unschedulable:NoSchedule 容限会自动添加到守护进程设置 Pod 中。在调度守护进程设置 pod 时，默认调度程序会忽略不可调度的节点。
4.1.2. 创建 daemonset
在创建守护进程集时，使用 nodeSelector 字段来指示守护进程集应在其上部署副本的节点。
先决条件
在开始使用守护进程集之前，通过将命名空间注解
openshift.io/node-selector设置为空字符串来禁用命名空间中的默认项目范围节点选择器：oc patch namespace myproject -p \ '{"metadata": {"annotations": {"openshift.io/node-selector": ""}}}'$ oc patch namespace myproject -p \ '{"metadata": {"annotations": {"openshift.io/node-selector": ""}}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 如果您要创建新项目，请覆盖默认节点选择器：
`oc adm new-project <name> --node-selector=""`.
`oc adm new-project <name> --node-selector=""`.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
流程
创建守护进程集：
定义守护进程集 yaml 文件：
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 创建守护进程集对象：
oc create -f daemonset.yaml
$ oc create -f daemonset.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 验证 pod 是否已创建好，并且每个节点都有 pod 副本：
查找 daemonset pod：
oc get pods
$ oc get podsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
hello-daemonset-cx6md 1/1 Running 0 2m hello-daemonset-e3md9 1/1 Running 0 2m
hello-daemonset-cx6md 1/1 Running 0 2m hello-daemonset-e3md9 1/1 Running 0 2mCopy to Clipboard Copied! Toggle word wrap Toggle overflow 查看 pod 以验证 pod 已放置到节点上：
oc describe pod/hello-daemonset-cx6md|grep Node
$ oc describe pod/hello-daemonset-cx6md|grep NodeCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Node: openshift-node01.hostname.com/10.14.20.134
Node: openshift-node01.hostname.com/10.14.20.134Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc describe pod/hello-daemonset-e3md9|grep Node
$ oc describe pod/hello-daemonset-e3md9|grep NodeCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例
Node: openshift-node02.hostname.com/10.14.20.137
Node: openshift-node02.hostname.com/10.14.20.137Copy to Clipboard Copied! Toggle word wrap Toggle overflow
- 如果更新守护进程设置的 pod 模板，现有的 pod 副本不会受到影响。
- 如果您删除了守护进程集，然后在创建新守护进程集时使用不同的模板和相同的标签选择器，它会将现有 pod 副本识别为具有匹配的标签，因而不更新它们，也不会创建新的副本，尽管 pod 模板中存在不匹配。
- 如果您更改了节点标签，守护进程集会把 pod 添加到与新标签匹配的节点，并从不匹配新标签的节点中删除 pod。
要更新守护进程集，请通过删除旧副本或节点来强制创建新的 pod 副本。
4.2. 使用任务在 Pod 中运行任务
作业（job）在 OpenShift Container Platform 集群中执行某项任务。
作业会跟踪任务的整体进度，并使用活跃、成功和失败 pod 的相关信息来更新其状态。删除作业会清理它创建的所有 pod 副本。作业是 Kubernetes API 的一部分，可以像其他对象类型一样通过 oc 命令进行管理。
作业规格示例
如需有关作业的更多信息，请参阅 Kubernetes 文档。
4.2.1. 了解作业和 cron 作业
作业会跟踪任务的整体进度，并使用活跃、成功和失败 pod 的相关信息来更新其状态。删除作业会清理它创建的所有 pod。作业是 Kubernetes API 的一部分，可以像其他对象类型一样通过 oc 命令进行管理。
OpenShift Container Platform 中有两种资源类型可以创建只运行一次的对象：
- 作业
- 常规作业是一种只运行一次的对象，它会创建一个任务并确保作业完成。
有三种适合作为作业运行的任务类型：
非并行作业：
- 仅启动一个 pod 的作业，除非 pod 失败。
- 一旦 pod 成功终止，作业就会马上完成。
带有固定完成计数的并行作业：
- 启动多个 pod 的作业。
-
Job 代表整个任务，并在
1到completions范围内的每个值都有一个成功 pod 时完成 。
带有工作队列的并行作业：
- 在一个给定 pod 中具有多个并行 worker 进程的作业。
- OpenShift Container Platform 协调 pod，以确定每个 pod 都应该使用什么作业，或使用一个外部队列服务。
- 每个 pod 都可以独立决定是否所有对等 pod 都已完成（整个作业完成）。
- 当所有来自作业的 pod 都成功终止时，不会创建新的 pod。
- 当至少有一个 pod 成功终止并且所有 pod 都终止时，作业成功完成。
- 当任何 pod 成功退出时，其他 pod 都不应该为这个任务做任何工作或写任何输出。Pod 都应该处于退出过程中。
如需有关如何使用不同类型的作业的更多信息，请参阅 Kubernetes 文档中的作业模式 。
- Cron job
- 通过使用 Cron Job，一个作业可以被调度为运行多次。
Cron Job 基于常规作业构建，允许您指定作业的运行方式。Cron job 是 Kubernetes API 的一部分，可以像其他对象类型一样通过 oc 命令进行管理。
Cron Job 可用于创建周期性和重复执行的任务，如运行备份或发送电子邮件。Cron Job 也可以将个别任务调度到指定时间执行，例如，将一个作业调度到低活动时段执行。一个 cron 作业会创建一个 Job 对象，它基于在运行 cronjob 的 control plane 节点上配置的时区。
Cron Job 大致会在调度的每个执行时间创建一个 Job 对象，但在有些情况下，它可能无法创建作业，或者可能会创建两个作业。因此，作业必须具有幂等性，而且您必须配置历史限制。
4.2.1.1. 了解如何创建作业
两种资源类型都需要一个由以下关键部分组成的作业配置：
- pod 模板，用于描述 OpenShift Container Platform 创建的 pod。
parallelism参数，用于指定在任意时间点上应并行运行多少个 pod 来执行某个作业。-
对于非并行作业，请保留未设置。当取消设置时，默认为
1。
-
对于非并行作业，请保留未设置。当取消设置时，默认为
completions参数，用于指定需要成功完成多少个 pod 才能完成某个作业。-
对于非并行作业，请保留未设置。当取消设置时，默认为
1。 - 对于带有固定完成计数的并行作业，请指定一个值。
-
对于带有工作队列的并行作业，请保留 unset。当取消设置默认为
parallelism值。
-
对于非并行作业，请保留未设置。当取消设置时，默认为
4.2.1.2. 了解如何为作业设置最长持续时间
在定义作业时，您可以通过设置 activeDeadlineSeconds 字段来定义其最长持续时间。以秒为单位指定，默认情况下不设置。若未设置，则不强制执行最长持续时间。
最长持续时间从系统中调度第一个 pod 的时间开始计算，并且定义作业在多久时间内处于活跃状态。它将跟踪整个执行时间。达到指定的超时后，OpenShift Container Platform 将终止作业。
4.2.1.3. 了解如何为 pod 失败设置作业避退策略
在因为配置中的逻辑错误或其他类似原因而重试了一定次数后，作业会被视为已经失败。控制器以六分钟为上限，按指数避退延时（10s，20s，40s …）重新创建与作业关联的失败 pod。如果控制器检查之间没有出现新的失败 pod，则重置这个限制。
使用 spec.backoffLimit 参数为作业设置重试次数。
4.2.1.4. 了解如何配置 Cron Job 以移除工件
Cron Job 可能会遗留工件资源，如作业或 pod 等。作为用户，务必要配置一个历史限制，以便能妥善清理旧作业及其 pod。Cron Job 规格内有两个字段负责这一事务：
-
.spec.successfulJobsHistoryLimit。要保留的成功完成作业数（默认为 3）。 -
.spec.failedJobsHistoryLimit。要保留的失败完成作业数（默认为 1）。
删除您不再需要的 Cron Job：
oc delete cronjob/<cron_job_name>
$ oc delete cronjob/<cron_job_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 这样可防止生成不必要的工件。
-
您可以通过将
spec.suspend设置为 true 来挂起后续执行。所有后续执行都会挂起，直到重置为false。
4.2.1.5. 已知限制
作业规格重启策略只适用于 pod，不适用于作业控制器。不过，作业控制器被硬编码为可以一直重试直到作业完成为止。
因此，restartPolicy: Never 或 --restart=Never 会产生与 restartPolicy: OnFailure 或 --restart=OnFailure 相同的行为。也就是说，作业失败后会自动重启，直到成功（或被手动放弃）为止。策略仅设定由哪一子系统执行重启。
使用 Never 策略时，作业控制器负责执行重启。在每次尝试时，作业控制器会在作业状态中递增失败次数并创建新的 pod。这意味着，每次尝试失败都会增加 pod 的数量。
使用 OnFailure 策略时，kubelet 负责执行重启。每次尝试都不会在作业状态中递增失败次数。另外，kubelet 将通过在相同节点上启动 pod 来重试失败的作业。