使用AWS re:Post即您表示您同意 AWS re:Post 使用条款
AWS re:Postre:Post

如何为 Amazon EKS 集群规划升级策略？

3 分钟阅读
0

升级 Amazon Elastic Kubernetes Service（Amazon EKS）集群时，我希望遵循最佳实践。

简短描述

新版本的 Kubernetes 对 Amazon EKS 集群进行了大幅更改。集群升级后便无法再降级。升级到最新版 Kubernetes 时，可以迁移到新集群，而不执行就地集群升级。如果选择迁移到新集群，诸如 VMware Velero 这样的集群备份和恢复工具可以帮助您进行迁移。有关详细信息，请参阅 GitHub 网站上的 Velero。

要查看 Amazon EKS 可用的 Kubernetes 当前和过去版本，请参阅 Amazon EKS Kubernetes 发布日历。

解决方法

进行升级准备工作

开始集群升级之前，注意要满足以下要求：

查看 Amazon EKS 和 Kubernetes 的重大更新

查看所有升级版变更记录，记下所有必需的升级步骤。此外，请注意 Amazon EKS 托管集群的所有特定要求或程序。

有关 Amazon EKS 集群平台版本和 Kubernetes 版本的任何重大更新，请参阅以下资源：

有关 Kubernetes 上游版本和主要更新的更多信息，请参阅以下文档：

了解 Kubernetes 弃用策略

API 升级之后，此前的 API 会被弃用，并最终被删除。要了解新版本 Kubernetes 可能如何弃用 API，请阅读 Kubernetes 网站上的弃用策略。

要检查集群中是否使用了已弃用的 API 版本，请使用 GitHub 上的 Kube No Trouble (kubent)。如使用的是已弃用的 API 版本，请先升级工作负载，然后再升级 Kubernetes 集群。

要在不同的 API 版本之间转换 Kubernetes 清单文件，请使用 kubectl convert 插件。有关详细信息，请参阅 Kubernetes 网站上的安装 kubectl convert 插件。

Kubernetes 的升级过程是怎样的

升级集群时，Amazon EKS 会使用升级后的 Kubernetes 版本启动新的 API 服务器节点来替换现有节点。如果其中任何一项检查失败，则 Amazon EKS 会回滚基础设施部署，集群将保留在先前的 Kubernetes 版本上。但此回滚不会影响正在运行中的应用程序，可以根据需要恢复任何集群。升级过程中，可能会遇到轻微的服务中断。

升级控制面板和数据面板

升级 Amazon EKS 集群需要更新两个主要组件，即控制面板和数据面板。升级这两个组件时，请记住以下注意事项。

Amazon EKS 集群就地升级

就地升级时，只能升级到下一个最高的 Kubernetes 次要版本。如果您当前的集群版本和目标版本之间有多个版本，则必须依次逐个升级到每个版本。每次就地升级 Kubernetes 集群时，请完成以下任务：

  • 根据需要更新您的 Kubernetes 清单，并更新已弃用或已删除的 API。
  • 升级集群控制面板。
  • 升级集群中的节点。
  • 根据需要更新您的 Kubernetes 附加组件和自定义控制器。

有关详细信息，请参阅 Planning Kubernetes upgrades with Amazon EKS 中的 Planning and executing Kubernetes version upgrades in Amazon EKS。另请参阅 GitHub 网站上的 Best practices for cluster upgrades。

蓝色/绿色或金丝雀 Amazon EKS 集群迁移

蓝色/绿色或金丝雀升级策略可能更复杂，但该策略能让升级具备简单回滚功能，而且不需要停机。有关蓝色/绿色或金丝雀升级，请参阅 Blue/green or canary Amazon EKS clusters migration for stateless ArgoCD workloads。

升级 Amazon EKS 托管节点组

**重要事项：**节点的 kubelet 不能比 kube-apiserver 更新。另外，也不能超前 kube-apiserver 两个次要版本。例如，假设 kube-apiserver 的版本为 1.24。这种情况下，kubelet 支持版本仅为 1.24、1.23 和 1.22。

要完全升级托管节点组，请完成以下步骤：

  1. 将 Amazon EKS 集群控制面板组件升级到最新版本。
  2. 更新托管节点组的节点。

迁移到 Amazon EKS 托管节点组

如果使用的是自主管理型节点组，则可以在不停机的情况下将工作负载迁移到 Amazon EKS 托管节点组。有关详细信息，请参阅 Seamlessly migrate workloads from EKS self-managed node group to EKS-managed node groups。

识别和升级下游依赖关系（附加组件）

集群通常含有外部产品，例如入站控制器、持续交付系统、监控工具和其他工作流程。更新 Amazon EKS 集群时，还必须更新附加组件和第三方工具。请务必了解附加组件与集群的配合使用方式以及更新方式。

**注意：**最佳做法是使用托管附加组件而不是自主管理型附加组件。

请参阅以下常见附加组件及其相关升级文档示例：

升级 AWS Fargate 节点

要更新 Fargate 节点，请删除节点所代表的 Pod。然后，在更新控制面板后，重新部署 Pod。在 Fargate 上启动的任何新 Pod 都有与集群版本匹配的 kubelet 版本。现有 Fargate Pod 没有改变。

**注意：**为了确保 Fargate Pod 的安全，Amazon EKS 必须定期对其进行修补。Amazon EKS 将尽可能减少更新 Pod 带来的影响。但如果无法成功驱逐 Pod，Amazon EKS 会将其删除。请参阅 Fargate 操作系统修补，了解如何最大限度减少中断。

升级 Karpenter 创建的无组节点

为 ttlSecondsUntilExpired 设置值时，该值会激活节点到期。在节点达到规定的寿命（以秒为单位）后，Amazon EKS 会将其删除。即使节点正在使用中，也会被删除。此过程支持您使用新预置的实例替换节点，从而对节点进行升级。替换节点后，Karpenter 会使用最新 Amazon EKS 优化的 AMI。有关更多信息，请参阅 Karpenter 网站上的 Disruption。

以下示例显示了一个已取消预置 ttlSecondsUntilExpired 的节点，然后替换为升级后的实例：

apiVersion: karpenter.sh/v1alpha5kind: Provisioner
metadata:
  name: default
spec:
  requirements:
    - key: karpenter.sh/capacity-type         # optional, set to on-demand by default, spot if both are listed
      operator: In
      values: ["spot"]
  limits:
    resources:
      cpu: 1000                               # optional, recommended to limit total provisioned CPUs
      memory: 1000Gi
  ttlSecondsAfterEmpty: 30                    # optional, but never scales down if not set
  ttlSecondsUntilExpired: 2592000             # optional, nodes are recycled after 30 days but never expires if not set
  provider:
        subnetSelector:
      karpenter.sh/discovery/CLUSTER_NAME: '*'
    securityGroupSelector:
      kubernetes.io/cluster/CLUSTER_NAME: '*'

**注意：**Karpenter 不会自动为该值添加抖动。如果您在短时间内创建多个实例，则这些实例会在几乎同一时间过期。为防止工作负载过度中断，请定义容器组中断预算。有关更多信息，请参阅 Kubernetes 网站上的为应用程序设置干扰预算。

主题
容器
标签
Amazon Elastic Kubernetes Service
语言
中文 (简体)
AWS 官方
AWS 官方已更新 3 个月前
没有评论

相关内容