你的Kubernetes控制平面该有有多少个节点？

控制平面节点数并不是“越多越好”那么简单。节点太少可能会导致系统无法运行，但节点太多会导致延迟增加。以下是确定K8s控制平面尺寸的超级指南。

Kubernetes集群通常由两类节点组成：运行应用程序的工作节点和控制集群的控制平面节点，它们调度工作节点上的作业，在负载需要时创建pod的新副本等。

控制平面运行的组件允许集群提供高可用性、从工作节点故障中恢复、响应pod需求的增加等。因此，确保控制平面的高可用性在生产环境中至关重要。

如果没有健全的控制平面，集群无法对其当前状态进行任何更改，这意味着无法调度新的pod。（你可以在控制平面节点上调度pod，但不建议用于生产集群，因为你不会希望工作负载需求从使Kubernetes高度可用的组件中获取资源。你还可以消除漏洞使工作负载能够访问控制平面秘密的机会，这将使你能够完全访问集群。）

那么，如何确保控制平面高可用？Kubernetes通过在多个节点上复制控制平面功能来实现高可用性。但是应该使用多少节点？

情况如何对你有利

控制平面的功能之一是提供用于Kubernetes自身配置的数据存储。该信息作为键值对存储在etcd数据库中。etcd使用仲裁系统，要求在向数据库提交任何更新之前，一半以上的副本可用。因此，两节点控制平面不仅需要一个节点可用，还需要两个节点可用。也就是说，从单节点控制平面到2节点控制平面会使可用性更差，而不是更好。

在2节点控制平面的情况下，当一个节点无法到达另一节点时，它不知道另一个节点是否已死亡（在这种情况下，该幸存节点可以继续对数据库进行更新）或无法到达。如果两个节点都已启动，但无法相互连接，并继续执行写操作，则最终会出现分裂的情况。

那么，集群的两半拥有不一致的数据副本，无法协调它们。因此，更安全的情况是锁定数据库并防止任何节点进一步写入。而且，由于两个节点中一个节点死亡的概率比一个节点高（事实上，假设它们是相同的节点，概率是两倍），因此两个节点控制平面的可靠性比单个节点更差。

这种逻辑适用于控制平面节点规模——etcd将始终要求一半以上的节点处于活动状态并可访问，以便具有仲裁，以便数据库可以执行更新。

因此，2节点控制平面要求两个节点都向上。3节点控制平面还要求2个节点处于启动状态。4节点控制平面需要3个节点。因此，4节点控制平面的可用性比3节点控制平面差——因为两个控制平面都可能遭受单节点中断，并且都无法处理2节点中断，但在4节点集群中发生这种情况的可能性更高。将节点添加到奇数大小的集群似乎更好（因为有更多的机器），但容错性更差，因为相同数量的节点可能会失败而不会丢失仲裁，但可能会失败的节点更多。

因此，一般规则是在控制平面中始终运行奇数个节点。

好事过头反成坏事

我们需要奇数个节点。这意味着3个节点，或5个，还是23个？

etcd文档说：“一个etcd集群可能不应超过七个节点。一个5成员的etcd集群可以容忍两个成员的故障，这在大多数情况下已经足够了。虽然更大的集群提供更好的容错能力，但写性能受到影响，因为数据必须在更多的机器上复制。”

Kubernetes文档称，“强烈建议在任何官方支持的规模下，始终为生产Kubernete集群运行静态五成员etcd集群。合理的规模是在需要更高可靠性时，将三成员集群升级为五成员集群。”

这些文档都暗示扩展etcd集群只是为了容错，而不是性能，事实上，扩展成员会降低性能。

笔者经过测试发现，对于给定大小的控制平面机器，3节点集群将提供最佳性能，但只能容忍一个节点出现故障。对于大多数环境，这够了（假设有良好的监控和流程来及时处理故障节点），但如果应用程序需要非常高的可用性并同时容忍2个控制平面节点故障，则5节点群集只会导致约5%的性能损失。

自动缩放怎么样？

很明显，etcd集群的自动扩展（即增加更多节点以响应高CPU负载）是一件坏事。正如我们从基准测试中看到的，向集群添加更多节点将降低性能，因为需要跨更多成员同步更新。此外，自动扩展还使你面临这样的情况，即可能使用偶数个集群成员运行，至少在扩展操作发生时是暂时的，因此增加了节点故障影响etcd可用性的可能性。

事实上，Kubernetes官方文件明确指出：

“一般规则是不放大或缩小etcd集群。不要为etcd集群配置任何自动缩放组。强烈建议始终以任何官方支持的规模为生产Kubernetes集群运行静态五成员etcd集群。”

使用自动缩放组从控制平面节点的故障中恢复，或者用CPU能力更强的节点替换控制平面节点是合理的（这就是AWS的EKS在讨论控制面板自动缩放时的含义）。然而，在替换控制平面成员时，甚至是失败的成员时，需要注意一些细节——这并不像添加新节点那么简单！

在紧急情况下，移除故障节点，然后添加新节点

从表面上看，添加一个新节点，然后删除故障节点似乎与删除故障节点，然后添加新节点相同。然而，前者的风险更大。

要了解原因，请考虑一个简单的3节点集群。3节点集群的仲裁数为2。如果一个节点出现故障，etcd集群可以继续使用其剩余的两个节点。但是，如果你现在向集群中添加新节点，仲裁将增加到3，因为集群现在是4节点集群，正在计算递减节点，我们需要一半以上的可用节点来防止分裂。

如果新成员配置错误，并且无法加入集群，现在有两个发生故障的节点，集群将关闭且无法恢复。因为只有两个节点在上，并且所需的法定数为3。

将此与首先删除故障节点进行比较。删除故障节点后，我们现在有一个2节点集群，具有2节点仲裁和两个节点（因此我们不能容忍任何进一步的故障，但我们可以在此状态下正常运行）。如果现在添加一个节点，创建一个3节点集群，仲裁将保持在2。如果新节点未能加入，我们的3节点集群中仍有2个节点，并且可以再次删除和重新添加新节点。

关键是，当etcd成员节点发生故障时，在尝试用新节点替换之前，从etcd中删除故障节点。

在Kubernetes文档中记录了制定这一程序的过程。但是，如果你运行的是专门为Kubernetes设计的操作系统TalosLinux，则过程会简单得多。Talos Linux具有帮助功能，可以自动删除关闭的etcd节点：

talosctl etcd remove-member   ip-172-31-41-76 kubectl delete node  ip-172-31-41-76

然后，你可以添加一个新的控制平面节点，在TalosLinux中，这与使用控制平面启动一个新节点一样简单。用于创建其他控制平面节点的yaml。

还应注意的是，Talos Linux使用etcd的学习器功能——所有新的控制平面节点都作为无投票学习器加入etcd，直到它们赶上所有事务。这意味着添加额外节点不会增加仲裁，直到该节点成为可靠成员，然后自动提升为投票成员。但是，这种增加的安全性不会改变在添加新节点之前删除失败节点的建议。

首先添加新节点，然后删除要替换的节点

要升级仍在运行的控制平面节点，并将其替换为具有更多CPU或内存的机器，操作顺序与节点发生故障时相反——先添加新节点，然后删除旧节点。

要了解原因，请考虑3节点etcd集群的情况，你希望将节点升级到更快的硬件。仲裁将需要2个节点才能使集群继续处理写操作。

一种方法是首先移除要替换的节点。这将留下一个2节点集群，仲裁为2。然后添加新节点。这会将群集返回到仲裁为2的3节点集群，但在转换过程中，没有容错——不适当的时间故障可能会使集群停机。

另一种方法是先添加新节点，创建一个4节点集群，该集群的仲裁数为3，然后删除一个节点。这会将集群返回到仲裁为2的3节点集群，但在转换期间，集群可以容忍节点的故障。

因此，在删除要替换的节点之前添加新节点更安全，如果它是可操作的。

在Kubernetes网站上记录了执行此操作的过程。Talos Linux再次让这变得更容易：

——通过使用controlplane.yaml文件引导添加新的控制平面节点。

——告诉要替换的节点离开集群：talosctl  -n 172.31.138.87 reset

——kubectl删除节点

“talosctl Reset”导致节点被擦除。Talos知道节点何时是控制平面节点，如果是，它将在重置时“优雅地”离开etcd。

总结

关于Kubernetes控制平面的大小和管理：

——使用三个或五个控制平面节点运行集群。对于大多数用例，三个就足够了。五个节点将提供更好的可用性，但在所需的节点数量方面成本更高，而且每个节点可能需要更多的硬件资源来抵消较大集群中出现的性能下降。

——实施良好的监控并将流程落实到位，以便及时处理故障节点（并测试它们）。

——即使有可靠的监控和替换故障节点的程序，备份etcd和控制平面节点配置，以防范意外灾难。

——监控etcd集群的性能。如果etcd性能缓慢，则垂直缩放节点，而不是节点数量。

——如果控制平面节点出现故障，请先将其删除，然后添加替换节点。

——如果替换未失败的节点，请添加新节点，然后删除旧节点。

原文链接：

https://thenewstack.io/how-many-nodes-for-your-kubernetes-control-plane/