最近更新时间:2024-09-10 16:07:39
创建Kubernets集群时,需结合节点资源预留和业务需求规划节点配置。若选用小规格节点可能存在以下弊端:
网络性能不足:小规格节点的网络资源受限。
节点容量不足:节点上有一部分资源默认预留用于Kubernetes和KCE的系统组件,包括CPU、内存和磁盘等,小规格节点的可分配资源可能不足。
资源利用率低:节点资源分配时,如果一个容器基本可以占用一个小规格节点,此节点的剩余资源就无法利用(构建新的容器或者是恢复失败的容器),在小规格Worker节点较多的情况下,存在资源浪费。
使用大规格节点的优势:
网络资源充足:网络带宽大,对于大带宽类的应用,资源利用率高。此外,容器在一台节点内建立通信的比例增大,减少网络传输。
镜像拉取效率高:因为同节点上镜像只需要拉取一次就可以被多个容器使用,小规格节点多的集群相对拉取镜像的次数会更多,影响容器的启动速度。
Master节点上运行着apiserver、etcd、scheduler、controller-manager等核心组件,对集群稳定性和可用性有至关重要的影响。生产环境的集群需慎重选择Master节点规格,Master规格跟集群规模有关,集群规模越大,所需要的Master规格也越高。
集群规模可以从多个角度衡量,如节点数量、pod数量、crd资源数量等,且同等规模下,pod大小、apiserver请求qps也会影响对apiserver的压力。KCE环境压测中发现,pod数量会显著影响apiserver内存消耗,您可参考此处建议值来选定Master规格。
压测环境说明:
KCE压测中所用pod yaml大小约为3kB,若您的业务pod较大,可参考压测规律对apiserver内存预估进行适当调整。当pod数量大于3000,pod yaml大小大于3500kB时,apiserver内存消耗近似随pod数量和pod yaml大小线性增长,当qps为50时,可参考如下测算公式(pod数量单位为个,pod yaml大小单位为B):
apiserver内存消耗=3+(pod数量-3000)/1000*1G+(pod yaml大小-3500)/1000*0.4M*pod数量
Master机型 | 推荐pod | 上限pod | 推荐qps | 上限qps |
4核8G | 3000 | 5000 | 30 | 50 |
8核16G | 6000 | 10000 | 60 | 80 |
16核32G | 12000 | 20000 | 80 | 100 |
32核64G | 24000 | 40000 | 110 | 130 |
64核128G | 48000 | 80000 | 200 | 220 |
如您有更大规模集群的配置需求,可工单咨询KCE后台一同进行评估。
为了保证节点的稳定性,金山云容器集群节点上会根据节点的规格预留一部分资源给Kubernetes的相关组件(kubelet,kube-proxy以及docker等),详见集群资源预留,建议结合资源预留和业务的资源申请,选择合适的节点配置。
根据业务类型确认CPU:Memory比例
对于使用内存比较多的应用例如java类应用,建议考虑使用1:8的机型;对于CPU密集型的业务,可以申请1:2的机器;如果是不同业务的混合部署,建议给不同机型或者配置的节点打上标签,配合nodeAffinity调度pod。
纯净模式