![]()
概述
做k8s集群工作节点的规划时,首先需要考虑的问题是: 应该使用哪种类型的服务器(Linux)实例节点,节点数量又需要多少个?
集群容量
通常k8s集群可以看作将多个服务器(Linux)节点抽象为一个大的”超级服务器节点”,该超级节点的总计算能力(如CPU和内存)是所有组成节点的能力之和.假如要在群集上运行的一组应用程序需要,需要一个总容量为8个CPU内核和32 GB 内存的集群,可能的两种实例类型及数量配置如下图:
![Kubernetes工作节点的数量规划？]()
方案一: 使用2台4核16GB服务器实例作为k8s工作节点
方案二: 使用4台2核8GB服务器实例作为k8s工作节点
哪种方案更好呢? 我相信大多数人此时有点懵逼了吧,为解决大家的这个疑惑下面我分别对这两种方案的利弊。
方案一
使用2台4核16GB服务器实例作为k8s工作节点的情况
优势
1.减少管理开销
与必须管理大量计算机相比，管理少量计算机较省力
2. 降低每个节点的成本
虽然功能更强大的机器比低端机器更昂贵，但价格上涨并不一定是线性的;如一台具有10个CPU内核和10 GB RAM的计算机可能比10台具有1个CPU内核和1 GB RAM的计算机便宜
3.允许运行需要大量资源的应用程序
如果您有一个需要8 GB内存的机器学习应用程序，则不能在只有1 GB内存的节点的群集上运行它;但是您可以在具有10 GB内存节点的群集上运行它
劣势
1.每个节点有大量Pod
每个Pod都会在该节点上运行的Kubernetes代理上引入一些开销，例如容器运行时(例如Docker)，kubelet和cAdvisor。
kubelet对节点上的每个容器执行常规的活动性和就绪性探测-更多的容器意味着kubelet在每次迭代中需要进行更多的工作。
cAdvisor会收集节点上所有容器的资源使用情况统计信息，而kubelet会定期查询此信息，并将其公开在其API上-同样，这意味着cAdvisor和kubelet在每次迭代中都需要做更多的工作。
如果Pod的数量变大，这些事情可能会开始减慢系统速度，甚至使系统不可靠。
2.有限复制
少量节点可能会限制应用程序的有效复制程度，如果您有一个由5个副本组成的高可用性应用程序，但是只有2个节点，则该应用程序的有效复制程度将降低为2。
3.爆炸半径更大
如果您只有几个节点，那么发生故障的节点的影响会比拥有多个节点的影响大。
4.大缩放比例
Kubernetes 为云基础架构提供了一个集群自动伸缩器，可根据当前需求自动添加或删除节点。
方案二
使用4台2核8GB服务器实例作为k8s工作节点的情况;这种方法包括由许多小节点而不是几个大节点组成集群。
这种方法的优缺点是什么?
使用许多小节点的优点主要对应于使用少量大节点的缺点。
优势
1.爆炸半径减小
如果您有100个Pod和10个节点，则每个节点平均仅包含10个Pod。因此，如果其中一个节点发生故障，则影响的pod数量较少。
很有可能只有您的某些应用程序受到影响，并且可能只有少量的副本受到影响，因此整个应用程序都不会受到影响。
2.允许高复制,实现高可靠性
Kubernetes调度程序可以将每个副本分配给更多不同的节点，这意味着，如果一个节点发生故障，最多将影响一个副本，并且您的应用程序仍然可用。
劣势
1.大量节点
使用较小的节点，则自然需要更多的节点才能达到给定的群集容量，对于Kubernetes控制平面而言，大量节点可能是一个挑战。
如每个节点都需要能够与其他每个节点进行通信，这使得可能的通信路径的数量与节点数量的平方成正比增长，所有这些都必须由控制平面进行管理。
2.更多的系统开销
Kubernetes在每个工作程序节点上运行一组系统守护进程，如容器运行时Docker、kube-proxy、kubelet等，这些守护程序一起消耗固定数量的资源，如果使用许多小节点，则这些系统组件使用的资源部分会更大。
3.降低资源利用率
如果使用较小的节点，那么最终可能会遇到大量资源片段，这些资源片段太小而无法分配给任何工作负载，因此导致资源浪费。
4.小节点上的Pod限制
在某些云基础架构上，小节点上允许的最大Pod数量比您预期的受到更多限制，如Amazon Elastic Kubernetes服务(EKS)就是这种情况，其中每个节点的Pod的最大数量取决于实例类型。
结论
因此您应该在集群中使用几个大型节点还是多个小型节点?与往常一样,通常没有确定的答案!
如果您的应用程序需要10 GB的内存，则您可能不应该使用小型节点-群集中的节点应至少具有10 GB的内存;
如果您的应用程序需要10倍的复制才能实现高可用性，那么您可能不应该仅使用2个节点-您的集群至少应包含10个节点
