Amazon EKS クラスターのアップグレードを計画する方法を教えてください。

解決策

アップグレードの影響を把握する

Kubernetes の新しいバージョンでは、Amazon EKS クラスターに有意な変更が行われる可能性があります。クラスターをアップグレードした後にダウングレードすることはできません。

Kubernetes の新しいバージョンにアップグレードする場合は、クラスターのインプレースアップグレードを実行せずに、新しいクラスターに移行できます。新しいクラスターに移行する場合、クラスターのバックアップおよび復元ツール (例: Velero) の利用を推奨します。詳細については、GitHub のウェブサイトで「Velero」を参照してください。

Kubernetes の最新バージョンと以前のバージョンに関する情報については、「Amazon EKS Kubernetes リリースカレンダー」を参照してください。

アップグレード要件を満たす

クラスターをアップグレードするには、次の要件を満たす必要があります。

• クラスターの作成時に指定したサブネットに含まれる、最大 5 つの利用可能な IP アドレスが必要です。
• AWS アカウントには、クラスターの AWS Identity and Access Management (IAM) ロールとセキュリティグループが必要です。
• シークレット暗号化を有効にする場合は、クラスターの IAM ロールは、AWS Key Management Service (AWS KMS) キーにアクセスできる必要があります。

Amazon EKS と Kubernetes のメジャーアップデートを確認する

次の手順を実行します。

• アップグレードバージョンに関する、文書化された変更をすべて確認し、必要なアップグレード手順を書き留めます。
• Amazon EKS マネージドクラスターに固有の要件や手順を確認します。

Amazon EKS クラスターと Kubernetes バージョンのプラットフォームバージョンに対するメジャーアップデートについては、次のドキュメントを参照してください。

• Amazon EKS における Kubernetes バージョンライフサイクルの概要
• Kubernetes の各バージョンの Amazon EKS プラットフォームバージョンを確認する
• 既存のクラスターを新しい Kubernetes バージョンに更新する

Kubernetes のアップストリームバージョンとメジャーアップデートに関する詳細については、次のドキュメントを参照してください。

• Kubernetes リリースノート (Kubernetes のウェブサイト)
• Kubernetes 変更ログ (GitHub のウェブサイト)

廃止された API を把握し、有無を確認する

Kubernetes が API をアップグレードする際、Kubernetes は以前の API の削除も行います。

廃止された API を管理するには、次の手順を実行します。

• Kubernetes が新しいバージョンの Kubernetes で API を廃止する際の動作については、Kubernetes のウェブサイトで「Kubernetes の廃止ポリシー」を参照してください。
• クラスター内の廃止された API バージョンを確認するには、Kube No Trouble (kubent) ツールを使用します。詳しい情報については、GitHub のウェブサイトで kube-no-trouble を参照してください。廃止された API バージョンを使用している場合は、Kubernetes クラスターをアップグレードする前にワークロードをアップグレードします。
• Kubernetes マニフェストファイルを異なる API バージョン間で変換するには、kubectl convert プラグインを使用します。詳細については、Kubernetes のウェブサイトで「kubectl convert プラグインのインストール」を参照してください。

Kubernetes のアップグレード中に想定される事象

クラスターをアップグレードする場合、Amazon EKS はアップグレードされた Kubernetes バージョンで新しい API サーバーノードを起動し、既存のノードを置き換えます。Amazon EKS も、一連の内部チェックを行います。チェックで問題があった場合、Amazon EKS はインフラストラクチャのデプロイをロールバックし、クラスターは以前の Kubernetes バージョン上に保持されます。ロールバックは実行中のアプリケーションには影響しないため、クラスターは復旧できます。

注: アップグレードプロセス中に、サービスの小規模な中断が発生する可能性があります。

コントロールプレーンとデータプレーンをアップグレードする

クラスターをアップグレードするには、コントロールプレーンとデータプレーンを更新する必要があります。

次のいずれかの方法でプレーンを更新します。

• クラスターのインプレースアップグレード
• ブルー/グリーンアップグレードまたは Canary アップグレード
• マネージドノードグループのアップグレード

クラスターのインプレースアップグレード

重要: インプレースアップグレードでは、Kubernetes の 現行よりも 1 バージョン新しいマイナーバージョンにのみアップグレードできます。現在のクラスターバージョンと目標バージョンの間に複数のバージョンが存在する場合は、各バージョンに順番にアップグレードする必要があります。

Kubernetes クラスターをインプレースアップグレードするたびに、次の手順を行います。

1. Kubernetes マニフェストと廃止された API を更新します。
2. クラスターのコントロールプレーンをアップグレードします。
3. クラスター内のノードをアップグレードします。
4. Kubernetes アドオンとカスタムコントローラーを更新します。

詳細については、「Amazon EKS で Kubernetes アップグレードを計画する」の「Amazon EKS で Kubernetes バージョンアップグレードを計画、実行する」および、「クラスターアップグレードのベストプラクティス」を参照してください。

ブルー/グリーンアップグレードまたは Canary アップグレード

ブルー/グリーンアップグレードまたは Canary アップグレードについては、「ステートレス ArgoCD ワークロードで Amazon EKS クラスターを移行する (ブルー/グリーンまたは Canary)」を参照してください。

マネージドノードグループのアップグレード

重要: ノードの kubelet を kube-apiserver より新しいバージョンにすることはできません。また、kubelet のバージョンが kube-apiserver より古い場合は、マイナーバージョン差が 2 を超えてはなりません。たとえば、kube-apiserver のバージョンが 1.24 の場合、Amazon EKS はバージョン 1.24、1.23、および 1.22 の kubelet のみをサポートします。

マネージドノードグループをアップグレードするには、マネージドノードグループのノードを更新します。

Amazon EKS マネージドノードグループに移行する

セルフマネージドノードグループを使用する場合は、ダウンタイムを発生させずに Amazon EKS マネージドノードグループにワークロードを移行できます。

ダウンストリームの依存関係を特定し、アップグレードする

クラスターには、サードパーティのアドオンやツールが含まれる場合があります (例: イングレスコントローラー、継続的デリバリーシステム、監視ツール、その他各種ワークフロー)。Amazon EKS クラスターを更新する場合、アドオンとサードパーティツールも更新する必要があります。アドオンがクラスターと連携したり、アドオンがアップグレードされたりする際の動作を把握する必要があります。

注: セルフマネージドアドオンではなく、マネージドアドオンの利用を推奨します。

次の一般的なアドオンの例および、アップグレードドキュメントを確認してください。

• 各クラスターバージョンに使用する Amazon Virtual Private Cloud Container Network Interface (Amazon VPC CNI) アドオンを特定します。詳細については、「Amazon VPC CNI を使用してポッドに IP アドレスを割り当てる」および、「Amazon VPC CNI プラグインでサービスアカウント用 IAM ロール (IRSA) を使用する設定を行う」を参照してください。
• セルフマネージド kube-proxy アドオンの各クラスターバージョンごとに、最新の kube-proxy コンテナイメージバージョンに更新します。詳細については、「Amazon EKS クラスターで kube-proxy を管理する」を参照してください。
• CoreDNS の各クラスターバージョンごとに、利用可能な最新の CoreDNS コンテナイメージバージョンに更新します。詳細については、「Amazon EKS クラスターで DNS 用の CoreDNS を管理する」を参照してください。
• バージョン 2.5.0 以降の AWS Load Balancer Controller には、Kubernetes バージョン 1.22 以降が必要です。詳細については、GitHub のウェブサイトで「AWS Load Balancer Controller リリース」を参照してください。インストールに関する情報については、「AWS Load Balancer Controller でインターネットトラフィックをルーティングする」を参照してください。
• Amazon Elastic Block Store (Amazon EBS) CSI ドライバーバージョン 1.25.0 以降には、Kubernetes バージョン 1.23 以降が必要です。詳細については、GitHub のウェブサイトで aws-ebs-csi-driver を参照してください。インストールとアップグレードに関する情報については、「ステップ 2: Amazon EBS CSI ドライバーを取得する」を参照してください。
• Amazon Elastic File System (Amazon EFS) CSI ドライバーバージョン 1.5.8 以降には、Kubernetes バージョン 1.22 以降が必要です。詳細については、GitHub のウェブサイトで aws-efs-csi-driver を参照してください。インストールとアップグレードに関する情報については、「Amazon EFS で Elastic ファイルシステムストレージを使用する」を参照してください。

Fargate ノードのアップグレード

AWS Fargate ノードを更新するには、次の手順を実行します。

1. ノードに関連するポッドを削除します。
2. コントロールプレーンを更新します。
3. API を再度デプロイします。

Fargate で起動する新しいポッドでは、クラスターのバージョンと一致する kubelet バージョンを使用するようになります。アップグレードは、既存の Fargate ポッドには影響しません。

注: Amazon EKS は、ポッドの安全性を保つべく、定期的に Fargate ポッドにパッチを適用することが求められています。ポッドの更新時、Amazon EKS はパッチの影響を最小限に抑えます。Amazon EKS がポッドを除外できない場合、Amazon EKS はそのポッドを削除します。中断を最小限に抑える方法については、「AWS Fargate OS パッチイベントにアクションを設定する」を参照してください。

Karpenter が作成したアンマネージドノードをアップグレードする

ttlSecondsUntilExpired に設定した値により、ノードの有効期限が有効化されます。指定した経過時間 (秒単位) にノードが達すると、Amazon EKS はそのノードを削除します。Amazon EKS ワークロードまたはアプリケーションがノードを使用中の場合も、削除は行われます。ttlSecondsUntilExpired を使用し、ノードを新規にプロビジョニングされたインスタンスで置き換えると、インスタンスをアップグレードできます。交換されたノードでは、Karpenter は最新の Amazon EKS 最適化Amazon マシンイメージ (AMI) を使用します。Karpenter によるノードの中断動作に関する詳細については、Karpenter のウェブサイトで「中断」を参照してください。

ノードが 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 により、ttlSecondsUntilExpired 値に自動でジッターが追加されることはありません。短期間に複数のインスタンスを作成した場合、同じタイミングで失効します。ワークロード中断の多発を防ぐために、ポッド中断にバジェットを設定してください。詳細については、Kubernetes のウェブサイトで「アプリケーションに中断バジェットを指定する」を参照してください。