在 K8s 中对 pod 请求和限制值的最佳实践是什么？

Question

最近我们在 AKS 集群中遇到了一些问题，即节点内存只是增加了，因为 pods 内存请求很高（request-2Gi，内存 2Gi），这增加了节点数。因此，为了减少节点数，我们将请求内存减少到 256MI 并限制为相同的值 (2GB)。在此之后，我们注意到集群中出现了一些奇怪的行为。

我们资源的请求百分比和限制有很大差异。
更清楚的是，限值显示为实际值的 602% 和 478%，差异很大在请求 % 之间。保持请求和限制之间的这种差异是正常的还是无害的？

 Resource                       Requests      Limits
  --------                       --------      ------
  cpu                            1895m (99%)   11450m (602%)
  memory                         3971Mi (86%)  21830Mi (478%)
  ephemeral-storage              0 (0%)        0 (0%)
  hugepages-1Gi                  0 (0%)        0 (0%)
  hugepages-2Mi                  0 (0%)        0 (0%)
  attachable-volumes-azure-disk  0             0

我们注意到我们的节点内存消耗显示超过 100%，这是一个惊人的现象节点如何消耗比实际更多内存的行为。

NAME                                CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
aks-nodepoolx-xxxxxxxx-vmss00000x   151m         7%     5318Mi          116%

NAME                                    READY   STATUS    RESTARTS   AGE
mymobile-mobile-xxxxx-ddvd6   2/2     Running   0          151m
myappsvc-xxxxxxxxxx-2t6gz     2/2     Running   0          5h3m
myappsvc-xxxxxxxxxx-4xnsh     0/2     Evicted   0          4h38m
myappsvc-xxxxxxxxxx-5b5mb     0/2     Evicted   0          4h28m
myappsvc-xxxxxxxxxx-5f52g     0/2     Evicted   0          4h19m
myappsvc-xxxxxxxxxx-5f8rz     0/2     Evicted   0          4h31m
myappsvc-xxxxxxxxxx-66lc9     0/2     Evicted   0          4h26m
myappsvc-xxxxxxxxxx-8cnfb     0/2     Evicted   0          4h27m
myappsvc-xxxxxxxxxx-b9f9h     0/2     Evicted   0          4h20m
myappsvc-xxxxxxxxxx-dfx9m     0/2     Evicted   0          4h30m
myappsvc-xxxxxxxxxx-fpwg9     0/2     Evicted   0          4h25m
myappsvc-xxxxxxxxxx-kclt8     0/2     Evicted   0          4h22m
myappsvc-xxxxxxxxxx-kzmxw     0/2     Evicted   0          4h33m
myappsvc-xxxxxxxxxx-lrrnr     2/2     Running   0          4h18m
myappsvc-xxxxxxxxxx-lx4bn     0/2     Evicted   0          4h32m
myappsvc-xxxxxxxxxx-nsc8t     0/2     Evicted   0          4h29m
myappsvc-xxxxxxxxxx-qmlrj     0/2     Evicted   0          4h24m
myappsvc-xxxxxxxxxx-qr75w     0/2     Evicted   0          4h27m
myappsvc-xxxxxxxxxx-tf8bn     0/2     Evicted   0          4h20m
myappsvc-xxxxxxxxxx-vfcdv     0/2     Evicted   0          4h23m
myappsvc-xxxxxxxxxx-vltgw     0/2     Evicted   0          4h31m
myappsvc-xxxxxxxxxx-xhqtb     0/2     Evicted   0          4h22m

Answer 1

大量 Evicted pods 表明您将资源请求设置得太低。请求和限制之间的 8 倍差异对我来说“感觉”非常大。

鉴于您的设置，kubectl describe node 输出对我来说是正确的。请注意，资源请求非常接近 100%：Kubernetes 将继续在节点上调度 pods，直到其资源 requests 达到 100%，无论相应的限制是什么，他们是。因此，如果您设法安排了 7x 256 MiB 请求 pods，那将请求 1,792 MiB 内存（2 GiB 节点的 88%）；如果每个 pod 指定的 limit 为 2 GiB，则总限制将为 7x 2048 MiB 或 14,336 MiB（物理容量的 700%）。

如果实际限制远高于系统的物理容量，并且 pods 实际使用了那么多内存，那么系统最终会运行内存不足。发生这种情况时，一个 pod 将获得 Evicted；哪个 pod 取决于它的实际使用量超过其请求的程度，即使它在其限制内。 Node-pressure Eviction 在 Kubernetes 文档中更详细地描述了该过程。

设置好这些限制是一门艺术。如果 requests 和 limits 相等，那么 pod 永远不会被驱逐（它的使用不能超过它的 requests）；但在这种情况下，如果 pod 没有使用 100% 的请求内存，那么该节点将未得到充分利用。如果它们不同，那么在更少的节点上安排 pods 会更容易，但是节点会被过度使用，当实际内存使用量增加时，某些东西会被驱逐。我可能会将请求设置为预期（观察到的）稳态内存使用，并将限制设置为您在正常操作中期望看到的最高值。

在 K8s 中对 pod 请求和限制值的最佳实践是什么？

What is the best practice to have request and limit values to a pod in K8s?

kubernetes

azure-aks