正文
前言
本人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进行特定的参数设置.
