gpt4 book ai didi

kubernetes - Kubernetes的放置导致Pod永远重启

转载 作者:行者123 更新时间:2023-12-02 11:52:39 25 4
gpt4 key购买 nike

我们有2个节点,每个节点具有96 GB的RAM。
计划是,我们的Pod将从其中一个节点获取90.5 GB的RAM,并从另一个节点获取91 GB的RAM。
实际发生的情况是,这些节点之一中的Pod占用了93.5 GB的空间,而另一个节点中则占用了88 GB的空间。
这导致Pod永远永久重新启动,并且应用程序从未达到运行状态。
背景:
我们是kubernetes的新手,并在AWS(v1.14.9-eks-658790)的eks集群上使用1.14版。
目前,我们有不同大小的 pod ,它们一起构成我们产品的1个单位。在测试设置中,我们要使用1个单元,而要在生产中使用多个单元。
对于我们来说,为节点支付更多的钱,减少 pods 限制或副本数量是一个问题。
pods 详细信息:

+-------------+--------------+-----------+-------------+
| Pod name | Mem requests | pod limit | # of copies |
+-------------+--------------+-----------+-------------+
| BIG-OK-POD | 35 | 46 | 2 |
| OK-POD | 7.5 | 7.5 | 4 |
| A-OK-POD | 6 | 6 | 8 |
| WOLF-POD | 5 | 5 | 1 |
| WOLF-B-POD | 1 | 1 | 1 |
| SHEEP-POD | 2 | 2 | 1 |
| SHEEP-B-POD | 2 | 2 | 1 |
| SHEEP-C-POD | 1.5 | 1.5 | 1 |
+-------------+--------------+-----------+-------------+
我们不在乎Pod在哪里运行,我们只希望节点能够处理内存需求而不会失败。
我对 pod 进行了重命名,以使其更容易遵循我们的预期。
预期的位置:
我们预计狼 pod 将在一个节点上,而绵羊 pod 将在另一个节点上,而OK pod 将在节点之间分配。
Node 1:
+-------------+-----------+-------------+----------------+
| Pod name | pod limit | # of copies | combined limit |
+-------------+-----------+-------------+----------------+
| BIG-OK-POD | 46 | 1 | 46 |
| OK-POD | 7.5 | 2 | 15 |
| A-OK-POD | 6 | 4 | 24 |
| WOLF-POD | 5 | 1 | 5 |
| WOLF-B-POD | 1 | 1 | 1 |
+-------------+-----------+-------------+----------------+
| | TOTAL: 91 |
+-------------+-----------+-------------+----------------+

Node 2:

+-------------+-----------+-------------+----------------+
| Pod name | pod limit | # of copies | combined limit |
+-------------+-----------+-------------+----------------+
| BIG-OK-POD | 46 | 1 | 46 |
| OK-POD | 7.5 | 2 | 15 |
| A-OK-POD | 6 | 4 | 24 |
| SHEEP-POD | 2 | 1 | 2 |
| SHEEP-B-POD | 2 | 1 | 2 |
| SHEEP-C-POD | 1.5 | 1 | 1.5 |
+-------------+-----------+-------------+----------------+
| | TOTAL: 90.5 |
+-------------+-----------+-------------+----------------+
实际位置:
Node 1:
+-------------+-----------+-------------+----------------+
| Pod name | pod limit | # of copies | combined limit |
+-------------+-----------+-------------+----------------+
| BIG-OK-POD | 46 | 1 | 46 |
| OK-POD | 7.5 | 2 | 15 |
| A-OK-POD | 6 | 4 | 24 |
| WOLF-POD | 5 | 1 | 5 |
| SHEEP-B-POD | 2 | 1 | 2 |
| SHEEP-C-POD | 1.5 | 1 | 1.5 |
+-------------+-----------+-------------+----------------+
| | TOTAL: 93.5 |
+-------------+-----------+-------------+----------------+

Node 2:
+-------------+-----------+-------------+----------------+
| Pod name | pod limit | # of copies | combined limit |
+-------------+-----------+-------------+----------------+
| BIG-OK-POD | 46 | 1 | 46 |
| OK-POD | 7.5 | 2 | 15 |
| A-OK-POD | 6 | 4 | 24 |
| WOLF-B-POD | 1 | 1 | 1 |
| SHEEP-POD | 2 | 1 | 2 |
+-------------+-----------+-------------+----------------+
| | TOTAL: 88 |
+-------------+-----------+-------------+----------------+
有没有办法告诉kubernetes节点应该将4 GB的内存留给节点本身?
阅读Marc ABOUCHACRA的答案后,我们尝试更改系统保留的内存(设置为0.2Gi),但是对于任何高于0.3Gi(0.5Gi,1Gi,2Gi,3Gi和4Gi)的值, pod 都停留在待处理状态状态永远。
更新:我们找到了一种减少一些Pod的限制的方法,现在系统已启动且稳定(即使其中1个节点在99%上)。我们无法让K8从预览配置开始,我们仍然不知道为什么。

最佳答案

Kubernetes让您配置服务器以便为系统守护程序保留资源。
为此,您需要配置 kubelet 代理。这是每个节点配置。
因此,如果要在一个节点上保留4Gb内存,则需要使用以下选项在该节点上配置kubelet代理:

--system-reserved=memory=4Gi
您可以在 official documentation中找到有关此内容的更多信息

关于kubernetes - Kubernetes的放置导致Pod永远重启,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/63824731/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com