技術記事 2026/7/31

EKSのアップグレードに「7日以内のやり直し」ができた ― バージョンロールバックとアップグレード戦略の設計判断

Amazon EKSのクラスタバージョンロールバック機能を整理します。7日以内・1マイナーバージョン前のみという制約、Readiness Insightsの4ステータス、巻き戻る対象/対象外の非対称性、クラスタ構成別の運用差を踏まえ、アップグレード戦略への実務インパクトを解説します。

#Amazon EKS
#Kubernetes
#AWS
#アップグレード
#SRE

Amazon EKSは、クラスタのKubernetesバージョンをインプレースアップグレードした後、コントロールプレーンを前のマイナーバージョンへロールバックできる機能を提供しています。アップグレード後にアプリケーションの非互換性や想定外の挙動が見つかった場合に、既知の正常な状態へ戻す手段です。

この機能の要点は「戻せる」こと自体よりも、戻せる条件が狭く設計されていることにあります。本記事では公式ドキュメントに基づき、前提条件とReadiness Insightsによる事前チェック、巻き戻る対象/対象外の非対称性、クラスタ構成ごとの運用差を整理します。

背景：EKSのアップグレードとロールバックの位置づけ

これまでEKSのクラスタバージョンアップグレードは「前に進む」操作でした。問題が見つかった場合の選択肢は、新バージョンの上で修正を当てるか、次のアップグレードまで我慢するかのいずれかでした。ロールバック機能は、この一方通行の運用に「アップグレード完了から7日以内」という限られた時間枠でのやり直しを追加します。EKSの基本的なアップグレード手順をすでに理解している方は、次のセクションから読み進めてください。

何が変わったか：ロールバックの前提条件

ロールバックを実行するには、次の条件をすべて満たす必要があります。

条件	内容
7日以内	アップグレード完了から7日を過ぎるとロールバックは利用できない
インプレースアップグレード済み	作成時点のバージョンのままのクラスタは戻せない
1マイナーバージョンのみ（N→N-1）	直前の1バージョンのみ戻せる。1.31→1.32→1.33と進めた場合、1.32へは戻せても1.31へは戻せない
サポート・拡張サポート	戻す先は現在サポート対象のバージョンであること。拡張サポート対象へ戻す場合は事前にポリシーを`EXTENDED`へ変更。拡張サポート終了に伴う自動アップグレード後は前バージョンへ戻せない
クラスタの状態・機能互換性	クラスタが`ACTIVE`であること、現バージョンで有効化したEKS機能が前バージョンで未対応でないこと。後者は`--force`でも回避できない

これらの条件は--forceでも突破できません。

ロールバックの3つの前提条件（7日以内・N→N-1のみ・機能互換性）から、Readiness Insightsのチェック項目、PASSING/WARNING/ERROR/UNKNOWNの4ステータスへ至るフロー図。--forceが回避できるのはinsightチェックのみで前提条件自体は回避できないという注記付き — 図1: ロールバックの前提条件とReadiness Insightsの4ステータス

Readiness Insightsは何を見ているか

前提条件を満たすと、EKSはROLLBACK_READINESSカテゴリのクラスタinsightとして、チェック結果を提示します。insightはアップグレード実行後に生成され、7日間のロールバック可能期間中に参照できます。24時間ごとに自動更新されるほか、コンソールやCLIのstart-insights-refreshで手動更新もでき、ロールバック開始時にも古いデータを検知すると自動再評価されます。

チェック対象は、API利用の互換性（フィールド単位の変更検知を含む）・クラスタヘルス・kubelet/kube-proxyのバージョンスキュー・アドオンのバージョン互換性です。EKS Auto Modeで動作しているクラスタでは、これに加えてNodePoolのdisruption budget・do-not-disrupt annotation・PodDisruptionBudgetの設定も評価されます。

結果はPASSING・WARNING・ERROR・UNKNOWNの4段階です。PASSINGとWARNINGはロールバックを妨げませんが、ERRORとUNKNOWNはブロックします。ブロック時は原因を解消するか、--forceですべてのinsightチェックを無視して進めるかを選びます。

--forceが無視するのはinsightチェックだけです。7日以内・N→N-1・EKS機能の互換性といった前提条件は--forceでも素通りしません。Auto Modeクラスタでは、--forceを使ってもNodePoolのdisruption budgetやPodDisruptionBudget等の中断制御は引き続き尊重されます。EKS側は、insightチェックを無視した場合の安全性を保証しないとも明記しており、結果への責任は利用者側に残ります。

設計判断ポイント①：巻き戻る/戻らないものの非対称性

ロールバックで戻るのは、Kubernetes APIサーバーとコントロールプレーンのコンポーネント・設定、そのプラットフォームバージョン（前バージョンの最新のプラットフォームバージョンに揃う）です。EKS Auto Modeを使っている場合は、ワーカーノードのロールバックもこの中に含まれ、EKS側が自動的に処理します。

一方で、次のものは自動では戻りません。

etcdデータ：クラスタの状態・リソース・設定はそのまま保持される
ワークロード：Pod・Deployment・Serviceは動き続ける
EKSアドオンのバージョン：変わらず、利用者が別途管理する
永続ボリュームとデータ：そのまま残る
自己管理・ハイブリッドノード：戻す作業は利用者の責任
Managed Node Group（MNG）：UpdateNodegroupVersionで個別に戻す必要がある

つまり、ロールバックは「コントロールプレーンだけを狭く正確に戻す」設計です。データやワークロードを壊さない安全性と引き換えに、アドオンやノード側は利用者が明示的に手当てしなければ新バージョンのまま取り残されます。前バージョンと非互換なアドオンは、コントロールプレーンのロールバック前にダウングレードが必要です。

ロールバックで巻き戻る対象（APIサーバー・コントロールプレーン設定・プラットフォームバージョン・Auto Modeワーカーノード）と巻き戻らない対象（etcd・ワークロード・アドオン・永続ボリューム）を左右に対比し、下段にAuto Mode／Managed Node Group／自己管理・ハイブリッド／Fargateの運用差を並べた図 — 図2: 巻き戻る対象/対象外の非対称性とクラスタ種別ごとの運用差

設計判断ポイント②：クラスタ構成別の運用差

ワーカーノード側の扱いは、クラスタ構成によって手順が異なります。

EKS Auto Modeは、ロールバックを開始すると、EKSがコントロールプレーンを戻す前にAuto Modeのワーカーノードを自動でロールバックします。追加操作は不要です。

**Managed Node Group（MNG）**は、コントロールプレーンとは別にUpdateNodegroupVersion APIでノードグループを戻す必要があります。ワーカーノードはコントロールプレーンより新しいバージョンで動作できないため、コントロールプレーンを戻す前にノード側を戻すのが前提です。

自己管理・ハイブリッドノードは、AMIや設定の更新を含め、ロールバック作業自体が利用者の責任です。

Fargateはロールバック非対応です。コントロールプレーンと同じバージョンで動くFargate podはkubeletのバージョンスキューでERRORになり、EKS側は自動的には戻せません。回避策はPodを事前削除しロールバック完了後に再デプロイするか、--forceでinsightチェックを無視する（互換性は未保証）かのいずれかです。

アップグレード戦略への実務インパクト

Readiness Insightsは「その時点のクラスタ状態」を評価する仕組みです。チェック後からロールバック完了までの間にクラスタへ変更を加えると、その変更は最初のチェックに反映されず、ロールバック後に問題を引き起こす可能性があります。ロールバックは「チェック済みの状態を戻す」操作であり、「今この瞬間を保証する」操作ではありません。

この制約を踏まえると、次の判断が求められます。

7日間を運用計画に組み込む。検証期間を7日以内に収めるか、超過後は「前に進むしかない」前提で検証項目を絞り込んでおきます。
アドオンとMNGの手当てを手順書に含める。コントロールプレーンだけ戻して安心すると、非互換やバージョン差分が後から表面化します。
Fargateクラスタは手順にPod削除・再デプロイを組み込む。気づかずロールバックすると--force頼みの運用になりかねません。
リハーサル省略の可否をinsightのステータスだけで判断しない。WARNINGは参考情報にすぎず、ERROR・UNKNOWNの--force無視はEKS側が安全性を保証しない領域に踏み込む判断です。

なお、拡張サポート対象のバージョンへロールバックする場合は、拡張サポート料金が新たに発生する点もコストの見積もりに含めておく必要があります。

まとめ

本記事のポイントを3つに整理します。

ロールバックは、アップグレード完了から7日以内・1マイナーバージョン前（N→N-1）のみという狭い条件で提供される機能です。Readiness InsightsはPASSING/WARNING/ERROR/UNKNOWNの4段階で示し、--forceが回避できるのはinsightチェックのみで前提条件自体は回避できません。
巻き戻るのはコントロールプレーンだけです。etcdデータ・ワークロード・永続ボリュームは保持される一方、アドオンのバージョンは自動では戻らず利用者が別途管理する必要があります。
クラスタ構成によって運用手順が異なります。Auto Modeはノードロールバックまで自動、MNGはUpdateNodegroupVersionで個別対応、自己管理・ハイブリッドは利用者の責任、Fargateはロールバック非対応です。

戻せる範囲と戻せない範囲、構成ごとの手順の違いを事前に手順書へ落とし込んでおくことが、この機能を実際の運用で使いこなす前提になります。