前言
一个软件得到官方的支持是非常重要的，因为软件有bug、缺陷，只有官方人员的修复才最可靠。一旦说这个版本不被官方支持了，也就意味着有问题也不会修复了。
总结几个时间点
- 官方文档docs是能看到最近5个版本的文档，但是能看到文档不代表这5个版本都还被官方支持。
- 一个版本（例如1.28）从开始开发到发布大概会经过4个月，比如1.28这个版本从开始开发2023年5月24号到最终发版2023年8月15号经历了2个月21天，再加上需求分析的4周，一共是经历了3个月21天。
版本支持的时间
一个版本发布后（例如1.28），从发布的那天起，大概会被官方支持12个月，然后此版本进入维护模式，进入维护模式后的2个月结束生命周期。例如1.28是2023年8月15号发布，进入维护模式的时间是2024年8月28号，生命周期结束于2024年10月28号。
一个K8S集群中各组件的兼容性
在一个K8S集群中，最理想的状态是所有组件版本完全一致，但是实际情况可能没这么理想。不过在一个集群中，版本不一致是有要求的。
- Apiserver 只能允许有一个版本的差别。例如1.28和1.27的apiserver是兼容的。
- kubelet 可以比Apiserver低三个版本。例如1.28、1.27、1.26、1.25。
- kube-proxy 可以比Apiserver低三个版本。例如1.28、1.27、1.26、1.25。
- controller-manage和scheduler 可以比Apiserver低一个版本。例如1.28、1.27
- kubectl 可以比apiserver版本新或者旧一个版本。例如1.29、1.28、1.27
如果为了省心来说，可以记忆为各组件的版本不能比Apiserver版本新，只能比Apiserver低一个版本来保证最大程度的兼容。
升级k8s版本的顺序
- 前提条件
这里演示从1.27升级到1.28
- 确保1.27已经升级到1.27的最新补丁版本
- 将组件升级到1.28的最新补丁版本
- 升级Apiserver
- 升级controller-manger、scheduler
- 升级kubelet
- 升级kube-proxy