Azure Kubernetes Service (AKS) クラスターのアップグレード オプション

この記事では、AKS クラスターのさまざまなアップグレード オプションについて説明します。 基本的な Kubernetes バージョンのアップグレードを実行するには、「AKS クラスターのアップグレード」を参照してください。

複数のノード プールまたは Windows Server ノードを使用する AKS クラスターについては、AKS 内のノード プールのアップグレードに関するページを参照してください。 Kubernetes クラスターをアップグレードせずに特定のノード プールをアップグレードするには、「特定のノード プールのアップグレード」を参照してください。

手動アップグレードの実行

手動アップグレードを実行して、クラスターを新しい Kubernetes バージョンにアップグレードするタイミングを制御できます。 手動アップグレードは、運用クラスターをアップグレードする前に新しい Kubernetes バージョンをテストする場合に便利です。 手動アップグレードを使って、クラスターを使用できる最新バージョンではない特定の Kubernetes バージョンにアップグレードすることもできます。

手動アップグレードを実行するには、次の記事を参照してください。

• AKS クラスターのアップグレード
• ノード イメージのアップグレード
• ノード サージ アップグレードのカスタマイズ
• ノードの OS の更新プログラムの処理

自動アップグレードを構成する

クラスターを使用できる最新の Kubernetes バージョンに自動的にアップグレードするように自動アップグレードを構成できます。 自動アップグレードは、クラスターが常に最新の Kubernetes バージョンを実行している必要がある場合に便利です。 自動アップグレードを使って、クラスターが常にサポートされている Kubernetes バージョンが実行されるようにすることもできます。

自動アップグレードを構成するには、次の記事を参照してください。

• AKS クラスターを自動的にアップグレードする
• 計画メンテナンスを使って AKS クラスターのアップグレードをスケジュールおよび制御する
• API の破壊的変更時に AKS クラスターのアップグレードを自動的に停止する (プレビュー)
• AKS クラスター ノードのオペレーティング システム イメージを自動的にアップグレードする
• GitHub Actions を使って AKS ノードにセキュリティ更新プログラムを自動的に適用する

複数の可用性ゾーンにまたがるノード プールに関する特別な考慮事項

AKS では、ノード グループでのベストエフォート ゾーン バランシングが使用されます。 アップグレード サージ中、Virtual Machine Scale Sets のサージ ノードのゾーンは事前に不明であるため、アップグレード中にゾーン構成が一時的に不均衡になる可能性があります。 ただし、アップグレードが完了すると、AKS によりサージ ノードが削除され、元のゾーン バランスが維持されます。 アップグレード中にゾーンのバランスを維持したい場合は、サージを 3 つのノードの倍数に増やします。すると、Virtual Machine Scale Sets により、ベスト エフォートのゾーン分散を使用して可用性ゾーン間でノードのバランスが保たれます。 ベスト エフォートのゾーン バランスでは、スケール セットはバランスを維持しながらスケールインとスケールアウトを試みます。 ただし、何らかの理由によりそれが不可能な場合 (たとえば、1 つのゾーンがダウンして、スケール セットがそのゾーンに新しい VM を作成できなくなった場合)、スケール セットは、スケールインまたはスケールアウトを成功させるため、一時的なアンバランスを許可します。

Azure ローカル冗長ストレージ (LRS) ディスクによってサポートされる永続ボリューム要求 (PVC) は特定のゾーンにバインドされており、サージ ノードが PVC のゾーンと一致しない場合、すぐに回復できない可能性があります。 ゾーンが一致しない場合、アップグレード操作によってノードのドレインが続行されても、PV がゾーンにバインドされていると、アプリケーションのダウンタイムが発生する可能性があります。 このようなケースに対応し、高可用性を維持するには、アプリケーションにポッド中断予算を構成して、ドレイン操作中に Kubernetes が可用性要件を尊重できるようにします。

アップグレードを最適化してパフォーマンスを改善し中断を最小限に抑える

計画メンテナンス期間、最大サージ、ポッド中断バジェット、ノード ドレイン タイムアウト、ノードのソーク時間 (プレビュー) を組み合わせると、メンテナンス期間の終了までにノード アップグレードが正常に完了する可能性が大幅に高まり、中断も最小限に抑えられます。

• 計画メンテナンス期間によってサービス チームは、事前に定義された期間中 (通常はトラフィックの少ない期間) に自動アップグレードをスケジュールして、ワークロードへの影響を最小限に抑えることができます。 少なくとも "4 時間" の期間を設けることをお勧めします。

• ノード プールの最大サージにより、アップグレード プロセス中に追加のクォータを要求することができ、同時にアップグレードするために選ばれるノードの数が制限されます。 最大サージが大きいほど、アップグレード プロセスが高速になります。 すべてのノードが同時にアップグレードされ、実行中のアプリケーションが中断される可能性があるため、100% に設定することはお勧めしません。 運用ノード プールには、最大サージ クォータを 33% にすることをお勧めします。

• ポッド中断バジェットはサービス アプリケーションに対して設定され、AKS によって制御されるノードのアップグレードなど、自発的な中断の最中にダウンする可能性があるポッドの数を制限します。 これは、アクティブである必要があるアプリケーション ポッドの最小数を示す minAvailable レプリカとして、あるいは終了できるアプリケーション ポッドの最大数を示す maxUnavailable レプリカとして構成してアプリケーションの高可用性を確保することができます。 ポッド中断バジェット (PDB) の構成に関して提供されているガイダンスを参照してください。 PDB 値を検証して、特定のサービスに最適な設定を決定する必要があります。

• ノード プールのノード ドレイン タイムアウトを使用すると、アップグレード中におけるポッドの削除とノードごとの正常終了の待機時間を構成できます。 このオプションは、長期のワークロードを処理する場合に役立ちます。 ノード ドレイン タイムアウトが (分単位で) 指定されているとき、AKS では、ポッド中断バジェットで待機を適用します。 指定されていない場合、既定のタイムアウトは 30 分です。

• ノードのソーク時間 (プレビュー) を使用すると、ノードのアップグレードを制御された方法でずらすことができ、アップグレード中のアプリケーションのダウンタイムを最小限にすることができます。 ノードのアップグレード間のアプリケーションの準備状況を確認するために、待機時間 (できるだけ 0 分に近い値が望ましい) を指定できます。 指定しない場合、既定値の 0 分が使用されます。 ノードのソーク時間は、ノード プールで使用可能な最大サージおよびノード ドレイン タイムアウトのプロパティと共に機能し、アップグレードの速度とアプリケーションの可用性という点で適切な結果が得られるようにします。

  Note

  ノードのソーク期間 (プレビュー) を使用するには、aks-preview Azure CLI 拡張機能のバージョン 0.5.173 以降がインストールされている必要があります。

次のステップ

この記事では、AKS クラスターのさまざまなアップグレード オプションを示しました。 アップグレードのベスト プラクティスとその他の考慮事項の詳細については、「AKS のパッチとアップグレードのガイダンス」を参照してください。