简要概述:本文讨论了在Kubernetes集群中选择较少数量的较大节点和选择较多数量的较小节点之间的利弊。
当创建一个Kubernetes集群时,最初的问题之一是:"我应该使用什么类型的工作节点,以及需要多少个?"
如果正在构建一个本地集群，是应该采购一些上一代的高性能服务器,还是利用数据中心中闲置的几台老旧机器呢？
或者,正在使用像Google Kubernetes Engine(GKE)这样的托管式Kubernetes服务,是应该选择八个n1-standard-1实例还是两个n1-standard-4实例来实现所需的计算能力呢？
目录
- 集群容量
- Kubernetes工作节点中的预留资源
- 工作节点中的资源分配和效率
- 弹性和复制
- 扩展增量和前导时间
- 拉取容器镜像
- Kubelet和扩展Kubernetes API
- 节点和集群限制
- 存储
- 总结和结论
集群容量
一般来说,Kubernetes集群可以被看作是将一组独立的节点抽象为一个大的"超级节点"。这个超级节点的总计算能力(包括CPU和内存)是所有组成节点的能力之和.
有多种实现这一目标的方法.例如,假设需要一个总计算能力为8个CPU核心和32GB内存的集群。以下是两种可能的集群设计模式：划分成两台机子或四台机子。
Kubernetes集群中的小型节点与大型节点 | 这两种选择都会得到相同容量的集群。左边的选择使用了四个较小的节点，而右边的选择使用了两个较大的节点。
问题是:哪种方法更好呢？---为了做出明智的决策,让我们深入了解如何在工作节点中分配资源。
Kubernetes工作节点中的预留资源
Kubernetes集群中的每个工作节点都是一个运行kubelet(Kubernetes代理)的计算单元。
kubelet是一个连接到控制平面的二进制文件,用于将节点的当前状态与集群的状态同步。
例如，当kubernetes调度程序将一个Pod分配给特定节点时,它不会直接向kubelet发送消息。相反，它会创建一个Binding对象并将其储存在etcd中。
kubelet定期检查集群的状态。一旦它注意到将一个新分配的Pod分配给其节点,它就会开始下载Pod的规范并创建它。
通常将kubelet部署为SystemD服务，并作为操作系统的一部分运行。
kubelet、SystemD和操作系统需要资源，包括CPU和内存，以确保正确运行。
因此，并不是所有工作节点的资源都仅用于运行Pod。
CPU和内存资源通常分配如下：
操作系统。Kubelet。Pods。驱逐阈值。
Kubernetes节点中的资源分配
您可能想知道这些组件分配了哪些资源。虽然具体配置可能会有所不同，但CPU分配通常遵循以下模式：
第一个核心的6%。后续核心的1%（最多2个核心）。接下来的两个核心的0.5%（最多4个核心）。四个核心以上的任何核心的0.25%。内存分配可能如下：
小于1GB内存的机器分配255 MiB内存。前4GB内存的25%。接下来的4GB内存的20%（最多8GB）。接下来的8GB内存的10%（最多16GB）。接下来的112GB内存的6%（最多128GB）。超过128GB的任何内存的2%。最后，驱逐阈值通常保持在100MB。
驱逐阈值 驱逐阈值代表内存使用的阈值。如果一个节点超过了这个阈值，kubelet将开始驱逐Pod，因为当前节点的内存不足。
考虑一个具有8GB内存和2个虚拟CPU的实例。资源分配如下：
70毫核虚拟CPU和1.8GB供kubelet和操作系统使用（通常一起打包）。保留100MB用于驱逐阈值。剩余的6.1GB内存和1930毫核可以分配给Pod。只有总内存的75%用于执行工作负载。
但这还不止于此。
您的节点可能需要在每个节点上运行一些Pod（例如DaemonSets）以确保正确运行，而这些Pod也会消耗内存和CPU资源。
例如，Kube-proxy、诸如Fluentd或Fluent Bit的日志代理、NodeLocal DNSCache或CSI驱动程序等。
这是一个固定的成本，无论节点大小如何，您都必须支付。
带有DaemonSets的Kubernetes节点中的资源分配 考虑到这一点，让我们来看一下"较少数量的较大节点"和"较多数量的较小节点"这两种截然相反的方法的利弊。
请注意，本文中的"节点"始终指的是工作节点。关于控制平面节点的数量和大小的选择是一个完全不同的主题。
工作节点中的资源分配和效率
随着更大实例的使用，kubelet预留的资源会减少。
让我们来看两种极端情况。
您想要为一个请求0.3个vCPU和2GB内存的应用部署七个副本。
在第一种情况下，您将为一个单独的工作节点提供资源以部署所有副本。在第二种情况下，您在每个节点上部署一个副本。为简单起见，我们假设这些节点上没有运行任何DaemonSets。
七个副本所需的总资源为2.1个vCPU和14GB内存（即7 x 300m = 2.1个vCPU和7 x 2GB = 14GB）。
一个4个vCPU和16GB内存的实例能够运行这些工作负载吗？
我们来计算一下CPU的预留：
第一个核心的6% = 60m + 第二个核心的1% = 10m + 剩余核心的0.5% = 10m 总计 = 80m
用于运行Pod的可用CPU为3.9个vCPU（即4000m - 80m）——绰绰有余。
接下来，我们来看一下kubelet预留的内存：
前4GB内存的25% = 1GB 接下来的4GB内存的20% = 0.8GB 接下来的8GB内存的10% = 0.8GB 总计 = 2.8GB
分配给Pod的总内存为16GB -（2.8GB + 0.1GB）——这里的0.1GB考虑到了100MB的驱逐阈值。
最后，Pod可以使用最多13.1GB的内存。
带有2个vCPU和16GB内存的Kubernetes节点中的资源分配
不幸的是，这还不够（即7个副本需要14GB的内存，但您只有13.1GB），您应该为部署这些工作负载提供更多内存的计算单元。
如果使用云提供商，下一个可用的增量计算单元是4个vCPU和32GB内存。
带有2个vCPU和16GB内存的节点不足以运行七个副本
太好了！
接下来，让我们看一下另一种情况，即我们尝试找到适合一个副本的最小实例，该副本的请求为0.3个vCPU和2GB内存。
我们尝试使用具有1个vCPU和4GB内存的实例类型。
预留的CPU总共为6%或60m，可用于Pod的CPU为940m。
由于该应用仅需要300m的CPU，这足够了。
kubelet预留的内存为25%或1GB，再加上额外的0.1GB的驱逐阈值。
Pod可用的总内存为2.9GB；由于该应用仅需要2GB，这个值足够了。
太棒了！
带有2个vCPU和16GB内存的Kubernetes节点中的资源分配 现在，让我们比较这两种设置。
第一个集群的总资源只是一个单一节点 — 4个vCPU和32GB。
第二个集群有七个实例，每个实例都有1个vCPU和4GB内存（总共为7个vCPU和28GB内存）。
在第一个示例中，为Kubernetes预留了2.9GB的内存和80m的CPU。
而在第二个示例中，预留了7.7GB（1.1GB x 7个实例）的内存和360m（60m x 7个实例）的CPU。
您已经可以注意到，在配置较大的节点时，资源的利用效率更高。
在单一节点集群和多节点集群之间比较资源分配情况
但还有更多。
较大的实例仍然有空间来运行更多的副本 — 但有多少个呢？
预留的内存为3.66GB（3.56GB的kubelet + 0.1GB的驱逐阈值），可用于Pod的总内存为28.44GB。预留的CPU仍然是80m，Pods可以使用3920m。此时，您可以通过以下方式找到内存和CPU的最大副本数：
Total CPU 3920 / Pod CPU 300 ------------------ Max Pod 13.1
您可以为内存重复进行计算：
总内存 28.44 / Pod内存 2 最大Pod 14.22
以上数字表明，内存不足可能会在CPU之前用尽，而在4个vCPU和32GB工作节点中最多可以托管13个Pod。
为2个vCPU和32GB工作节点计算Pod容量 那么第二种情况呢？
是否还有空间进行扩展？
实际上并没有。
虽然这些实例仍然具有更多的CPU，但在部署第一个Pod后，它们只有0.9GB的可用内存。
为1个vCPU和4GB工作节点计算Pod容量 总之，不仅较大的节点能更好地利用资源，而且还可以最小化资源的碎片化并提高效率。
这是否意味着您应该始终提供较大的实例？
让我们来看另一个极端情况：节点意外丢失时会发生什么？
弹性和复制
较少数量的节点可能会限制您的应用程序的有效复制程度。
例如，如果您有一个由5个副本组成的高可用应用程序，但只有两个节点，那么有效的复制程度将降低为2。
这是因为这五个副本只能分布在两个节点上，如果其中一个节点失败，可能会一次性失去多个副本。
具有两个节点和五个副本的集群的复制因子为两个
另一方面，如果您至少有五个节点，每个副本都可以在一个单独的节点上运行，而单个节点的故障最多会导致一个副本失效。
因此，如果您有高可用性要求，您可能需要在集群中拥有一定数量的节点。
具有五个节点和五个副本的集群的复制因子为五 您还应该考虑节点的大小。
当较大的节点丢失时，一些副本最终会被重新调度到其他节点。
如果节点较小，仅托管了少量工作负载，则调度器只会重新分配少数Pod。
虽然您不太可能在调度器中遇到任何限制，但重新部署许多副本可能会触发集群自动缩放器。
并且根据您的设置，这可能会导致进一步的减速。
让我们来探讨一下原因。
扩展增量和前导时间
您可以使用水平扩展器（即增加副本数量）和集群自动缩放器（即增加节点计数）的组合来扩展部署在Kubernetes上的应用程序。
假设您的集群达到总容量，节点大小如何影响自动缩放？
首先，您应该知道，当集群自动缩放器触发自动缩放时，它不会考虑内存或可用的CPU。
换句话说，总体上使用的集群不会触发集群自动缩放器。
相反，当一个Pod因资源不足而无法调度时，集群自动缩放器会创建更多的节点。
此时，自动缩放器会调用云提供商的API，为该集群提供更多的节点。
集群自动缩放器在Pod由于资源不足而处于挂起状态时提供新的节点。
集群自动缩放器在Pod由于资源不足而处于挂起状态时提供新的节点。
不幸的是，通常情况下，配置节点是比较缓慢的。
要创建一个新的虚拟机可能需要几分钟的时间。
提供较大或较小实例的配置时间是否会改变？
不，通常情况下，无论实例的大小如何，配置时间都是恒定的。
此外，集群自动缩放器不限于一次添加一个节点；它可能会一次添加多个节点。
我们来看一个例子。
有两个集群：
第一个集群有一个4个vCPU和32GB的单一节点。第二个集群有13个1个vCPU和4GB的节点。一个具有0.3个vCPU和2GB内存的应用程序部署在集群中，并扩展到13个副本。
这两种设置都已达到总容量
当部署扩展到15个副本时会发生什么（即增加两个副本）？
在两个集群中，集群自动缩放器会检测到由于资源不足，额外的Pod无法调度，并进行如下配置：
对于第一个集群，增加一个具有4个vCPU和32GB内存的额外节点。对于第二个集群，增加两个具有1个vCPU和4GB内存的节点。由于在为大型实例或小型实例提供资源时没有时间差异，这两种情况下节点将同时可用。
然而，你能看出另一个区别吗？
第一个集群还有空间可以容纳11个额外的Pod，因为总容量是13个。
而相反，第二个集群仍然达到了最大容量。
你可以认为较小的增量更加高效和更便宜，因为你只添加所需的部分。
但是让我们观察一下当您再次扩展部署时会发生什么——这次扩展到17个副本（即增加两个副本）。
第一个集群在现有节点上创建了两个额外的Pod。而第二个集群已经达到了容量上限。Pod处于待定状态，触发了集群自动缩放器。最终，又会多出两个工作节点。
在第一个集群中，扩展几乎是瞬间完成的。
而在第二个集群中，您必须等待节点被配置完毕，然后才能让Pod开始提供服务。
换句话说，在前者的情况下，扩展速度更快，而在后者的情况下，需要更多的时间。
通常情况下，由于配置时间在几分钟范围内，您应该谨慎考虑何时触发集群自动缩放器，以避免产生更长的Pod等待时间。
换句话说，如果您能够接受（潜在地）没有充分利用资源的情况，那么通过使用较大的节点，您可以实现更快的扩展。
但事情并不止于此。
拉取容器镜像也会影响您能够多快地扩展工作负载，这与集群中的节点数量有关。
