Rancher 2.4如何实现零宕机升级集群

共计 1342 个字符，预计需要花费 4 分钟才能阅读完成。

丸趣 TV 小编给大家分享一下 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 可用性结构。

以上是“Rancher 2.4 如何实现零宕机升级集群”这篇文章的所有内容，感谢各位的阅读！相信大家都有了一定的了解，希望分享的内容对大家有所帮助，如果还想学习更多知识，欢迎关注丸趣 TV 行业资讯频道！