如何更佳安全的升级Kubernetes节点
发布时间：2022-04-25 09:12:04 所属栏目：云计算 来源：互联网
导读：您是否害怕将集群升级到更新的 Kubernetes 版本？有几个原因可能会促使您升级。也许您想要执行以下操作之一： 需要升级的组件有哪些？ 一个 Kubernetes 集群由一组节点和一个控制平面组成。工作节点托管运行容器化应用程序的 pod。控制平面管理集群中的工作
|
您是否害怕将集群升级到更新的 Kubernetes 版本？有几个原因可能会促使您升级。也许您想要执行以下操作之一： 需要升级的组件有哪些？ 一个 Kubernetes 集群由一组节点和一个控制平面组成。工作节点托管运行容器化应用程序的 pod。控制平面管理集群中的工作节点和 Pod。 Kubernetes 集群的组件（来自kubernetes.io） 要升级 Kubernetes 集群，您将按以下顺序升级这两个组件： 升级控制平面 升级工作节点 对于自托管和托管集群，升级控制平面非常简单。这篇文章将重点关注最小化工作节点升级的停机时间。 就地升级（也称为滚动更新） 异地升级 对于就地升级，节点会被逐一排空并封锁，这样就不会在该节点上安排新的 Pod。然后删除该节点并使用更新的 Kubernetes 版本重新创建该节点。新节点启动并运行后，将更新下一个节点。该策略类似下面的可视化动画 动画显示了 Kubernetes 集群中节点的就地升级 就地升级的优势在于它需要最少的额外计算资源（单个额外节点）。这种策略的缺点是它可能需要相当长的时间，因为节点会被排空并逐个升级一个个节点。此外，Pod 可能需要进行 1 次以上的移动，因为它们在节点排空期间被打乱。 对于异地升级，使用新的 Kubernetes 版本创建一个新的节点池。一旦新节点全部运行，就可以对旧节点池进行封锁，将旧节点一一排空，然后再删除旧节点池。该策略在下面的动画中可视化： 动画显示了 Kubernetes 集群中节点的异地升级 异地升级需要临时加倍计算资源以换取更短的升级窗口。升级持续时间的减少是由于新升级节点的启动时间并行化，以及 pod 移动的最小化。在此策略中，Pod 从旧节点移动到新升级的节点。 假设您对计算资源利用率的暂时增加可以接受，我们建议您使用异地升级策略来加快速度。 配置 K8s 资源 无论您选择哪种工作节点升级策略，都将涉及将您的 pod 从原始节点改组到升级节点。如果您的资源配置不正确，可能会导致停机。让我们来看看一些潜在的陷阱。 Deployment 集群中的大多数 pod 都可能由Deployment控制。Deployment 代表一组没有唯一身份的相同 pod。部署通过管理应用程序的多个副本并在任何实例失败时部署替换来提高可用性。 要消除停机时间，请确保您的应用程序具有PodDisruptionBudget (PDB)。PDB 通过限制同时关闭的复制应用程序的 pod 数量来帮助提供更高的可用性。 例如，以下 PDB 声明 80% 的带有front-end标签的 pod 在中断期间（例如我们的升级）必须可用。这确保了服务负载的副本数量永远不会低于总副本的某个百分比。 请注意，您需要确保有多个副本（至少在升级期间是暂时的），以便能够升级节点。 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 资源的简要考虑，您应该能够在下次升级期间最大限度地减少停机时间。 （编辑：南通站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
站长推荐