在 iDesktop Java,Kubernetes支持最多5000节点规模的集群。 更具体地说,我们支持满足以下 所有 标准的配置:
集群是一组运行Kubernetes代理组件的节点(物理或虚拟机),它们被 “master” (集群管理平面)所管理。
一般来说,集群的节点数量通过平台相关的 config-default.sh
文件中的 NUM_NODES
值来控制,(例如,详见 GCE’s config-default.sh
)。
对很多云提供商来说,单纯地修改NUM_NODES
为一个非常大的值,可能会导致集群的创建脚本失败。 例如,在GCE中部署时,会因配额不足,导致集群启动失败。
当建立一个大型的Kubernetes集群,以下几个问题必须考虑。
为了避免出现配额问题,当创建包含大量节点的集群时,考虑:
为了提升大规模集群的性能,我们将事件对象存储到独立的etcd实例中。
创建集群时,当前的salt脚本:
在 GCE/Google Kubernetes Engine 或 AWS平台中, kube-up
会根据集群的节点规模合理地设置管理节点的规格。 在其他云平台上,用户需要手动配置。 作为参考,GCE使用的规格为:
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)。 所以如果部署大规模集群时不对这些值进行调整,插件可能会因为资源占用达到上限而不断被杀死。
为了避免集群插件的资源问题,创建多节点的集群时,考虑以下几点:
Heapster的资源限制是基于集群的初始规模动态设置的 (参考 #16185 和 #22940)。 当发现Heapster资源耗尽,应考虑调整计算Heapster内存请求的公式 (参考上述PR)。
关于如何检测插件是否达到资源上限 参考 计算资源的故障排除章节。
将来,我们期望基于集群规模来设置集群插件的资源限制,并且在集群规模增长或缩小时能够动态调整。 欢迎提出PR来实现这些特性。
因为种种原因 (详见 #18969),在 NUM_NODES
值很大的情况下执行
kube-up.sh
, 可能因为其中一小部分节点没有正常启动而失败。
这时我们有两种选择:重启集群 (kube-down.sh
然后再 kube-up.sh
),或者在执行 kube-up.sh
之前,
将环境变量 ALLOWED_NOTREADY_NODES
设置为合适的值。 这将允许 kube-up.sh
以少于 NUM_NODES
的节点数量启动集群。 依据失败的具体原因,另外的节点可能在后面加入集群,或者集群节点数量将保持在 NUM_NODES - ALLOWED_NOTREADY_NODES
。
此页是否对您有帮助?
Thanks for the feedback. If you have a specific, answerable question about how to use Kubernetes, ask it on Stack Overflow. Open an issue in the GitHub repo if you want to report a problem or suggest an improvement.