☰

保证命名空间中的 ResourceQuota

tag-icon • tag-icon kubernetes
保证命名空间中的 ResourceQuota

我正在运行一个跨团队共享的集群，我想保证每个团队都拥有最少的资源，尤其是内存。

继指示我尝试在其命名空间中使用以下内容：

apiVersion: v1
kind: ResourceQuota
metadata:
  name: mem-quota
spec:
  hard:
    requests.memory: 8Gb

然而，通过阅读更多文档，我们发现这并不能保证他们的 pod 拥有 8Gb 的内存。这只是意味着他们的 podrequests.memory值的总和不能超过 8Gb。他们可能会像上面一样设置 8Gb，但只使用 4Gb，如果集群在其他地方已达到最大容量，并且无法安排新的 pod，则无法创建新的 pod。

又例如，我可以在总内存只有 8Gi 的集群上创建一个值为 16Gi 的ResourceQuota。requests.memory

有没有办法可以保证一个团队拥有固定数量的内存仅供他们使用？

答案1

这仅意味着它们的 pod 请求的内存值总和不能超过 8Gb

是的，这就是 ResourceQuota 的逻辑。来自了解资源配额：

资源配额的工作原理如下：

  • 用户将计算资源请求放在他们的 pod 上。同一命名空间中所有 pod 的所有资源请求总和不得超过该命名空间的任何资源配额文档中的任何硬资源限制。请注意，我们过去通过计算 Pod 的资源限制总和来验证资源配额，但后来改为使用资源请求。保留了之前创建的 Pod 的向后兼容性，因为仅指定资源限制的 Pod 的资源请求默认与其定义的限制相匹配。用户只需为他们在资源配额中请求的资源而不是他们的限制付费，因为请求是集群在调度期间保证的最小资源量。有关过度提交的更多信息，请参阅计算资源。

  • 如果创建 pod 会导致命名空间超出该命名空间的资源配额中指定的任何限制，则请求将失败，并显示 HTTP 状态代码 403 FORBIDDEN。

  • 如果在命名空间中启用了配额，并且用户未在 pod 上为启用了配额的每个资源指定请求，则 pod 的 POST 将失败，并显示 HTTP 状态代码 403 FORBIDDEN。提示：在检查配额之前，使用 LimitRange 准入控制器强制限制的默认值（然后资源请求默认等于限制，请参阅准入控制器）以避免此问题。

但是本文扩展了一些案例，您需要单独划分资源。这不是已经实现的。

配额和集群容量： 有时可能需要更复杂的策略，例如：

  • 按比例在几个团队之间分配总集群资源。
  • 允许每个租户根据需要增加资源使用量，但要有一个宽松的限制，以防止意外的资源耗尽。
  • 检测来自一个命名空间的需求，添加节点并增加配额。

可以使用 ResourceQuota 作为构建块来实现此类策略，通过编写一个“控制器”来监视配额使用情况并根据其他信号调整每个命名空间的配额硬限制。

我希望您需要在自己的控制器中编写自定义逻辑。

另请查看如何使用 OPA 强制 Kubernetes 命名空间具有资源配额

相关内容