Amazon EKS クラスターのアップグレード戦略をどのように計画すればよいですか?
Amazon Elastic Kubernetes Service (Amazon EKS) クラスターをアップグレードする際に、ベストプラクティスに従いたいと考えています。
簡単な説明
Kubernetes の新しいバージョンでは、Amazon EKS クラスターが大きく変わる可能性があります。クラスターをアップグレードした後にダウングレードすることはできません。新しいバージョンの Kubernetes にアップグレードすると、クラスターをインプレースアップグレードする代わりに、新しいクラスターに移行できます。新しいクラスターに移行することを選んだ場合、VMware の Velero のようなクラスターバックアップおよび復元ツールが移行に役立ちます。詳細については、GitHub のウェブサイトで「Velero」を参照してください。
Amazon EKS で利用可能な Kubernetes の現在のバージョンと過去のバージョンを確認するには、「Amazon EKS Kubernetes リリースカレンダー」を参照してください。
解決策
アップグレードを準備する
クラスターのアップグレードを開始する前に、次の要件を確認してください。
- Amazon EKS には、クラスターの作成時に指定したサブネットから最大 5 つの利用可能な IP アドレスが必要です。
- クラスターの AWS Identity and Access Management (IAM) ロールとセキュリティグループが AWS アカウントに存在している必要があります。
- シークレット暗号化を有効にする場合は、クラスターの IAM ロールに AWS Key Management Service (AWS KMS) キーのアクセス権が必要です。
Amazon EKS と Kubernetes のメジャーアップデートを確認する
アップグレードバージョンについて文書化されている変更をすべて確認し、必要なアップグレード手順を書き留めます。また、Amazon EKS マネージドクラスターに固有の要件や手順にも注意してください。
Amazon EKS クラスタープラットフォームバージョンと Kubernetes バージョンのメジャーアップデートについては、以下のリソースを参照してください。
Kubernetes のアップストリームバージョンとメジャーアップデートの詳細については、以下のドキュメントを参照してください。
- Kubernetes ウェブサイトの Kubernetes release notes
- GitHub ウェブサイトのChangelog
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 のみでサポートされます。
マネージドノードグループを完全にアップグレードするには、次の手順を実行します。
Amazon EKS マネージドノードグループに移行する
セルフマネージドノードグループを使用する場合は、ダウンタイムなしで Amazon EKS マネージドノードグループにワークロードを移行できます。詳細については、「Seamlessly migrate workloads from EKS self-managed node group to EKS-managed node groups」を参照してください。
ダウンストリームの依存関係 (アドオン) を特定してアップグレードする
クラスターには多くの場合、入力コントローラー、継続的配信システム、監視ツール、その他のワークフローなどの外部製品が含まれています。Amazon EKS クラスターを更新するときは、アドオンとサードパーティツールも更新する必要があります。アドオンがクラスターでどのように機能し、どのように更新されるかを必ず理解しておいてください。
注: セルフマネージドアドオンの代わりにマネージドアドオンを使用することをお勧めします。
以下に示す一般的なアドオンの例と、関連するアップグレードドキュメントを確認してください。
- Amazon VPC CNI: 各クラスターバージョンに使用する Amazon VPC CNI アドオンの推奨バージョンについては、「Amazon VPC CNI plugin for Kubernetes Amazon EKS アドオンの使用」を参照してください。また、GitHub ウェブサイトの「Update the aws-node daemonset to use IRSA」を参照してください。
- kube-proxy セルフマネージドアドオン: Amazon EKS クラスターの各バージョンで、利用可能な最新の kube-proxy コンテナイメージバージョンに更新してください。詳細については、「Kubernetes kube-proxy アドオンの使用」を参照してください。
- CoreDNS: Amazon EKS クラスターの各バージョンで、利用可能な最新の CoreDNS コンテナイメージバージョンに更新してください。詳細については、「セルフマネージド型アドオンを更新する」を参照してください。
- AWS ロードバランサーコントローラー: AWS ロードバランサーコントローラーのバージョン 2.5.0 以降には、Kubernetes バージョン 1.22 以降が必要です。詳細については、GitHub ウェブサイトの「AWS Load Balancer Controller のリリース」を参照してください。インストールに関する情報については、「AWS Load Balancer Controller アドオンのインストール」を参照してください。
- Amazon Elastic Block Store (Amazon EBS) コンテナストレージインターフェイス (CSI) ドライバー: Amazon EBS CSI ドライバーのバージョン 1.25.0 以降には、Kubernetes バージョン 1.23 以降が必要です。詳細については、GitHub ウェブサイトの「Amazon EBS CSI ドライバーリリース」を参照してください。インストールとアップグレードの情報については、「Amazon EBS CSI ドライバーを Amazon EKS アドオンとして管理する」を参照してください。
- Amazon Elastic File System (Amazon EFS) コンテナストレージインターフェイス (CSI) ドライバー: Amazon EFS CSI ドライバーのバージョン 1.5.8 以降には、Kubernetes バージョン 1.22 以降が必要です。詳細については、GitHub ウェブサイトのAmazon EFS CSI ドライバーのリリースを参照してください。インストールとアップグレードの情報については、「Amazon EFS CSI ドライバー」を参照してください。
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」を参照してください。
関連するコンテンツ
- 質問済み 3ヶ月前lg...
- 質問済み 1ヶ月前lg...
- 質問済み 1年前lg...
- 質問済み 6ヶ月前lg...
- AWS公式更新しました 3年前
- AWS公式更新しました 2年前
- AWS公式更新しました 1年前