Kubernetes集群规模-Kubernetes集群应该有多大？

说在前面的话

今天谈谈k8s集群规模问题，到底集群应该有多大？虽然这个问题有些干燥，却包含了不少生产经验，若是这个问题也对你有所困扰，你能够选择继续读下去，你们在本身的公司不论是上云仍是虚拟化技术，都已经在容器的途中多多少少都已经在迁移或者迁移的路上，在云原生的技术圈中，当谈到kubernetes稳定性可靠性的问题时，你殊不知道如何下手，目前不少从事k8s的技术圈的人，可能还处于似懂非懂，多少知道点的状况，可是深刻玩懂K8S的人，却很少，真有大规模实践的人却少之又少，而这篇总结在集群规模上的一些建议但愿给你带来帮助

谈到Kubernetes集群时，规模相当重要。群集中的节点数在肯定工做负载的总体可用性和性能方面起着重要做用。在某种程度上，名称空间的数量也是如此。

可是，这并不意味着越大越好。旨在最大化节点数量的Kubernetes集群规模调整策略并不是总能带来最佳结果，固然，从成本的角度来看，也可能从总体可用性或性能的角度来看，都不是。最大化的名称空间也毫不是明智的策略。

相反，计算要包含在群集中的节点数须要仔细考虑各类因素。

为何Kubernetes集群大小很重要？

Kubernetes集群的大小（就节点数而言）以关键的方式影响着性能和可用性。

关于性能，更多的节点一般意味着更好的性能。这不是由于节点数自己能够提升性能，而是由于拥有更多的节点一般意味着群集可使用更多的资源。所以，从这个意义上讲，节点数是性能的代理。

而至于可用性，节点数在塑造此特性方面起着更直接的做用。拥有的节点越多，遇到较大节点故障以致于破坏群集可用性的机会就越小。

固然，除了节点数影响性能和可用性以外，还有许多其余因素。pod和名称空间之间的资源分配，网络质量，底层基础结构的可靠性以及网络上节点之间的相互距离（仅举几个因素）也对性能和可用性产生重大影响。

为何更多的节点并不老是更好?

你可能会想固然地认为能够添加到集群中的节点越多越好。并不是彻底如此，缘由有几个。

并不是全部节点都相等

首先也是最重要的事实是，组成节点的方式有不少变化。

一些节点比其余节点为集群贡献了更多的硬件资源，所以在提升性能方面作得更多。在这方面，总节点数不能很好地表示群集的性能。具备5,000个节点（Kubernetes当前能够支持的最大节点）的集群，每一个节点的资源分配最少，其性能可能不如由100个高端节点组成的集群。

在某些状况下，某些节点比其余节点更有可能保持可用性。与不托管在云中的虚拟机相比，位于本地数据中心的没有电源备份的物理服务器的可靠性较差（与本地基础结构相比，可靠性要高得多）。所以，节点数不是群集可用性的精确度量。

物理节点与虚拟机节点

一样，Kubernetes集群中物理机和虚拟机的混合会以关键方式影响其性能和可用性。

在Kubernetes中，物理服务器和虚拟机均可以充当节点。二者在本质上都不比另外一个更可靠或更高。可是，由仅在少许物理服务器上运行的许多虚拟机节点组成的群集，其可靠性可能不如在其中包含更多物理服务器的群集那样可靠。不管物理服务器是直接充当节点仍是虚拟机节点的主机，拥有更多物理服务器均可以减小任何一台服务器故障的影响。

换句话说，若是仅在五台物理服务器上托管100个虚拟机节点，则一台物理服务器的故障将使您的节点数减小20％。这是一个巨大的成功，所以最好混合使用更多的物理服务器。

也就是说，将事情推向相反的极端也不理想。若是要使每一个物理服务器成为其本身的节点，则一台服务器的故障将使您的群集失去该服务器贡献的总资源。出于可用性和性能的目的，最好在每一个物理服务器上至少运行几个虚拟机，并让这些虚拟机做为节点链接到群集。这样，若是其中一个节点发生故障，或者启动时间太长，则基础物理服务器的资源只有一部分会丢失。

底线：群集中物理机与虚拟机的比率以复杂的方式影响性能和可用性。找到合适的比率没有简单的公式，可是你应该寻求一个健康的中间立场。

更多的节点意味着更多的复杂性

一样值得注意的是，节点越多，管理和跟踪全部节点就越困难。

鉴于Kubernetes中的大部份内容都是自动化的，所以在这方面，拥有大量节点并非很大的障碍。但这仍然是要考虑的因素。你将必须配置，监视和保护每一个节点。若是你作这些事情的能力有限，则应考虑使群集保持较小。

性能和可用性是相对的

最后要记住的事实是性能和可用性始终是相对的。不管你有多少个节点（或没有节点），或者集群的配置多么完美，你都永远不会最大化。

我提到这一点是为了强调，若是你过于着迷于最大化节点数，最终可能会被扼杀。你应该努力达到可接受的性能和可用性水平，而后继续前进。除此以外，你最终会减小节点投资的回报（更不用说管理没必要要的复杂性了）。

调整Kubernetes集群的大小

那么，你如何找到最佳位置？如何确保有足够的节点但又没有太多的节点，而且物理机和虚拟机的混合恰到好处？

显然，这个问题没有简单或广泛的答案。你须要考虑多种因素及其对你特定需求的影响。

你的物理基础设施有多可靠？

若是构成节点基础的物理基础结构很是可靠，那么你能够拥有更少的节点。整体而言，基于此缘由，基于云的Kubernetes部署能够具备比本地部署更少的节点。（不管你认为本地数据中心多么可靠，它均可能不如现代云可靠。）

每一个节点有多少资源？

节点的硬件配置文件（不管是物理仍是虚拟硬件）也是一个关键因素。从性能角度来看，若是每一个节点提供相对大量的硬件资源，则不须要那么多节点。

你有几个主节点？

当涉及到整个群集的可用性和性能时，主节点比工做节点要重要得多。你可能有多个工做节点发生故障，而且看不到重大影响。可是，若是主节点是你惟一的主节点，则它的故障多是灾难性的。即便不是，它所产生的影响也是灾难性的

所以，在担忧添加更多工做进程以前，须要考虑群集中包含多少个主节点，并可能集中精力增长主节点的数量。

你的群集托管多少工做量？

工做负载总数是肯定群集大小的关键考虑因素。尽管使用Kubernetes命名空间能够轻松地将集群划分为各个工做负载（或工做负载组）的隔离区域，但仍是有一点要比直接添加更多的命名空间更好地简单地将集群分为较小的集群。

每一个名称空间都会增长管理开销。这也增长了多个问题的挑战（能够经过资源配额解决，可是您你须手动设置配额，所以它们不是可扩展的解决方案）。

群集大小调整的一些极其基本的经验法则

若是你一直在阅读这篇文章，以寻找有关使群集多大的具体指导，请容许我重申，没有什么比“一刀切”的答案更好了。

尽管如此，我仍是愿意提出一些很是基本的，很是广泛的，过于简化的建议：

对于生产名称空间或群集，每一个容器至少应有一个节点。（这并不意味着你应该在每一个容器上运行它的节点（相反），而是可用于承载容器实例的最小节点总数应等于容器总数。）
对于生产名称空间或群集中的每一个Pod，你应该有一台物理计算机。它是做为本身的节点运行仍是做为节点托管虚拟机都可有可无。关键是经过拥有足够的基础物理计算机来提升群集的可用性。

若是单个群集中的名称空间超过六个，那么该考虑将群集拆分为较小的群集了。
一样，这些是很是基本的规则。（此外，请记住，若是在开发/测试环境中对性能和可用性的关注一般不那么大）

结论

调整Kubernetes集群的规模是一门艺术，而不是一门科学。影响因素多种多样，从托管节点的基础结构类型，设置的主节点数量到物理机与虚拟机的比率，不一而足。将以上指示视为很是通常的准则，并准备根据你的特定需求调整集群大小。

最后欢迎讨论k8s技术我的v 信 kubefetch