容器云平台的性能设计

容器云平台的性能设计

目录

1 Kubernetes整体容量规划 (01)

2 Master节点性能设计 (02)

2.1 Master节点架构和容量设计 (02)

2.2 Master节点监控和性能调优 (04)

2.2.1 Master性能调优 (04)

2.2.2 Master相关监控指标建议 (05)

3 Infra节点性能设计 (05)

3.1 EFK架构和容量 (05)

3.2 EFK监控和调优 (07)

3.3 Prometheus架构和容量 (08)

3.4 Prometheus监控和调优 (12)

3.5 Ingress架构和容量 (13)

3.6 Ingress监控和调优 (14)

4 应用节点规划和调整 (15)

4.1 计算节点架构和容量 (15)

4.1.1 容量规划 (15)

4.1.2 CPU Manager (16)

4.1.3 存储 (16)

4.2 计算节点监控和性能调优 (17)

4.3 计算节点监控和性能调优 (18)

4.3.1 应用资源依赖 (18)

4.3.2 应用配置优化 (20)

5 参考 (23)

1 Kubernetes整体容量规划

通常一个完整的高可用Kubernetes群集由3类节点组成：

◎Master节点：用于运行API Server和ETCD等控制服务。

◎Infra节点：涉及容器基础设施相关，包括负责日志查询的EFK集群、负责容器监控的Prometheus和AlertManager集群和负责外部流量导入的Ingress集群等。

◎App节点：负责运行普通业务应用的节点。

每个计算节点都具有一些可分配的资源（CPU，内存，GPU等）。 因此如何更合理地分配这些计算资源，在确保平台本身稳定性的同时满足业务需求并提升资源利用率，这就需要对集群的容量进行规划。

针对集群计算资源，首先需要定义节点数量和总资源容量。假设要在群集上运行的一个应用需要总容量为8 Core 32G的计算资源，这里主要有2种部署思路：

一个思路是使用2台4Core 16GB服务器实例作为Kubernetes工作节点，即较少的节点、较高配的服务器（类似集群直接使用物理机）。另一个思路是使用4台2Core 8GB服务器实例作为Kubernetes工作节点（类似集群使用虚拟机）。这么，哪种思路更有优势？下文我们做下对比：

由上图可以发现，如果使用高配置方案，针对集群的管理便利性由于节点数量较少而变得较为简单，同时针对应用的资源利用率会有所提升。但是同样也需要注意到由于节点密度较高，单个节点出现故障后的导致应用影响的爆炸半径会比较大，对节点容量规划和监控自愈响应有一定要求。

因为上述特点，在Kubernetes集群节点容量规划上，应保持节点配置和节点规模的平衡。下文将具体阐述主要组件的规划思路。

2 Master节点性能设计

2.1 Master节点架构和容量设计

Master节点通过static pod启动API Server、Controller Manager、Scheduler等控制服务，以及ETCD分布式数据库。后者是CoreOS基于Raft协议开源的分布式key-value存储，可用于服务发现、共享配置以及一致性保障（如数据库选主、分布式锁等）。在这里用于存储Kubernetes API Server所接收的API对象。

对于Master的容量设计主要包括如下几点：

1.节点和服务高可用。

关于这点Kubernetes本身高可用部署架构就涉及。建议至少3台Master节点。同时通过设置污点节点亲和性的方式，避免应用容器调度到Master上。参考下图Master节点架构，Master上主要涉及kube-apiserv-er、kube-controller-manager与kube-scheduler几个服务。高配置方案低配置方案管理便利性

节点少，管理成本低节点多，管理成本高应用可用资源

单节点资源多、应用适配灵活单节点资源较少、应用单实例资源依赖不可过大应用稳定性

单节点应用较多，爆炸半径大单节点应用较少，爆炸半径小资源利用率单节点资源颗粒度大，可充分利

用单节点资源颗粒度小，可能无法满足应用而闲置

kube-apiserver：由于服务本身无状态，需要确保通过负载均衡实现访问API Server多实例的高可用访问。

kube-controller-manager与kube-scheduler：由于这两个服务一般使用单一主节点active，多个从节点standy的模式运行。其内部会使用锁争用方式确认主节点，其余节点处于standy状态。直到主节点发生异常锁失效后被其他节点争用代替（在后续开发方案设计的文章中会涉及实现方法）。

2.ETCD

本身需要高可用部署，建议至少3个节点，根据实际性能情况可以和Master一并运行或独立部署。官方使用kubeadm部署的方案参考

https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/ 。物理硬件上，由于ETCD其高度依赖存储和网络，建议使用SSD等高IOPS存储方案并确保ETCD集群之间以及API Server访问ETCD网络条件良好。另一方面，ETCD也涉及客户端和服务器优化，这部分在下一节再进行讨论。

通常来说Master节点的性能与ETCD相关，与集群中API对象的读写频率成正比。若集群节点数量稳定，总体而言其TPS和IOPS还是趋于稳定的。因此建议采用合理计算资源的高配置方案搭建集群。