翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# クラスターバージョンのロールバックのベストプラクティス
<a name="rollback-cluster-upgrades"></a>

Amazon Elastic Kubernetes Service (Amazon EKS) バージョンロールバックを使用すると、インプレースアップグレードから 7 日以内にクラスターの Kubernetes コントロールプレーンを以前のマイナーバージョンに戻すことができます。このページでは、アップグレードワークフローの一環としてロールバックを計画、実行、運用するためのベストプラクティスについて説明します。

前提条件の詳細、step-by-stepの手順、API リファレンスについては、[「Rollback cluster to previous Kubernetes version](https://docs.aws.amazon.com/eks/latest/userguide/rollback-cluster.html)」を参照してください。

## 責任共有モデルがロールバックにどのように適用されるかを理解する
<a name="understand-how-the-shared-responsibility-model-applies-to-rollback"></a>

クラスターバージョンのロールバックを開始すると、Amazon EKS はコントロールプレーンのロールバックを管理します。データプレーン、アドオン、アプリケーションの互換性については、お客様の責任となります。以下に、責任の概要を示します。
+  **Amazon EKS は、Kubernetes API サーバーとコントロールプレーンコンポーネントを**ロールバックします。Auto Mode クラスターの場合、Amazon EKS はロールバックワーカーノードも管理します。
+  **ユーザーは、マネージド型ノードグループ、セルフマネージド型ノード、ハイブリッドノードのロールバックを担当します**。また、アドオンの互換性を検証し、アプリケーション、カスタムコントローラー、およびサードパーティーツールが以前のバージョンと正しく動作することを確認する必要があります。

アップグレードの責任共有モデルの詳細については、[「責任共有モデルがクラスターのアップグレードにどのように適用されるかを理解する](cluster-upgrades.md)」を参照してください。

## ロールバックを念頭に置いてアップグレードを計画する
<a name="plan-upgrades-with-rollback-in-mind"></a>

バージョンロールバックは、ロールバックウィンドウを開いたままにするようにアップグレードワークフローが設計されている場合に最適です。
+  **コントロールプレーンとデータプレーンのアップグレード (非自動モードクラスター) を分離します。**マネージド型ノードグループまたはセルフマネージド型ノードを使用するクラスターの場合は、まずコントロールプレーンをアップグレードし、ワーカーノードをアップグレードする前にベイク期間を許可することを検討してください。ノードは N-1 のままですが、kubelet バージョンスキューインサイトは PASSING ステータスのままです。これにより、最初にノードをロールバックすることなく、ロールバックパスがクリアになります。
+  **アドオンをクロス互換性バージョンにアップグレードします。**コントロールプレーンをアップグレードする前に、すべてのアドオン (マネージド型およびセルフマネージド型) が現在の Kubernetes バージョンとターゲット Kubernetes バージョンの両方と互換性があることを確認してください。これにより、アップグレードとロールバックの両方でアドオンの互換性に関するインサイトが明確になります。
  + Amazon EKS マネージドアドオンを使用すると、アドオンバージョンの互換性を自動的にチェックするロールバック準備状況インサイトを活用できます。
  + マネージドアドオンの自己管理 (EKS アドオンライフサイクルの外部でバージョンを上書きするなど) は避けてください。ロールバック中、インサイトはマネージドアドオン設定を信頼できるソースとして扱い、導入したバージョンドリフトを検出しません。
+  **ベイク期間中APIs を使用しないでください。**7 日間の期間中に新しいバージョンでのみ利用可能な APIs または機能を使用するリソースを作成する場合は、ロールバックする前にリソースを削除する必要があります。アップグレードが安定していると確信できるまで、new-version-only APIs の採用を制限します。
+  **アップグレードは早く、遅くはありません。**ロールバックが利用可能になると、延長されたサポート期限まで待たずに、新しいバージョンリリースの直後に自信を持ってアップグレードできます。以前にアップグレードすると、検証にかかる時間が長くなり、延長サポート料金が削減されます。
+  **延長サポートのロールバック制限に注意してください。**延長サポートの終了時にクラスターが自動的にアップグレードされた場合、以前のバージョンにロールバックすることはできません。標準サポートの終了時に自動アップグレードされた場合はロールバックできますが、まずアップグレードポリシーを に変更する必要があります`EXTENDED`。

非推奨ポリシー、リリースノート、アドオンの互換性などの一般的なアップグレード計画ガイダンスについては、[「クラスターアップグレードのベストプラクティス](cluster-upgrades.md)」を参照してください。

## ロールバック前にロールバック準備状況のインサイトを確認する
<a name="review-rollback-readiness-insights-before-rolling-back"></a>

Amazon EKS は、クラスターインサイトの `ROLLBACK_READINESS`カテゴリにpoint-in-timeロールバック準備状況インサイトを表示します。これらのチェックは、ロールバックの安全性を評価するための主要なツールです。
+  **アップグレード直後にインサイトを確認します。**問題が発生するまで待たないでください。アップグレード後、ロールバック準備状況のインサイトをチェックして、現在のロールバック体制を把握します。
+  **ERROR インサイトにプロアクティブに対処します。**アップグレードの直後にインサイトに ERROR ステータスが表示された場合は、7 日間のウィンドウがまだ開いている間に早期に解決してください。待機時間が長くなるほど、クラスターの状態が分岐し、新しいブロッカーが表示される可能性が高くなります。
+  **インサイトの内容を理解します。**Insights は、Amazon EKS マネージドアドオンのバージョン、API の使用状況、バージョンスキュー、クラスターの状態をチェックします。セルフマネージドアドオン、カスタムコントローラー、またはアプリケーションレベルの互換性はチェックされません。セルフマネージドアドオン (クラスターオートスケーラー、イングレスコントローラー、カスタム演算子、モニタリングエージェントなど) の独自の互換性検証を維持します。

インサイトチェックとステータス動作の完全なリストについては、[「Rollback cluster to previous Kubernetes version](https://docs.aws.amazon.com/eks/latest/userguide/rollback-cluster.html)」を参照してください。

## ロールバック用の非自動モードノードを準備する
<a name="prepare-non-auto-mode-nodes-for-rollback"></a>

マネージド型ノードグループ、セルフマネージド型ノード、または AWS Fargate を使用するクラスターの場合、ワーカーノードがターゲットロールバックバージョンと互換性があることを確認する責任があります。
+  **マネージド型ノードグループ。**コントロールプレーンをロールバックする前に、マネージド型ノードグループを以前のバージョンにロールバックする必要があります。以前の Kubernetes バージョンで `UpdateNodegroupVersion`オペレーションを使用します。ロールバックは、設定された更新設定 (`maxUnavailable`、更新戦略) を尊重します。
+  **セルフマネージド型ノードとハイブリッドノード。**コントロールプレーンをロールバックする前に、以前の Kubernetes バージョンを使用するようにノード AMIs または設定を更新します。
+  **Fargate。**Fargate ワーカーノードでは、バージョンロールバックはサポートされていません。ロールバックを開始する前に、コントロールプレーンと同じバージョンを実行している Fargate ポッドを削除するか、 `--force` を使用してバージョンスキューインサイトをバイパスします (ポッドが置き換えられるまで予期しない動作が発生する可能性があります）。

ノードの更新中にワークロードの可用性を確保するための PodDisruptionBudget およびトポロジスプレッド設定ガイダンスについては、[「クラスターのアップグレードのベストプラクティス](cluster-upgrades.md)」を参照してください。

## ロールバックの Amazon EKS Auto Mode 中断コントロールを管理する
<a name="manage-amazon-eks-auto-mode-disruption-controls-for-rollback"></a>

Amazon EKS Auto Mode を実行しているクラスターの場合、ノードのロールバックフェーズはオペレーションの最長部分になる可能性があります。中断コントロールは、ロールバックの完了速度を直接決定します。
+  **ロールバックを開始する前に、中断予算を確認します。**Amazon EKS は、NodePool 中断予算のロールバック準備状況に関するインサイトを提供します。予算を 0 に設定すると、ERROR インサイトがトリガーされ、ロールバックが無期限にブロックされます。制限付き予算と PodDisruptionBudgets (PDBs) は WARNING インサイトをトリガーするため、ロールバックは遅くなりますが、進行は許可されます。ロールバックを開始する前に ERROR インサイトに対処します。
+  **ロールバック中に予算を調整する準備をします。**ロールバックに予想以上に時間がかかる場合は、ロールバックの進行`kubectl`中に を通じて NodePool 中断予算と PDBsを調整できます。予算を増やすと、より多くの同時ノード置換が可能になります。
+  **ブロックノードからdo-not-disrupt注釈を削除します。**ノードの`karpenter.sh/do-not-disrupt`注釈は、無期限にロールバックをブロックします。置き換えるノードから削除します。
+  **ノードのロールバックの進行状況を追跡します。**を使用して`kubectl get nodes -l karpenter.sh/nodepool=<nodepool-name> -o wide`、以前のバージョンの AMI に置き換えられたノードをモニタリングします。
+  **必要に応じて CancelUpdate を使用します。**ロールバックに時間がかかりすぎたり、解決するよりも多くの問題が発生した場合は、ロールバックをキャンセルします。キャンセル後、ノードは現在のバージョンに収束するため、別のアプローチを取ることができます。
+  **適切なタイムアウトを設定します。**の `timeoutMinutes`パラメータ`rollbackConfig`を使用して、運用上の期待に合わせます。デフォルトは 720 分 (12 時間) です。保守的な予算を持つクラスターの場合は、増やすことを検討してください。IaC マネージドクラスターの場合は、ツールのタイムアウトに合わせてください。

Auto Mode のロールバック手順と `CancelUpdate`オペレーションの詳細については、[「Amazon EKS Auto Mode クラスターのロールバック](https://docs.aws.amazon.com/eks/latest/userguide/rollback-automode-nodes.html)」を参照してください。

## ロールバックの進行状況をモニタリングする
<a name="monitor-rollback-progress"></a>

ロールバック中に、以下を使用してステータスを追跡し、問題を検出します。
+  **DescribeUpdate オペレーション。**`describe-update` ロールバックオペレーションの現在のステータスを確認するには、 を使用します (`InProgress`、`Successful`、`Failed`、`Cancelled`)。キャンセルの進行状況を追跡するには、レスポンスの `cancellation` オブジェクトを確認します。
+  **クラスターインサイト。**Amazon EKS は、コントロールプレーンのロールバックに進む前にインサイトを再チェックします (Auto Mode のノードロールバックが完了した後）。表示される可能性のある新しい ERROR インサイトをモニタリングします。
+  **クラスターのステータス。**Auto Mode クラスターの場合、クラスターのステータスはノードのロールバック`ACTIVE`中に残り、コントロールプレーンのロールバック中に`UPDATING`のみ に変わります。ロールバックが進行中であることを知るためにクラスターのステータスだけに依存しないでください。 を使用します`DescribeUpdate`。
+  **ノードバージョン。**Auto Mode では、ノードの Kubernetes バージョンをチェックして、ノードの置き換えの進行状況を追跡します。Managed Node Groups の場合、ノードグループの更新ステータスをモニタリングします。

## Infrastructure as Code (IaC) マネージドクラスターの処理
<a name="handle-infrastructure-as-code-iac-managed-clusters"></a>

Infrastructure as Code (IaC) ツールには、Auto Mode のロールバック期間と競合する可能性のあるタイムアウト制限があります。
+  **AWS CloudFormation** は、リソースあたり最大 36 時間をサポートします。ロールバックがこれを超えると、CloudFormation はこれを no-op として扱います。これにより、テンプレートが実際のクラスターバージョンを反映していないドリフト状態のままになる可能性があります。デフォルトのロールバックタイムアウトは 720 分 (12 時間) です。
+  **Terraform Enterprise/Cloud** のタイムアウトは約 24 時間ですが、クライアント側のタイムアウトは異なります。
+  Amazon EKS がロールバックを完了する前に** IaC ツールがタイムアウトしないように、IaC ツールのタイムアウト`timeoutMinutes`に合わせます**。 IaC 
+  IaC **ではなく、制限された予算で CLI/API for Auto Mode クラスターを使用してロールバックを開始することを検討してください**。IaC レイヤーがタイムアウトした場合は、 `CancelUpdate` を直接使用します。
+  **AWS CloudFormation スタックのロールバックは、バージョンロールバックをトリガーしません。**AWS CloudFormation スタックの更新が失敗した場合、自動スタックは以前のテンプレートバージョンに戻されてもクラスターバージョンのロールバックは開始されません。バージョンロールバックを明示的に開始する必要があります。

## ロールバックをルーチンワークフローではなく安全ネットとして使用する
<a name="use-rollback-as-a-safety-net-not-a-routine-workflow"></a>

バージョンロールバックは、アップグレード後の問題からの復旧に役立つように設計されています。既存のアップグレードプラクティスと組み合わせると最適です。
+  **Rollback はテストを補完し、置き換えるものではありません。**クラスターインサイト、非本番環境でのアップグレード前テスト、ステージングされたロールアウトを引き続き使用します。ロールバックは、テストがキャッチできないケース、つまり本番環境でのみ発生する問題を処理します。
+  **ロールバックにより、プライマリ安全メカニズムとしての手動バックアップおよびスナップショット手順の必要性が軽減されます。**ネイティブロールバックを利用できるため、アップグレード中のディザスタリカバリのために etcd スナップショットやカスタムロールバックスクリプトのみに依存する必要がなくなります。
+  **インサイトはベストエフォートとpoint-in-timeです。**Amazon EKS は、ロールバックをトリガーするときにそれらを評価します。そのチェック後に行われた変更 (新しい APIs) はキャプチャされず、ロールバックの完了後に問題が発生する可能性があります。
+  **ロールバックはアプリケーションの復旧を保証するものではありません。**Amazon EKS はコントロールプレーンを安全に元に戻しますが、アプリケーション、設定、および依存関係は、以前のバージョンに対して検証する責任があります。

## ロールバックによりブルー/グリーンアップグレードの必要性が減る
<a name="rollback-reduces-the-need-for-blue-green-upgrades"></a>

以前は、ブルーグリーンクラスターのアップグレードを主に「元に戻すパス」に使用していた組織では、代わりにバージョンロールバックを使用したインプレースアップグレードを検討できるようになりました。ロールバックによるインプレースアップグレードにより、インフラストラクチャコスト (重複するクラスターなし）、一貫したクラスターアイデンティティ (同じ API エンドポイント、OpenID Connect (OIDC) プロバイダー、Elastic Network Interface (ENIs))、およびより簡単なオペレーションが可能になります。

一度に複数のバージョンを変更したり、ワークロードの移行を広範囲にテストしたり、検証中に完全なトラフィック分離を維持したりする必要がある場合は、ブルーグリーンが引き続き推奨されます。詳細については、[クラスターアップグレードのベストプラクティスの「ブルー/グリーンクラスターの評価](cluster-upgrades.md)」を参照してください。

## 関連リソース
<a name="related-resources"></a>
+  [クラスターを以前の Kubernetes バージョンにロールバックする](https://docs.aws.amazon.com/eks/latest/userguide/rollback-cluster.html) 
+  [Amazon EKS Auto Mode クラスターをロールバックする](https://docs.aws.amazon.com/eks/latest/userguide/rollback-automode-nodes.html) 
+  [クラスターのアップグレードのベストプラクティス](https://docs.aws.amazon.com/eks/latest/best-practices/cluster-upgrades.html) 
+  [クラスターのインサイト](https://docs.aws.amazon.com/eks/latest/userguide/cluster-insights.html) 
+  [EKS での Kubernetes バージョンライフサイクル](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html)