将 Pod 部署到超额分配的节点 - 控制 Pod 在节点上的部署（调度） | 节点

在超额分配状态下，容器计算资源请求和限制之和超过系统可用资源。在开发环境中，为了权衡保证性能和容量，超额分配可能是可取的。

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

了解超额分配

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

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

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

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

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

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

OpenShift Dedicated 还通过将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
#...

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

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