集群升级分析
Kubernetes升级分析记录。
网上大部分关于Kubernetes升级的文章，都没有考虑生产环境的业务影响，在参考时要谨慎判断。
1. 社区策略
1.1 版本兼容
总结：一次只能升级一个minor版本，比如1.18.x升级到1.19.x。
1.2 升级方案
2. 业界方案
2.1 原地升级
将kubernetes相关组件原地替换软件包，重启服务完成升级。
公司 | 方案 |
|---|---|
蚂蚁 | |
vivo | |
Google云 | |
阿里云 |
Google云的升级文档描述了升级过程需要移除节点上的Pod， 未找到回退方案。
阿里云原地升级不影响业务， 替盘升级要移除节点上的Pod， 不支持回退。
原地升级要关注一些可能导致应用不可用的场景，升级过程是否能容忍？具体要结合自己环境的实际运维经验判断，比如下面一些Bug，和版本及架构等都有关系。
如下Bug可能导致Node出现NotReady，概率低，但是已经遇到过多次。
如下Bug在升级过程中可能引发coreDNS不可用，导致集群应用大面积异常。
2.2 迁移升级
新建一个高版本集群，将应用迁移应用到新集群，下线旧版本集群完成升级。
公司 | 方案 |
|---|---|
Alibaba Cloud |
官方/公司案例较少，在Medium、Reddit等站点能看到一些个人总结、讨论。
根据应用运行环境，如下要考虑。
防火墙，迁移可能会导致应用对外暴露的IP变化。
Chart，版本跨度大可能导致API变化，涉及Chart修改。
OS依赖，检查应用是否依赖OS，比如日志清理脚本，特殊内核参数等。
成本，大集群的升级成本将会非常高。
3. 升级策略
升级这件事上，成本和风险要做取舍。
要稳定 ，考虑替换升级，风险可控，万一升级过程遇到预期外的异常，可以快速回退到原集群，确保服务正常。
要成本 ，考虑原地升级，风险较大，万一升级过程遇到预期外的异常，可能必须等到问题解决才能拉起服务，除非回退方案做的足够好。但是毕竟原来的运行环境已经变化了，回退方案也是一个新的变更，也有风险。
成本与应用强相关，如果应用能容忍按节点驱逐，即使替换迁移，成本也不会增加很多，比如旧集群下线的节点加入新集群使用；如果无法容忍按节点驱逐，意味着节点上的Pod迁移完成前，这个节点不能被新集群使用，因为无法按节点驱逐，导致清空一个节点的周期将会很长，具体取决于上面的应用什么时候迁移走。
4. LTS
5. 工具
Kubernetes objects api-version compatibility checker and provides migration path for K8s objects and prepare it for cluster upgrades
Kubernetes PreUpGrade (Checker)
6. 参考
记录下升级分析需要的一些信息。