创建大型集群

支持

在 v1.18 版本中， Kubernetes 支持的最大节点数为 5000。更具体地说，我们支持满足以下*所有*条件的配置：

• 节点数不超过 5000
• Pod 总数不超过 150000
• 容器总数不超过 300000
• 每个节点的 pod 数量不超过 100

• • 支持
  • 设定
    • 配额问题
    • Etcd 存储
    • 主控节点大小和主控组件
    • 插件资源
    • 允许启动时次要节点失败

设定

集群是一组运行着 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 使用率往往与集群的规模/负载成比例增长） ：
  • InfluxDB 和 Grafana
  • kubedns、dnsmasq 和 sidecar
  • Kibana
• 根据集群的规模，如果使用了以下插件，调整其副本数量（每个插件都有多个副本，增加副本数量有助于处理增加的负载，但是，由于每个副本的负载也略有增加，因此也请考虑增加 CPU/内存限制）：
  • elasticsearch
• 根据集群的规模，如果使用了以下插件，限制其内存和 CPU 上限（这些插件在每个节点上都有一个副本，但是 CPU/内存使用量也会随集群负载/规模而略有增加）：
  • FluentD 和 ElasticSearch 插件
  • FluentD 和 GCP 插件

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。