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可用性结构。