如果你已经使用Kubernetes一段时间了，不妨考虑计划定期升级。从Kubernetes1.19开始，每个开源版本都提供一年的补丁。您将需要升级到最新的可用次要版本或补丁版本以获得安全性和错误修复。但是，如何在不停机的情况下升级基础架构的关键部分？本文将指导您了解在任何环境中升级Kubernetes时要考虑的常见模式。我们不会深入研究执行升级的所有工具和注意事项。如果您使用的是集群管理工具或托管Kubernetes服务，则应查阅文档以了解最适合您环境的选项。您还需要注意，某些工作负载和环境可能会限制您选择的升级策略。我们将讨论集群升级的一些高级模式：就地升级蓝绿升级滚动升级金丝雀升级这些模式类似于应用程序升级选项，但由于它们的潜在影响，可能需要一些独特的考虑。升级您的基础架构可能会产生相当大的成本，具体取决于升级需要多长时间以及您的规模有多大。控制平面组件Kubernetes控制平面由KubernetesAPI服务器、etcd数据库、控制器管理器、调度程序以及您环境中可能拥有的任何其他控制器（例如云或入口）组成。升级APIServer是升级集群的第一步。Kubernetes将状态存储在etcd中，并且在进行任何重大应用程序升级时，您需要确保至少有一个已验证可以恢复的备份。在某些情况下，API服务器升级可能还需要etcd升级。数据平面组件Kubernetes数据平面由kubelet、容器运行时以及您在集群工作负载中使用的任何网络、日志记录或存储驱动程序组成。对于许多集群，至少需要更新kube-proxy和CNI插件。您的数据平面组件可以小于或等于您的API服务器版本。理想情况下，您的主机操作系统、容器运行时和数据平面组件可以相互独立升级。解耦这些组件将确保您可以在错误修复、新功能或安全补丁发布时快速升级。托管Kubernetes服务如果您使用AmazonElasticKubernetesService(EKS)等托管Kubernetes服务，系统会为您处理控制平面升级。如果您使用托管节点组(MNG)等托管数据平面服务，您的数据平面升级也应由您的云提供商自动处理。即使使用托管服务，您仍然负责验证集群中安装的工作负载、额外的控制器和第三方插件（例如CNI）。在测试或开发环境中升级集群之前，应测试这些组件的API兼容性。在所有这些升级策略中，您应该避免在集群升级期间进行应用程序升级。如果可能，请让您的工作负载使用相同的版本，以尽量减少可能错误地归因于Kubernetes升级的故障。同时尽量减少其他潜在问题，例如方案升级或应用程序API兼容性。对于任何Kubernetes升级，您应该按以下顺序升级组件：控制平面数据平面和节点附加组件工作负载这些升级模式将帮助您决定如何升级最适合您的集群和环境的组件。01.就地升级执行就地升级时，您必须格外小心以确保组件保持健康，因为您正在当前为生产流量提供服务的集群上执行工作。就地升级可以包括包更新（例如yum、apt）、配置管理自动化（例如Ansible、Chef）或VM/容器映像更改。理想情况下，您的升级将是脚本化和自动化的（包括回滚），但如果这是您的第一次升级，那么在开发或测试环境中手动进行升级可能会有所帮助。就地升级意味着所有组件将大致同时升级。如果您通过配置管理更改所需的APIServer版本并推送新配置，则所有APIServer将在收到新配置后升级。这与我们稍后讨论的滚动升级不同。就地升级的主要好处是它在任何规模下都是最快的。如果手动完成，您可以更好地控制组件和升级过程。它很容易适应多种环境（本地或云）。从基础设施成本的角度来看，它是最便宜的。根据您的流程、规模和工具，就??地升级可能是能够编写脚本的最直接方式。脚本可以在本地或在开发集群中进行测试，而无需重新配置集群管理团队可能无法访问的资源——例如负载平衡器或DNS。如果你想使用这种方式升级，原地升级还需要考虑以下限制：如果你所有的APIserver或者controller同时升级，可能会导致宕机。如果你想从Kubernetes1.16迁移到1.20，你必须将整个集群升级四次到每个次要版本。验证每个步骤可以是一个手动过程，这会增加额外的时间和出错的机会。您应该在失败的情况下测试您的回滚计划，因为某些升级无法轻松恢复。（例如方案变更）。02.蓝/绿升级蓝/绿集群升级需要您使用新版本的Kubernetes创建第二个集群。您需要部署新的控制平面和数据平面，然后将所有工作负载复制到新集群，然后将流量从旧集群切换到新集群。您可以使用蓝/绿更新集群的各个组件，但整体集群升级更易于部署和回滚。消息是设置新集群通常比升级集群更容易。对于如何将工作负载部署到新集群，您有多种选择。如果您的工作负载已经是GitOps或持续交付的一部分，您可以在升级之前或期间将部署移动到新集群和旧集群。如果您没有自动部署，您可以使用像Velero这样的工具来备份您现有的工作负载并将它们部署到新的集群。创建一个新的“绿色”集群可以让您确信新版本会按预期工作，并让您可以控制何时切换版本。新集群还可用于验证自动化工具，例如Terraform模块或GitOps存储库。您可以随时通过DNS或负载平衡器进行更改，即使是在维护窗口或低利用率期间也是如此。蓝/绿升级的主要好处是：在发送流量之前预先验证所有组件是否健康。您可以一次升级多个版本（例如，从1.16直接升级到1.20）。您可以更改可能难以测试的基础设施的其他部分（例如切换区域、添加区域、更改实例类型）。回滚是最安全和最简单的。蓝/绿部署需要考虑的缺点包括：就基础架构成本而言，这是最昂贵的策略，因为您必须在迁移期间运行两倍的计算容量。如果您有数千个工作节点，您可能无法获得运行完整的第二个集群所需的全部计算能力。如果您有许多并发集群升级，则此策略很难扩展到数十或数百个集群。除非您有备用服务器，否则在没有虚拟化的情况下在本地进行蓝/绿并不容易。如果您有许多端点要更新，一次切换所有流量可能并不容易。负载平衡器可能需要预先调整和缓存预热。请注意DNS生存时间(TTL)，它可能用于也可能不用于分散负载。一次切换所有集群流量需要跨团队协调迁移到新集群；和工程周期来验证工作负载的大小是否正确。当您有少量集群或少于几百个工作节点时，蓝/绿可能是一个很好的策略。它允许您跳过版本并且回滚是安全的，但它可能需要更多的基础架构支出和协调时间。03.滚动升级如果你熟悉Kubernetes的部署策略，你就会对滚动升级不陌生。滚动升级将已部署组件之一升级到新副本，然后缩减旧副本。它将继续这种模式，直到删除所有旧组件。滚动升级的增量性质与就地升级和蓝/绿策略相比具有一些优势。与就地升级类似，您一次升级Kubernetes一个次要版本。当需要升级多个版本时，这可能是额外的工作，但这是唯一受支持的选项。根据要升级的组件，您可以使用不同的工具来升级每个组件。对于像控制平面这样的资源，您可能希望将具有升级的APIServer的新服务器添加到控制平面，然后关闭旧服务器。如果您使用的是AWS，则可以更改AutoScaling组启动配置AMI并一次更换一个实例。其他控制平面组件（例如调度程序）可以作为集群中的容器运行，因此您可以使用标准Kubernetes滚动部署升级来升级这些组件。与蓝/绿相比，滚动升级的主要区别在于您的外部流量路由（DNS和负载均衡器）将保持指向同一位置。在继续进行生产集群升级之前，您要确保在不同的集群或环境中测试所有附加组件和工作负载。请注意，AWSManagedNodeGroups、kOps、Cluster-API和许多其他Kubernetes集群管理工具使用滚动升级策略。优势包括：与就地升级相比更安全的更新和回滚。成本低于蓝/绿，并且不太可能耗尽资源。如果出现问题，您可以暂停升级过程。可以在本地环境中模拟。滚动升级是最常见的自动化工具。它们在速度和成本之间取得了很好的平衡，同时也减少了人工工作和风险。升级生产集群时，所有现有工作负载仍将被部署；只要您测试了它们的兼容性，您的升级就应该是可自动化的。使用滚动升级时的其他注意事项包括：根据您的规模，滚动升级可能会很慢。在升级期间，您可能需要协调控制器、守护程序或插件升级。您可能无法在集群范围内进行更改，例如添加可用区或更改架构。04.Canary升级Canary应用部署一次，为新版本应用提供少量流量。金丝雀升级可以被认为是具有蓝/绿优势的滚动升级。通过金丝雀升级，您可以使用要部署的版本创建一个新的Kubernetes集群。然后添加一个小型数据平面，并将您现有的应用程序以较小的规模部署到新集群。通过负载均衡器配置、DNS循环或服务网格将新的集群工作负载添加到现有生产流量。现在您可以监控流向新集群的流量，并慢慢扩大新集群中的工作负载并缩小旧集群中的工作负载。你可以一次做一件工作，根据你的习惯慢慢或快做。如果任何单个工作负载开始出现故障，您可以缩减新集群中的单个工作负载以自动使用旧集群。Canary集群升级的好处包括：新集群更容易创建和验证。您可以在升级期间跳过次要的Kubernetes版本（例如，1.16到1.20）。可以基于每个团队选择应用程序部署。由于流量使用增加，错误的影响很小。您可以在升级期间对基础架构进行大的更改。集群开始时很小，因此基础架构成本很低，并且您可以在扩展时预热缓存和负载均衡器。如果您想进行更大的更改（例如模式更改）或想要添加额外的可用区，金丝雀是一个不错的选择。通过启动一个较小的集群并根据工作负载增加它，您可以确保您不会在新实例变得更高效或工作负载请求和约束发生变化时过度配置您的基础设施。与任何事情一样，需要权衡取舍。以下是使用金丝雀部署时应注意的一些问题：回滚应用程序可能需要手动干预以更改负载均衡器或缩小新集群的规模。调试应用程序可能会更加困难，因为您需要知道发生了哪些集群错误。如果您有数十个或数百个集群，则可以在升级集群时将集群数量增加50%或更多。Canary是最复杂的升级策略，但它受益于自动化部署、健康检查和性能监控。结论无论您选择哪种升级策略，重要的是要了解它们的工作原理以及随着Kubernetes使用量的增长可能出现的任何问题。你需要有一个升级策略，因为Kubernetes有频繁的发布和偶尔的错误。与新版本保持同步可能是基础架构安全流程的重要组成部分，并使应用程序能够快速利用新功能。如果您在没有考虑如何升级的情况下部署了Kubernetes并迁移了所有工作负载，那么现在是开始规划的最佳时机。如果您没有运行自己的Kubernetes集群的业务需求，我强烈建议您使用可用的托管Kubernetes选项之一。选择托管控制平面和数据平面可以每年为您节省数天或数周的规划和升级时间。每个托管选项执行升级的方式可能不同，但它们都可以让您专注于工作负载和业务价值，而不是控制平面高可用性或数据平面兼容性。
