Kubernetes は年間 3 つのマイナーバージョンというリリースサイクルにより、セキュリティと機能を維持するためにクラスターを定期的にアップグレードする必要があります。しかし、Kubernetes のバージョンアップグレードは必ずしも容易ではありません。新しいバージョンでは、機能の追加、API の非推奨化、内部コンポーネントの変更など、既存のアプリケーションに影響を与える可能性のある変更が導入されることがよくあります。オープンソースの Kubernetes は、その設計上、アップグレード完了後に Kubernetes コントロールプレーンをロールバックする機能を備えていません。ネイティブなロールバックの手段がないため、多くの組織はコストのかかる緩和戦略を採用してきました。これには、インフラストラクチャコストが 2 倍になるブルー / グリーンデプロイメントや、多大なエンジニアリング時間を消費するクラスター状態の手動スナップショットが含まれ、いずれもネイティブには存在しなかったセーフティネットを構築するためのものでした。
Amazon EKS バージョンロールバックにより、アップグレード後に問題を発見した場合、Kubernetes コントロールプレーンを既知の正常な状態へ安全に戻せるようになりました。EKS Auto Mode を使用しているクラスターの場合、ロールバック機能はデータプレーンにも及び、クラスター全体にわたる包括的な保護を提供します。この機能は 2 つの重要なメリットをもたらします。1 つ目は、本番環境のアップグレードに信頼性の高いセーフティネットを提供し、災害復旧計画に関する規制要件を満たす手段を提供することです。2 つ目は、ロールバックによって遅延の理由がなくなるため、セキュリティ体制を強化するより迅速なアップグレードをサポートすることです。その結果、チームはプロアクティブにアップグレードを行い、既知の CVE を含むバージョンを実行する時間を短縮し、サポートされ積極的にパッチが適用されたソフトウェアを要求するフレームワークへのコンプライアンスを維持できます。アップグレードを元に戻す手段を提供することで、EKS バージョンロールバックは運用の信頼性を維持しながら、最新の Kubernetes リリースへの追従を支援します。
バージョンロールバックにより、プラットフォームエンジニアやクラスター管理者は、インプレースアップグレードのためのセーフティネットを手に入れます。アップグレード後に問題が発生した場合、7 日以内にクラスターを以前の Kubernetes バージョンに戻すことができます。EKS は Amazon EKS ロールバックインサイトを使用して、以前のバージョンとの互換性についてクラスターを自動的にスキャンし、ロールバックの安全性に影響を与える可能性がある問題を表面化させます。
ロールバックは、実行中のワークロードへの影響を最小限に抑えるため、NodePool disruption budgets や PodDisruptionBudgets (PDBs) を含む、設定された disruption budgets を遵守します。--force フラグは EKS ロールバックインサイト の警告をバイパスし、潜在的な互換性の問題が検出された場合でもロールバックを続行します。ただし、--force は disruption budgets やポッドレベルの中断制御を上書きしません。これらは、ワークロードの可用性を維持するため、ロールバックプロセス全体を通じて引き続き遵守されます。
これらの検証は、ロールバックを開始する前に潜在的なブロッカーを特定することで、データプレーンのロールバックがスムーズに進行できることを確認するのに役立ち、自動化されたノード置換プロセスを遅延または妨げる可能性のある設定を可視化します。
aws eks cancel-update \
--name my-cluster \
--update-id <update-id> \
--region <aws-region>
キャンセル後、クラスターはロールバックが開始された時点のバージョンで ACTIVE 状態に戻り、次の操作に進むことができます。
ロールバック中のスケーリング
Amazon EKS は、バージョンロールバックの進行中であっても、ワークロードの需要に応じてクラスターの応答性を維持します。EKS はクラスターの同時更新をサポートしていませんが、アクティブなロールバック操作中も、必要に応じてクラスターのコントロールプレーンのスケーリングを継続します。これは、ロールバックの期間中にクラスターの API サーバーの負荷が増加した場合、EKS が需要に対応するためコントロールプレーンのインフラストラクチャを自動的にスケーリングすることを意味します。バージョンの復元が処理されている間、ワークロードは影響を受けません。
Amazon EKS バージョンロールバックの始め方
ロールバックを開始するには、既存の UpdateClusterVersion API、AWS Command Line Interface (AWS CLI)、Amazon EKS コンソール、またはその他の任意のツールを使用できます。
AWS CLI を使用する
ロールバックプロセスでは、アップグレードに使用するものと同じ API を使用しますが、以前のバージョンを指定します。
# バージョン 1.33 から 1.32 にロールバック
aws eks update-cluster-version \
--name my-cluster \
--kubernetes-version 1.32
ロールバックを開始する前に、EKS クラスターインサイトで ロールバックインサイト を確認してください。
# ロールバックインサイトの一覧を取得
aws eks list-insights \
--cluster-name my-cluster \
--filter category=ROLLBACK_READINESS
# 特定のインサイトの詳細情報を取得
aws eks describe-insight \
--cluster-name my-cluster \
--id <insight-id>
クラスターインサイトがエラー (ERROR ステータス) を報告した場合は、ロールバックを続行する前にそれらの問題を解決する必要があります。PASSING、WARNING、または UNKNOWN ステータスのインサイトはロールバックをブロックしません。
Amazon EKS コンソールを使用する
Amazon EKS コンソールで、以下の操作を行います。
- クラスターに移動し、Actions メニューを選択します。
- ロールバッククラスターバージョン を選択します。
- ロールバックインサイト を確認して、ブロックする問題がないか特定します。
- ターゲットバージョンを選択し、Initiate rollback を選択します。
- ロールバックアクションを確認します。
Salesforce における EKS ロールバック導入の歩み
Amazon EKS は、EKS クラスター向けの Kubernetes バージョンロールバックを導入しました。この機能により、クラスター管理者は、インプレースアップグレードの完了後の任意の時点で、コントロールプレーンのアップグレードを以前のマイナーバージョンに戻すことができます。この機能は、アップグレードプロセスで長らく有効な手立てがなかった重大なリスクを根本から解消します。
ロールバック適用の前提条件
ロールバック機能の最も重要な前提条件は、コントロールプレーンとデータプレーン (kubelet) の間のバージョン関係です。ノードの kubelet がアップグレードされたバージョン (N+1) にリサイクルされた後、コントロールプレーンを元に戻すには、対応するデータプレーンのロールバックが必要です。
これにより、現在のアップグレードパイプラインへの直接的な依存関係が生じます。そのパイプラインは、ステージ間のベイク期間なしに、コントロールプレーン、アドオン、データプレーンを単一の連続した実行で進めます。
したがって、コントロールプレーンとデータプレーンのアップグレードを明確に分離することが、ロールバック機能を有意義に活用するための前提条件となります。
推奨プロセス：コントロールプレーンのベイク期間を設けた段階的アップグレード
ロールバックの期間を維持し、アップグレード後のリグレッションの範囲を縮小するために、アップグレードシーケンスを次のように再構成することをお勧めします。
- アドオンのアップグレード – マネージドアドオンを、N-1、N、N+1 の K8s バージョンと相互に互換性のあるバージョンにアップグレードします。これにより、アドオンがロールバックまたはアップグレードのいずれかのブロック要因にならないことを検証します。
- コントロールプレーンのアップグレードとベイク – コントロールプレーンをターゲットバージョンにアップグレードし、環境ごとに約 1 週間のベイク期間を設けます。この期間により、データプレーンが新しいバージョンにアップグレードされる前に、コントロールプレーンのリグレッションを早期に検出できます。
- データプレーンのアップグレード – ベイク期間の後、ノードのリサイクルを進めて kubelet をターゲットバージョンにアップグレードします。
注意: サイクルの早い段階でリグレッションを表面化させるため、コントロールプレーンとデータプレーンのバージョンを一致させた初期検証の実施をお勧めします。
推奨されるシーケンスは、コントロールプレーンのアップグレード、次に 1 週間のベイク期間、続いてデータプレーンのアップグレード (ノードの入れ替え) です。
データプレーンのアップグレード中または後にリグレッションが特定された場合は、以下のようになります。
- データプレーンのリグレッションのみ: ワーカーノードを N-1 の kubelet にロールバックします。コントロールプレーンは N のままです。
- コントロールプレーンとデータプレーンの両方のリグレッション: まずデータプレーンをロールバックし (kubelet を N-1 に戻す)、その後コントロールプレーンのロールバックを開始します。
メリット:
- このアプローチにより、フリート全体で迅速なコントロールプレーンの展開が可能になり (コントロールプレーンのアップグレードは高速)、EKS 拡張サポート料金の発生を抑えることができます。
- これにより、ベイク期間中もロールバックの期間が開いたままになり、インシデント対応がより迅速かつ低リスクになります。
トレードオフ:
- フリートで完全なアップグレードサイクル (コントロールプレーン + データプレーン) の実施完了に時間がかかります。
シナリオ例
シナリオ 1: 問題が検出されないクリーンなロールバック
クラスターが 1.30 から 1.31 にアップグレードされました。ロールバックインサイトはすべて PASSING を示しています。管理者がロールバックを開始します。
aws eks update-cluster-version --name my-cluster --kubernetes-version 1.30
# Returns InProgress VersionRollback update
シナリオ 2: インサイトエラーによってロールバックがブロックされる
クラスターが 1.30 から 1.31 にアップグレードされました。データプレーンのノードはすでに kubelet 1.31 にリサイクルされています。ロールバックインサイトは kubelet/kube-proxy のバージョンスキューについて ERROR を示しています。
解決策: 影響を受けるノードを 1.30 の kubelet にリサイクルして戻し、kube-proxy を互換性のあるバージョンにロールバックし、インサイトを更新してからロールバックを再試行します。
シナリオ 3: 複数バージョンのロールバックを試みる
クラスターが 1.29 から 1.30、そして 1.31 にアップグレードされ、その後 1.30 にロールバックされました。管理者が 1.29 へのロールバックを試みます。
aws eks update-cluster-version --name my-cluster --kubernetes-version 1.29
# Error: The cluster cannot be rolled back to the Kubernetes version specified.
# You can only rollback by 1 version.
ロールバックインサイトの対象範囲
ロールバックインサイトは EKS マネージドアドオン (coredns、VPC CNI、kube-proxy) をチェックします。cluster-autoscaler のようなセルフマネージドアドオンは自動的にはチェックされません。Salesforce では、ロールバックのターゲットバージョンとのセルフマネージドアドオンの互換性について、独自の検証を維持する必要があります。
当社の Kubernetes アップグレードプロセスは、さまざまなバージョンにわたる複数のアップグレードサイクルを経て、広範な検証、ベイク期間、自動化されたサインオフ、段階的な本番展開を備えた厳格な多段階プログラムへと構築されてきました。これらすべては、1 つの根本的な制限を補うために設計されたものでした。それは、EKS がコントロールプレーンのロールバックをサポートしていなかったことです。
EKS バージョンロールバックのローンチは、Kubernetes アップグレードのリスクの捉え方・考え方を根本的に変えます。
- 本番環境のアップグレードのための真のセーフティネット — いずれかの段階的ロールアウトの各グループでアップグレード後の問題が表面化した場合でも、ロールバックはもはや選択肢から外れることはありません。
- フリート全体でのより迅速なコントロールプレーンの展開 — コントロールプレーンとデータプレーンのアップグレードをベイク期間で分離することにより、チームはフリート全体でコントロールプレーンのバージョンを迅速に進めることができ、拡張サポート料金が発生するリスクを軽減します。
- 規制リスクの低減 — 規制対象のワークロードでは、文書化されテストされたロールバックの手段が、災害復旧計画のコンプライアンス要件に対応します。
この機能を最大限に活用するには、対象を絞ったパイプラインの変更を行う必要があります。すなわち、コントロールプレーンとデータプレーンの展開の分離、コントロールプレーンとデータプレーンにおけるアップグレードステージ間のベイク期間の導入、そしてロールバックインサイトの統合と適切なガードレールを備えたロールバック専用パイプラインの構築です。
当社の既存のアップグレードの厳格さと EKS バージョンロールバックのサポートを組み合わせることで、チームは大規模なクラスターフリート全体をより高い信頼性と縮小された影響範囲でアップグレードできる態勢が整います。
考慮事項
この機能に関する主要な考慮事項は以下のとおりです。
ロールバックの範囲 – バージョンロールバックは、1 つの Kubernetes マイナーバージョン (N から N-1) のロールバックをサポートします。複数バージョンのロールバックは現在サポートされていません。クラスターがインプレースアップグレードを通じて現在のバージョンにアップグレードされた場合にのみロールバックできます。バージョン N で作成されたクラスターは N-1 にロールバックできません。
サポートされるバージョン – バージョンロールバックは、現在サポートされている EKS バージョンで利用できます。これにより、ローンチ時点で現在サポートされているすべての EKS バージョンでのロールバックサポートが検証されます。
ロールバックの期間とタイムアウト – 以前のバージョンが EKS によってサポートされ続けている限り、アップグレード完了後 7 日以内であれば、いつでもロールバックを開始できます。ただし、新しいバージョンの新しい API や機能を利用する変更を加えた場合は、ロールバックする前にそれらの変更を元に戻す必要があります。
デフォルトでは、EKS はロールバック操作を失敗と見なす前に、完了までに最大 7 日間を許可します。さらに、ロールバックの準備状況を評価するのに役立つロールバックインサイトは、アップグレード後 7 日間のみ利用可能であるため、その期間内に評価して対応することが重要です。ただし、AWS CloudFormation や Terraform (それぞれ 36 時間および 24 時間の独自の操作タイムアウトを適用します) のような infrastructure-as-code (IaC) ツールを使用してクラスターを管理している場合、7 日間のロールバック期間が自動化パイプラインとの競合を引き起こす可能性があります。
これに対処するために、ロールバックリクエストでカスタムの timeoutMinutes を指定して、EKS が操作を失敗させる前にロールバックを試みる最大時間を定義できます。これにより、EKS のロールバック動作を IaC ツールのタイムアウト設定に合わせることができます。
aws eks update-cluster-version \
--name my-cluster \
--kubernetes-version 1.32 \
--rollback-config timeoutMinutes=1440
拡張サポート – 拡張サポート対象のバージョンにロールバックすると、クラスターに拡張サポート料金が発生し始めます。標準サポート対象のバージョンに再度アップグレードすると、拡張サポート料金は停止します。
ワーカーノードのロールバック – Auto Mode クラスターの場合、EKS はワーカーノードのロールバックを自動的に管理します。Managed Node Groups の場合は、UpdateNodegroupVersion API を使用してワーカーノードをロールバックします。セルフマネージドノードおよびハイブリッドノードは、お客様が手動でロールバックする必要があります。
Fargate: バージョンロールバックは AWS Fargate ワーカーノードではサポートされていません。Fargate ベースのクラスターのコントロールプレーンはロールバックできますが、ロールバック前のコントロールプレーンと同じ Kubernetes バージョンを実行している Fargate ポッドは、ERROR ステータスの kubelet バージョンスキューインサイトをトリガーします。これは、基盤となるインフラストラクチャが API サーバーとは独立した kubelet バージョンのダウングレードをサポートしていないために発生します。これを回避するには、ロールバックを開始する前に影響を受ける Fargate ポッドを削除するか、--force を使用してインサイトチェックをバイパスします。そうすれば、コントロールプレーンのロールバックが完了すると、新しいポッドがロールバックされたバージョンで起動します。
アドオンの互換性 – UpdateAddon API または EKS コンソールを通じて希望するアドオンバージョンを指定することで、EKS アドオンを手動でロールバックできます。クラスターインサイトは、ロールバックの安全性に影響を与える可能性のあるアドオン互換性の問題を特定します。
安全性チェック – EKS ロールバックインサイトは、ロールバックを許可する前に、API 互換性、feature gate 互換性、バージョンスキューポリシーを含む複数の安全性チェック項目に照らしてクラスターを自動的に検証します。ロールバックを続行する前に、すべてのエラーを解決する必要があります。EKS アップグレードインサイトは、標準的な Kubernetes および EKS コンポーネントの既知の互換性チェックをカバーしていることに注意することが重要です。カスタムアドオン、カスタムビルドされた AMI、または特注の設定については、アップグレード前にお客様の責任で検証する必要があります。さらに、バージョンロールバックは、日常的なアップグレードワークフローとしてではなく、アップグレード後の問題に対するセーフティネットとして設計されています。アップグレードインサイトが評価する内容の詳細については、EKS クラスターインサイトのドキュメントを参照してください。
今すぐご利用いただけます
Amazon EKS バージョンロールバックは、Amazon EKS が利用可能なすべての AWS リージョンで利用できるようになりました。リージョンごとの提供状況については、AWS リージョン別サービスページをご覧ください。
バージョンロールバックの使用に追加料金はかかりません。
詳細は、Amazon EKS ユーザーガイドの Amazon EKS バージョンロールバックのドキュメントをご覧ください。
Amazon EKS コンソールでぜひお試しいただき、AWS re:Post for EKS または通常の AWS サポート窓口を通じてフィードバックをお寄せください。
