6.4. 配置集群以将 pod 放置到过量使用的节点上

处于过量使用（overcommited）状态时，容器计算资源请求和限制的总和超过系统中可用的资源。过量使用常用于开发环境，因为在这种环境中可以接受以牺牲保障性能来换取功能的情况。

注意

OpenShift Container Platform 中默认启用过量使用。请参阅禁用节点过量使用。

6.4.1. 了解过量使用

请求和限制可让管理员允许和管理节点上资源的过量使用。调度程序使用请求来调度容器，并提供最低服务保证。限制约束节点上可以消耗的计算资源数量。

OpenShift Container Platform 管理员可以通过配置主控机（master）来覆盖开发人员容器上设置的请求和限制之间的比率，来控制过量使用的程度并管理节点上的容器密度。与项目一级上的用于指定限制和默认值的 LimitRange 一起使用，可以调整容器限制和请求以达到所需的过量使用程度。

注意

如果没有在容器中设定限制，则这些覆盖无效。创建一个带有默认限制（基于每个独立的项目或在项目模板中）的 LimitRange 对象，以确保能够应用覆盖。

在进行这些覆盖后，容器限制和请求必须仍需要满足项目中的 LimitRange 对象的要求。这可能会导致 pod 被禁止的情况。例如，开发人员指定了一个接近最小限制的限制，然后其请求被覆盖为低于最小限制。这个问题在以后会加以解决，但目前而言，请小心地配置此功能和 LimitRange。

6.4.2. 了解资源请求和过量使用

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

限制的强制实施取决于计算资源类型。如果容器没有请求或限制，容器会调度到没有资源保障的节点。在实践中，容器可以在最低本地优先级适用的范围内消耗指定的资源。在资源较少的情况下，不指定资源请求的容器将获得最低的服务质量。

调度基于请求的资源，而配额和硬限制指的是资源限制，它们可以设置为高于请求的资源。请求和限制的差值决定了过量使用程度；例如，如果为容器赋予 1Gi 内存请求和 2Gi 内存限制，则根据 1Gi 请求将容器调度到节点上，但最多可使用 2Gi；因此过量使用为 200％。

6.4.2.1. 了解 Fluentd 的缓冲数据块限制

如果 Fluentd 日志记录器无法满足大量日志的需求，则需要切换到文件缓冲来降低内存用量并防止数据丢失。

Fluentd 文件缓冲以数据块的形式存储记录。数据块存储在缓冲区中。

注意

要按如下修改 Fluentd daemonset 中的 FILE_BUFFER_LIMIT 或 BUFFER_SIZE_LIMIT 参数，您需要把集群日志系统设置为未管理（unmanaged）状态。处于非受管状态的 Operator 不被正式支持，集群管理员需要完全掌控各个组件的配置和升级。

Fluentd buffer_chunk_limit 由环境变量 BUFFER_SIZE_LIMIT 决定，其默认值为 8m。每个输出的文件缓冲区大小由环境变量 FILE_BUFFER_LIMIT 决定，其默认值为 256Mi。持久性卷大小必须大于 FILE_BUFFER_LIMIT 与输出相乘的结果。

例如，Fluentd pod 上应通过 PVC 或主机挂载准备持久性卷 /var/lib/fluentd。然后，将该区域用作文件缓冲区。

buffer_type 和 buffer_path 在 Fluentd 配置文件中进行配置，如下所示：

$ egrep "buffer_type|buffer_path" *.conf
output-es-config.conf:
  buffer_type file
  buffer_path `/var/lib/fluentd/buffer-output-es-config`
output-es-ops-config.conf:
  buffer_type file
  buffer_path `/var/lib/fluentd/buffer-output-es-ops-config`

Fluentd buffer_queue_limit 是变量 BUFFER_QUEUE_LIMIT 的值。默认值为 32。

环境变量 BUFFER_QUEUE_LIMIT 计算为 (FILE_BUFFER_LIMIT / (number_of_outputs * BUFFER_SIZE_LIMIT))。

如果 BUFFER_QUEUE_LIMIT 变量具有默认值：

FILE_BUFFER_LIMIT = 256Mi
number_of_outputs = 1
BUFFER_SIZE_LIMIT = 8Mi

buffer_queue_limit 的值为 32。若要更改 buffer_queue_limit，您必须更改 FILE_BUFFER_LIMIT 的值。

在这个公式中，如果所有日志都发送到单个资源，则 number_of_outputs 为 1，否则每多一个资源就会递增 1。例如，number_of_outputs 的值为：

1 - 如果所有日志都发送到单个 Elasticsearch pod
2 - 如果应用程序日志发送到 Elasticsearch pod，并且 ops 日志发送到另一个 Elasticsearch pod
4 - 如果应用程序日志发送到一个 Elasticsearch pod，ops 日志发送到另一个 Elasticsearch pod，并且这两者都转发到其他 Fluentd 实例

6.4.3. 了解计算资源和容器

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

6.4.3.1. 了解容器 CPU 请求

容器可以保证获得其请求的 CPU 量，还可额外消耗节点上提供的超额 CPU，但不会超过容器指定的限制。如果多个容器试图使用超额 CPU，则会根据每个容器请求的 CPU 数量来分配 CPU 时间。

例如，如果一个容器请求了 500m CPU 时间，另一个容器请求了 250m CPU 时间，那么该节点上提供的额外 CPU 时间以 2:1 比例在这两个容器之间分配。如果容器指定了一个限制，它将被限速，无法使用超过指定限制的 CPU。使用 Linux 内核中的 CFS 共享支持强制实施 CPU 请求。默认情况下，使用 Linux 内核中的 CFS 配额支持以 100ms 测量间隔强制实施 CPU 限制，但这可以禁用。

6.4.3.2. 了解容器内存请求

容器可以保证获得其请求的内存量。容器可以使用高于请求量的内存，但一旦超过请求量，就有可能在节点上遇到内存不足情形时被终止。如果容器使用的内存少于请求量，它不会被终止，除非系统任务或守护进程需要的内存量超过了节点资源保留考虑在内的内存量。如果容器指定了内存限制，则超过限制数量时会立即被终止。

6.4.4. 了解过量使用和服务质量类

当节点上调度了没有发出请求的 pod，或者节点上所有 pod 的限制总和超过了机器可用容量时，该节点处于过量使用状态。

在过量使用环境中，节点上的 pod 可能会在任意给定时间点尝试使用超过可用量的计算资源。发生这种情况时，节点必须为 pod 赋予不同的优先级。有助于做出此决策的工具称为服务质量 (QoS) 类。

对于每个计算资源，容器划分到三个 QoS 类中的一个，它们按照优先级降序排列：

表 6.19. 服务质量类
优先级	类名称	描述
1（最高）	Guaranteed	如果为所有资源设置了限制和可选请求（不等于 0）并且它们相等，则容器被归类为 Guaranteed。
2	Burstable	如果为所有资源设置了请求和可选限制（不等于 0）并且它们不相等，则容器被归类为 Burstable。
3（最低）	BestEffort	如果没有为任何资源设置请求和限制，则容器被归类为 BestEffort。

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

Guaranteed 容器优先级最高，并且保证只有在它们超过限制或者系统遇到内存压力且没有优先级更低的容器可被驱除时，才会被终止。
在遇到系统内存压力时，Burstable 容器如果超过其请求量并且不存在其他 BestEffort 容器，则有较大的可能会被终止。
BestEffort 容器被视为优先级最低。系统内存不足时，这些容器中的进程最先被终止。

6.4.4.1. 了解如何为不同的服务质量层级保留内存

您可以使用 qos-reserved 参数指定在特定 QoS 级别上 pod 要保留的内存百分比。此功能尝试保留请求的资源，阻止较低 QoS 类中的 pod 使用较高 QoS 类中 pod 所请求的资源。

OpenShift Container Platform 按照如下所示使用 qos-reserved 参数：

值为 qos-reserved=memory=100% 时，阻止 Burstable 和 BestEffort QoS 类消耗较高 QoS 类所请求的内存。这会增加 BestEffort 和 Burstable 工作负载上为了提高 Guaranteed 和 Burstable 工作负载的内存资源保障而遭遇 OOM 的风险。
值为 qos-reserved=memory=50% 时，允许 Burstable 和 BestEffort QoS 类消耗较高 QoS 类所请求的内存的一半。
值为 qos-reserved=memory=0% 时，允许 Burstable 和 BestEffort QoS 类最多消耗节点的所有可分配数量（若可用），但会增加 Guaranteed 工作负载不能访问所请求内存的风险。此条件等同于禁用这项功能。

6.4.5. 了解交换内存和 QoS

您可以在节点上默认禁用交换，以便保持服务质量 (QoS) 保障。否则，节点上的物理资源会超额订阅，从而影响 Kubernetes 调度程序在 pod 放置过程中所做的资源保障。

例如，如果两个有保障 pod 达到其内存限制，各个容器可以开始使用交换内存。最终，如果没有足够的交换空间，pod 中的进程可能会因为系统被超额订阅而被终止。

如果不禁用交换，会导致节点无法意识到它们正在经历 MemoryPressure，从而造成 pod 无法获得它们在调度请求中索取的内存。这样节点上就会放置更多 pod，进一步增大内存压力，最终增加遭遇系统内存不足 (OOM) 事件的风险。

重要

如果启用了交换，则对于可用内存的资源不足处理驱除阈值将无法正常发挥作用。利用资源不足处理，允许在遇到内存压力时从节点中驱除 pod，并且重新调度到没有此类压力的备选节点上。

6.4.6. 了解节点过量使用

在过量使用的环境中，务必要正确配置节点，以提供最佳的系统行为。

当节点启动时，它会确保为内存管理正确设置内核可微调标识。除非物理内存不足，否则内核应该永不会在内存分配时失败。

在过量使用的环境中，务必要正确配置节点，以提供最佳的系统行为。

当节点启动时，它会确保为内存管理正确设置内核可微调标识。除非物理内存不足，否则内核应该永不会在内存分配时失败。

为确保这一行为，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 = 1

$ sysctl -a |grep panic
vm.panic_on_oom = 0

注意

节点上应该已设置了上述标记，不需要进一步操作。

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

使用 CPU CFS 配额禁用或强制实施 CPU 限制
为系统进程保留资源
为不同的服务质量等级保留内存

6.4.6.1. 使用 CPU CFS 配额禁用或强制实施 CPU 限制

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

先决条件

为您要配置的节点类型获取与静态机器配置池 CRD 关联的标签。执行以下步骤之一：

查看 Machine Config Pool：

$ oc describe machineconfigpool <name>

例如：

$ oc describe machineconfigpool worker

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfigPool
metadata:
  creationTimestamp: 2019-02-08T14:52:39Z
  generation: 1
  labels:
    custom-kubelet: small-pods 1

1: 如果添加了标签，它会出现在 labels 下。

如果标签不存在，则添加一个键/值对：

$ 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:
      custom-kubelet: small-pods 2
  kubeletConfig:
    cpu-cfs-quota: 3
      - "false"

1: 为 CR 分配一个名称。
2: 指定要应用配置更改的标签。
3: 将 cpu-cfs-quota 参数设置为 false。

如果需要禁用 CPU 限制强制实施，则务必要了解其对您的节点可能造成的影响：

如果容器发出 CPU 请求，它将继续由 Linux 内核中的 CFS 份额来实施。
如果容器没有明确发出 CPU 请求，但它确实指定了限制，则请求将默认为指定的限制，并且由 Linux 内核中的 CFS 份额来实施。
如果容器同时指定 CPU 请求和限制，则由 Linux 内核中的 CFS 份额来实施请求，并且限制不会对节点产生影响。

6.4.6.2. 为系统进程保留资源

为提供更可靠的调度并且最大程度减少节点资源过量使用，每个节点都可以保留一部分资源供系统守护进程使用（节点上必须运行这些守护进程才能让集群正常工作，如 sshd 等）。特别是，建议您为内存等不可压缩的资源保留资源。

流程

要明确为非 pod 进程保留资源，请通过指定可用于调度的资源来分配节点资源。如需了解更多详细信息，请参阅“为节点分配资源”。

6.4.7. 禁用节点过量使用

启用之后，可以在每个节点上禁用过量使用。

流程

要在节点中禁用过量使用，请在该节点上运行以下命令：

$ sysctl -w vm.overcommit_memory=0

6.4.8. 禁用项目过量使用

启用之后，可以按项目禁用过量使用。例如，您可以允许独立于过量使用配置基础架构组件。

流程

在某个项目中禁用过量使用：

编辑项目对象文件

添加以下注解：

quota.openshift.io/cluster-resource-override-enabled: "false"

创建项目对象：
```
$ oc create -f <file-name>.yaml
```