版本偏差策略

前言

一个软件得到官方的支持是非常重要的,因为软件有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. 前提条件
    这里演示从1.27升级到1.28
  • 确保1.27已经升级到1.27的最新补丁版本
  • 将组件升级到1.28的最新补丁版本
  1. 升级Apiserver
  2. 升级controller-manger、scheduler
  3. 升级kubelet
  4. 升级kube-proxy