Kubernetes工作节点的数量规划？

概述

规划k8s集群工作节点时，首先要考虑的问题是应该使用哪种类型的服务器(Linux)实例节点:以及需要多少个节点？

集群容量

通常k8s集群可以被视为将多个服务器(Linux)节点抽象成一个大型“超级服务器节点”。超级节点的总计算能力(如中央处理器和内存)是所有组成节点能力的总和。如果群集上运行的一组应用程序需要一个总容量为8个CPU内核和32 GB内存的群集，以下两种可能的实例类型和数量配置中哪一种更好？我相信大多数人现在都有点困惑。为了解决这个问题，我想分别讨论这两项计划的利弊。

@

方案一: 使用2台4核16GB服务器实例作为k8s工作节点

方案二: 使用4台2核8GB服务器实例作为k8s工作节点

方案一

优势

与必须管理大量计算机相比，管理少量计算机的劳动强度较低

1.减少管理开销

2. 降低每个节点的成本

3.允许运行需要大量资源的应用程序

劣势

1.每个节点有大量Pod

2.有限复制

Each Pod的集群上运行它，这会给在该节点上运行的Kubernetes代理带来一些开销，例如容器运行时(例如Docker)、kubelet和cAdvisor。

3.爆炸半径更大

4.大缩放比例

如果Pod的数量变大，这些事情可能会使系统变慢，甚至使系统变得不可靠。

方案二

少量节点可能会限制应用程序的有效复制。如果您有一个由5个副本组成但只有2个节点的高可用性应用程序，应用程序的有效复制将减少到2个。

优势

1.爆炸半径减小

2.允许高复制,实现高可靠性

劣势

1.大量节点

2.更多的系统开销

这种方法的优缺点是什么？

3.降低资源利用率

4.小节点上的Pod限制

结论

如果您有100个PODs和10个节点，每个节点平均只包含10个PODs。因此，如果其中一个节点出现故障，受影响的pod数量很少。

Kubernes调度程序可以将每个副本分配给更多不同的节点，这意味着如果一个节点出现故障，最多会影响一个副本，并且您的应用程序仍然可用。

使用较小的节点，这自然需要更多的节点才能达到给定的群集容量。对于库本内斯控制平面，大量节点可能是一个挑战。

kubernes在每个工作节点上运行一组系统守护程序，如容器运行时Docker、Kube代理、kubelet等。这些守护进程一起消耗固定数量的资源。如果使用许多小节点，这些系统组件使用的资源部门分支将会更大。

在一些云基础架构上，小节点上允许的最大PODs数量比您预期的更有限，例如亚马逊弹性库本内服务(EKS)，其中每个节点的最大PODs数量取决于实例类型。

那么您应该在集群中使用多少个大节点或多少个小节点？像往常一样，通常没有明确的答案！

如果您的应用程序需要10 GB的内存，您可能不应该使用小节点——集群中的节点应该至少有10 GB的内存。

如果您的应用程序需要10倍的复制来实现高可用性，那么您可能不应该只使用2个节点——您的集群应该至少包含10个节点