Question

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

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

<块引用>

 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 pod 表明您将资源请求设置得太低。请求和限制之间的 8 倍差异对我来说“感觉”非常大。

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

如果实际限制远高于系统的物理容量，而 Pod 实际使用了那么多内存，那么系统最终将耗尽内存。发生这种情况时，Pod 将获得 Evicted;哪个 pod 取决于它的实际使用量超过了它的请求，即使它在它的限制之内。 Kubernetes 文档中的 Node-pressure Eviction 更详细地描述了该过程。

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

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

1 个答案: