创建大型集群
支持
在 v1.18 版本中, Kubernetes 支持的最大节点数为 5000。更具体地说,我们支持满足以下*所有*条件的配置:
- 节点数不超过 5000
- Pod 总数不超过 150000
- 容器总数不超过 300000
- 每个节点的 pod 数量不超过 100
设定
集群是一组运行着 Kubernetes 代理的节点(物理机或者虚拟机),这些节点由主控节点(集群级控制面)控制。
通常,集群中的节点数由特定于云平台的配置文件 config-default.sh
(可以参考 GCE 平台的 config-default.sh
)中的 NUM_NODES
参数控制。
但是,在许多云供应商的平台上,仅将该值更改为非常大的值,可能会导致安装脚本运行失败。例如,在 GCE,由于配额问题,集群会启动失败。
因此,在创建大型 Kubernetes 集群时,必须考虑以下问题。
配额问题
为了避免遇到云供应商配额问题,在创建具有大规模节点的集群时,请考虑:
- 增加诸如 CPU,IP 等资源的配额。
- 例如,在 GCE,您需要增加以下资源的配额:
- CPUs
- VM 实例
- 永久磁盘总量
- 使用中的 IP 地址
- 防火墙规则
- 转发规则
- 路由
- 目标池
- 由于某些云供应商会对虚拟机的创建进行流控,因此需要对设置脚本进行更改,使其以较小的批次启动新的节点,并且之间有等待时间。
Etcd 存储
为了提高大规模集群的性能,我们将事件存储在专用的 etcd 实例中。
在创建集群时,现有 salt 脚本可以:
- 启动并配置其它 etcd 实例
- 配置 API 服务器以使用 etcd 存储事件
主控节点大小和主控组件
在 GCE/Google Kubernetes Engine 和 AWS 上,kube-up
会根据节点数量自动为您集群中的 master 节点配置适当的虚拟机大小。在其它云供应商的平台上,您将需要手动配置它。作为参考,我们在 GCE 上使用的规格为:
- 1-5 个节点:n1-standard-1
- 6-10 个节点:n1-standard-2
- 11-100 个节点:n1-standard-4
- 101-250 个节点:n1-standard-8
- 251-500 个节点:n1-standard-16
- 超过 500 节点:n1-standard-32
在 AWS 上使用的规格为
- 1-5 个节点:m3.medium
- 6-10 个节点:m3.large
- 11-100 个节点:m3.xlarge
- 101-250 个节点:m3.2xlarge
- 251-500 个节点:c4.4xlarge
- 超过 500 节点:c4.8xlarge
注意:在 Google Kubernetes Engine 上,主控节点的大小会根据集群的大小自动调整。更多有关信息,请参阅 此博客文章。
在 AWS 上,主控节点的规格是在集群启动时设置的,并且,即使以后通过手动删除或添加节点的方式使集群缩容或扩容,主控节点的大小也不会更改。
插件资源
为了防止内存泄漏或 集群插件 中的其它资源问题导致节点上所有可用资源被消耗,Kubernetes 限制了插件容器可以消耗的 CPU 和内存资源(请参阅 PR #10653 和 #10778)。
例如:
containers:
- name: fluentd-cloud-logging
image: k8s.gcr.io/fluentd-gcp:1.16
resources:
limits:
cpu: 100m
memory: 200Mi
除了 Heapster 之外,这些限制都是静态的,并且限制是基于 4 节点集群上运行的插件数据得出的(请参阅 #10335)。在大规模集群上运行时,插件会消耗大量资源(请参阅 #5880)。因此,如果在不调整这些值的情况下部署了大规模集群,插件容器可能会由于达到限制而不断被杀死。
为避免遇到集群插件资源问题,在创建大规模集群时,请考虑以下事项:
- 根据集群的规模,如果使用了以下插件,提高其内存和 CPU 上限(每个插件都有一个副本处理整个群集,因此内存和 CPU 使用率往往与集群的规模/负载成比例增长) :
- 根据集群的规模,如果使用了以下插件,调整其副本数量(每个插件都有多个副本,增加副本数量有助于处理增加的负载,但是,由于每个副本的负载也略有增加,因此也请考虑增加 CPU/内存限制):
- 根据集群的规模,如果使用了以下插件,限制其内存和 CPU 上限(这些插件在每个节点上都有一个副本,但是 CPU/内存使用量也会随集群负载/规模而略有增加):
Heapster 的资源限制与您集群的初始大小有关(请参阅 #16185 和 #22940)。如果您发现 Heapster 资源不足,您应该调整堆内存请求的计算公式(有关详细信息,请参阅相关 PR)。
关于如何检测插件容器是否达到资源限制,参见 计算资源的故障排除 部分。
未来,我们期望根据集群规模大小来设置所有群集附加资源限制,并在集群扩缩容时动态调整它们。 我们欢迎您来实现这些功能。
允许启动时次要节点失败
出于各种原因(更多详细信息,请参见 #18969),
在 kube-up.sh
中设置很大的 NUM_NODES
时,可能会由于少数节点无法正常启动而失败。
此时,您有两个选择:重新启动集群(运行 kube-down.sh
,然后再运行 kube-up.sh
),或者在运行 kube-up.sh
之前将环境变量 ALLOWED_NOTREADY_NODES
设置为您认为合适的任何值。采取后者时,即使运行成功的节点数量少于 NUM_NODES
,kube-up.sh
仍可以运行成功。根据失败的原因,这些节点可能会稍后加入集群,又或者群集的大小保持在 NUM_NODES-ALLOWED_NOTREADY_NODES
。
反馈
此页是否对您有帮助?
感谢反馈。如果您有一个关于如何使用 Kubernetes 的特定的、需要答案的问题,可以访问 Stack Overflow. 在 GitHub 仓库上登记新的问题 报告问题 或者 提出改进建议.