クラスターバージョンのロールバックのベストプラクティス

Amazon EKS は、Kubernetes API サーバーとコントロールプレーンコンポーネントをロールバックします。Auto Mode クラスターの場合、Amazon EKS はロールバックワーカーノードも管理します。

ユーザーは、マネージド型ノードグループ、セルフマネージド型ノード、ハイブリッドノードのロールバックを担当します。また、アドオンの互換性を検証し、アプリケーション、カスタムコントローラー、およびサードパーティーツールが以前のバージョンと正しく動作することを確認する必要があります。

コントロールプレーンとデータプレーンのアップグレード (非自動モードクラスター) を分離します。マネージド型ノードグループまたはセルフマネージド型ノードを使用するクラスターの場合は、まずコントロールプレーンをアップグレードし、ワーカーノードをアップグレードする前にベイク期間を許可することを検討してください。ノードは N-1 のままですが、kubelet バージョンスキューインサイトは PASSING ステータスのままです。これにより、最初にノードをロールバックすることなく、ロールバックパスがクリアになります。

アドオンをクロス互換性バージョンにアップグレードします。コントロールプレーンをアップグレードする前に、すべてのアドオン (マネージド型およびセルフマネージド型) が現在の Kubernetes バージョンとターゲット Kubernetes バージョンの両方と互換性があることを確認してください。これにより、アップグレードとロールバックの両方でアドオンの互換性に関するインサイトが明確になります。

ベイク期間中APIs を使用しないでください。7 日間の期間中に新しいバージョンでのみ利用可能な APIs または機能を使用するリソースを作成する場合は、ロールバックする前にリソースを削除する必要があります。アップグレードが安定していると確信できるまで、new-version-only APIs の採用を制限します。

アップグレードは早く、遅くはありません。ロールバックが利用可能になると、延長されたサポート期限まで待たずに、新しいバージョンリリースの直後に自信を持ってアップグレードできます。以前にアップグレードすると、検証にかかる時間が長くなり、延長サポート料金が削減されます。

延長サポートのロールバック制限に注意してください。延長サポートの終了時にクラスターが自動的にアップグレードされた場合、以前のバージョンにロールバックすることはできません。標準サポートの終了時に自動アップグレードされた場合はロールバックできますが、まずアップグレードポリシーを に変更する必要がありますEXTENDED。

アップグレード直後にインサイトを確認します。問題が発生するまで待たないでください。アップグレード後、ロールバック準備状況のインサイトをチェックして、現在のロールバック体制を把握します。

ERROR インサイトにプロアクティブに対処します。アップグレードの直後にインサイトに ERROR ステータスが表示された場合は、7 日間のウィンドウがまだ開いている間に早期に解決してください。待機時間が長くなるほど、クラスターの状態が分岐し、新しいブロッカーが表示される可能性が高くなります。

インサイトの内容を理解します。Insights は、Amazon EKS マネージドアドオンのバージョン、API の使用状況、バージョンスキュー、クラスターの状態をチェックします。セルフマネージドアドオン、カスタムコントローラー、またはアプリケーションレベルの互換性はチェックされません。セルフマネージドアドオン (クラスターオートスケーラー、イングレスコントローラー、カスタム演算子、モニタリングエージェントなど) の独自の互換性検証を維持します。

マネージド型ノードグループ。コントロールプレーンをロールバックする前に、マネージド型ノードグループを以前のバージョンにロールバックする必要があります。以前の Kubernetes バージョンで UpdateNodegroupVersionオペレーションを使用します。ロールバックは、設定された更新設定 (maxUnavailable、更新戦略) を尊重します。

セルフマネージド型ノードとハイブリッドノード。コントロールプレーンをロールバックする前に、以前の Kubernetes バージョンを使用するようにノード AMIs または設定を更新します。

Fargate。Fargate ワーカーノードでは、バージョンロールバックはサポートされていません。ロールバックを開始する前に、コントロールプレーンと同じバージョンを実行している Fargate ポッドを削除するか、 --force を使用してバージョンスキューインサイトをバイパスします (ポッドが置き換えられるまで予期しない動作が発生する可能性があります）。

ロールバックを開始する前に、中断予算を確認します。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 マネージドクラスターの場合は、ツールのタイムアウトに合わせてください。

DescribeUpdate オペレーション。describe-update ロールバックオペレーションの現在のステータスを確認するには、 を使用します (InProgress、Successful、Failed、Cancelled)。キャンセルの進行状況を追跡するには、レスポンスの cancellation オブジェクトを確認します。

クラスターインサイト。Amazon EKS は、コントロールプレーンのロールバックに進む前にインサイトを再チェックします (Auto Mode のノードロールバックが完了した後）。表示される可能性のある新しい ERROR インサイトをモニタリングします。

クラスターのステータス。Auto Mode クラスターの場合、クラスターのステータスはノードのロールバックACTIVE中に残り、コントロールプレーンのロールバック中にUPDATINGのみ に変わります。ロールバックが進行中であることを知るためにクラスターのステータスだけに依存しないでください。 を使用しますDescribeUpdate。

ノードバージョン。Auto Mode では、ノードの Kubernetes バージョンをチェックして、ノードの置き換えの進行状況を追跡します。Managed Node Groups の場合、ノードグループの更新ステータスをモニタリングします。

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 スタックの更新が失敗した場合、自動スタックは以前のテンプレートバージョンに戻されてもクラスターバージョンのロールバックは開始されません。バージョンロールバックを明示的に開始する必要があります。

Rollback はテストを補完し、置き換えるものではありません。クラスターインサイト、非本番環境でのアップグレード前テスト、ステージングされたロールアウトを引き続き使用します。ロールバックは、テストがキャッチできないケース、つまり本番環境でのみ発生する問題を処理します。

ロールバックにより、プライマリ安全メカニズムとしての手動バックアップおよびスナップショット手順の必要性が軽減されます。ネイティブロールバックを利用できるため、アップグレード中のディザスタリカバリのために etcd スナップショットやカスタムロールバックスクリプトのみに依存する必要がなくなります。

インサイトはベストエフォートとpoint-in-timeです。Amazon EKS は、ロールバックをトリガーするときにそれらを評価します。そのチェック後に行われた変更 (新しい APIs) はキャプチャされず、ロールバックの完了後に問題が発生する可能性があります。

ロールバックはアプリケーションの復旧を保証するものではありません。Amazon EKS はコントロールプレーンを安全に元に戻しますが、アプリケーション、設定、および依存関係は、以前のバージョンに対して検証する責任があります。

クラスターを以前の Kubernetes バージョンにロールバックする

Amazon EKS Auto Mode クラスターをロールバックする

クラスターのアップグレードのベストプラクティス

クラスターのインサイト

EKS での Kubernetes バージョンライフサイクル