kubernetes - Kubernetes限制和资源请求最好更接近

Question

一位更有经验的 DevOps 人员告诉我，资源（CPU 和内存）限制和请求更接近于调度 pod。

直观地说，我可以对 K8s 进行更少的放大和缩小需要更少的计算能力吗？或者有人可以更详细地解释它吗？

标签： kubernetes

Answer 1

资源请求和限制做了两个根本不同的事情。Kubernetes 调度程序仅根据资源请求的总和将 pod 放置在节点上：如果节点有 8 GB 的 RAM，并且当前在该节点上调度的 pod 请求 7 GB 的 RAM，那么一个新的 pod 请求 512 MB将适合那里。限制控制 pod 实际允许使用多少资源，如果使用过多，它会受到 CPU 限制或 OOM 终止。

在实践中，许多工作负载可能是“突发的”。在峰值负载下可能需要 2 GB 的 RAM，但比闲置时要少得多。提供足够的硬件以在峰值负载下运行所有​​内容并不一定有意义，但随后让它大部分时间处于空闲状态。

如果资源请求和限制相距甚远，那么您可以在同一节点上“安装”更多 pod。但是，如果整个系统开始繁忙，您可能会发现许多 Pod 的使用量都超过了它们的资源请求，并且实际上使用的内存比节点的内存要多，而没有任何单个 Pod 超出其限制。

考虑一个具有 8 GB RAM 的节点，以及具有 512 MB RAM 资源请求和 2 GB 限制的 Pod。这些吊舱中有 16 个“适合”。但是，如果每个 pod 想要使用 1 GB RAM（在资源限制允许的情况下），那么总内存就会超过节点的总内存，并且您将开始获得任意 OOM-kills。如果 Pod 请求 1 GB RAM，则只有 8 个“适合”，并且您将需要两倍的硬件来运行它们，但在这种情况下，集群将运行良好。

在云环境中处理此问题的一种策略是您的运维团队所要求的，使资源请求和限制彼此非常接近。如果一个节点已满，自动缩放器将自动从云中请求另一个节点。缩小规模有点棘手。但是这种方法避免了由于 Kubernetes 节点过度使用而导致事物随机死亡的问题，代价是需要更多硬件来维持空闲状态。