スキップしてコンテンツを表示
AWS re:Postを使用することにより、以下に同意したことになります AWS re:Post 利用規約
AWS re:Postre:Post
re:Postに関して

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

所要時間3分
0

Amazon Elastic Kubernetes Service (Amazon EKS) クラスターをアップグレードする際の推奨事項を実施したいと考えています。

解決策

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

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

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

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

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

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

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

次の手順を実行します。

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

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

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

廃止された 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 クラスターを更新する場合、アドオンとサードパーティツールも更新する必要があります。アドオンがクラスターと連携したり、アドオンがアップグレードされたりする際の動作を把握する必要があります。

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

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

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 のウェブサイトで「アプリケーションに中断バジェットを指定する」を参照してください。

トピック
Containers
タグ
Amazon Elastic Kubernetes Service
言語
日本語
AWS公式更新しました 10ヶ月前
コメントはありません

関連するコンテンツ