6.11. 为 OpenShift Container Platform 集群中的节点分配资源
为提供更可靠的调度并最大程度减少节点资源过量使用,请保留一部分 CPU 和内存资源供底层节点组件(如 kubelet
和 kube-proxy
)以及其余系统组件(如 sshd
和 NetworkManager
)使用。通过指定要保留的资源,您可以为调度程序提供有关节点可用于 pod 使用的剩余 CPU 和内存资源的更多信息。您可以允许 OpenShift Container Platform 自动决定节点的最佳 system-reserved
CPU 和内存资源,或您可以针对您的节点手动决定并为节点设置最佳资源。
要手动设置资源值,您必须使用 kubelet 配置 CR。您不能使用机器配置 CR。
6.11.1. 了解如何为节点分配资源
OpenShift Container Platform 中为节点组件保留的 CPU 和内存资源基于两个节点设置:
设置 | 描述 |
---|---|
|
此设置不会用于 OpenShift Container Platform。将您要保留的 CPU 和内存资源添加到 |
|
此设置标识要为节点组件和系统组件(如 CRI-O 和 Kubelet)保留的资源。默认设置取决于 OpenShift Container Platform 和 Machine Config Operator 版本。确认 |
如果没有设置标志,则使用默认值。如果未设置任何标记,则分配的资源设置为引入可分配资源前的节点容量。
任何使用 reservedSystemCPUs
参数特别保留的 CPU 都无法使用 kube-reserved
或 system-reserved
进行分配。
6.11.1.1. OpenShift Container Platform 如何计算分配的资源
分配的资源数量根据以下公式来计算:
[Allocatable] = [Node Capacity] - [system-reserved] - [Hard-Eviction-Thresholds]
Allocatable
提供的 Hard-Eviction-Thresholds
可提高系统可靠性,因为 Allocatable
的值在节点级别强制实施。
如果 Allocatable
为负值,它会被设为 0
。
每个节点报告容器运行时和 kubelet 使用的系统资源。为简化配置 system-reserved
参数,请使用节点概述 API 查看用于节点的资源。节点概述位于 /api/v1/nodes/<node\" /proxy/stats/summary
。
6.11.1.2. 节点如何强制实施资源限制
节点可以根据配置的可分配值限制 pod 可消耗的资源总量。此功能可以防止 pod 使用系统服务(如容器运行时和节点代理)所需的 CPU 和内存资源,从而显著提高节点可靠性。为提高节点可靠性,管理员应该根据目标保留资源使用。
节点使用一个新的 cgroup 分级结构来强制实施对资源的约束。它可以强制实现对服务质量的要求。所有 pod 都在专用的 cgroup 层次结构中启动,与系统守护进程隔离。
管理员应该像对待具有保证服务质量的 pod 一样对待系统守护进程。系统守护进程可能会在其限定控制组中爆发,此行为需要作为集群部署的一个部分进行管理。通过在 system-reserved
中指定 CPU 和内存资源量,为系统守护进程保留 CPU 和内存资源。
强制实施 system-reserved
限制可防止关键系统服务接收 CPU 和内存资源。因此,关键系统服务可能会被内存不足 killer 结束。我们的建议是,只在您为节点进行了详细配置后,强制实施 system-reserved
,且您可以确定,如果关键系统服务因为该组中的任何进程导致内存不足 killer 终止它时,可以恢复。
6.11.1.3. 了解驱除阈值
如果某个节点面临内存压力,这可能会影响整个节点以及该节点上运行的所有 pod。例如,使用超过保留内存量的系统守护进程可触发内存不足事件。为避免系统耗尽或降低内存不足事件的可能性,节点会提供处理资源不足情况的功能。
您可以使用 --eviction-hard
标记保留一些内存。每当节点上的内存可用量低于该绝对值或百分比时,节点会尝试驱除 pod。如果节点上没有系统守护进程,pod 的内存会被限制在 capacity - eviction-hard
内。因此,pod 不能使用作为达到内存不足状态前驱除缓冲量而预留的资源。
下例演示了节点内存可分配量的影响:
-
节点容量为
32Gi
-
--system-reserved 为
3Gi
-
--eviction-hard 设置为
100Mi
。
对于这个节点,有效节点可分配量的值是 28.9Gi
。如果节点和系统组件使用其所有保留量,则 pod 的可用内存为 28.9Gi
,并且 kubelet 会在超过这个阈值时驱除 pod。
如果您通过顶级 cgroup 强制实施节点可分配量 (28.9Gi
),那么 pod 永不会超过 28.9Gi
。除非系统守护进程消耗的内存超过 3.1Gi
,否则不会执行驱除。
如果系统守护进程没有用尽其所有保留量,那么在上例中,pod 会在节点开始驱除前面临被其限定 cgroup 执行 memcg OOM 终止的问题。为了在这种情况下更好地强制实施 QoS,节点会对所有 pod 的顶级 cgroup 应用硬驱除阈值,即 Node Allocatable + Eviction Hard Thresholds
。
如果系统守护进程没有用尽所有保留量,每当 pod 消耗的内存超过 28.9Gi
时,节点就会驱除 pod。如果不及时驱除,消耗的内存超过 29Gi
时就会对 pod 执行 OOM 终止。
6.11.1.4. 调度程序如何确定资源可用性
调度程序使用 node.Status.Allocatable
(而非 node.Status.Capacity
)的值来决定节点是否成为 pod 调度的候选者。
在默认情况下,节点会将其机器容量报告为可完全被集群调度。
6.11.2. 自动为节点分配资源
OpenShift Container Platform 可以自动决定与特定机器配置池关联的节点的最佳 system-reserved
CPU 和内存资源,并在节点启动时使用这些值更新节点。默认情况下,system-reserved
CPU 为 500m
,system-reserved
内存为 1Gi
。
要在节点上自动决定并分配 system-reserved
资源,请创建一个 KubeletConfig
自定义资源(CR)来设置 autoSizingReserved: true
参数。各个节点上的脚本根据每个节点上安装的 CPU 和内存容量,计算相应保留资源的最佳值。该脚本考虑了增加的容量要求保留资源的相应增加。
自动确定最佳的 system-reserved
设置可确保集群高效运行,并防止因为 CRI-O 和 kubelet 等系统组件的资源丢失而出现节点故障,而无需手动计算和更新值。
此功能默认为禁用。
先决条件
输入以下命令为您要配置的节点类型获取与静态
MachineConfigPool
对象关联的标签:$ oc edit machineconfigpool <name>
例如:
$ oc edit machineconfigpool worker
输出示例
apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfigPool metadata: creationTimestamp: "2022-11-16T15:34:25Z" generation: 4 labels: pools.operator.machineconfiguration.openshift.io/worker: "" 1 name: worker #...
- 1
- 标签会出现在
Labels
下。
提示如果没有适当的标签,请添加键/值对,例如:
$ oc label machineconfigpool worker custom-kubelet=small-pods
流程
为配置更改创建自定义资源(CR):
资源分配 CR 的示例配置
apiVersion: machineconfiguration.openshift.io/v1 kind: KubeletConfig metadata: name: dynamic-node 1 spec: autoSizingReserved: true 2 machineConfigPoolSelector: matchLabels: pools.operator.machineconfiguration.openshift.io/worker: "" 3 #...
前面的示例在所有 worker 节点上启用自动资源分配。OpenShift Container Platform 排空节点、应用 kubelet 配置并重启节点。
运行以下命令来创建 CR:
$ oc create -f <file_name>.yaml
验证
输入以下命令登录到您配置的节点:
$ oc debug node/<node_name>
将
/host
设置为 debug shell 中的根目录:# chroot /host
查看
/etc/node-sizing.env
文件:输出示例
SYSTEM_RESERVED_MEMORY=3Gi SYSTEM_RESERVED_CPU=0.08
kubelet 使用
/etc/node-sizing.env
文件中的system-reserved
值。在上例中,worker 节点分配了0.08
CPU 和 3 Gi 内存。显示最佳值可能需要几分钟时间。
6.11.3. 手动为节点分配资源
OpenShift Container Platform 支持对 CPU 和内存资源类型执行分配。还支持 ephemeral-resource
资源类型。对于 cpu
类型,您可以以内核数为单位指定资源数量,如 200m
、0.5
或 1
。对于 memory
和 ephemeral-storage
,您可以指定资源数量(以字节为单位),如 200Ki
、50Mi
或 5Gi
。默认情况下,system-reserved
CPU 为 500m
,system-reserved
内存为 1Gi
。
作为管理员,您可以通过一组 <resource_type>=<resource_quantity>
对(如 cpu=200m,memory=512Mi
)来设置这些值。
您必须使用 kubelet 配置 CR 来手动设置资源值。您不能使用机器配置 CR。
有关推荐的 system-reserved
值的详情,请参考推荐的 system-reserved 值。
先决条件
输入以下命令为您要配置的节点类型获取与静态
MachineConfigPool
CRD 关联的标签:$ oc edit machineconfigpool <name>
例如:
$ oc edit machineconfigpool worker
输出示例
apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfigPool metadata: creationTimestamp: "2022-11-16T15:34:25Z" generation: 4 labels: pools.operator.machineconfiguration.openshift.io/worker: "" 1 name: worker #...
- 1
- 标签会出现在 Labels 下。
提示如果标签不存在,请添加键/值对,例如:
$ oc label machineconfigpool worker custom-kubelet=small-pods
流程
为配置更改创建自定义资源 (CR)。
资源分配 CR 的示例配置
apiVersion: machineconfiguration.openshift.io/v1 kind: KubeletConfig metadata: name: set-allocatable 1 spec: machineConfigPoolSelector: matchLabels: pools.operator.machineconfiguration.openshift.io/worker: "" 2 kubeletConfig: systemReserved: 3 cpu: 1000m memory: 1Gi #...
运行以下命令来创建 CR:
$ oc create -f <file_name>.yaml