Kubernetes集群不是在升级，就是在升级的路上。而对于维护K8s集群的团队来说，最担心的莫过于，系统因为K8s升级而引发了服务器大规模崩溃。

目前k8s尚未提供LTS版

官方k8s版本更迭太快，公司跟不上节奏

企业期望稳定性并不是出于保守或惰性，而是太多现实的原因——客户与供应商达成的合同、监管和法定要求、技术风险政策的限制，都在此列。

但为了灵活而生的K8s，似乎在作为基础设施的层面上，并不是一个足够稳重的搭档，它的更新速度非常快，大大超出业务迭代。

即便K8s社区支持的深度和广度足够可靠的支持使用者能从社区类似的问题中找到答案，即便大多数组织能够忍受部署K8s的痛苦，但频繁的升级操作却让许多用户叫苦不迭。

不断重写东西，对于中小型团队而言几乎是不可能的。

跟上K8s版本发布节奏，有多难

Kubernetes 遵循“N-2”支持政策（最近的 3 个次要版本获得安全和错误修复）以及“15周”的发布周期。
因此，一个版本会支持14个月（12 个月的支持期和 2 个月的升级期）。

升级的难度要大于重新部一套

官网升级方案：https://kubernetes.io/zh-cn/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/

比较靠谱的升级方案

1、公司有一定规模，架构时：采用异地双活的方案，DNS层轮询AB两个机房
	升级时，dns解析去掉一个机房，进行专门的升级（重部一套新的），后再加入，然后再升级另外一个机房
	-----》本质就是蓝绿发布
	
2、如果公司规模很小，就一套k8s集群，但用的都是云主机，那建议还是蓝绿最靠谱

3、如果公司规模很小，就一套k8s集群，并且用的都是物理机，这种只能按部就班的升级，提前在测试环境演练好，做好回滚方案，在晚上进行，开发、测试、运维都一齐加班
Kubernetes的升级过程需要考虑多个维度，包括集群中的主节点和工作节点、在Pod内运行的应用程序以及API版本。下面是一个基本的步骤来平滑地升级您的Kubernetes集群：
1、备份和计划：在进行任何升级操作之前，一定要备份你的etcd数据存储以及任何相关的配置文件。同时，明确升级时间，通知涉及人员等。
2、先升级主节点：使用kubeadm upgrade plan命令检查可用的升级。然后，使用kubeadm upgrade apply命令升级你的主节点。这将包括Kubernetes API server，控制管理器，调度程序，和默认DNS服务器等组件。
3、升级工作节点：升级完主节点后，你可以逐个将工作节点从集群中切出，升级，并重新加入集群。这个过程可以使用kubectl drain（用于准备和停止节点上的工作负荷），kubeadm upgrade node（用于实际升级节点），和kubectl uncordon（让节点可以被调度）命令来完成。
4、升级网络插件：主节点和工作节点完成升级后，如果你使用了网络插件，还需要按照插件提供商的指导进行升级。
5、验证升级：升级完成后，使用kubectl get nodes命令确认所有的节点都已经升级到新的版本。此外，还需要对你的应用程序进行测试，保证升级没有产生负面影响。
这只是一个大致的流程，实际的升级操作可能会更加复杂，因为可能会涉及到集群内的不同程序以及API对象的升级。在操作之前建议每一步都要计划充分并再三测试以确保环境的稳定。