Kubernetes集群该多大？

 

​Kubernetes已经成为事实上的管理平台，而我们还需要进一步明白这到底意味着什么。实际上，它存在于专用应用程序平台和通用基础设施抽象之间的灰色区域中。

几个月前，笔者在Twitter上进行了一个关于Kubernetes集群的调查。笔者想知道Kubernetes是否正在成为虚拟化平台的整体替代品还是仅仅是作为应用程序框架发展。如果是前者，运维人员使用该平台作为大规模的多租户系统，为Google Borg、VMware vCenter、OpenStack或Mesosphere等“数据中心O / S”提供共同的运维基准。如果是后者，开发人员将该平台用作单个应用程序、生命周期管理系统来提供更好的管理持续部署的自动化。显然，两种情况都在发生，为什么？

在近30个回应中，超过一半的人认为较小的特定于应用程序的集群是正确的选择。总的来说，回答反映了对小集群提供的分离、隔离和控制的渴望。笔者还认为小型集群更有可能利用基于VM的底层IaaS。这符合笔者之前的感受——用户在获得运维经验的同时在现有的IaaS上使用K8s。

那么，小集群更好吗？对于大多数用例，是的。它们把问题的“爆炸半径”降至最小，并将Kubernetes版本和升级问题分开。Kubernetes管理费用很低，因此现在可以容忍蔓延。此外，即使缺少多集群治理，云提供商也几乎消除了创建新集群的管理成本。随着多租户运营模式的出现以及运营团队出现治理要求，预计这种趋势会发生变化。

这项调查的目的是预测裸机Kubernetes的趋势线。由于裸机服务器较大，我们更有可能将其用于更大的多租户集群，以便用户可以共享VM云等资源。这个用例虽然不太常见，但在调查结果中已经有苗头，表明裸机集群需要更多时间。

值得注意的是OpenStack社区使用Kubernetes作为底层的临时方法。由于策略是将单个功能集群构建为安装程序，因此它实际上是一种小型集群方法，并且无法提升Kubernetes的广泛可用性。笔者观察到其他独立软件供应商（ISV）试图采用类似的策略来将单个应用程序Kubernetes作为安装程序采用。然而，这种方法带来了新的挑战，因为供应商还没有准备好拥有必要的Kubernetes发行版或有安装问题。

笔者的看法是，小型集群总是会在调查中获胜，因为它们更易于设置和运维。这意味着小型用户是Kubernetes的门户。但是，大型共享集群前端有足够的动力来使Kubernetes将成为更常见的基础设施底层。今天，命名空间的采用可能有限，但池指向它们变得更加普遍。命名空间允许集群中的多个用户限制其在集群中的范围和可见性。它不是一个完整的多租户功能，但现在提供了同样的好处。

 

支持小集群的人认为：

——任何时候小的多个集群都优于大型单体集群，这样可以避免不可预见问题的“爆炸半径”。

——K8S不是多租户系统。除此之外，我认为k8s的部署更类似于传统集群（每个应用程序一个），而不是单个大型平台。

——目前，我们每个团队使用一个集群，每个应用程序使用一个命名空间。更多的运维，但更安全，而且我们避免了关键场景。

 

支持大集群的人认为：

​——足够多的大集群能够轮转用于维护，并仍然保持所有工作负载的可用性。如何轮转需要精心设计并易于遵循。

——今天我们都是多租户，但希望允许专用集群用于大规模的独立工作负载。而多租户仍将是默认设置。

 

 

原文链接：

https://thenewstack.io/the-optimal-kubernetes-cluster-size-lets-look-at-the-data/