Rancher 2.4实现零宕机升级集群，无需担心组件出现短暂故障！
什么是零宕机升级集群
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可用性结构。