HAQM EKS 版本升级：升级指南

HAQM Elastic Kubernetes Service (EKS) 是一个完全托管的 Kubernetes 服务，它简化了在 AWS 上部署、管理和扩展容器化应用程序的过程。作为一个快速发展的技术领域，Kubernetes 不断推出新的版本，带来性能改进、新功能和安全增强。因此，及时升级 EKS 集群版本至关重要。

EKS 遵循 Kubernetes 版本发布周期，通常每年发布三到四个次要版本。每个 EKS 版本的生命周期通常为 14 个月，包括约 12 个月的标准支持期和 2 个月的延长支持期。在这个周期结束后，该版本将达到生命周期终止（EOL）状态，AWS 将不再为其提供支持或安全更新。2024年4月，HAQM EKS 宣布全面推出对 Kubernetes 版本的延伸支持，HAQM EKS 中的延伸支持从标准支持结束时立即开始，并持续 12 个月。获得延伸支持的 EKS 集群将继续获得 Kubernetes 控制面板的安全补丁，以及 HAQM VPC CNI、kube-proxy 和 CoreDNS 附加组件、AWS 发布的 EKS 优化型 AMI 和 EKS Fargate 节点的关键补丁。延伸支持每小时每个集群 0.60 美元收取费用。

下表显示了每个 Kubernetes 版本需要考虑的重要发布和支持日期。扩展支持从该版本的标准支持终止之日起开始计费。

为什么要升级

升级的策略

• STANDARD – 标准支持终止后，EKS 集群可以自动升级。使用此设置不会产生扩展支持费用，但 EKS 集群将自动升级到处于标准支持期内的下一个受支持的 Kubernetes 版本。
• EXTENDED – Kubernetes 版本的标准支持终止后，EKS 集群将进入扩展支持状态。使用此设置，您将需要支付扩展支持费用。您可以将集群升级到标准支持期内的 Kubernetes 版本，以免产生扩展支持费用。依据扩展支持运行的集群在扩展支持终止时将可以自动升级。

集群升级策略决定了集群在标准支持期结束时会发生什么。如果升级策略是 EXTENDED，则集群将不会自动升级，而是进入扩展支持状态。如果升级策略是 STANDARD，则将自动升级。

您可以使用 supportType 属性为新集群和现有集群设置版本策略。参考：查看升级策略

如果希望集群保持当前 Kubernetes 版本以利用扩展支持期，则必须在标准支持期结束之前启用扩展支持升级策略。

升级的价值和好处

1. 性能改进

每个新版本的 Kubernetes 都会带来性能上的优化。这可能包括更高效的资源调度、更快的启动时间、更低的延迟等。通过升级，您可以充分利用这些改进，提高集群的整体性能和效率。

例如：在 Kubernetes 1.24 版本中，引入了 Pod 优雅终止功能的改进。这使得在节点关闭时，Pod 能够更快速、更可靠地终止，从而减少了服务中断时间，提高了集群的整体性能和可用性。

2. 新功能和增强

Kubernetes 社区不断开发新功能和增强现有功能。升级 EKS 版本可以让您获得这些新特性，如改进的自动扩展、更强大的网络策略、增强的监控和日志功能等。这些新功能可以帮助您更好地管理和优化您的容器化应用程序。

例如：Kubernetes 1.25 引入了 Pod Security Admission 控制器，这是一个内置的准入控制器，可以强制执行 Pod Security Standards。这个新功能大大提升了集群的安全性，使管理员能够更轻松地实施安全策略。

3. 安全性增强

安全是容器化应用程序面临的一个持续挑战。新版本的 Kubernetes 通常会包含重要的安全补丁和增强功能。通过及时升级，您可以确保您的 EKS 集群获得最新的安全保护，减少潜在的漏洞风险。

例如：在 Kubernetes 1.26 中，修复了一个严重的安全漏洞（CVE-2022-3162），这个漏洞可能允许攻击者通过特制的 YAML 文件获取未经授权的访问权限。升级到这个版本可以保护您的集群免受此类攻击。

4. 更好的稳定性

随着 Kubernetes 的成熟，每个新版本都会修复之前版本中发现的 bug 和稳定性问题。升级到较新的版本可以帮助您避免这些已知问题，提高集群的整体稳定性。

例如：Kubernetes 1.27 修复了一个长期存在的 bug，该 bug 可能导致在某些情况下 kube-proxy 不正确地处理 NodePort 服务。升级到这个版本可以提高网络连接的稳定性。

5. 更广泛的生态系统支持

Kubernetes 有一个庞大的生态系统，包括各种工具、插件和集成。新版本的 Kubernetes 通常会得到这些生态系统工具的优先支持。通过升级，您可以确保与这些工具的兼容性，并享受到它们的最新功能。

例如：许多流行的 Kubernetes 工具，如 Istio 服务网格，通常会首先支持最新的几个 Kubernetes 版本。升级 EKS 可以确保您能使用 Istio 的最新版本及其所有新特性。

2.2 不升级的影响

1. 安全性风险

不升级 EKS 版本可能会使您的集群面临已知的安全漏洞。随着时间的推移，旧版本中的安全漏洞可能被发现和公开，而这些漏洞在新版本中已经被修复。继续使用旧版本会增加您的集群被攻击的风险。

例如：如果您的集群仍在运行 Kubernetes 1.22 或更早版本，您将面临 CVE-2021-25741 漏洞的风险，这个漏洞可能允许攻击者绕过 Pod 安全策略。

2. 失去 Kubernetes 社区的支持

Kubernetes 社区主要关注当前和最近的几个版本。使用过时的版本意味着您可能无法获得社区的支持，包括问题解决、文档更新和最佳实践建议。这可能会增加运维的难度和成本。

例如：如果您使用的是 Kubernetes 1.20 版本（已于 2022 年 2 月停止支持），您可能在 Kubernetes GitHub 仓库或 Slack 频道中提出的问题得不到社区的响应，因为社区主要关注当前支持的版本。

3. 合规性问题

许多行业标准和合规要求（如 PCI DSS、HIPAA 等）要求使用受支持的、及时更新的软件版本。使用过时的 EKS 版本可能会导致合规性问题，特别是在安全敏感的行业中。

例如：如果您的公司需要遵守 PCI DSS 标准，使用过时的、不再接收安全更新的 Kubernetes 版本可能会导致审计失败，因为 PCI DSS 要求使用受支持的、及时更新的软件版本。

4. 集成和兼容性问题

随着时间的推移，许多与 Kubernetes 集成的工具和服务可能会停止支持旧版本。这可能导致您无法使用某些重要的工具或服务，或者需要使用这些工具的旧版本，从而可能引入其他问题。

例如：如果您使用的是较旧的 EKS 版本（如 1.19），您可能无法使用最新版本的 AWS Load Balancer Controller，这可能会限制您使用某些新的 AWS 网络功能。

5. 技术债务累积

推迟升级可能导致技术债务的累积。当您最终决定升级时，可能需要跨越多个版本，这通常比定期进行小规模升级更具挑战性和风险。

例子：如果您的集群仍在运行 Kubernetes 1.18，要升级到当前支持的版本（如 1.27）将需要跨越多个大版本。这个过程可能需要处理多个破坏性变更，增加了升级的复杂性和风险。

6. 支持成本增加

使用不受支持的旧版本可能会增加您的运维成本。您可能需要投入更多的时间和资源来解决问题，或者可能需要寻求昂贵的第三方支持。

例如：如果您的集群运行的是不再受支持的版本（如 1.20），当遇到问题时，您可能需要聘请专门的 Kubernetes 顾问来解决问题，而不是依赖 AWS 支持或社区帮助，这可能会大大增加您的运维成本。

综上所述，虽然升级 EKS 版本可能需要一定的工作和计划，但不升级所带来的潜在风险和成本通常远远超过升级的成本。定期升级 EKS 版本是维护健康、安全和高效的 Kubernetes 环境的关键实践。

3. EKS 升级的方案分析和选择

在决定升级 EKS 集群时，有几种不同的方法可供选择。每种方法都有其优点和缺点，适用于不同的场景。以下我们将分析三种主要的升级方案：就地升级控制面、升级控制面和数据面、以及蓝绿升级。我们将从操作复杂度和耗时、人工投入成本、优势和感知的影响、以及资源成本等方面进行比较。

3.1 只升级控制面

这种方法只升级 EKS 控制平面，不涉及工作节点的升级。

优点：

• 操作简单，只需要在 AWS 控制台或通过 AWS CLI 执行几个命令即可完成。
• 升级过程快速，通常只需要 20-30 分钟。
• 对运行中的工作负载影响最小，不需要重新调度 Pod。
• 资源成本低，不需要额外的计算资源。
• 可以利用控制面和数据面的版本差异，短期延缓数据面升级带来工作量。

缺点：

• 控制平面和数据平面版本不一致可能导致兼容性问题。
• 无法利用新版本 Kubernetes 在节点层面的改进。
• 后续还需要单独升级工作节点，增加了总体工作量。

适用场景：

• 需要快速升级以解决紧急安全问题。
• 集群规模较小，后续可以快速完成节点升级。
• 对新版本特性的需求主要集中在控制平面。

3.2 原集群升级

这种方法同时升级 EKS 控制平面和所有工作节点。

优点：

• 确保整个集群版本一致，避免兼容性问题。
• 可以充分利用新版本的所有特性和改进。
• 一次性完成所有升级工作，减少后续操作。
• 对与有状态应用无需进行数据迁移或复制

缺点：

• 操作复杂度高，需要仔细规划和执行。
• 升级时间较长，取决于集群规模，可能需要几小时到几天。
• 对运行中的工作负载有一定影响，需要重新调度 Pod。
• 人工投入成本较高，需要持续监控和可能的手动干预。

适用场景：

• 有足够的维护窗口进行全面升级。
• 需要利用新版本在节点层面的改进。
• 集群规模适中，可以在合理时间内完成全面升级。

3.3 蓝绿/灰度升级

这种方法创建一个新的 EKS 集群（绿色），然后逐步将工作负载从旧集群（蓝色）迁移到新集群。

优点：

• 风险最小，可以快速回滚。
• 对生产环境影响最小，可以逐步迁移并验证。
• 提供了彻底更新和清理的机会。
• 可以跨版本选择升级到比较新的版本，不受单次升级版本限制。

缺点：

• 操作复杂度最高，需要详细的规划和执行。
• 资源成本最高，需要同时运行两个集群。
• 总体耗时最长，包括新集群创建、数据迁移和验证的时间。
• 人工投入成本最高，需要仔细管理迁移过程。

适用场景：

• 大规模、关键性生产环境。
• 有足够的资源和时间进行全面测试和逐步迁移。
• 需要借机进行架构调整或彻底清理。

3.4 有状态服务和无状态服务的升级选择

在选择升级方案时，还需要考虑集群中运行的服务类型：

无状态服务

无状态服务通常更容易升级，因为它们不依赖于特定的数据状态。对于这类服务：

• 就地升级控制面和数据面通常是一个好选择，因为可以利用 Kubernetes 的滚动更新功能。
• 蓝绿升级也是一个不错的选择，可以轻松地将流量从旧集群切换到新集群。

有状态服务

有状态服务（如数据库、消息队列等）的升级更具挑战性，因为需要考虑数据的一致性和持久性。对于这类服务：

• 原集群升级是不可逆的，无法回滚。
• 蓝绿升级是一个更好的选择，因为它允许在新集群中完全设置和验证服务，但是需要进行数据迁移和切换。
• 无论选择哪种方法，都需要特别注意数据迁移策略和一致性保证。

3.5 方案选择建议

1. 对于暂时没有做好升级准备但是当心控制平面被自动升级，只升级控制平面是一种比较快的方法用来暂时解决升级问题。
2. 对于升级要求没有这么苛刻，或者那些有一定维护窗口的集群，原集群升级控制面和数据面是一个平衡的选择。
3. 对于大规模或者关键业务的的生产环境，特别是对升级有着苛刻要求的业务，蓝绿或灰度升级能够提供同时满足稳定和灵活的需求。
4. 无论选择哪种方法，都要确保有详细的升级计划、充分的测试和可靠的回滚策略。

最后，升级决策应该基于您的具体情况，包括业务需求、资源约束、风险承受能力和技术能力。仔细评估每种方法的优缺点，并根据您的特定环境选择最合适的升级策略。

4. 总结和展望

本文详细探讨了 HAQM EKS 版本升级的重要性、不同升级方案的比较以及选择合适升级策略的考虑因素。我们了解到，及时升级 EKS 版本不仅可以提高集群的性能和安全性，还能确保您充分利用 Kubernetes 的最新功能和社区支持。

我们分析了三种主要的升级方案：只升级控制面、原集群升级、以及蓝绿/灰度升级。每种方案都有其适用的场景，选择时需要考虑操作复杂度、资源成本、对业务的影响等多个因素。同时，我们还讨论了有状态服务和无状态服务在升级时的不同考虑。

在未来的两篇文章中，我们将深入探讨具体的升级实施方法：

1. 《HAQM EKS 版本升级：控制平面和数据平面实战》：我们将详细介绍如何在 EKS 执行原集群升级。我们将提供详细的命令示例和最佳实践，帮助您顺利完成就地升级过程。
2. 《HAQM EKS 版本升级：升级方案之蓝绿升级》：这篇文章将聚焦于更复杂但更安全的蓝绿/灰度升级策略。

本篇作者