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 ウェブサイトの「Kubernetes Deprecation Policy」を参照してください。

クラスターで非推奨の API バージョンを使用しているかどうかを確認するには、GitHub ウェブサイトの Kube No Trouble (kubent) を使用してください。非推奨の API バージョンを使用している場合は、Kubernetes クラスターをアップグレードする前にワークロードをアップグレードしてください。

Kubernetes マニフェストファイルを異なる API バージョン間で変換するには、kubectl convert プラグインを使用してください。詳細については、Kubernetes ウェブサイトの「Install kubectl convert plugin」を参照してください。

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

クラスターをアップグレードすると、Amazon EKS はアップグレードされた Kubernetes バージョンで新しい API サーバーノードを起動し、既存のノードを置き換えます。これらのチェックのいずれかが失敗した場合、Amazon EKS はインフラストラクチャのデプロイをロールバックし、クラスターは以前の Kubernetes バージョンのままになります。ただし、このロールバックは実行中のアプリケーションには影響せず、必要に応じて任意のクラスターを復元できます。アップグレードプロセス中に、サービスが少し中断されることがあります。

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

Amazon EKS クラスターをアップグレードするには、2 つの主要コンポーネントである、コントロールプレーンとデータプレーンを更新する必要があります。これらのコンポーネントをアップグレードする際には、次の点に留意してください。

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

インプレースアップグレードの場合は、2 番目に新しい 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」も参照してください。

ブルー/グリーンまたは canary の Amazon EKS クラスターの移行

ブルー/グリーンまたは canary のアップグレード戦略は、より複雑になる可能性がありますが、簡単なロールバック機能でダウンタイムなしでアップグレードを行えます。ブルー/グリーンまたは canary のアップグレードについては、「Blue/green or canary Amazon EKS clusters migration for stateless ArgoCD workloads」を参照してください。

Amazon EKS マネージドノードグループをアップグレードする

**重要:**ノードの kubelet は kube-apiserver より新しいものであってはなりません。また、kube-apiserver より 2 つ以上前のマイナーバージョンであってはなりません。例えば、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 ノードを更新するには、そのノードが表すポッドを削除します。次にコントロールプレーンを更新し、ポッドを再デプロイします。Fargate で起動する新しいポッドには、クラスターのバージョンと一致する kubelet バージョンがあります。既存の Fargate ポッドは変更されません。

注: Fargate ポッドを安全に保つために、Amazon EKS で定期的にポッドにパッチを適用する必要があります。Amazon EKS は、影響を軽減する方法でポッドの更新を試みます。ただし、ポッドを正常に終了できない場合、Amazon EKS はポッドを削除します。「Fargate OS のパッチ適用」を参照して、中断を最小限に抑えるようにしてください。

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 ウェブサイトの「Specifying a disruption budget for your application」を参照してください。

AWS公式
AWS公式更新しました 2ヶ月前
コメントはありません

関連するコンテンツ