问题描述
我们有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。 目前,我们有不同大小的豆荚,它们一起构成我们产品的1个单位。在测试设置中,我们要使用1个单元,而要在生产中使用多个单元。 对于我们来说,为节点支付更多的钱,减少pod限制或减少副本数量是一个问题。
有关吊舱的详细信息:
+-------------+--------------+-----------+-------------+
| 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在哪里运行,我们只是希望节点能够处理内存需求而不会失败。
我重命名了吊舱,以便更轻松地遵循我们的预期。
预期的位置:
我们预计狼豆荚将在一个节点上,而绵羊豆荚在另一个节点上,而OK豆荚将在节点之间分配。
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的限制的方法,现在系统已启动且稳定(即使其中一个节点在99%上)。我们无法让K8从预览配置开始,我们仍然不知道为什么。
解决方法
Kubernetes让您配置服务器,以便为系统守护程序保留资源。
为此,您需要配置 kubelet 代理。这是每个节点的配置。
因此,如果要在一个节点上保留4Gb内存,则需要使用以下选项在该节点上配置kubelet代理:
--system-reserved=memory=4Gi
中找到有关此内容的更多信息。
,
每种资源类型都有两个资源说明符。
- 资源请求
- 资源限制
资源请求指定Pod应该保留的特定资源(CPU或内存)的数量。豆荚可以使用比请求更多的资源-但不能超过资源限制。
根据Kubernetes文档:
创建Pod时,Kubernetes调度程序会为 荚继续运行。每个节点的最大容量 资源类型:它可以为Pod提供的CPU和内存量。 调度程序可确保对于每种资源类型, 预定容器的资源请求少于 节点的容量。请注意,尽管实际内存或CPU资源 节点上的使用率很低,调度程序仍然拒绝放置Pod 如果容量检查失败,则在节点上执行。这样可以防止 稍后资源使用量增加时,节点上的资源短缺,例如 例如,在每天的请求率高峰期间。
这是资源请求和限制的典型配置。
resources:
requests:
memory: "64Mi"
cpu: "250m"
limits:
memory: "128Mi"
cpu: "500m"
,
您已经触摸了同一“堆栈溢出问题”中的几个主题。
主题1。
有没有办法告诉kubernetes节点应该为节点本身留出4 GB的内存? 背景:...在eks群集上的版本1.14
Official doc主题表示,如果您的Kubernetes服务器版本为1.8或更高版本,则它是可配置的。
GiHub上有一条关于“ --kube-reserved和--system-reserved无法正常工作#72762”的话题,这也是值得检查的。
非常全面的article,其中指定了如何防止关键系统和Kubernetes服务的资源匮乏。
主题2。
我们希望狼豆荚在一个节点上,而绵羊豆荚在另一个节点上
您可以将Pod限制为只能在特定的Node(s)上运行,或者更喜欢在特定的节点上运行。有几种方法可以做到这一点,推荐的方法都使用label selectors进行选择。
nodeSelector
是推荐的最简单的节点选择约束形式。 nodeSelector
是PodSpec的一个字段。它指定键值对的映射。为了使Pod有资格在节点上运行,该节点必须具有每个指示的键值对作为标签(它也可以具有其他标签)。最常见的用法是一对键值对。
“确定”窗格将在节点之间分配。
Pod间亲和性和反亲和性使您可以约束based on labels on pods that are already running on the node可以对您的Pod进行调度的节点,而不必基于节点上的标签。 规则的形式为“如果该X已经运行了一个或多个符合规则Y的Pod,则该Pod应该(或者在非亲和性的情况下不应该)在X中运行”。
主题3。
听起来这可能适用于我详细分享的2个节点的用例,但是在生产中我们有很多节点,我们宁愿不一一配置它们
- 如果您想自定义位置您的广告连播(即“狼”在奇数节点上,“绵羊”在偶数节点上,并且仅每个节点一个OK,A-OK,BIG-OK实例)。
- “我们宁可不要一一配置它们”-有很多方法可以管理基础结构/标签/部署,但这是一个独立的问题。