您是否害怕将集群升级到更新的 Kubernetes 版本？有几个原因可能会促使您升级。也许您想要执行以下操作之一：

使用新的测试版 API需要更新 Kubernetes 版本的最新特性遵循使您的软件保持最新的最佳实践

无论是什么原因，都值得回顾一下您的升级过程，以确保您在升级期间最大限度地减少停机时间（和焦虑）。

需要升级的组件有哪些？

一个 Kubernetes 集群由一组节点和一个控制平面组成。工作节点托管运行容器化应用程序的 pod。控制平面管理集群中的工作节点和 Pod。

Kubernetes 集群的组件（来自kubernetes.io）

要升级 Kubernetes 集群，您将按以下顺序升级这两个组件：

升级控制平面升级工作节点

对于自托管和托管集群，升级控制平面非常简单。这篇文章将重点关注最小化工作节点升级的停机时间。

升级工作节点

在工作节点上升级 Kubernetes 版本有两种策略：

就地升级（也称为滚动更新）异地升级

对于就地升级，节点会被逐一排空并封锁，这样就不会在该节点上安排新的 Pod。然后删除该节点并使用更新的 Kubernetes 版本重新创建该节点。新节点启动并运行后，将更新下一个节点。该策略类似下面的可视化动画：

动画显示了 Kubernetes 集群中节点的就地升级

就地升级的优势在于它需要最少的额外计算资源（单个额外节点）。这种策略的缺点是它可能需要相当长的时间，因为节点会被排空并逐个升级一个个节点。此外，Pod 可能需要进行 1 次以上的移动，因为它们在节点排空期间被打乱。

对于异地升级，使用新的 Kubernetes 版本创建一个新的节点池。一旦新节点全部运行，就可以对旧节点池进行封锁，将旧节点一一排空，然后再删除旧节点池。该策略在下面的动画中可视化：

动画显示了 Kubernetes 集群中节点的异地升级

异地升级需要临时加倍计算资源以换取更短的升级窗口。升级持续时间的减少是由于新升级节点的启动时间并行化，以及 pod 移动的最小化。在此策略中，Pod 从旧节点移动到新升级的节点。

假设您对计算资源利用率的暂时增加可以接受，我们建议您使用异地升级策略来加快速度。

配置 K8s 资源

无论您选择哪种工作节点升级策略，都将涉及将您的 pod 从原始节点改组到升级节点。如果您的资源配置不正确，可能会导致停机。让我们来看看一些潜在的陷阱。

独立 Pod

Pod 是 Kubernetes 中最小的可部署对象。它代表在您的集群中运行的应用程序的单个实例。Pod 是短暂的；如果一个 pod 从一个节点被驱逐，这个 pod 不会替换自己。由于 Pod 不是自愈的，因此不建议您直接创建单个 Pod。相反，请使用 Deployment 等控制器为您创建和管理 Pod。

为了最大限度地减少停机时间，请确保您的所有 pod 都由 ReplicaSet、Deployment、StatefulSet 或类似的东西管理，升级后可能需要手动重新安排独立 pod。

Deployment

集群中的大多数 pod 都可能由Deployment控制。Deployment 代表一组没有唯一身份的相同 pod。部署通过管理应用程序的多个副本并在任何实例失败时部署替换来提高可用性。

要消除停机时间，请确保您的应用程序具有PodDisruptionBudget (PDB)。PDB 通过限制同时关闭的复制应用程序的 pod 数量来帮助提供更高的可用性。

例如，以下 PDB 声明 80% 的带有front-end标签的 pod 在中断期间（例如我们的升级）必须可用。这确保了服务负载的副本数量永远不会低于总副本的某个百分比。

apiVersion: policy/v1kind: PodDisruptionBudgetmetadata:  name: demospec:  minAvailable: 80%  selector:    matchLabels:      name: front-end

请注意，您需要确保有多个副本（至少在升级期间是暂时的），以便能够升级节点。

DaemonSet

DaemonSet确保所有（或部分）节点运行一个 pod 的副本。守护程序集通常用于节点监控或日志收集，通常不提供流量。对于这些用例，在工作程序节点升级期间数据存在小的差距通常是可以接受的。

StatefulSets

StatefulSet 是 Kubernetes 控制器类型，用于管理有状态的应用程序，例如数据库或消息队列。升级 StatefulSets 比升级 Deployments 需要更多考虑。

要消除停机时间，请确保您已配置以下内容：

添加一个 PodDisruptionBudget（请参阅“部署”部分中的说明）。对于基于仲裁的应用程序，确保运行的副本数永远不会低于仲裁所需的数量（例如，minAvailable: 51%）。确保您拥有多个副本（至少是暂时的，在升级期间）。确保保留所有 PersistentVolume 。对于基于选举的应用程序，请确保您已配置就绪探测。StatefulSet 潜在事件-1

为了说明升级 StatefulSet 时 PodDisruptionBudget (PDB) 的重要性，让我们考虑一个使用分布式消息系统STAN的示例集群。

STAN 依赖于Raft的仲裁共识，这意味着需要大多数（> 50%）的服务器可以就决策达成一致。这个集群的 STAN StatefulSet 有 5 个副本。如果其中 2 个副本失败，STAN 仍然可以运行。但是，如果超过 2 个副本失败，STAN 将无法达到法定人数并停止工作。

我们的示例集群的 STAN StatefulSet 没有 PDB。使用此配置，升级期间可能会通过以下方式失去仲裁：

由于缺少 PDB，控制计划表明可以中断任意数量的 STAN pod。

这意味着节点池升级能够同时中断超过 50% 的 STAN pod。在这种情况下，当第一个节点耗尽时，5 个 STAN pod 中的 3 个会立即被驱逐。剩下的 2 个 STAN pod 无法维持仲裁，这会导致不可恢复的数据丢失。这种故障模式在下面的动画中进行了可视化。5 个方块代表 5 个 STAN Pod。

升级期间 Raft 应用程序失去仲裁的动画。StatefulSet 缺少 PDB

在这种情况下，配置有的 PDB 可以minAvailable: 51%通过确保立即从正在耗尽的节点中驱逐不少于 51% 的 Pod 来防止仲裁损失。

StatefulSet 潜在事件-2

为了说明升级 StatefulSets 时就绪探测的重要性，让我们考虑相同的示例集群。

我们的示例集群的 STAN StatefulSet 配置了一个 PDB（带有minAvailable: 51%）和一个 liveness probe，但是它缺少一个 readiness probe。使用此配置，升级期间可能会通过以下方式失去仲裁：

控制器遵循 PDB 并确保在给定时间中断的 STAN 节点不到一半。最初只有 2 个 STAN pod 会从排空节点中逐出。然而，由于缺乏就绪探测，一旦中断的 STAN pod 被调度并激活，控制器就可以中断更多的 pod。由于活跃度检查旨在指示正在运行的容器，因此 STAN 在开始（或完成）读取 Raft 日志之前将自己标记为活跃。但是，鉴于 2 个 STAN pod 还没有完成对 Raft 日志的读取，它还没有准备好接受流量。如果控制器现在中断了更多的 STAN pod，那么当我们有 > 50% 的活跃 STAN pod 时，可能有 < 50% 的就绪 STAN pod（即一些 pod 正忙于从 Raft 日志中恢复状态）。剩下的 2 个 STAN pod 无法维持仲裁，这会导致不可恢复的数据丢失。

这种故障模式在下面的动画中进行了可视化。5 个方块代表 5 个 STAN Pod。红色方块表示Pod 尚未活跃。黄色方块表示 pod 尚未准备好。

升级期间 Raft 应用程序失去仲裁的动画。StatefulSet 缺少 Readiness 探测。

在这种情况下，在新创建的 STAN pod 准备好之前，就绪探测会阻止更多的 STAN pod 被中断。准备就绪探针可以配置为向/streaming/serverz监控端点发送 HTTP GET 请求；在 STAN 服务器准备好之前，此端点不会响应请求。

总结

升级 Kubernetes 集群可能会令人伤脑筋。但是，通过对升级过程的基本了解和对各种 Kubernetes 资源的简要考虑，您应该能够在下次升级期间最大限度地减少停机时间。

关键词： 应用程序 停机时间 最大限度 计算资源