Amazon EKS が Kubernetes バージョンロールバックに対応

Last updated at 2026-07-05Posted at 2026-07-05

はじめに

2026 年 7 月 1 日、AWS は Amazon EKS に対して Kubernetes バージョンロールバックを発表しました。マイナーバージョンアップグレードを実行した後、一定期間内であれば直前のバージョンへ戻せるようになったことが大きな特徴です。

EKS でクラスターを運用している方の中には、アップグレード後に想定外の問題が発生し、戻す手段がないまま原因調査や対応に追われた経験がある方もいるのではないでしょうか。今回のアップデートは、その課題に直接応えるものです。

本記事では、何が変わったのか、どのような場面で有効なのか、そしてどう判断し実践すればよいのかを中心に解説します。EKS を運用するインフラ・プラットフォームエンジニアの方や、アップグレード戦略の検討に関わる方を想定読者としています。

何が変わったのか

Amazon EKS のマイナーバージョンアップグレードは、これまで実行すると元に戻せない一方通行の操作でした。今回のアップデートにより、アップグレード完了後 7 日間以内であれば、コントロールプレーンを直前のバージョンへロールバックできるようになりました。戻る先は旧バージョンを再現した状態ではなく、実際に本番で稼働していた検証済みのバージョンそのものです。

ロールバックの対象範囲

ロールバックによって戻される対象と、戻されない対象は以下の通りです。

区分	対象
ロールバックされる	Kubernetes API サーバー、コントロールプレーンの各コンポーネント、EKS プラットフォームバージョン、EKS Auto Mode のワーカーノード
ロールバックされない	etcd データ、ワークロード（Pod・Deployment 等）、永続ボリューム、EKS アドオン、マネージドノードグループ、セルフマネージドノード・ハイブリッドノード

etcd のデータやワークロードはそのまま維持されます。ロールバックはあくまで Kubernetes のコントロールプレーンを対象とした操作であり、クラスターの状態やアプリケーションのデータが失われるものではありません。

ロールバックの制約

ロールバックを実行するには、いくつかの条件を満たす必要があります。

制約	内容
期間	アップグレード完了から 7 日間以内
対象バージョン	直前の 1 つ前のマイナーバージョンのみ（N から N-1）。2 世代以上前や、クラスター作成時点のバージョンへは戻せない
クラスター状態	`ACTIVE` 状態であること。他の更新が進行中の場合は実行不可
ノード	マネージドノードグループ、セルフマネージドノード、Fargate は対象外で、個別に対応が必要

特に、マネージドノードグループやセルフマネージドノードのバージョンはこの機能では戻らないため、コントロールプレーンをロールバックする前後で、ワーカーノード側の対応を別途行う必要があります。

コストとリージョン

この機能は追加コストなしで、Amazon EKS が提供されている全リージョンで利用できます。既存のクラスターに対しても、特別な事前設定を行うことなく利用可能です。

活用シーン

Amazon EKS のマイナーバージョンアップグレードは、これまで実行後に戻す手段がありませんでした。アップグレード後に、非推奨 API の利用や自作コントローラーとの非互換性、サードパーティ製ツールとの相性問題など、検証環境では発覚しにくい問題が本番環境で表面化するケースは少なくありません。今回のロールバック機能は、こうした「アップグレードしてみないと分からない問題」に対する安全網です。

この機能がなかった頃の対処法

ロールバック機能が存在しなかったこれまで、アップグレード後に問題が発生した場合の対処法は限られていました。

対処法	内容と課題
Blue/Green クラスター移行	新旧バージョンのクラスターを並行運用し、切り戻せるようにする方法。確実だが、クラスターをもう 1 つ用意する分のコストと構築の手間がかかる
事前のステージング環境での徹底検証	本番投入前に十分なテストを行う方法。ただし、本番相当の負荷やトラフィックパターンでしか再現しない問題までは防ぎきれない
クラスターの再構築	最終手段として、旧バージョンでクラスターを作り直す方法。ダウンタイムや作業負荷が大きい

いずれの方法も、追加のインフラ準備や作業コストを伴うものでした。今回の機能により、既存クラスターの API 操作 1 つで、コントロールプレーンを直前のバージョンへ戻せる選択肢が加わったことになります。

活用が見込まれる場面

この機能が特に役立つと考えられる場面を整理すると、次のようになります。

場面	活用イメージ
本番アップグレード後のトラブル対応	アップグレード直後に想定外の挙動が発生した際、原因調査と並行して、まず直前のバージョンへ戻して影響を最小化できる
非推奨 API やカスタムコントローラーの互換性検証	本番環境でアップグレードを試しつつ、問題があれば 7 日以内であれば戻せるという前提のもと、段階的に検証を進められる
EKS Auto Mode 運用チームのオペレーション簡素化	Auto Mode を利用している場合、ワーカーノードのロールバックも EKS 側で自動的に行われるため、運用側でノードの巻き戻し作業を個別に行う必要がない

この機能は、本番運用時のトラブル対応を助けるだけでなく、アップグレードを先延ばしにする理由を減らす効果もあります。ロールバックできるという前提があれば、既知の CVE を抱えたバージョンで稼働する期間を短くしやすくなり、パッチ適用済みソフトウェアを求めるコンプライアンス要件を満たしやすくなる、という運用チーム側のメリットも見込めます。

次章では、この安全網がどのような仕組みで実現されているのかを解説します。

仕組み

Amazon EKS は、アップグレード後のロールバックが安全に実行できるかどうかを、cluster insights の ROLLBACK_READINESS カテゴリという仕組みで可視化しています。この insight は、アップグレード完了後に自動的に評価され、7 日間のロールバック可能期間中、コンソールや CLI から確認できます。

Rollback Readiness Insights

チェック対象になるのは、API の互換性（API バージョンの世代交代に伴う非互換や、新しいフィールド・enum の変更などフィールドレベルの検出も含む）、クラスターのヘルス状態、kubelet や kube-proxy のバージョンスキュー、EKS アドオンのバージョン互換性です。EKS Auto Mode を利用しているクラスターでは、これに加えて NodePool の disruption budget や do-not-disrupt annotation、PodDisruptionBudget の設定も評価されます。

各チェックの結果は、次の 4 段階のステータスで表されます。

ステータス	意味	ロールバックへの影響
PASSING	問題なし	実行可能
WARNING	軽微な懸念あり	実行可能（あくまで参考情報）
ERROR	ブロッキングな問題あり	解消するか `--force` で回避しない限り実行不可
UNKNOWN	判定不能	解消するか `--force` で回避しない限り実行不可

insight はロールバック実行時にも再評価されます。insight データが古い場合、EKS はロールバック実行前に自動でリフレッシュを行います。

`--force` フラグの挙動

ERROR ステータスの insight があっても、--force フラグを付けることで、すべての insight チェック（ERROR・WARNING・UNKNOWN）をバイパスしてロールバックを進めることができます。

ただし、--force が無効化するのは insight チェックのみです。7 日間のウィンドウや、クラスター作成時点のバージョンかどうかのチェック、N-1 より前への多段階ロールバックを防ぐチェックといった前提条件は --force でも回避できません。EKS Auto Mode クラスターの場合も、NodePool の disruption budget や PodDisruptionBudget、do-not-disrupt annotation による制御は --force を指定しても引き続き有効です。

EKS Auto Mode のロールバックの流れ

EKS Auto Mode を利用しているクラスターでは、ワーカーノードのロールバックが Karpenter ベースの仕組みで自動的に行われます。処理の流れは次の通りです。

フェーズ	クラスターステータス	内容
ノードロールバック中	ACTIVE	Karpenter が既存ノードを、直前バージョンの AMI を使ったノードへ順次置き換える。この間もコントロールプレーンは現行バージョンのまま稼働を継続する
コントロールプレーンロールバック	UPDATING	API サーバーおよびコントロールプレーンの各コンポーネントが直前バージョンへ切り替わる
ロールバック完了	ACTIVE	クラスター全体が直前バージョンになる

処理の流れを図にすると、次のようになります。

ノードのロールバックが先に行われ、コントロールプレーンのロールバックは全ノードが対象バージョンのバージョンスキューポリシー内に収まった後に実行されます。Kubernetes のバージョンスキューポリシーでは、ワーカーノードは kube-apiserver より最大 3 マイナーバージョンまで古いバージョンで稼働できるため、この移行期間中の状態も許容される構成です。

ノードロールバックには既定で 720 分（12 時間）のタイムアウトが設定されており、rollbackConfig の timeoutMinutes パラメーターで 120 分から 10080 分（2 時間〜 7 日間）の範囲でカスタマイズできます。タイムアウトに達すると、ノードは現行バージョンへ戻り、コントロールプレーンのロールバックは行われないまま更新は失敗ステータスになります。

ノードのロールバックが完了する前であれば、CancelUpdate API でロールバック処理自体を中断することもできます。中断した場合、ノードは現行バージョンへ戻り、コントロールプレーンのロールバックは実行されません。7 日間のウィンドウ内であれば、中断後に改めてロールバックを実行し直すこともできます。

判断軸

これまでアップグレード後に問題が起きた場合、選択肢は基本的に「直す（Fix Forward）」しかありませんでした。ロールバック機能が加わったことで、「戻す」という選択肢も並んで検討できるようになりましたが、どちらが適切かはケースによって変わります。

判断のポイント

観点	ロールバックが向くケース	Fix Forward が向くケース
影響範囲	クラスター全体や複数のワークロードに影響が出ている	特定の Pod や機能のみに影響が限定されている
原因特定までの時間	原因の特定に時間がかかりそうで、まず影響を止めたい	原因が明確で、修正のほうが早く終わりそう
7 日間ウィンドウの残り	期限が近く、判断を先延ばしにするとロールバック自体ができなくなる	十分な時間が残っており、調査を進める余地がある
アドオンの互換性	ロールバック前提で、あらかじめアドオンのダウングレードも計画できている	直前バージョンで動かないアドオンが多く、ダウングレードのコストが大きい

ロールバック後もデータは戻らない点に注意

ロールバックが戻すのはコントロールプレーンのバージョンのみで、etcd のデータやワークロードの状態は保持されたままです。アップグレード後からロールバックまでの間に、新しい API や新しいフィールドを使ってリソースを作成していた場合、それらのリソースはロールバック後も残り続けます。--force で insight のエラーを無視して作成されたリソースについても、自動的にはクリーンアップされません。ロールバックを判断する際は、この間にどれだけ「書き込み」が発生したかも考慮に入れる必要があります。

また、insight の評価はロールバックを判断した時点のスナップショットです。insight を確認した後にクラスターへ変更を加えた場合、その変更はロールバック実行時の再評価まで反映されないことがあります。

責任分担の考え方

EKS が担うのはコントロールプレーンを安全に切り替えることまでで、アプリケーションやカスタムコントローラー、サードパーティ製ツールが直前バージョンで問題なく動作するかどうかの確認は利用者側の責任です。ロールバックを選ぶ場合も、戻した先のバージョンで自分たちのワークロードが動作することを前提として判断する必要があります。

なお、Standard Support 対象のバージョンから Extended Support 対象のバージョンへロールバックする場合、その時点から Extended Support の追加費用が発生します。

実践

ここからは、実際にロールバックを行う際の流れを、CLI のコマンド例とあわせて見ていきます。大きく分けると、Insight の確認、ワーカーノードとアドオンの準備、コントロールプレーンのロールバック実行、進捗確認という 4 つのステップになります。

Insight の確認

まず、ロールバックに影響する問題がないか、ROLLBACK_READINESS カテゴリの insight を確認します。コンソールからはクラスターの Upgrade insights タブで確認でき、CLI からは次のように取得できます。

aws eks list-insights \
  --cluster-name <cluster-name> \
  --region <region> \
  --filter '{"categories": ["ROLLBACK_READINESS"]}'

個別の insight の詳細は describe-insight で確認します。

aws eks describe-insight \
  --cluster-name <cluster-name> \
  --region <region> \
  --id <insight-id>

ERROR や UNKNOWN の insight があれば、内容を確認して対応します。対応が難しい場合は、後述の --force フラグで実行することもできますが、EKS 側では安全性を保証できない実行になる点は理解しておく必要があります。

ワーカーノードの準備

コントロールプレーンをロールバックする前に、ワーカーノード側の対応状況を確認しておきます。ノードの種別ごとに必要な対応は次の通りです。

ノードの種別	必要な対応
EKS Auto Mode	対応不要。ロールバック実行時に EKS が自動でノードのロールバックも行う
マネージドノードグループ	`update-nodegroup-version` で事前に直前バージョンへ更新しておく
セルフマネージドノード・ハイブリッドノード	利用者側の責任で AMI や設定を直前バージョンへ更新する
Fargate	ロールバック非対応。コントロールプレーンと同一バージョンの Fargate Pod が残っていると kubelet version skew の insight が ERROR になる

マネージドノードグループの更新は、次のようなコマンドで行います。

aws eks update-nodegroup-version \
  --cluster-name <cluster-name> \
  --nodegroup-name <nodegroup-name> \
  --kubernetes-version <kubernetes-version> \
  --region <region>

Fargate を利用している場合、コントロールプレーンと同じバージョンで稼働中の Pod があると insight が ERROR になります。ロールバック前にそれらの Pod を削除しておき、再デプロイ時に直前バージョンで起動させるのが基本的な対応です。--force で insight を無視して進めることもできますが、kubelet のバージョンスキュー違反を抱えたまま Fargate ワークロードが動作することになるため、置き換えが完了するまでは想定外の挙動が起きる可能性があります。

アドオンの確認

EKS はコントロールプレーンのロールバックにあわせてアドオンのバージョンを自動では戻しません。insight でアドオンの互換性を確認し、直前バージョンと互換性がないものがあれば、事前にダウングレードしておきます。

aws eks update-addon \
  --cluster-name <cluster-name> \
  --addon-name <addon-name> \
  --addon-version <addon-version> \
  --region <region>

なお、insight でチェックされるのは EKS マネージドアドオンのバージョンのみです。セルフマネージドのアドオンや、マネージドアドオンのバージョンを個別に上書きしている場合は、直前バージョンとの互換性を自分で確認しておく必要があります。

コントロールプレーンのロールバック実行

準備が整ったら、コントロールプレーンのロールバックを実行します。コンソールからは、クラスターの Actions メニューから Rollback cluster version を選択し、内容を確認したうえで実行します。

CLI の場合、既存の update-cluster-version コマンドに直前（N-1）のバージョンを指定して実行します。

aws eks update-cluster-version \
  --name <cluster-name> \
  --kubernetes-version <kubernetes-version> \
  --region <region>

コントロールプレーンのロールバックにかかる時間は、通常のアップグレードとほぼ同程度で、目安として 20 分程度です。

進捗の確認

実行後は、describe-update で進捗を確認できます。

aws eks describe-update \
  --name <cluster-name> \
  --region <region> \
  --update-id <update-id>

コンソールの場合は、クラスターの Update history タブから該当の更新 ID のステータスを確認できます。ステータスは InProgress から Successful または Failed に遷移し、Auto Mode クラスターの場合はノードのロールバック中もクラスター自体は ACTIVE のままで、コントロールプレーンのロールバックが始まったタイミングで UPDATING に切り替わります。

まとめ

今回のアップデートにより、Amazon EKS のマイナーバージョンアップグレードは、実行から 7 日間以内であれば直前のバージョンへ戻せるようになりました。戻る先は旧バージョンの再現ではなく、実際に本番で稼働していた検証済みの状態です。追加コストなしで全リージョンで利用でき、EKS Auto Mode を利用しているクラスターであれば、ワーカーノードのロールバックも自動で行われます。

一方で、戻せるのはコントロールプレーンのみで、マネージドノードグループやセルフマネージドノード、Fargate、アドオンについては個別の対応が必要です。万能な「取り消し」ではなく、期間と対象範囲が限定された保険です。

これまで一方通行だったアップグレードに「戻す」という選択肢が加わったことで、本番環境でのアップグレード運用の進め方は変わります。既存クラスターで insight の内容を確認しておくことが、この機能を活用する最初のステップです。

参考リンク

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up