在AWS EKS上，我将包含17个副本(请求和限制64Mi内存)的部署添加到一个包含2个节点的小型集群，类型为t3.mall。
加上Kube-System Pod，每个节点的运行Pod总数为11个，剩余1个待定，即：
节点#1：
Aws-node-1
核心-5-1as3
核心-5-2das
Kube-Proxy-1
+7个应用程序Pod副本
节点#2：
Aws-node-1
Kube-Proxy-1
+9个应用程序Pod副本
我知道t3mall是一个非常小的例子。我只是想弄明白是什么限制了我。内存请求不是这样的，我的可用资源远远不足。
我发现，根据示例类型的不同，每个节点都有IP地址限制。Https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html?shortFooter=true#AvailableIpPerENI.
我没有找到任何其他文档明确表示这限制了Pod的创建，但我假设是这样的。根据该表，t3.mall可以有12个IPv4地址。如果是这种情况，这是一个限制因素，因为我有11个Pod，那么1个缺失的IPv4地址到哪里去了？
4条答案
按热度按时间wa7juj8i1#
实际每个EKS示例的最大示例数量如this document所示。
对于t3小示例，每个示例为11个示例。也就是说，您的群集中最多可以有22个Pod。这些Pod中有6个是系统Pod，因此最多保留16个工作负载Pod。
您正在尝试运行17个工作负载Pod，所以这太多了。我猜其中16个已经安排好了，还有1个还在等待中。
定义每个示例最大示例示例数量的formula如下：
在哪里：
因此，对于t3，这个计算是
3 * (4-1) + 2 = 11。本文档中每个示例类型的
N和M的值。k0pti3hp2#
对于任何在搜索谷歌时遇到这一问题的人。请注意，自2021年8月起，现在可以使用最新的AWS CNI插件增加节点上的最大Pod数，如here所述。
使用这里解释的基本配置，t3中型节点从最多17个pod增加到最多110个，这对于我要做的事情来说已经足够了。
dluptydi3#
这就是我们停止使用
EKS而转而使用KOPS部署的自我管理群集的原因。使用aws-cni的IMOEKS造成了太多的限制，这实际上违背了使用Kubernetes的主要好处之一，即有效利用可用资源。EKS将系统约束从CPU / memory使用转移到网络IP限制领域。Kubernetes旨在提供高密度、高效管理资源。对于
EKS’s版本则不是这样，因为节点可能空闲，几乎整个内存都可用，但如果pods > (N * (M-1) + 2)，群集将无法在利用率较低的节点上调度Pod。人们可能会忍不住使用另一个
CNI，例如Calico，然而，由于禁止访问主节点，因此将仅限于工作节点。 这会导致群集有两个网络，并且在尝试访问K8s API或与招生控制器一起工作时会出现问题。它确实取决于工作流要求，对于我们来说，高Pod密度、资源的高效使用以及对集群的完全控制是最重要的。
5gfr0r5j4#
连接到您的EKS节点
运行此命令
忽略NVIDIA-SMI未找到输出
完整脚本位置https://github.com/awslabs/amazon-eks-ami/blob/master/files/bootstrap.sh