Kubernetes的设计初衷是要解决管理大规模容器化环境时的困难。不过，这并不意味着Kubernetes在任何的环境下都可以进行扩展。有一些方法可以让用户最大限度地发挥Kubernetes的扩展能力，而在扩展Kubernetes时，有一些重要事项和限制需要注意，本文中我将对这些内容进行说明。

规模和性能

扩展Kubernetes集群，首先要注意的就是规模和性能之间的平衡。比如，Kubernetes 1.6可被用于多达5000个节点的集群。不过5000个节点并不是硬性限制的最大值，它只是一个推荐的节点最大值。在实际使用中，节点数可以远超过5000个，只是这样会导致性能下降罢了。

这个问题具体来说是这样的：Kubernetes有两个服务层级的目标，一个是在一秒内返回99%的API调用。另一个是在5秒内启动99%的pods。尽管这些目标并不是完整的一套性能指标，但它们确实为评估通用集群性能提供了良好的基准。而据Kubernetes所说，超过5000个节点的集群可能无法实现这些服务层级的目标。

所以有一点请大家注意，在有些时候，为了发挥Kubernetes的扩展性，你有可能不得不牺牲一部分的性能，这些牺牲对你来说既可能是值得的，也可能是不值得的，而这取决于你具体的部署场景。

配额（quotas）

在建立非常大规模的Kubernetes集群时，你可能会遇到的一个主要问题就是配额问题。对于基于云的节点尤为如此，因为云服务提供商通常情况下会设置配额限制。

这个问题之所以如此重要，是因为部署大规模的Kubernetes集群实际上是一个看似简单的过程。config-default.sh文件有NUM_NODES的设置。表面上，你可以通过加大与此设置相关联的值来构建大规模集群。虽然这在某些情况下可行，但最终也可能会遭遇到配额问题。因此，在你打算扩展集群之前，很有必要就现有的任何配额先和云供应商进行沟通。云供应商不仅可以让你了解现有配额的情况，而且至少一部分云供应商会同意用户增加配额限制的请求。

当你在评估这些限制的时候，需要注意，尽管配额限制会直接限制你创建Kubernetes集群的数量，然而集群大小的限制更多是出自与Kubernetes间接相关的配额。例如，提供商可能会限制允许你使用的IP地址数量，或者限制你创建的虚拟机实例数量。而好消息是，主要的几个云服务商已经有多次和Kubernetes打交道的经验，应该能够帮助你解决这些问题。

主节点

除了上述的限制外，还需要考虑的一个问题是集群大小对所需的主节点大小和数量的影响。这些取决于Kubernetes的实现方式，不过要记住的一点是，集群越大，所需的主节点数量也越多，而那些主节点的功能需求也就越高。

如果你正在从头构建新的Kubernetes集群，这可能是一个无关的问题，毕竟确定需要的主节点数量是集群规划过程中的正常阶段。可是如果你打算扩展现有Kubernetes集群，那么你更需要去多加考虑主节点的需求，因为在集群启动时主节点的大小就已经设置好了，而且不能够动态调整。

扩展附加组件（scaling add-ons）

另一件需要我们注意的是，Kubernetes定义了附加组件容器的资源限制。这些资源限制可确保附加组件不会消耗过多的CPU和内存资源。

这些有关限制的问题是，它们是基于相对较小的集群进行定义的。如果你在大规模集群中运行某些附加组件，它们可能会需要超额使用更多的资源。这是因为附加组件必须服务更多的节点，也因此需要额外的资源。如果开始出现与组件相关限制的问题，那么你就会看到附加组件一个一个地被kill掉。

总结

Kubernetes集群可以大规模扩展，但可能会遇到与配额和性能相关的问题。因此，在向Kubernetes集群添加大量新节点之前，请一定要仔细考虑横向扩展所出现的各种需求。