一位经验丰富的DevOps人士告诉我，资源（CPU和内存）的限制和请求会更好，以便更紧密地调度Pod。
凭直觉我可以对K8s进行更少的图像放大和缩小需要更少的计算能力？或者有人可以更详细地解释它？
答案 0 :(得分：3)
资源请求和限制做了两个根本不同的事情。 Kubernetes调度程序仅根据资源请求的总和在节点上放置一个Pod：如果该节点具有8 GB RAM，并且当前在该节点上调度的Pod请求了7 GB RAM，则一个新的Pod将请求512 MB将适合那里。这些限制控制了Pod实际允许使用的资源量，如果使用过多，则会受到CPU限制或OOM破坏。
在实践中，许多工作负载可能是“突发的”。在峰值负载下可能需要2 GB的RAM，但远远少于闲置时的RAM。提供足够的硬件以在峰值负载下运行所有内容并不一定要让它在大多数时间处于空闲状态。
如果资源请求和限制相距甚远，则可以在同一节点上“容纳”更多的容器。但是，如果整个系统开始忙碌，那么您可以关闭许多Pod，这些Pod都在使用超出其资源请求的内存，并且实际上使用的内存比节点多，而没有任何Pod超出其限制。
请考虑一个具有8 GB RAM的节点，以及一个具有512 MB RAM资源请求和2 GB限制的Pod。这些吊舱中有16个“合适”。但是，如果每个Pod想要使用1 GB RAM（受资源限制所允许），则总内存要比节点多，并且您将开始获得任意的OOM杀伤力。如果Pod要求1 GB RAM，则只能容纳8 GB，并且您将需要两倍的硬件来运行它们，但是在这种情况下，群集将快乐地运行。
在云环境中解决此问题的一种策略是您的运营团队要求的，使资源请求和限制彼此非常接近。如果一个节点已满，自动缩放器将自动从云中请求另一个节点。缩小比例有点棘手。但是这种方法避免了由于Kubernetes节点被过量使用而导致事物随机死亡的问题，以为空闲状态需要更多硬件为代价。