部署于K8S集群上面应用性能影响点推测

前言

本人2017年第一次接触K8S. 中间断断续续学习K8S相关的内容.
但是最近一年,几乎没太有学习.
因为之前学习了四五年, 一直以为产品马上要用
结果一直被浇冷水.
去年开始学乖了. 不这么搞了
但是发现产品要开始用了..
这里只能临时抱佛脚. 猜测一下可能影响K8S上面应用性能的要点.

---

摘要

1. 物理层面的影响
2. 虚拟化层的影响(如果有)
3. OS层的影响(内核参数, 网络参数等)
4. K8S部署模式的影响
5. K8S网络组件,服务注册发现(etcd压力)的影响.
6. 应用配置的影响(limit request等)
7. POD数量的以及服务出口的影响.
8. 镜像层数,大小,复杂度对拉取,启动和运行性能的影响.
9. 容器运行的损耗.
10.K8S的监控,探针对性能的影响.
11.POD迁移,auto scale 等对性能波动的影响.
12.启动脚本的影响(JVM内存参数优化等)

---

1. 物理层

1. 物理机器的价格
   贵的服务器不一定好, 但是好的服务器一定贵.
2. 物理机器的CPU,主频,核数.电源模式.
   注意 最好是设置最高性能, 避免平衡模式导致性能下降.
3. 空调温度
   举个例子. 温度较高时,DDR内存的充电会从64ms充电完成,降低到32ms.
   会导致充电频率增大一倍,将低内存带宽.
   CPU温度过高也会导致自主降频保护.
4. 网络设备.
   网卡性能,双工设置,网线材质,交换机配置,交换机压力负责.机房机柜距离.
5. 硬盘类型-raid卡性能.
   影响镜像拉取,有应用服务器的启动速度.并且如果前端文件较多,会影响响应速度.
6. 机器CPU类型.是否信创. 内存参数等.

---

2. 虚拟化层的影响

1. 虚拟化大大降低了部署复杂度,提高了部署效率.
   但是也会导致一定的性能开销. 理论上会导致至少15%-25%的性能损失.
2. 虚拟化的超售情况.
   虚拟化一般内存超售的比较少(除非是气泡技术).
   CPU可能会超售, 会出现挤占的情况,影响性能.
3. 虚拟化的类型.
   理论上类似于阿里的神龙,腾讯的黑石,是最佳的虚拟化(不完全)实现技术
   ESXi的效率理论上比Openstack的KVM要优秀一些.
4. 虚拟化驱动.
   不管是硬件和软件驱动一定要最新.
   最新可能有bug,但是旧的一般 性能都不好

---

3. OS层的影响

1. 内核版本
   至少4.18, 太低的版本无法发挥高版本软件的性能.
2. 内核参数
   tcp 文件 进程树 磁盘文件类型 落盘参数 是否开启大页等等.
3. 机器剩余磁盘空间
   影响IO.
4. 是否进行过优化, 是否关闭了不必要的服务.

---

4. K8S部署模式的影响

1. K8S的版本
   不同版本可能有不同的性能表现
2. K8S的部署方式
   是源码部署, 二进制部署, 容器化部署,还是其他部署模式.
   理论上经过最优秀编译参数的源码部署性能可能最好
   但是技术要求最高.难度也最高.
   越是简单的部署,兼容性越高的产品.他越难发挥特定硬件上面的性能.
3. 特定的部署工具
   不建议minikube 等方式用于生产.建议选用商业版.
4. K8S使用的容器平台与操作系统内核是否最佳适配.
   建议选用官方文档里面测试过最优秀的组合.

---

5. K8S网络组件,服务注册发现(etcd压力)的影响.

1. 网络组件
   flannel calico cilium 不同网络组件对网络性能影响很大.
2. 服务注册发现的性能
   拆分SU的情况下可能用到Kube DNS等的组建, 会有一定的性能损耗.
3. service 去找pod时也需要使用pod - id转换.可能也有开销.
4. etcd等的压力
   etcd里面存储的内容很多,不仅有网络等的配置(pod node ip设置.)
   还影响产品的部署效率和k8s命令的查询速度.

---

6. 应用配置的影响(limit request等)

1. 需要确认好node的配置.一遍进行pod的资源限制.
   建议优化好pod的最低配置,避免影响性能.
2. Pod与node的affinity的影响.
   不建议pod集中于某一些node. 一方面有争用.
   另外一方面不高可用.
3. pod的配置需要与产品进行验证.
   不建议私自修改参数. 尤其是内存和CPU的参数.
   而且需要针对不同的应用类型进行定制话的修改.
   比如前端应用可能需要更多的内存缓存, 更好的磁盘读写.
   后端计算查询汇总应用可能需要更多的CPU进行计算

---

7. POD数量的以及服务出口的影响.

1. 建议对产品的容量进行规划. 定义好pod数量.
   每个pod支撑的用户数量是有限制的, 建议可以进行自动扩展等.
2. 应用出口ingress 面对 service 以及service面对 pod的黏性.
   虽然黏性能够降低部分云原生的要求
   但是建议还是使用黏性来降低必须要分布式一致性的缓存要求.
3. proxy对服务出口转发的性能的影响
   ingress可能需要对所有的node进行转发. 里面的参数和配置也表重要.

---

8. 镜像层数,大小,复杂度对拉取,启动和运行性能的影响.

1. 镜像尽量要精简.
   一方面是大小,一方面是层数.
   太大了拉取和推送性能低.层数多了IO性能会收到影响.
2. 降低复杂度
   建议镜像内复用文件系统的部署模式.减少不必要的兼容性问题.
3. 进行启动优化.
   springboot复杂之后启动速度太慢了 需要优化.
4. 镜像存储路径的设置
   建议要尽量大. 定期清理. IO要好,避免影响部署效率.

---

9. 容器运行的损耗.

1. 容器层需要关注有调优
   避免容器启动过多,调度出问题. 并且因为路由表增多后导致路由性能下降.
2. 建议选择最优的容器层的设置.
   建议部署时确认版本, 确认参数(systemd,或者是一些部署参数等.)
3. 容器自己也有网络栈, 建议选用最佳的网络栈, 避免不必要的损耗.

---

10. K8S的监控,探针对性能的影响.

1. cAdviser 等组件的影响.
   K8S会自动收集pod等的运行情况, 虽然不会影响POD自身的运行,但是会对整个服务器产生更多的压力.
2. sideCar模式的影响.
   istio等组件,以及安全设置可能对应影响产品的交互性.
3. 监控探针会产生多余的非产品的流量, 如果产品并发量足够多,建议能够拆分不同的物理网卡进行承载.
   区分开东西和南北流量.

---

11.POD迁移,auto scale 等对性能波动的影响.

1. POD迁移等
   从容器承载应用开始一般就要求应用服务器是无状态.
   因为再K8S看来容器都是朝生墓死的. 最开始K8S都是要求不开swap
   可以做到fast failure 避免程序在半死不活状态影响判断.
   但是这就导致了一个问题. pod可能会不听的启动迁移.
   如果没有预热和预加载会导致前几次响应超级缓慢. 需要优化.
2. 自动扩容等的影响.
   与上面一个内容类似. 因为可以自动或者是人工的扩容, 这一块必须得进行相关的优化.
   不然首次访问可能存在问题
   可能需要预热和特定脚本进行拉起特定产品的缓存.

---

12. 启动脚本的影响(JVM内存参数优化等)

1. JDK_1.8_191开始.java就可以识别自己是在镜像内了.
   但是建议针对不同的应用还是进行JVM内存参数的设置.
   比如文档系统高IO占用的和流程高CPU占用的使用相同的JVM参数肯定不合适.
   建议需要有最佳时间, 进行比率设置.
2. JAVA版本的选择.
   不建议选用没有验证过的java版本跑生产. 建议使用成熟稳定测试过的版本.
3. 不同CPU的处理
   华为鲲鹏社区曾经发文称,ARM的codecache的要求要比x86的codecache内存要大
   因为RISC的指令集在相同代码编译时会产生更大的code cache item.
   同样的产品, 对code cache 方法区缓存的要求会更大.
   建议针对不同架构的CPU进行特定的参数设置.