将 Pod 部署到超额认购节点 - 控制 Pod 在节点上的部署（调度） | 节点 | Red Hat OpenShift Service on AWS

在超额分配状态下，容器计算资源请求和限制的总和超过系统可用资源。在开发环境中，如果可以接受以牺牲性能保证换取容量的折衷方案，则超额分配可能是可取的。

请求和限制使管理员能够允许和管理节点上资源的超额分配。调度程序使用请求来调度您的容器并提供最低服务保证。限制约束了节点上可能消耗的计算资源量。

理解超额分配

AWS 上的 Red Hat OpenShift 服务管理员可以通过配置主节点来覆盖开发者容器上设置的请求和限制之间的比率，从而控制超额分配的级别并管理节点上的容器密度。结合指定限制和默认值的每个项目的LimitRange对象，这将调整容器限制和请求以达到所需的超额分配级别。

如果容器未设置任何限制，则这些覆盖将无效。为每个项目或在项目模板中创建一个具有默认限制的LimitRange对象，以确保覆盖适用。

这些覆盖之后，容器限制和请求仍必须通过项目中的任何LimitRange对象进行验证。例如，开发人员可以指定接近最小限制的限制，然后将请求覆盖到最小限制以下，从而导致 Pod 被禁止。这种不好的用户体验应该在未来的工作中得到解决，但目前，请谨慎配置此功能和LimitRange对象。

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

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

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

AWS 上的 Red Hat OpenShift 服务还通过将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
#...

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

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