说在前面的话
今天谈谈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
