Azure Kubernetes Service (AKS) クラスターのアップグレードのしくみ

Azure Kubernetes Service (AKS)はローリング アップグレードを実行して、実行中のワークロードの中断を最小限に抑えます。

ほとんどの運用ワークロードでは、AKS Automatic が推奨される既定値です (該当する場合)。 AKS Automatic には、Kubernetes バージョンの自動アップグレード、自動ノード オペレーティング システム (OS) イメージの更新、マネージド システム ノード操作、手動オーバーヘッドを軽減する組み込みのセーフガードなど、アップグレード操作用の運用対応の既定値が含まれています。 詳細については、「 AKS 自動の概要」を参照してください。

この記事では、AKS のアップグレードのしくみについて説明し、AKS Automatic と AKS Standard が異なる点について説明します。

[前提条件]

アップグレード モデル: AKS Automatic と AKS Standard

AKS 自動クラスター モードと AKS Standard クラスター モードでは、同じ Kubernetes アップグレードの基礎が使用されますが、既定値と運用所有権が異なります。

アップグレードに関する懸念事項 AKS Automatic AKS Standard
生産の位置付け ほとんどの運用環境のワークロードに推奨される既定値 (該当する場合) デフォルトではより多くの手動設定が必要な柔軟なモデル
Kubernetes マイナー バージョンのアップグレード 事前構成済みの自動アップグレード チャネル 既定では手動、オプションの自動チャネル
ノード OS イメージのアップグレード 構成済みの自動ノード OS イメージ チャネル 既定では手動、オプションの自動チャネル
システムノードプールの操作 AKS によって管理される お客様が管理
計画メンテナンス期間 既定で使用可能 オプションの構成
ワークロード中断制御 顧客管理（レプリカ戦略、準備動作、中断ポリシーなどを含む） 顧客管理（レプリカ戦略、準備動作、中断ポリシーなどを含む）

Note

AKS Automatic はプラットフォーム操作を簡素化しますが、共有責任は引き続き適用されます。 ワークロード レベルの可用性の設計と削除ポリシーの動作は、引き続きお客様の責任です。

AKS でのローリング アップグレード動作

AKS は、ノードの置き換えまたは再イメージ化中に容量を保持するローリング パターンを使用してノード プールをアップグレードします。 この動作は、すべての AKS クラスター モードで同じです。

大まかに言えば、AKS:

  1. アップグレード設定に基づいて一時的なサージ容量を追加します。
  2. ノードを切断してドレインし、ワークロードを移動します。
  3. ノードをターゲット バージョンに再イメージ化または置き換えます。
  4. 完了後に一時的な増強容量を削除します。

ローリングアップグレードの例

この例では、 maxSurge を 1 に設定して、2 ノード クラスターを Kubernetes 1.30 から 1.31 にアップグレードする方法を示します。

手順 1: 初期セットアップ

クラスターは、バージョン 1.30 を実行する 2 つのノードから始まり、各ホスト アプリケーション ポッドです。

バージョン 1.30 を実行する 2 つのノード、各ホスティング アプリケーション ポッド、および新しく作成されたサージ ノードを使用したクラスターの初期セットアップを示す図。

  • ノード 1: ポッド A、ポッド B
  • ノード 2: ポッド C、ポッド D
  • サージ ノード: 空 (DaemonSet と新しいポッドを除く)

手順 2: 最初のノードを隔離して排出する

AKS は、ノード 1 をコードンして新しいポッドのスケジューリングを防止し、その後、既存のポッドをドレインします。

ノード 1 が切断およびドレインされ、ポッドが削除され、他の使用可能なノードで置き換えられていることを示す図。

  • ポッド A →が削除され、サージ ノードで置き換えられました
  • ポッド B →削除され、ノード 2 で置き換えられました

手順 3: 最初のノードをアップグレードする

ノード 1 は Kubernetes バージョン 1.31 で再イメージ化され、ポッドは他のノードで引き続き実行されます。

アプリケーション ポッドがノード 2 とサージ ノードで引き続き実行されている間に、ノード 1 がバージョン 1.31 に再イメージ化されたことを示す図。

  • ノード 1: v1.31 にアップグレード
  • ノード 2: ポッド B、ポッド C、ポッド D
  • サージ ノード: ポッド A

手順 4: 2 番目のノードをコルドンしてドレインする

AKS はノード 2 のプロセスを繰り返し、ポッドは削除され、スケジューラはそれらを適切な使用可能なノードに再配布します。

ノード 2 が切断およびドレインされ、アップグレードされたノード 1 とサージ ノードでポッドが削除され、置き換えられていることを示す図。

  • ポッド C、B →削除され、ノード 1 で置き換えられました
  • ポッド D →サージ ノードで削除および置換
  • ノード 2: v1.31 にコード化および再イメージ化

手順 5: サージ ノードを削除する

すべての永続的なノードがアップグレードされると、サージ ノードは切断され、ドレインされ、削除されます。

サージノードがドレインされて削除され、ポッドが退去させられたうえでアップグレード済みの永続ノード上で置き換えられる様子を示す図。

  • ポッド A →削除され、ノード 1 で置き換えられました
  • ポッド D →削除され、ノード 2 で置き換えられました
  • サージ ノード: 削除済み

最終状態

すべてのノードで Kubernetes バージョン 1.31 が実行され、クラスター全体でポッドがスケジュールされています。

  • ノード 1 (v1.31): ポッド A、ポッド C
  • ノード 2 (v1.31): ポッド B、ポッド D

制限付きポッド中断予算 (PDB) の動作

制限の厳しい PDB で削除がブロックされている場合、ノードのドレインが遅延または防止される可能性があります。 AKS では、設定された動作に応じて、Cordon ドレイン不可能なノードの動作を使用し、アップグレード対象の他のノードのアップグレードを続行できます。 ブロックされたノードは、ブロック状態が解決されるまで古いバージョンのままになることがあります。

制限付き PDB の例

この例では、2 ノード クラスターを Kubernetes 1.30 から 1.31 にアップグレードし、 maxSurge を 2 に設定し、PDB で最初のノードのドレイン操作をブロックする方法を示します。

手順 1: 制限の厳しい PDB を使用した初期セットアップ

クラスターはバージョン 1.30 を実行する 2 つのノードから始まり、PDB によってポッド A が削除されないように保護されます。

ポッド A を削除から保護する 2 つのノード、サージ ノード、ポッド中断予算を含む初期クラスターを示す図。

  • ノード 1: ポッド A (PDB によって保護)、ポッド B
  • ノード 2: ポッド C、ポッド D
  • サージ ノード: 新しく作成された 2 つのノード
  • PDB: ポッド A の退去を防止します

手順 2: 最初のノードを排水しようとする (ブロック中)

AKS はノード 1 を切断しますが、PDB の制限によりポッド A をドレインできません。

ノード 1 は隔離されているものの、Pod Disruption Budget によってドレインがブロックされ、Pod A はスタックしたまま、Pod B はサージ ノードに退避された状態を示す図。

  • ノード 1: 隔離され、検疫済みとしてマークされている (ポッド A が応答しない)
  • ポッド B →サージ ノード 1 で削除および置換されますが、サージ ノード 2 は一時的に使用されません
  • 状態: ノード 1 のアップグレードがブロックされました

手順 3: 2 番目のノードに進む

ノード 1 が検疫されると、AKS はノード 2 のアップグレードを続行します。

ノード 1 が検疫されたままで、ノード 2 はスケジュール不可にされたうえで正常にドレインされ、ポッドはサージ ノードに移動される様子を示す図。

  • ノード 1: 検疫されたままになります (v1.30)
  • ノード 2: 隔離され、正常に排出された
  • ポッド C →サージ ノード 2 で削除および置換
  • ポッド D →サージ ノード 2 で削除され、置き換えられました

手順 4: 2 番目のノードをアップグレードする

ノード 2 が Kubernetes バージョン 1.31 に正常に再イメージ化されました。

ノード 2 がバージョン 1.31 に正常にアップグレードされ、ノード 1 がポッド A で検疫されたままであることを示す図。

  • ノード 1: ポッド A で検疫済み (v1.30) のまま
  • ノード 2: v1.31 にアップグレード
  • サージ ノード 1: ポッド B
  • サージ ノード 2: ポッド C、ポッド D

手順 5: 1つのサージ ノードが、もう一方のサージ ノードの削除に伴い、恒久的な置き換えノードになります

ノード 1 は検疫されたままであるため、サージ ノード 1 は v1.31 を実行している永続的な代替になり、サージ ノード 2 は削除されます。

Node 1 が隔離されたまま、Surge Node がバージョン 1.31 を実行する恒久的な置き換えとなることを示す図。

  • ノード 1: 検疫済み (v1.30) - 手動による介入が必要
  • ポッド C、ポッド D →サージ ノード 2 から削除され、ノード 2 で置き換えられました
  • サージ ノード 1 (v1.31): ポッド B (現在は永続的)
  • サージ ノード 2 (v1.31): 削除済み

最終状態

アップグレードは、手動による介入を必要とする 1 つの検疫済みノードで完了します。

  • ノード 1: ポッド A で検疫済み (v1.30) - お客様は手動で解決する必要があります ( 「解決できないノードの解決」を参照)
  • ノード 2 (v1.31): 正常に実行されている
  • 以前のサージ ノード (v1.31): 現在は恒久的な置き換え

Important

検疫されたノード (ノード 1) は、お客様の責任において処理されます。 次のいずれかを行う必要があります。

  • ポッド A の削除を許可するように PDB を調整します。
  • ポッド A を手動で削除します。
  • ブロック条件を修正した後、ノードを削除して再作成します。

PDB でブロックされるアップグレードに関する主な考慮事項

  • [Undrainable node behavior]:この検疫動作を有効にするために、ノード プールの Cordon に設定します。
  • お客様の責任: 検疫されたノードを解決するには、手動による介入が必要です。
  • クラスター容量: サージ ノードは永続的になり、クラスターの容量計画に影響を与える可能性があります。
  • 監視: Azure Monitorまたは kubectl を使用して検疫済みノードを追跡し、タイムリーな解決を確保します。

Tip

検疫シナリオを完全に回避するために、 自動 PDB 管理 を使用してデプロイ レプリカを自動的にスケールアップし、ドレインが開始される前に PDB 制約が満たされるようにすることができます。 これにより、ブロックされることなく強制終了を実行できるため、手動での隔離解除作業が不要になります。

Blue-Green ノードプールのアップグレード（手動操作）

Blue-Green アップグレードでは、ワークロードを移行する前に新しいノード プールの完全なセットを手動で作成することで、より制御されたアップグレード アプローチが提供されます。 この手動アプローチでは、アップグレード プロセスとタイミングを完全に制御できます。

詳細については、 AKSBlue-Green ノード プールのアップグレードに関するページを参照してください。

Blue-Green アップグレードを使用するタイミング

手動による Blue-Green ノードプールのアップグレードは、明示的な移行チェックポイント、カスタムの検証ゲート、または厳密に管理された切り替えなど、特殊な要件に対応する高度な戦略です。

必要に応じ、手動 Blue-Green を使用します。

  • オペレーターが制御する移行フェーズ。
  • コミット前のカスタム検証と受け入れ条件。
  • 内部運用手順書に紐付いた明示的なロールバック手順。

該当するほとんどの運用ワークロードでは、AKS 自動の既定のアップグレード動作が推奨される開始点であり、通常、手動 Blue-Green は例外的なケース用に予約されています。

重要な概念

  • 青いノード プール: 現在の Kubernetes バージョンを実行している既存のノード プール。
  • 緑のノード プール: ターゲット Kubernetes バージョンを実行して作成する新しいノード プール。
  • 手動制御: 移行プロセスのすべての側面を管理します。
  • 検証チェックポイント: 続行、一時停止、またはロールバックのタイミングを決定します。

Blue-Green アップグレードの利点

  • フル コントロール: 各ステップがいつ行われるかを正確に決定します。
  • カスタム検証: 独自の検証条件とタイミングを実装します。
  • 段階的な移行: 好みのペースでワークロードを移動します。
  • 簡単なロールバック: 元のノードは、削除するまで使用できます。

Blue-Green アップグレードに関する主な考慮事項

  • 手動作業: プロセス全体を通じてアクティブな管理が必要です。
  • クォータ要件: アップグレード中にノード容量の 2 倍が必要です。
  • 計画: 検証基準とロールバック手順を文書化します。

手動 Blue-Green アップグレード プロセスの例

この例では、Blue-Green デプロイを使用して、2 ノード クラスターを Kubernetes 1.30 から 1.31 に手動でアップグレードする方法を示します。

手順 1: 緑のノード プールを作成する

まず、既存のノード プールと共に、ターゲットの Kubernetes バージョンで新しいノード プールを手動で作成します。

バージョン 1.30 を実行しているブルー ノード プールと、バージョン 1.31 を実行する新しく作成された緑ノード プールを使用した Blue-Green 初期セットアップを示す図。

  • 青いノード プール (v1.30): ポッド A、ポッド B、ポッド C、ポッド D (既存)
  • 緑のノード プール (v1.31): 空 (手動で作成)
  • あなたのアクション: 新しい Kubernetes バージョンで az aks nodepool add を実行する

手順 2: 青いノードを手動で切断する

青色のノードをスケジュール不可としてマークし、既存の Pod は実行したまま、新しい Pod がスケジュールされないようにします。

  • あなたのアクション: 各青いノードでkubectl cordon
  • ブルー ノード: 切断、新しいポッドはスケジュールされない
  • 緑のノード: ワークロードを受け取る準備ができました

手順 3: 青いノードを手動でドレインする (制御されたペース)

移行のペースを制御するには、ノードを一度に 1 つずつ手動でドレインするか、またはバッチでドレインします。

ポッドが退避されて Green ノード プール上で置き換えられながら Blue ノードがドレインされ、続いて 2番目の Blue ノードがドレインされて、残りのポッドが Green ノード プールに移行される様子を示す図。

  • アクション: 選択されたブルー ノード上での kubectl drain
  • ポッドの移行: ポッドが自動的に緑色のノードに再スケジュールされる
  • 検証: 続行する前に、緑のノード上のワークロードを確認する

手順 4: 検証して決定する

ワークロードを移行した後、緑のノードでアプリケーションのパフォーマンスを検証します。

ブルー ノード プールがロールバック可能なまま、緑のノード プールで実行されているすべてのワークロードを含む検証フェーズを示す図。

このフェーズでは、次のことができます。

  • 監視: アプリケーションのメトリックとログを確認する
  • テスト: 緑のノード プールで検証テストを実行する
  • 決定: 緑にコミットするか、青にロールバックする

手順 5: コミットまたはロールバック

検証に基づいて、アップグレードまたはロールバックを手動で完了します。

オプション A - コミット (成功):

青いノード プールが削除され、緑のノード プールがプライマリ ノード プールになり、正常にコミットされたことを示す図。

  • 実行する操作: az aks nodepool delete を使用して青いノード プールを削除する
  • 結果: 緑のノード プールがプライマリになる

オプション B - ロールバック (問題が検出されました):

ブルー ノード プールと緑ノード プールに戻るワークロードが削除された場合のロールバックを示す図。

  • 実行する操作: kubectl uncordon を使用して青いノードのスケジューリング制限を解除し、kubectl drain を使用して緑のノードをドレインし、az aks nodepool delete を使用して緑のノード プールを削除します
  • 結果: ワークロードが Blue ノードに戻る

アップグレード計画の運用に関する考慮事項

  • サージ (maxSurge) 構成: アップグレード中に作成されるサージ ノードの数を制御します。 値を大きくするとアップグレードが高速化されますが、より多くのリソースが消費されます。
  • ポッド中断予算 (PDB): アップグレード プロセス中にアプリケーションの可用性を確保するように PDB を構成します。
  • ノード プールのアップグレード: 各ノード プールは個別にアップグレードされます。 それに応じてアップグレード戦略を計画します。
  • 容量とクォータ: アップグレード ウィンドウの前に、一時的な安定状態の容量要件を検証します。
  • 監視とアラート: アップグレードを開始する前に、監視とアラートを設定します。

AKS 自動では、運用環境の準備のために、いくつかのプラットフォーム レベルのアップグレードの選択肢が事前に構成されています。 AKS Standard では、チームは通常、これらの選択を明示的に行います。

関連するコンテンツ

  • Last updated on