4.4. 将 pod 放置到过量使用的节点

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

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

OpenShift Dedicated 管理员可以通过配置主控机（master）来覆盖开发人员容器上设置的请求和限制之间的比率，来控制过量使用的程度并管理节点上的容器密度。与项目一级上的用于指定限制和默认值的 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
#...

注意

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

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