将您的集群配置为在超额分配节点上放置 Pod - 使用集群 | 节点 | OpenShift Container Platform 4.17

资源请求和超额分配
使用集群资源覆盖运算符进行集群级别超额分配
节点级别超额分配
项目级限制
- 禁用项目的超额分配
其他资源

在超额分配状态下，容器计算资源请求和限制的总和超过系统可用资源。例如，您可能希望在开发环境中使用超额分配，在这种环境中，可以接受以牺牲保证的性能为代价来换取容量。

容器可以指定计算资源请求和限制。请求用于调度您的容器并提供最低服务保证。限制会约束在节点上可以消耗的计算资源量。

调度程序尝试优化集群中所有节点的计算资源使用情况。它将 Pod 放置到特定节点上，同时考虑 Pod 的计算资源请求和节点的可用容量。

OpenShift Container Platform 管理员可以控制超额分配的级别并管理节点上的容器密度。您可以使用集群资源覆盖运算符配置集群级别超额分配，以覆盖在开发人员容器上设置的请求和限制之间的比率。结合节点超额分配，您可以调整资源限制和请求以达到所需的超额分配级别。

在 OpenShift Container Platform 中，您必须启用集群级别超额分配。节点超额分配默认启用。请参阅禁用节点的超额分配。

资源请求和超额分配

对于每个计算资源，容器可以指定资源请求和限制。调度决策是根据请求做出的，以确保节点有足够的可用容量来满足请求的值。如果容器指定了限制，但省略了请求，则请求将默认为限制。容器无法超过节点上指定的限制。

限制的执行取决于计算资源类型。如果容器没有请求或限制，则容器将调度到没有资源保证的节点。实际上，容器能够消耗尽可能多的指定资源，而具有最低的本地优先级。在资源不足的情况下，未指定资源请求的容器将获得最低的服务质量。

调度基于请求的资源，而配额和硬限制指的是资源限制，可以将其设置为高于请求的资源。请求和限制之间的差异决定了超额分配的级别；例如，如果容器获得 1Gi 的内存请求和 2Gi 的内存限制，则它基于节点上可用的 1Gi 请求进行调度，但可以使用高达 2Gi；因此，它被超额分配了 200%。

使用集群资源覆盖运算符进行集群级别超额分配

集群资源覆盖运算符是一个准入 Webhook，允许您控制超额分配的级别并管理集群中所有节点的容器密度。该运算符控制特定项目中的节点如何超过定义的内存和 CPU 限制。

您必须按照以下部分所示，使用 OpenShift Container Platform 控制台或 CLI 安装集群资源覆盖运算符。在安装过程中，您将创建一个ClusterResourceOverride自定义资源 (CR)，您可以在其中设置超额分配的级别，如下例所示

apiVersion: operator.autoscaling.openshift.io/v1
kind: ClusterResourceOverride
metadata:
    name: cluster (1)
spec:
  podResourceOverride:
    spec:
      memoryRequestToLimitPercent: 50 (2)
      cpuRequestToLimitPercent: 25 (3)
      limitCPUToMemoryPercent: 200 (4)
# ...

1	名称必须为`cluster`。
2	可选。如果已指定或默认为容器内存限制，则将内存请求覆盖为限制的此百分比，范围为 1-100。默认为 50。
3	可选。如果已指定或默认为容器 CPU 限制，则将 CPU 请求覆盖为限制的此百分比，范围为 1-100。默认为 25。
4	可选。如果已指定或默认为容器内存限制，则如果已指定，则将 CPU 限制覆盖为内存限制的百分比。以 100% 的比例缩放 1Gi 的 RAM 等于 1 个 CPU 内核。这在覆盖 CPU 请求（如果已配置）之前进行处理。默认为 200。

如果容器未设置限制，则集群资源覆盖操作符的覆盖无效。请创建带有每个项目的默认限制的LimitRange对象，或在Pod规范中配置限制，以便覆盖生效。

配置后，可以通过为每个项目的 Namespace 对象应用以下标签来启用每个项目的覆盖：

apiVersion: v1
kind: Namespace
metadata:

# ...

  labels:
    clusterresourceoverrides.admission.autoscaling.openshift.io/enabled: "true"

# ...

操作符监视ClusterResourceOverride CR，并确保ClusterResourceOverride 准入 Webhook 安装在与操作符相同的命名空间中。

使用 Web 控制台安装集群资源覆盖操作符

您可以使用 OpenShift Container Platform CLI 安装集群资源覆盖操作符，以帮助控制集群中的超额使用。

默认情况下，安装过程会在clusterresourceoverride-operator命名空间中的工作节点上创建一个集群资源覆盖操作符 Pod。您可以根据需要将此 Pod 移动到其他节点，例如基础设施节点。基础设施节点不计入运行环境所需的订阅总数。有关更多信息，请参见“移动集群资源覆盖操作符 Pod”。

先决条件

如果容器未设置限制，则集群资源覆盖操作符无效。您必须使用LimitRange对象为项目指定默认限制，或在Pod规范中配置限制才能应用覆盖。

步骤

要使用 OpenShift Container Platform Web 控制台安装集群资源覆盖操作符：

在 OpenShift Container Platform Web 控制台中，导航到主页 → 项目
1. 点击创建项目。
2. 指定clusterresourceoverride-operator作为项目的名称。
3. 点击创建。
导航到操作符 → OperatorHub。
1. 从可用操作符列表中选择ClusterResourceOverride Operator，然后点击安装。
2. 在安装操作符页面上，确保为安装模式选择了集群上的特定命名空间。
3. 确保为已安装命名空间选择了clusterresourceoverride-operator。
4. 选择更新通道和批准策略。
5. 点击安装。

在已安装操作符页面上，点击ClusterResourceOverride。

在ClusterResourceOverride Operator详细信息页面上，点击创建 ClusterResourceOverride。

在创建 ClusterResourceOverride页面上，点击YAML 视图并编辑 YAML 模板以根据需要设置超额使用值

apiVersion: operator.autoscaling.openshift.io/v1
kind: ClusterResourceOverride
metadata:
  name: cluster (1)
spec:
  podResourceOverride:
    spec:
      memoryRequestToLimitPercent: 50 (2)
      cpuRequestToLimitPercent: 25 (3)
      limitCPUToMemoryPercent: 200 (4)

1	名称必须为`cluster`。
2	可选：如果使用，请指定覆盖容器内存限制的百分比（1-100）。默认为`50`。
3	可选：如果使用，请指定覆盖容器 CPU 限制的百分比（1-100）。默认为`25`。
4	可选：如果使用，请指定覆盖容器内存限制的百分比。以 100% 的比例扩展 1 Gi RAM 等于 1 个 CPU 内核。如果配置了此项，则会在覆盖 CPU 请求之前进行处理。默认为`200`。

点击创建。

通过检查集群自定义资源的状态来检查准入 Webhook 的当前状态

在ClusterResourceOverride Operator页面上，点击集群。

在ClusterResourceOverride 详情页面上，点击YAML。调用 Webhook 时，会出现mutatingWebhookConfigurationRef部分。

apiVersion: operator.autoscaling.openshift.io/v1
kind: ClusterResourceOverride
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"operator.autoscaling.openshift.io/v1","kind":"ClusterResourceOverride","metadata":{"annotations":{},"name":"cluster"},"spec":{"podResourceOverride":{"spec":{"cpuRequestToLimitPercent":25,"limitCPUToMemoryPercent":200,"memoryRequestToLimitPercent":50}}}}
  creationTimestamp: "2019-12-18T22:35:02Z"
  generation: 1
  name: cluster
  resourceVersion: "127622"
  selfLink: /apis/operator.autoscaling.openshift.io/v1/clusterresourceoverrides/cluster
  uid: 978fc959-1717-4bd1-97d0-ae00ee111e8d
spec:
  podResourceOverride:
    spec:
      cpuRequestToLimitPercent: 25
      limitCPUToMemoryPercent: 200
      memoryRequestToLimitPercent: 50
status:

# ...

    mutatingWebhookConfigurationRef: (1)
      apiVersion: admissionregistration.k8s.io/v1
      kind: MutatingWebhookConfiguration
      name: clusterresourceoverrides.admission.autoscaling.openshift.io
      resourceVersion: "127621"
      uid: 98b3b8ae-d5ce-462b-8ab5-a729ea8f38f3

# ...

1	对`ClusterResourceOverride`准入 Webhook 的引用。

其他资源

移动集群资源覆盖运算符 Pod

使用 CLI 安装集群资源覆盖操作符

您可以使用 OpenShift Container Platform CLI 安装集群资源覆盖操作符，以帮助控制集群中的超额使用。

先决条件

如果容器未设置限制，则集群资源覆盖操作符无效。您必须使用LimitRange对象为项目指定默认限制，或在Pod规范中配置限制才能应用覆盖。

步骤

要使用 CLI 安装集群资源覆盖操作符：

为集群资源覆盖操作符创建一个命名空间
1. 为集群资源覆盖操作符创建一个Namespace对象 YAML 文件（例如，cro-namespace.yaml）
  apiVersion: v1 kind: Namespace metadata: name: clusterresourceoverride-operator
2. 创建命名空间
  $ oc create -f <file-name>.yaml
  例如
  $ oc create -f cro-namespace.yaml

创建操作符组

为集群资源覆盖操作符创建一个OperatorGroup对象 YAML 文件（例如，cro-og.yaml）

apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: clusterresourceoverride-operator
  namespace: clusterresourceoverride-operator
spec:
  targetNamespaces:
    - clusterresourceoverride-operator

创建操作符组

$ oc create -f <file-name>.yaml

例如

$ oc create -f cro-og.yaml

创建订阅

为集群资源覆盖操作符创建一个Subscription对象 YAML 文件（例如，cro-sub.yaml）

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: clusterresourceoverride
  namespace: clusterresourceoverride-operator
spec:
  channel: "4.17"
  name: clusterresourceoverride
  source: redhat-operators
  sourceNamespace: openshift-marketplace

创建订阅

$ oc create -f <file-name>.yaml

例如

$ oc create -f cro-sub.yaml

在clusterresourceoverride-operator命名空间中创建一个ClusterResourceOverride自定义资源 (CR) 对象

切换到clusterresourceoverride-operator命名空间。
```
$ oc project clusterresourceoverride-operator
```

为集群资源覆盖操作符创建一个ClusterResourceOverride对象 YAML 文件（例如，cro-cr.yaml）

apiVersion: operator.autoscaling.openshift.io/v1
kind: ClusterResourceOverride
metadata:
    name: cluster (1)
spec:
  podResourceOverride:
    spec:
      memoryRequestToLimitPercent: 50 (2)
      cpuRequestToLimitPercent: 25 (3)
      limitCPUToMemoryPercent: 200 (4)

1	名称必须为`cluster`。
2	可选：如果使用，请指定覆盖容器内存限制的百分比（1-100）。默认为`50`。
3	可选：如果使用，请指定覆盖容器 CPU 限制的百分比（1-100）。默认为`25`。
4	可选：如果使用，请指定覆盖容器内存限制的百分比。以 100% 的比例扩展 1 Gi RAM 等于 1 个 CPU 内核。如果配置了此项，则会在覆盖 CPU 请求之前进行处理。默认为`200`。

创建ClusterResourceOverride对象

$ oc create -f <file-name>.yaml

例如

$ oc create -f cro-cr.yaml

通过检查集群自定义资源的状态来验证准入 Webhook 的当前状态。

$ oc get clusterresourceoverride cluster -n clusterresourceoverride-operator -o yaml

调用 Webhook 时，会出现mutatingWebhookConfigurationRef部分。

示例输出

apiVersion: operator.autoscaling.openshift.io/v1
kind: ClusterResourceOverride
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"operator.autoscaling.openshift.io/v1","kind":"ClusterResourceOverride","metadata":{"annotations":{},"name":"cluster"},"spec":{"podResourceOverride":{"spec":{"cpuRequestToLimitPercent":25,"limitCPUToMemoryPercent":200,"memoryRequestToLimitPercent":50}}}}
  creationTimestamp: "2019-12-18T22:35:02Z"
  generation: 1
  name: cluster
  resourceVersion: "127622"
  selfLink: /apis/operator.autoscaling.openshift.io/v1/clusterresourceoverrides/cluster
  uid: 978fc959-1717-4bd1-97d0-ae00ee111e8d
spec:
  podResourceOverride:
    spec:
      cpuRequestToLimitPercent: 25
      limitCPUToMemoryPercent: 200
      memoryRequestToLimitPercent: 50
status:

# ...

    mutatingWebhookConfigurationRef: (1)
      apiVersion: admissionregistration.k8s.io/v1
      kind: MutatingWebhookConfiguration
      name: clusterresourceoverrides.admission.autoscaling.openshift.io
      resourceVersion: "127621"
      uid: 98b3b8ae-d5ce-462b-8ab5-a729ea8f38f3

# ...

1	对`ClusterResourceOverride`准入 Webhook 的引用。

其他资源

移动集群资源覆盖运算符 Pod

配置集群级超额使用

集群资源覆盖操作符需要一个ClusterResourceOverride自定义资源 (CR) 和一个标签，用于您希望操作符控制超额使用的每个项目。

默认情况下，安装过程会在clusterresourceoverride-operator命名空间中的控制平面节点上创建两个集群资源覆盖 Pod。您可以根据需要将这些 Pod 移动到其他节点，例如基础设施节点。基础设施节点不计入运行环境所需的订阅总数。有关更多信息，请参见“移动集群资源覆盖操作符 Pod”。

先决条件

如果容器未设置限制，则集群资源覆盖操作符无效。您必须使用LimitRange对象为项目指定默认限制，或在Pod规范中配置限制才能应用覆盖。

步骤

要修改集群级超额使用：

编辑ClusterResourceOverride CR

apiVersion: operator.autoscaling.openshift.io/v1
kind: ClusterResourceOverride
metadata:
    name: cluster
spec:
  podResourceOverride:
    spec:
      memoryRequestToLimitPercent: 50 (1)
      cpuRequestToLimitPercent: 25 (2)
      limitCPUToMemoryPercent: 200 (3)
# ...

1	可选：如果使用，请指定覆盖容器内存限制的百分比（1-100）。默认为`50`。
2	可选：如果使用，请指定覆盖容器 CPU 限制的百分比（1-100）。默认为`25`。
3	可选：如果使用，请指定覆盖容器内存限制的百分比。以 100% 的比例扩展 1 Gi RAM 等于 1 个 CPU 内核。如果配置了此项，则会在覆盖 CPU 请求之前进行处理。默认为`200`。

确保已为每个您希望集群资源覆盖操作符控制超额使用的项目添加了以下标签：

apiVersion: v1
kind: Namespace
metadata:

# ...

  labels:
    clusterresourceoverrides.admission.autoscaling.openshift.io/enabled: "true" (1)

# ...

1	将此标签添加到每个项目。

其他资源

移动集群资源覆盖运算符 Pod

移动集群资源覆盖操作符 Pod

默认情况下，集群资源覆盖操作符安装过程会在clusterresourceoverride-operator命名空间中的节点上创建一个操作符 Pod 和两个集群资源覆盖 Pod。您可以根据需要将这些 Pod 移动到其他节点，例如基础设施节点。

您可以创建和使用基础设施节点来仅托管基础设施组件，例如默认路由器、集成的容器镜像注册表以及集群指标和监控组件。这些基础设施节点不计入运行环境所需的订阅总数。有关基础设施节点的更多信息，请参见“创建基础设施机器集”。

以下示例显示集群资源覆盖 Pod 部署到控制平面节点，而集群资源覆盖操作符 Pod 部署到工作节点。

集群资源覆盖 Pod 示例

NAME                                                READY   STATUS    RESTARTS   AGE   IP            NODE                                        NOMINATED NODE   READINESS GATES
clusterresourceoverride-786b8c898c-9wrdq            1/1     Running   0          23s   10.128.2.32   ip-10-0-14-183.us-west-2.compute.internal   <none>           <none>
clusterresourceoverride-786b8c898c-vn2lf            1/1     Running   0          26s   10.130.2.10   ip-10-0-20-140.us-west-2.compute.internal   <none>           <none>
clusterresourceoverride-operator-6b8b8b656b-lvr62   1/1     Running   0          56m   10.131.0.33   ip-10-0-2-39.us-west-2.compute.internal     <none>           <none>

节点列表示例

NAME                                        STATUS   ROLES                  AGE   VERSION
ip-10-0-14-183.us-west-2.compute.internal   Ready    control-plane,master   65m   v1.30.4
ip-10-0-2-39.us-west-2.compute.internal     Ready    worker                 58m   v1.30.4
ip-10-0-20-140.us-west-2.compute.internal   Ready    control-plane,master   65m   v1.30.4
ip-10-0-23-244.us-west-2.compute.internal   Ready    infra                  55m   v1.30.4
ip-10-0-77-153.us-west-2.compute.internal   Ready    control-plane,master   65m   v1.30.4
ip-10-0-99-108.us-west-2.compute.internal   Ready    worker                 24m   v1.30.4
ip-10-0-24-233.us-west-2.compute.internal   Ready    infra                  55m   v1.30.4
ip-10-0-88-109.us-west-2.compute.internal   Ready    worker                 24m   v1.30.4
ip-10-0-67-453.us-west-2.compute.internal   Ready    infra                  55m   v1.30.4

步骤

通过为集群资源覆盖操作符的Subscription自定义资源 (CR) 添加节点选择器来移动集群资源覆盖操作符 Pod。

编辑 CR

$ oc edit -n clusterresourceoverride-operator subscriptions.operators.coreos.com clusterresourceoverride

添加节点选择器以匹配您想要安装集群资源覆盖操作符 Pod 的节点上的节点角色标签。

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: clusterresourceoverride
  namespace: clusterresourceoverride-operator
# ...
spec:
  config:
    nodeSelector:
      node-role.kubernetes.io/infra: "" (1)
# ...

1	指定您想要部署集群资源覆盖操作符 Pod 的节点的角色。

如果基础设施节点使用了污点，则需要在 Subscription CR 中添加容忍。

例如

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: clusterresourceoverride
  namespace: clusterresourceoverride-operator
# ...
spec:
  config:
    nodeSelector:
      node-role.kubernetes.io/infra: ""
    tolerations: (1)
    - key: "node-role.kubernetes.io/infra"
      operator: "Exists"
      effect: "NoSchedule"

1	为基础设施节点上的污点指定容忍。

通过向 ClusterResourceOverride 自定义资源 (CR) 添加节点选择器来移动集群资源覆盖 Pod。

编辑 CR

$ oc edit ClusterResourceOverride cluster -n clusterresourceoverride-operator

添加节点选择器以匹配基础设施节点上的节点角色标签。

apiVersion: operator.autoscaling.openshift.io/v1
kind: ClusterResourceOverride
metadata:
  name: cluster
  resourceVersion: "37952"
spec:
  podResourceOverride:
    spec:
      cpuRequestToLimitPercent: 25
      limitCPUToMemoryPercent: 200
      memoryRequestToLimitPercent: 50
  deploymentOverrides:
    replicas: 1 (1)
    nodeSelector:
      node-role.kubernetes.io/infra: "" (2)
# ...

1	可选：指定要部署的集群资源覆盖 Pod 的数量。默认值为 `2`。每个节点只允许一个 Pod。
2	可选：指定您想要部署集群资源覆盖 Pod 的节点的角色。

如果基础设施节点使用了污点，则需要在 ClusterResourceOverride CR 中添加容忍。

例如

apiVersion: operator.autoscaling.openshift.io/v1
kind: ClusterResourceOverride
metadata:
  name: cluster
# ...
spec:
  podResourceOverride:
    spec:
      memoryRequestToLimitPercent: 50
      cpuRequestToLimitPercent: 25
      limitCPUToMemoryPercent: 200
  deploymentOverrides:
    replicas: 3
    nodeSelector:
      node-role.kubernetes.io/worker: ""
    tolerations: (1)
    - key: "key"
      operator: "Equal"
      value: "value"
      effect: "NoSchedule"

1	为基础设施节点上的污点指定容忍。

验证

您可以使用以下命令验证 Pod 是否已移动

$ oc get pods -n clusterresourceoverride-operator -o wide

集群资源覆盖 Pod 现在已部署到基础设施节点。

示例输出

NAME                                                READY   STATUS    RESTARTS   AGE   IP            NODE                                        NOMINATED NODE   READINESS GATES
clusterresourceoverride-786b8c898c-9wrdq            1/1     Running   0          23s   10.127.2.25   ip-10-0-23-244.us-west-2.compute.internal   <none>           <none>
clusterresourceoverride-786b8c898c-vn2lf            1/1     Running   0          26s   10.128.0.80   ip-10-0-24-233.us-west-2.compute.internal   <none>           <none>
clusterresourceoverride-operator-6b8b8b656b-lvr62   1/1     Running   0          56m   10.129.0.71   ip-10-0-67-453.us-west-2.compute.internal   <none>           <none>

其他资源

创建基础设施机器集

节点级超额承诺

您可以使用各种方法来控制特定节点上的超额承诺，例如服务质量 (QoS) 保证、CPU 限制或预留资源。您还可以为特定节点和特定项目禁用超额承诺。

理解计算资源和容器

节点强制执行的计算资源行为特定于资源类型。

理解容器 CPU 请求

容器保证其请求的 CPU 量，并且还可以使用节点上可用的额外 CPU，上限为容器指定的任何限制。如果多个容器尝试使用额外的 CPU，则 CPU 时间将根据每个容器请求的 CPU 量进行分配。

例如，如果一个容器请求 500m 的 CPU 时间，另一个容器请求 250m 的 CPU 时间，那么节点上任何额外的 CPU 时间将以 2:1 的比例分配给这些容器。如果容器指定了限制，则会对其进行限制，使其不会使用超过指定限制的 CPU。CPU 请求使用 Linux 内核中的 CFS 共享支持强制执行。默认情况下，CPU 限制使用 Linux 内核中的 CFS 配额支持在 100 毫秒的测量间隔内强制执行，但这可以禁用。

理解容器内存请求

容器保证其请求的内存量。容器可以使用超过请求量的内存，但是一旦超过其请求量，它可能会在节点上的低内存情况下被终止。如果容器使用的内存少于请求量，则除非系统任务或守护程序需要超过节点资源预留中所考虑的内存量，否则不会终止它。如果容器指定了内存限制，则如果超过限制量，它将立即被终止。

理解超额承诺和服务质量类

当节点上调度了一个没有发出任何请求的 Pod，或者该节点上所有 Pod 的限制总和超过了可用的机器容量时，该节点就被认为是超额承诺的。

在超额承诺的环境中，节点上的 Pod 可能会尝试使用任何给定时间点都超过可用量的计算资源。当这种情况发生时，节点必须优先考虑一个 Pod 而不是另一个 Pod。用于做出此决定的机制称为服务质量 (QoS) 类。

Pod 被指定为三个 QoS 类之一，优先级递减。

表 1. 服务质量类
优先级	类名	描述
1（最高）	Guaranteed（保证）	如果所有资源都设置了限制（和可选的请求）（不等于 0），并且它们相等，则该 Pod 被归类为Guaranteed（保证）。
2	Burstable（突发）	如果所有资源都设置了请求（和可选的限制）（不等于 0），并且它们不相等，则该 Pod 被归类为Burstable（突发）。
3（最低）	BestEffort（尽力而为）	如果没有为任何资源设置请求和限制，则该 Pod 被归类为BestEffort（尽力而为）。

内存是一种不可压缩的资源，因此在低内存情况下，优先级最低的容器将首先被终止。

Guaranteed（保证）容器被认为是最高优先级，并且保证只有在超过其限制或系统内存压力很大并且没有其他可以驱逐的低优先级容器时才会被终止。
在系统内存压力下，Burstable（突发）容器更有可能在其超过其请求并且不存在其他BestEffort（尽力而为）容器时被终止。
BestEffort（尽力而为）容器的优先级最低。如果系统内存不足，这些容器中的进程将首先被终止。

了解如何在服务质量层级之间预留内存

您可以使用qos-reserved参数来指定特定 QoS 级别中的 Pod 要预留的内存百分比。此功能尝试预留请求的资源，以防止较低 OoS 类的 Pod 使用较高 QoS 类 Pod 请求的资源。

OpenShift Container Platform 使用qos-reserved参数如下：

值为qos-reserved=memory=100%将阻止Burstable（突发）和BestEffort（尽力而为）QoS 类使用较高 QoS 类请求的内存。这增加了在BestEffort（尽力而为）和Burstable（突发）工作负载上导致 OOM 的风险，以换取提高Guaranteed（保证）和Burstable（突发）工作负载的内存资源保证。
值为qos-reserved=memory=50%将允许Burstable（突发）和BestEffort（尽力而为）QoS 类使用较高 QoS 类请求的内存的一半。
值为qos-reserved=memory=0%将允许Burstable（突发）和BestEffort（尽力而为）QoS 类如果可用，则可以使用高达节点可分配量的全部内存，但这增加了Guaranteed（保证）工作负载无法访问请求的内存的风险。此条件实际上禁用了此功能。

了解交换内存和 QoS

您可以默认在节点上禁用交换以保留服务质量 (QoS) 保证。否则，节点上的物理资源可能会超额订阅，从而影响 Kubernetes 调度程序在 Pod 安置期间做出的资源保证。

例如，如果两个保证型 Pod 已达到其内存限制，则每个容器都可能开始使用交换内存。最终，如果没有足够的交换空间，由于系统超额订阅，Pod 中的进程可能会被终止。

未能禁用交换会导致节点无法识别它们正在经历MemoryPressure（内存压力），从而导致 Pod 未收到其在调度请求中声明的内存。结果，将更多 Pod 放置在节点上以进一步增加内存压力，最终增加您遇到系统内存不足 (OOM) 事件的风险。

如果启用了交换，则可用内存的任何超出资源处理驱逐阈值将无法按预期工作。利用超出资源处理允许在节点内存压力下将 Pod 从节点中驱逐，并在没有此类压力的备用节点上重新调度。

理解节点超额承诺

在超额认购环境中，正确配置节点以提供最佳系统行为非常重要。

节点启动时，它会确保正确设置内存管理的内核可调标志。除非物理内存耗尽，否则内核绝不应该导致内存分配失败。

为了确保此行为，OpenShift Container Platform 通过将vm.overcommit_memory参数设置为1来配置内核始终超额认购内存，从而覆盖默认的操作系统设置。

OpenShift Container Platform 还通过将vm.panic_on_oom参数设置为0来配置内核在内存不足时不出现恐慌。设置为 0 表示内核在内存不足 (OOM) 条件下调用 oom_killer，这会根据优先级终止进程。

您可以在节点上运行以下命令来查看当前设置

$ sysctl -a |grep commit

示例输出

#...
vm.overcommit_memory = 0
#...

$ sysctl -a |grep panic

示例输出

#...
vm.panic_on_oom = 0
#...

上述标志应该已经设置在节点上，无需进一步操作。

您还可以对每个节点执行以下配置

使用 CPU CFS 配额禁用或强制执行 CPU 限制
为系统进程预留资源
跨服务质量层预留内存

使用 CPU CFS 配额禁用或强制执行 CPU 限制

默认情况下，节点使用 Linux 内核中的完全公平调度程序 (CFS) 配额支持强制执行指定的 CPU 限制。

如果您禁用 CPU 限制强制执行，则务必了解其对节点的影响

如果容器具有 CPU 请求，则 Linux 内核中的 CFS 共享将继续强制执行该请求。
如果容器没有 CPU 请求，但有 CPU 限制，则 CPU 请求默认为指定的 CPU 限制，并由 Linux 内核中的 CFS 共享强制执行。
如果容器同时具有 CPU 请求和限制，则 Linux 内核中的 CFS 共享将强制执行 CPU 请求，而 CPU 限制对节点没有影响。

先决条件

通过输入以下命令，获取与您要配置的节点类型的静态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	标签显示在“标签”下。

如果标签不存在，请添加键值对，例如

$ oc label machineconfigpool worker custom-kubelet=small-pods

步骤

为您的配置更改创建自定义资源 (CR)。

禁用 CPU 限制的示例配置

apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  name: disable-cpu-units (1)
spec:
  machineConfigPoolSelector:
    matchLabels:
      pools.operator.machineconfiguration.openshift.io/worker: "" (2)
  kubeletConfig:
    cpuCfsQuota: false (3)

1	为 CR 命名。
2	指定来自机器配置池的标签。
3	将`cpuCfsQuota`参数设置为`false`。

运行以下命令创建 CR
```
$ oc create -f <file_name>.yaml
```

为系统进程预留资源

为了提供更可靠的调度并最大限度地减少节点资源超额认购，每个节点都可以预留一部分资源供系统守护进程使用，这些守护进程需要在您的节点上运行才能使您的集群正常运行。特别是，建议您为不可压缩的资源（例如内存）预留资源。

步骤

要为非 Pod 进程显式预留资源，请通过指定可用于调度的资源来分配节点资源。有关更多详细信息，请参阅为节点分配资源。

禁用节点的超额认购

启用后，可以在每个节点上禁用超额认购。

步骤

要在节点上禁用超额认购，请在该节点上运行以下命令

$ sysctl -w vm.overcommit_memory=0

项目级限制

为了帮助控制超额认购，您可以设置每个项目的资源限制范围，为超额认购无法超过的项目指定内存和 CPU 限制以及默认值。

有关项目级资源限制的信息，请参阅其他资源。

或者，您可以为特定项目禁用超额认购。

禁用项目的超额认购

启用后，可以按项目禁用超额认购。例如，您可以允许基础设施组件独立于超额认购进行配置。

步骤

创建或编辑命名空间对象文件。

添加以下注释

apiVersion: v1
kind: Namespace
metadata:
  annotations:
    quota.openshift.io/cluster-resource-override-enabled: "false" (1)
# ...

1	将此注释设置为`false`将为此命名空间禁用超额认购。

配置集群以将 Pod 部署到超额分配节点上

资源请求和超额分配

使用集群资源覆盖运算符进行集群级别超额分配

使用 Web 控制台安装集群资源覆盖操作符

使用 CLI 安装集群资源覆盖操作符

配置集群级超额使用

移动集群资源覆盖操作符 Pod

节点级超额承诺

理解计算资源和容器

理解容器 CPU 请求

理解容器内存请求

理解超额承诺和服务质量类

了解如何在服务质量层级之间预留内存

了解交换内存和 QoS

理解节点超额承诺

使用 CPU CFS 配额禁用或强制执行 CPU 限制

为系统进程预留资源

禁用节点的超额认购

项目级限制

禁用项目的超额认购

其他资源