マネージド型ノードグループを利用した Amazon EKS クラスターのアップグレード戦略を検討する

はじめに

Amazon Elastic Kubernetes Service (Amazon EKS) は、独自のコントロールプレーンをインストール、運用、保守することなく、AWS 上で Kubernetes を実行できるマネージドサービスです。Amazon EKS を使用すると、AWS インフラストラクチャのすべてのパフォーマンス、スケール、信頼性、および可用性のメリットを享受できるだけでなく、AWS ネットワーキングおよびセキュリティサービスとの統合の恩恵も受けることができます。また、Amazon EKS クラスターは、セルフマネージド型ノード、マネージド型ノードグループ、AWS Fargate といったノードオプションを組み合わせて Pod をスケジュールできます。各ノードオプションの詳細については Amazon EKS ノードを参照ください。

Kubernetes コミュニティは、平均して 4 ヶ月に一度新しい Kubernetes のマイナーバージョンをリリースします。Amazon EKS は、アップストリームのリリースサイクルに従う形でマイナーバージョンをリリースします。そして、マイナーバージョンのリリース後 14 ヶ月間は Amazon EKS の標準サポート対象となります。Kubernetes の最新機能を利用したり、オープンソースで公開されているエコシステムとの互換性を保つために、Amazon EKS で新しいマイナーバージョンが利用可能になったら EKS クラスターをタイムリーに更新することをお勧めしています。一方で、ビジネスの成長とともにシステムが大きくなり、ユーザーが管理する EKS クラスターもスケールし大規模なものになっていきます。それにより、クラスターのアップグレードに必要な工数なども増えることが予想されます。そのため、約 4 ヶ月に一度という頻度のリリースサイクルを追従するためには、事前にクラスターのアップグレード戦略をしっかりと検討することが重要です。

この記事では、マネージド型ノードグループのノードオプションを利用したクラスターについてフォーカスを当て、どのようなアップグレード戦略を検討できるか説明します。ユーザーは、各戦略の特徴などを理解した上で適切にアップグレードを計画できます。

Amazon EKS クラスターのアップグレード戦略

概要

はじめに、EKS クラスターのアップグレードを実行するにあたって必要となる前提知識について補足します。最初に、クラスターのアップグレード手順全体の流れを理解しておくことが大切です。クラスターをアップグレードする際は、クラスターを構成するコントロールプレーンや EKS アドオン / カスタムコントローラー、データプレーンをそれぞれアップグレードする必要があります。加えて、アップグレードに関する制約も注意する必要があります。クラスターをアップグレードすると、以前の Kubernetes バージョンにダウングレードすることはできません。そのため、事前にリリース内容やその影響範囲を確認した上でアップグレードプロセスを実行する必要があります。また、クラスターのコントロールプレーンを新しいバージョンに更新する前に、クラスター内のマネージド型ノードグループが管理するノードのマイナーバージョンがコントロールプレーンのバージョンと同じであることを確認する必要があります。例えば、コントロールプレーンがバージョン 1.29 を実行し、かつノードがバージョン 1.28 を実行している場合、コントロールプレーンを 1.30 に更新する前に、ノードをバージョン 1.29 に更新する必要があります。クラスターのアップグレード手順の詳細については EKS ベストプラクティスガイドと Amazon EKS クラスターの Kubernetes バージョンの更新を参照ください。

この記事では、アップグレードに関する制約やアップグレードプロセスにかかる作業コスト、システムへの影響度などを考慮した 3 つのアップグレード戦略について考えます。

インプレースアップグレード
ノードグループレベルのブルー/グリーンアップグレード
クラスターレベルのブルー/グリーンアップグレード

これらのアップグレード戦略について、それぞれの特徴やメリットとデメリットなどを評価します。

インプレースアップグレード

図 1: インプレースアップグレード

Amazon EKS はクラスターのインプレースアップグレードをサポートしています。インプレースアップグレードでは、コントロールプレーンのアップグレード後、データプレーンであるマネージド型ノードグループのアップグレードを行います。Amazon EKS では UpdateNodegroupVersion API を提供しており、マネジメントコンソールや eksctl などを介してマネージド型ノードグループをアップグレードすることが可能です。マネージド型ノードグループのアップグレードを実行すると、NodegroupUpdateConfig で定義されている maxUnavailable および maxUnavailablePercentage の設定に従って、ノードグループ内のノードが一定台数毎にローリングアップグレードされます。新しいバージョンのノードが立ち上がった後、古いバージョンのノードから Pod を Drain します。その後、すべての Pod が削除されたノードが終了します。マネージド型ノードグループのアップグレードプロセスの詳細については、マネージド型ノードの更新動作を参照ください。

インプレースアップグレードでは、既存のクラスターリソースが維持されるため、クラスター構成 (API エンドポイント、OIDC、ENI、ロードバランサーなど) の一貫性が保たれます。アプリケーションの再展開や外部リソース (DNS、ストレージなど) の移行なども必要としないため、クラスターを管理するユーザーにとって複雑性が少ないです。そのため、この戦略は 3 つの戦略のうち最もシンプルな方法といえます。また、マネージド型ノードグループ内の各ノードはローリングアップグレードにより順番に終了されるため、アップグレードプロセス時に発生するランニングコストも効率的に抑えることができます。

一方で、クラスターのアップグレード後は以前の Kubernetes バージョンにダウングレードすることはできません。また、1 度に実行できる Kubernetes マイナーバージョンのアップグレードは 1 つだけになります。そのため、2 つ以上のバージョン (例えば、1.28 から 1.30 ) を更新する必要がある場合は、アップグレードプロセスを 2 回実行する必要があります。また、マネージド型ノードグループのアップグレードプロセスは完全に自動化されており、このプロセスを実行するとすべての古いバージョンのノードが 1 度に新しいバージョンに置き換わります。そのため、例えばアプリケーションの停止タイミングや順序などを制御するためにノードグループ内の特定のノードのみアップグレードを実行して新しいバージョンに置き換える、といった細かい制御ができません。

インプレースアップグレード戦略を選択する際、EKS クラスター上で動作するシステムにどのような影響が起こり得るか確認することが重要です。例えば、EKS の新しいバージョンでどのような Kubernetes の API が非推奨または削除されるか把握します。そして、それらの変更により自身のシステムでどのような影響が起こるか確認する必要があります。Amazon EKS のリリースノートを確認することでこれらを確認できます。加えて、Amazon EKS アップグレードインサイトを利用することで、クラスターのアップグレード時に影響する可能性のある問題を特定できます。また、ノードグループのアップグレード時にアプリケーションの可用性が担保される必要があります。例えば、古いバージョンのノードから Pod が Drain されてもシステムを維持するために必要な数の Pod が維持されるように設計する必要があります。ユーザーは、PodDisruptionBudgets や topologySpreadConstraints をワークロードに設定することで、適切な可用性設定ができます。これらの詳細については EKS ベストプラクティスガイドを参照ください。

ノードグループレベルのブルー/グリーンアップグレード

図 2: ノードグループレベルのブルー/グリーンアップグレード

ノードグループレベルのブルー/グリーンアップグレードでは、コントロールプレーンはインプレースでのアップグレードを実行します。これにより、既存のクラスターリソースが維持された状態でアップグレードプロセスを実行できます。そのため、クラスターを管理するユーザーにとって複雑性が少ない点はインプレースアップグレード戦略と同様です。インプレースアップグレード戦略と異なるのは、コントロールプレーンのアップグレードが完了した後、あらかじめ新しい Kubernetes バージョンで構成されたマネージド型ノードグループを作成する点です。

すでに説明したように、UpdateNodegroupVersion API を利用したマネージド型ノードグループのアップグレードでは、アップグレードプロセスは完全に自動化されています。そのため、Drain されるノードの順序など、細かい制御をユーザーはできません。一方で、この戦略では古いバージョンのノードグループから新しいバージョンのノードグループへの Pod の移行はユーザーが完全に制御することになります。そのため、ユーザーは古いバージョンの各ノードに対する Cordon や Drain のタイミングや順序を任意で計画できます。これは、例えば長時間実行されるバッチ処理が動作しているノードが存在する場合などに有効です。また、マネージド型ノードグループが管理する各ノードには eks.amazonaws.com/nodegroup ラベルが付与されます。nodeSelector や nodeAffinity でこのラベルを参照することで、Pod 単位で新しいノードグループへのスケジューリングを制御することも可能です。

一方で、この戦略でアップグレードプロセスを実行している最中は 2 つのノードグループが一時的に存在することになります。そのため、インプレースアップグレード戦略と比較してランニングコストは高くなることが考えられます。ただし、ブルーとグリーン各マネージド型ノードグループのスケール数をアプリケーションの移行状況に応じて制御していくことでランニングコストを最適化することはできます。また、Pod の移行に必要な操作をすべてユーザーが実行する必要があるため、アップグレードに必要な作業コストもインプレースアップグレード戦略よりも高くなることが考えられます。

その他、クラスターのダウングレードに関する制約や EKS クラスター上で動作するシステムへの影響確認などが必要な点はインプレースアップグレード戦略と同様です。

クラスターレベルのブルー/グリーンアップグレード

図 3: クラスターレベルのブルー/グリーンアップグレード

クラスターレベルのブルー/グリーンアップグレードでは、新規に新しい Kubernetes バージョンの EKS クラスターを作成します。そして、古い Kubernetes バージョンのクラスターで動作するアプリケーションを新しいバージョンのクラスターに対してデプロイします。その後、古いバージョンのクラスターから新しいバージョンのクラスターで動作するアプリケーションにトラフィックを切り替えるなどして新しいバージョンのクラスターにアプリケーションを移行します。このように、この戦略ではノードグループレベルのブルー/グリーンアップグレード戦略と同様にアプリケーション単位でアップグレードプロセスを進めることができます。

Amazon EKS では、アプリケーションをクラスター外部に公開する場合、AWS Load Balancer Controller を利用することで Network Load Balancer (NLB) や Application Load Balancer (ALB) を作成できます。そのため、NLB や ALB を宛先とするアプリケーションの DNS レコードや NLB や ALB に関連付けされるターゲットグループを制御することで、古いバージョンのクラスターから新しいバージョンのクラスターで動作するアプリケーションにトラフィックを切り替えることができます。AWS Load Balancer Controller では TargetGroupBinding というカスタムリソースを提供しています。これを利用することで、NLB や ALB のターゲットグループに Kubernetes の Service リソースを関連付けることができます。リスナールールによって、古いバージョンのクラスターおよび新しいバージョンのクラスターで動作するアプリケーションが関連付けられたターゲットグループに対して、柔軟な条件でトラフィックシフトが制御できます。また、DNS の場合はトラフィックシフトの際に TTL を考慮する必要がありますが、ターゲットグループを利用する場合はその必要がありません。

この戦略では、既に説明したようにトラフィックシフトによってアプリケーション単位でアップグレードプロセスを制御できます。また、新しいバージョンのクラスターにアプリケーションをデプロイした後、その環境内で安全に動作確認を実行できます。さらに、新しいバージョンのクラスターで問題が起きた際に古いバージョンのクラスターにアプリケーションを切り戻すことができます。他の 2 つの戦略では、クラスターのアップグレード後にダウングレードを行うことはできませんが、この戦略では古いバージョンのクラスターにトラフィックシフトすることでアプリケーション単位で切り戻すことができます。また、新規にクラスターを立ち上げることによって、インプレースアップグレードの制約である 1 度に実行できる Kubernetes マイナーバージョンのアップグレードは 1 つだけという制約を受けることがなくなります。そのため、2 つ以上のバージョンを一度にアップグレードできるようになります。このように、1 度に実行できるマイナーバージョンのアップグレードやアップグレード後のダウングレードに制約のある他の 2 つの戦略と比較すると、この戦略は最も柔軟かつ安全にクラスターをアップグレードできるといえます。

一方で、この戦略でアップグレードプロセスを実行している最中は 2 つのクラスターが一時的に存在することになります。そのため、他の 2 つの戦略と比較してランニングコストは最も高くなることが考えられます。また、古いバージョンのクラスター上で動作する各アプリケーションを新しいバージョンのクラスターにデプロイする際に、アプリケーションのデプロイプロセスにどのような変更を加えるべきか評価する必要があります。CI/CD パイプラインでのアプリケーションのデプロイ先クラスター追加などの作業コストを評価することが大切です。GitOps と呼ばれる運用フレームワークを利用することで、システムの望ましい状態に関して信頼できる唯一の情報源 (single source of truth) を宣言的に管理することができるため、これらの作業を省力化することができるかもしれません。GitOps の詳細については GitOps を用いた Amazon EKS の自動化を参照ください。また、永続ボリュームを利用しているようなステートフルなアプリケーションが存在する場合、それらの移行手順を計画する必要があります。例えば、永続ボリュームとして Amazon Elastic Block Store (EBS) を利用している場合はスナップショット機能の利用を検討できますが、データの整合性に関しては注意する必要があります。加えて、他にもトラフィックシフトの作業を実行する必要もあります。そのため、他の 2 つの戦略と比較してアップグレードプロセスに必要な作業コストも最も高くなることが考えられます。

アップグレードプロセスに役立つ機能

ここまで、EKS クラスターのアップグレード戦略について各戦略の解説を行いました。その中で、クラスターをアップグレードする際にその変更内容が既存のシステムにどのような影響がもたらすかを確認することの重要性について言及しました。しかし、確認内容に不足がないようにするためには多くの時間を費やす必要があります。また、最新の Amazon EKS のリリースを追従することが理想的ではありますが、様々な理由によりクラスターのアップグレード作業が難しい場合もあります。そのため、ユーザーが運用しているクラスターバージョンの標準サポート期間が終了してしまうリスクも考えられます。この記事では、このような課題に対して役立つ Amazon EKS の機能について紹介します。

Amazon EKS アップグレードインサイト

図 4: Amazon EKS アップグレードインサイト

Amazon EKS アップグレードインサイトでは、Amazon EKS と Kubernetes のベストプラクティスに従うのに役立つ推奨事項を提供します。そして、EKS クラスターがそれらの推奨事項に適合しているか自動的かつ定期的にチェックされます。この機能により、クラスターのアップグレードに影響する可能性のある問題をスキャンして確認できます。非推奨もしくは削除予定の Kubernetes の API を利用しているクライアントを特定できるため、クラスターをアップグレードする前に修正する必要があるコントローラーやコンフィグレーションを素早く見つけて対応できます。さらに、バージョン固有のガイダンスにより、次のバージョンへのアップグレードに関する重要な情報を確認できます。この機能を活用することで、クラスターのアップグレードのテストと検証に費やす工数を最小限に抑えることができ、かつ新しいクラスターバージョンで動作するアプリケーションの信頼性を向上できます。

Amazon EKS インサイトは無料で利用でき、すべての Amazon EKS バージョンでデフォルトでオンになっています。 Amazon EKS アップグレードインサイトの詳細については、クラスターのインサイトを参照ください。

延長サポート

延長サポートでは、クラスターバージョンの標準サポート期間 14 ヶ月に加えて最大 12 ヶ月のサポートを提供します。延長サポート期間中は、そのバージョンに対して Amazon EKS が管理する Kubernetes コントロールプレーンの継続的なセキュリティパッチを受け取ることが可能です。さらに、Amazon VPC CNI、kube-proxy、CoreDNS アドオン、AWS が提供する Amazon EKS 最適化 Amazon Linux AMI、Bottlerocket、Amazon EKS 最適化 Windows AMI、Amazon EKS Fargate ノードの重要なパッチをリリースします。また、延長サポートに該当するすべてのクラスターは、引き続き AWS からテクニカルサポートを受けることができます。

延長サポートはデフォルトで有効化されていますが、クラスター毎に有効/無効を設定できます。延長サポートの設定方法については Manage EKS extended support を参照ください。延長サポートが有効化されている場合、クラスター標準サポートが終了したバージョンを利用しているクラスターは自動的に延長サポートに入ります。また、延長サポートで動作しているクラスターに対して追加料金が発生します。この記事の投稿時点では、延長サポート対象となるクラスターあたり 1 時間あたり 0.60 USD が請求されます。この料金には、Amazon EKS クラスターに支払うクラスターあたり 1 時間あたり 0.10 USD が含まれます。延長サポートの詳細については Amazon EKS Kubernetes のバージョンを参照ください。

まとめ

この記事では、Amazon EKS クラスターのアップグレードについて、アップグレードに関する制約やアップグレードプロセスにかかるコスト、システムへの影響度などを考慮した 3 つのアップグレード戦略について考察をしました。約 4 ヶ月に一度のリリースサイクルを追従するためには、アップグレードの柔軟性や安全性、それにかかる各種コストなどを考慮した上で適切な戦略を選択することが必要です。さらに、ビジネスの成長とともにシステムやクラスターの規模は大きくなります。そのため、定期的に適切なアップグレード戦略を見直すことも大切です。また、Amazon EKS ではクラスター運用を支える機能が日々アップデートされるため、これらの機能を利用しながら運用を効率化できます。

著者プロフィール

shota-suzuki 鈴木祥太 (Shota Suzuki) は AWS Japan のソリューションアーキテクトで、Web 業界のお客様を中心にアーキテクチャ設計や構築をサポートしています。

Amazon Web Services ブログ