**このページの改善にご協力ください** 

このユーザーガイドに貢献するには、すべてのページの右側のペインにある「**GitHub でこのページを編集する**」リンクを選択してください。

# EKS Auto Mode クラスターをロールバックする
<a name="rollback-automode"></a>

EKS Auto Mode を実行しているクラスター上でバージョンロールバックを開始すると、Amazon EKS はコントロールプレーンを元に戻す前に Auto Mode ワーカーノードのロールバックを自動的に管理します。このページでは、Auto Mode ノードのロールバックの仕組み、それを高速化する方法、および必要に応じてキャンセルする方法について説明します。

前提条件、インサイトチェック、ロールバックプロセス全体など、バージョンロールバックに関する一般的な情報については、「[以前の Kubernetes バージョンにクラスターをロールバックする](rollback-cluster.md)」を参照してください。

## Auto Mode のロールバックの仕組み
<a name="_how_auto_mode_rollback_works"></a>

EKS Auto Mode は Karpenter ベースのシステムを使用して、Kubernetes バージョンのアップグレードやロールバックなどのワーカーノードインフラストラクチャを管理します。Auto Mode が有効になっているクラスター上で以前の (N-1) バージョンで `UpdateClusterVersion` を呼び出すと、EKS は次のシーケンスを実行します:

1. 前提条件を検証し、ロールバックの準備状況インサイトを更新します。

1. Karpenter ベースのシステムを使用してノードを目的のロールバックバージョンにドリフトし、設定された中断コントロールを尊重します。

1. すべてのノードが目的のロールバックバージョンの Kubernetes バージョンスキューポリシー内にあるようにした後、EKS はインサイトを再チェックし、コントロールプレーンのロールバックに進みます。

コントロールプレーンは現在の (新しい) バージョンのままで、ノードがロールバックしている間もトラフィックを正常に処理し続けます。Kubernetes バージョンスキューポリシーでは、kube-apiserver より古い最大 3 つのマイナーバージョンをノードで実行できるため、この中間状態は有効です。

**注記**  
[以前の Kubernetes バージョンにクラスターをロールバックする](rollback-cluster.md) で説明されているのと同じ API とプロセスを使用して、ロールバックをトリガーします。Auto Mode ノードのロールバック用の個別の API はありません。

**注記**  
ノードのロールバックフェーズ (ステップ 2) は、中断コントロールに応じて数分から 7 日かかる場合があります。設定されたタイムアウト内にノードのロールバックが完了しない場合、更新は失敗としてマークされます。

**注記**  
ロールバックの進行中、他の顧客トリガーのコントロールプレーンの更新はブロックされます。別の更新を実行するには、まず CancelUpdate API を使用してロールバックをキャンセルします。

## ロールバック中のクラスターステータス
<a name="automode-rollback-cluster-status"></a>


| フェーズ | クラスターステータス | 起きていること | 
| --- | --- | --- | 
| ノードのロールバックが進行中 |  **ACTIVE**  | Karpenter はノードを以前のバージョンの AMI に置き換えています。コントロールプレーンは正常で、現在のバージョンでトラフィックを処理しています。 | 
| コントロールプレーンのロールバック |  **UPDATING**  | API サーバーとコントロールプレーンのコンポーネントは、以前のバージョンに戻されています。 | 
| ロールバックが完了 |  **ACTIVE**  | クラスターは以前のバージョンで完全に動作しています。 | 

クラスターのステータスは、ノードのロールバックフェーズ中も `ACTIVE` のままです。`ListUpdates` または `DescribeUpdate` を使用して、ロールバックが進行中かどうかを判断します。Amazon EKS コンソールで、クラスターに移動し、**更新履歴**タブを開いて、ロールバックに関連付けられた更新 ID のステータスを表示します。

ロールバック中に個々のノードの進行状況を追跡するには、Auto Mode ノードの Kubernetes バージョンを確認します。

```
kubectl get nodes -l karpenter.sh/nodepool=<nodepool-name> -o wide
```



## 中断コントロール
<a name="automode-disruption-controls"></a>

Auto Mode のロールバックは、既存のすべての中断コントロールを尊重します。これらのコントロールは、ノードを置き換える速さを決定し、ロールバック期間に大きな影響を与える可能性があります。

### NodePool 中断予算
<a name="_nodepool_disruption_budgets"></a>

NodePool 中断予算は、同時に中断できるノードの数を制御します。ロールバック中、Karpenter はノードを以前のバージョンにドリフトするときにこれらの予算を尊重します。
+ ドリフトに対する `nodes: 0` の予算は、ロールバックを無期限にブロックします。これにより、ERROR インサイトがトリガーされます。
+ 制限された予算 (例: `nodes: 1`) はロールバックを遅らせますが、前進を許可します。

ノードの 10% を一度に置き換えることができる中断予算を持つ NodePool の例:

```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  disruption:
    budgets:
      - nodes: "10%"
        reasons:
          - Drifted
```

NodePool 中断予算の設定の詳細については、「[EKS Auto Mode 用のノードプールを作成する](https://docs.aws.amazon.com/eks/latest/userguide/create-node-pool.html)」および「[Karpenter 中断予算](https://karpenter.sh/docs/concepts/disruption/#disruption-budgets)」を参照してください。

### PodDisruptionBudgets
<a name="_poddisruptionbudgets"></a>

Kubernetes PodDisruptionBudgets はノードの交換時に優先されます。PDB がポッドのエビクションを妨げる場合、ノードの中断は最大 TerminationGracePeriod 遅延します。
+ `maxUnavailable: 0` がある PDB はノードの中断を遅延させます。これにより、WARNING インサイトがトリガーされます。
+ PDB はロールバックを完全にブロックしませんが、大幅に遅くなる可能性があります。

詳細については、「[PDB を使用して重要なワークロードを保護する](https://docs.aws.amazon.com/prescriptive-guidance/latest/ha-resiliency-amazon-eks-apps/pdb.html)」および「[Kubernetes の PDB ドキュメント](https://kubernetes.io/docs/tasks/run-application/configure-pdb/)」を参照してください。

### Do-not-disrupt 注釈
<a name="_do_not_disrupt_annotations"></a>

`karpenter.sh/do-not-disrupt` 注釈はノードまたはポッド上で設定できます。

 **ノード上:** ノードの中断を無期限にブロックします。これにより ERROR インサイトがトリガーされ、そのノード上でロールバックを続行する前に削除する必要があります。

 **ポッド上:** 最大 TerminationGracePeriod ノードの中断を遅延します。これにより WARNING インサイトがトリガーされますが、ロールバックは完全にブロックされません。

Karpenter の中断動作の詳細については、「[Karpenter の中断ドキュメント](https://karpenter.sh/docs/concepts/disruption/)」を参照してください。



## ロールバックの高速化
<a name="automode-speed-up-rollback"></a>

ロールバックに予想以上に時間がかかる場合は、ロールバックの進行中に中断コントロールを調整できます。

### NodePool 中断予算を増やす
<a name="_increase_nodepool_disruption_budgets"></a>

NodePool リソースを編集して、より多くの同時ノード置換を許可します。

```
kubectl edit nodepool default
```

予算をより高い値に変更します:

```
spec:
  disruption:
    budgets:
      - nodes: "50%"
        reasons:
          - Drifted
```

### ノードから do-not-disrupt 注釈を削除する
<a name="_remove_do_not_disrupt_annotations_from_nodes"></a>

注釈を使用してノードを一覧表示し、それを削除します。

```
# List nodes with the annotation
kubectl get nodes -o json | jq '.items[] | select(.metadata.annotations["karpenter.sh/do-not-disrupt"] == "true") | .metadata.name'

# Remove from a specific node
kubectl annotate node <node-name> karpenter.sh/do-not-disrupt-
```

### PodDisruptionBudgets を調整する
<a name="_adjust_poddisruptionbudgets"></a>

PDB がポッドの削除を遅くしている場合は、一時的にそれらを調整します:

```
kubectl edit pdb <pdb-name> -n <namespace>
```

**警告**  
中断コントロールを調整すると、アプリケーションの可用性の保証に影響します。本番環境で変更を加える前に、必ず影響を理解してください。

中断コントロールの管理の詳細については、「[Amazon EKS Auto Mode でのポッドとノードの中断の防止](https://repost.aws/articles/ARONpaMO8rQAqXM_BLmhyqWA/preventing-pod-and-node-disruption-in-amazon-eks-auto-mode)」を参照してください。



## ロールバックのキャンセル
<a name="automode-cancel-rollback"></a>

ロールバックは、ノードがロールバックしている間のみ、キャンセル可能な状態になります。このフェーズで CancelUpdate を使用してオペレーションを停止できます。

```
aws eks cancel-update \
  --name my-cluster \
  --update-id <update-id> \
  --region us-west-2
```

### キャンセル動作
<a name="_cancel_behavior"></a>


| 側面 | 動作 | 
| --- | --- | 
| キャンセル可能な場合 | Auto Mode ノードがロールバックされている間のみ (コントロールプレーンのロールバックが開始される前) | 
| セマンティクス | ベストエフォートが停止。ノードのロールバックオペレーションを停止します。 | 
| 中断中のノード | ノードがキャンセル時に中断中である場合、現在のオペレーションを完了します。 | 
| キャンセル後のステータス | `Cancelling` から `Cancelled` への移行を更新します。 | 
| クラスターステータス | 全体を通して `ACTIVE` のままです。 | 

### キャンセル後
<a name="_after_cancellation"></a>

キャンセルが成功すると、ノードは通常どおり現在のクラスターバージョンにドリフトします。更新は `Cancelling` から `Cancelled` に移行します。

キャンセル後、すぐに以下を行えます:
+ ロールバックを再試行する (7 日間の資格ウィンドウ内である限り)。
+ 別のクラスター更新を実行する。
+ クラスターを現在のバージョンのままにする。

### キャンセルできない場合
<a name="_when_cancel_is_not_possible"></a>

ノードのロールバックが既に完了していてコントロールプレーンのロールバックが開始されている場合、または更新が `Successful` または `Failed` ステータスで既に完了している場合、キャンセルは失敗します。

**注記**  
CloudFormation と Terraform は CancelUpdate API を直接サポートしていません。IaC を通じて開始されたロールバックをキャンセルする必要がある場合は、API を直接呼び出す必要があります。



## ロールバックのタイムアウト
<a name="automode-rollback-timeout"></a>

Auto Mode ノードのロールバックには、`rollbackConfig` の `timeoutMinutes` パラメータによって制御される設定可能なタイムアウトがあります。デフォルトのタイムアウトは 720 分 (12 時間) です。値は 120 分 (2 時間)～10080 分 (7 日) で設定できます。タイムアウトは、最小許容プロパティです。つまり、指定した時間よりも早く発生することはありませんが、その後すぐに発生する可能性があります。

```
aws eks update-cluster-version \
  --name my-cluster \
  --kubernetes-version 1.30 \
  --rollback-config timeoutMinutes=1440 \
  --region us-west-2
```

すべてのノードが指定されたタイムアウト内にロールバックを完了していない場合:

1. ロールバックはタイムアウトします。

1. ノードは現在のクラスターバージョンにドリフトし始めます。

1. コントロールプレーンは現在のバージョンのままです (ロールバックされていません)。

1. 更新ステータスは `Failed` に移行します。

タイムアウト後、元のアップグレードから 7 日間のロールバック資格ウィンドウ内にある場合は、ロールバックを再試行できます。実際には、ノードのロールバックが 7 日目にタイムアウトする場合、ロールバック資格ウィンドウも 7 日間であるため、それが期限切れになっている可能性があります。

タイムアウトを回避するには、ロールバックを開始する前にロールバックの準備状況インサイトを確認してください。これらのインサイトは、ノードのロールバックプロセスを遅らせる可能性のある中断予算や注釈について警告します。



## --force フラグと Auto Mode
<a name="automode-force-flag"></a>

`UpdateClusterVersion` 上の `--force` フラグは、クラスターインサイトチェックのみをバイパスします。Auto Mode ノードの中断動作には影響しません。

`--force` を使用しても、次のようになります:
+ NodePool 中断予算は引き続き優先されます。
+ PodDisruptionBudgets は引き続き優先されます。
+ Do-not-disrupt 注釈は引き続き尊重されます。
+ 7 日間のノードロールバックタイムアウトは引き続き適用されます。

ノードのロールバックを高速化する唯一の方法は、中断コントロール自体を調整することです。詳細については、「[ロールバックの高速化](#automode-speed-up-rollback)」を参照してください。



## IaC タイムアウトの競合
<a name="automode-iac-timeout"></a>

Infrastructure-as-Code ツールには、Auto Mode のロールバック期間と競合する可能性のあるタイムアウト制限があります。CloudFormation では、リソースごとに最大 36 時間許可されます。オペレーションがタイムアウトすると、CloudFormation はこれを no-op として扱います。これにより、クラスターがドリフト状態になり、テンプレートに実際のクラスターバージョンが反映されない可能性があります。バージョンロールバックは明示的に開始される必要があります。Terraform Enterprise/Cloud のタイムアウトは約 24 時間ですが、クライアント側のタイムアウトは認証情報の有効期限やその他の要因によって異なる場合があります。

ロールバック期間を IaC ツールに合わせるには、`rollbackConfig` の `timeoutMinutes` パラメータを使用して適切なタイムアウトを設定します。IaC ツールがタイムアウトした場合は、CancelUpdate API を直接使用してコントロールを回復します。制限付きの中断予算がある場合は、IaC の代わりに CLI または API から直接ロールバックを開始することを検討してください。



## ノードのロールバック中のシステム更新
<a name="automode-system-updates"></a>

Auto Mode ノードがロールバックしている間、EKS はコントロールプレーンの安全性と可用性を引き続き維持します。

顧客トリガーの更新 (UpdateClusterVersion や UpdateClusterConfig など) は、ノードのロールバックの進行中にブロックされます。優先度の高い更新を実行する必要がある場合は、まず `CancelUpdate` を使用してロールバックをキャンセルしてから、更新を実行し、資格ウィンドウ内にある場合はロールバックを再開します。



## 関連リソース
<a name="automode-rollback-related-resources"></a>
+  [以前の Kubernetes バージョンにクラスターをロールバックする](rollback-cluster.md) 
+  [EKS Auto Mode の概要](https://docs.aws.amazon.com/eks/latest/userguide/automode.html) 
+  [EKS 自動モードl 用のノードプールを作成する](https://docs.aws.amazon.com/eks/latest/userguide/create-node-pool.html) 
+  [EKS Auto Mode クラスターの Kubernetes バージョンを更新する](https://docs.aws.amazon.com/eks/latest/userguide/auto-upgrade.html) 
+  [Amazon EKS Auto Mode でのポッドとノードの中断の防止](https://repost.aws/articles/ARONpaMO8rQAqXM_BLmhyqWA/preventing-pod-and-node-disruption-in-amazon-eks-auto-mode) 
+  [EKS 自動モードl のトラブルシューティング](https://docs.aws.amazon.com/eks/latest/userguide/auto-troubleshoot.html) 
+  [Karpenter の中断に関するドキュメント](https://karpenter.sh/docs/concepts/disruption/) 
+  [Kubernetes PodDisruptionBudgets](https://kubernetes.io/docs/tasks/run-application/configure-pdb/)