Rancher 2.4实现零宕机升级集群，无需担心组件出现短暂故障！

在瞬息万变的技术世界中，为用户提供持续不断、快速的创新至关重要。Kubernetes是一个极佳引擎，可以在云端、本地以及边缘驱动创新。因此，Kubernetes及其整个生态系统本身迭代十分迅速，让Kubernetes保持最新状态以确保安全和新功能的使用对于任何部署来说都至关重要。

什么是零宕机升级集群

Rancher 2.4已于上周GA，在Rancher 2.4中，我们正式引入了零宕机集群升级功能。通俗来说，这个功能可以让你在飞机飞行过程中更换引擎，而不受任何干扰。开发人员可以继续将应用程序部署到集群，用户也可以继续使用服务而不会受到干扰。与此同时，与Rancher的OOB （out of band）Kubernetes更新结合使用之后，集群operator可以在已发布版本的数小时内安全地发布维护和安全更新。

在Rancher之前的版本中，RKE首先升级etcd节点，并且注意不中断quorum。然后Rancher立刻迅速升级所有控制平面的节点，最后所有worker节点也会马上升级。这导致API和工作负载可用性会出现短暂故障。此外，一旦控制平面更新，Rancher便将集群状态视为“active”，使得operator可能不知道工作节点依旧在升级中。

在Rancher 2.4中，我们优化了整个升级流程以保证CI/CD流水线的正常交付和工作负载持续为流量提供服务。在整个过程中，Rancher会以更新状态查看集群，这使operator可以快速看到集群中正在发生的某些事情。

Rancher依旧先从ectd节点开始升级，一次升级一个节点，并且注意不破坏quorum。作为额外的预防措施，operator会在升级前对etcd和Kubernetes配置进行快照。并且如果你需要回滚，整个集群可以恢复到升级前的状态。

如你所知，部署应用程序到集群需要Kubernetes API可用。在Rancher 2.4中，Kubernetes控制平面节点也会一次升级一个。第一台server将会 offline、升级然后放回集群。接下来，仅当之前的节点报告其状态为健康时，控制平面节点才会开始升级。这一行为保证了API在升级过程中始终响应请求。

Rancher 2.4节点升级的两大更改

集群上的大多数活动发生在worker节点上。在Rancher 2.4中，节点的升级方式发生了两个重大变化。第一个是可以设置单次升级worker节点的数量。对于传统的方法或者较小的集群，operator可以一次只选择一个节点进行升级。对于较大集群的operator而言，可以调整设置以升级更大的批处理规模。该选项在风险和时间之间取得平衡，并提供了最大的灵活性。第二个更改是operator可以在worker节点升级前选择消耗工作负载。首先驱逐节点可以最大程度地减少Pod重新启动对Kubernetes次要版本升级的影响。

诸如CoreDNS、NGINX Ingress和CNI驱动程序之类的附加服务与worker节点同步更新。Rancher 2.4公开了每种附加部署类型的升级策略，这使得附加升级可以使用原生Kubernetes可用性结构。