Azure Kubernetes Service (AKS)のノード中断ポリシー (プレビュー)

AKS クラスターの管理と保守を行う際に、特定の構成変更ではノードを再イメージ化する必要があります。 この再イメージ化操作により、ノードを再作成するローリング更新がトリガーされます。 再イメージ化操作中に、AKS はノードを切断し (新しいポッド スケジューリングを防ぎます)、既存のポッドをドレインし (ポッド中断バジェットを考慮しながら、他の使用可能なノードで削除して再スケジュール)、更新された構成でノードを再イメージ化します。 このプロセスは完全なノード再作成であり、再起動ではありません。基になる VM は新しい OS イメージで再イメージ化されます。 適切に構成された永続ボリューム (Azure ディスク、Azure Files、またはその他の外部ストレージを使用) は影響を受けませんが、ノードのローカルエフェメラル ストレージ (EmptyDir ボリュームやローカル パスなど) に格納されているデータは完全に失われます。 これらの操作は重要な更新プログラムを適用するために必要ですが、実行中のワークロードが中断され、アプリケーションの可用性に影響を与える可能性があります。 ノード中断ポリシーを使用すると、これらの破壊的操作をいつ続行するかをきめ細かく制御できます。これにより、更新の必要性と運用上の安定性のバランスを取るのに役立ちます。

Important

AKS のプレビュー機能は、セルフサービスのオプトイン単位で利用できます。 プレビューは、"現状有姿のまま" および "利用可能な限度" で提供され、サービス レベル アグリーメントおよび限定保証から除外されるものとします。 AKS プレビューは、ベストエフォート ベースでカスタマー サポートによって部分的にカバーされます。 そのため、これらの機能は運用環境での使用を目的としていません。 詳細については、次のサポート記事を参照してください。

ノード中断ポリシーとは

ノード中断ポリシーは、ノードの再イメージ化と再デプロイを必要とする操作をいつ実行できるかを制御するクラスター レベルの構成です。 コントロール ゲートとして機能し、次の操作を行うことができます。

  • サービス中断を伴う操作は、メンテナンス時間帯に合わせてください。
  • 重要なビジネス期間中に構成の変更をブロックしながら、ノード イメージのアップグレードとセキュリティ パッチの続行を許可します。
  • トラフィックの多いイベント中に予測可能なクラスターの動作を維持します。

このポリシーは、カスタム証明機関 (CA) 信頼証明書の更新、セキュリティ プロファイル設定の変更、ノード OS 構成の変更など、ノードの再作成を必要とするユーザーが開始した構成の変更に適用されます。

Note

重要なのは、このポリシーでは、ノード イメージのバージョンの更新 ( SecurityPatch と NodeImage アップグレード チャネルを含む) または Kubernetes バージョンのアップグレードはブロックされません。 これらの操作は、ポリシーが Blockに設定されている場合でも、構成されたスケジュールに従って続行されます。 詳細については、「 ノード中断ポリシーによって制御されないアップグレード操作」を参照してください。 さらに、特定の復旧操作は、クラスターの正常性と可用性を確保するために、このポリシーによって制御されません。 詳細については、「 ノード中断ポリシーによって制御されない回復操作」を参照してください。

ノード中断ポリシーのしくみ

ノード中断ポリシーは、 nodeDisruptionProfile プロパティを使用してクラスター レベルで構成します。 ノードの再イメージ化を必要とする操作を試みると、AKS は現在のポリシー設定を確認します。

  • ポリシーの評価: AKS は、現在のポリシーに基づいて操作が許可されているかどうかを評価します。
  • メンテナンス期間のチェック (該当する場合): AllowDuringMaintenanceWindowを使用している場合、AKS は現在の時刻が構成されたメンテナンス期間内にあるかどうかを確認します。
  • 操作の実行またはブロック: ノード中断操作は許可されている場合は続行され、ブロックされた場合はエラー メッセージで拒否されます。

ポリシーのオプション

ノード中断ポリシーでは、次の 3 つのポリシー構成がサポートされています。

Policy 説明 利用シーン
Allow ノードの再イメージ化を必要とする操作をいつでも続行できます。 これが既定の動作です。 更新プログラムの適用に迅速に優先順位を付け、ワークロードの中断を許容できる場合に使用します。
AllowDuringMaintenanceWindow ノードの再イメージ化が必要な操作は、 aksManagedNodeOSUpgradeSchedule メンテナンス期間内に発生しない限りブロックします。 運用スケジュールに合わせて特定のメンテナンス期間に中断を制限する場合に使用します。
Block ノードの再イメージ化を必要とするすべての操作をブロックします。 重要なビジネス期間中やトラフィックの多いイベント中など、ノードの中断を防ぐ必要がある場合に使用します。

Note

AllowDuringMaintenanceWindowを使用する場合は、aksManagedNodeOSUpgradeScheduleメンテナンス時間帯を設定する必要があります。 メンテナンス期間の設定の詳細については、「計画メンテナンスを使用して、Azure Kubernetes Service クラスターのアップグレードをスケジュールおよび制御する」を参照してください。 メンテナンス期間を構成しない場合は、ノード中断操作が許可されます。

Considerations

ノード中断ポリシーを使用する場合は、次の考慮事項に注意してください。

ノード中断ポリシーの対象となる操作

クラスター レベルの操作

ネットワーク ポリシーの有効化と CNI オーバーレイのアップグレードAzure

必要なネットワーク コンポーネントをインストールし、ポッド間通信をセキュリティで保護および管理するネットワーク 規則を構成するには、ノードを再イメージ化する必要があります。

次の表は、 再イメージ化をトリガーするネットワーク ポリシーのアップグレードの概要を示しています。

差出人 〜へ
なし (ネットワーク ポリシーなし) Azure ネットワーク ポリシー
なし (ネットワーク ポリシーなし) Calico
Azure CNI Azure CNI オーバーレイ
Azure ネットワーク ポリシー なし (ネットワーク ポリシーなし)
Calico なし (ネットワーク ポリシーなし)

Note

Azureと Calico のネットワーク ポリシーを既に有効にした後で変更しても、再イメージ化は必要ありません。

ノード OS アップグレード チャネル の変更

各チャネルでは、実行中のノードでは 変更できない 異なる OS 修正プログラム適用インフラストラクチャと構成が使用されます。

次の表は、 再イメージ化をトリガーするノード OS アップグレード チャネルの変更の概要を示しています。

差出人 〜へ
アンマネージド なし
指定されていません。 アンマネージド
セキュリティパッチ アンマネージド
NodeImage アンマネージド
なし アンマネージド
指定されていません。 アンマネージド
アンマネージド セキュリティパッチ
アンマネージド NodeImage

IPv6 デュアル スタック 有効化

デュアル スタック通信をサポートするには、ノードには IPv4 と IPv6 の両方の IP 構成とネットワーク スタックの更新 (nftables ルールなど) が必要です。

次の表は、 再イメージ化をトリガーする IP 構成とネットワーク スタックの更新の概要を示しています。

差出人 〜へ
IPv4 のみ IPv4 + IPv6 (デュアル スタック)

Cilium データ プレーン の変更

カーネル・レベルでパケット処理を処理する eBPF プログラムをインストールまたは削除する必要があります。

次の表は、 再イメージ化をトリガーする Cilium データ プレーンの変更の概要を示しています。

差出人 〜へ
なし Cilium
Cilium なし

HTTP プロキシ 構成の更新

すべてのノード コンポーネント (コンテナー化、kubelet、システム サービス) には、システム全体で適用された更新されたプロキシ構成が必要です。 HTTP プロキシ構成を更新すると、AKS によってクラスター内のすべてのノード プールが自動的に再イメージ化されます。

ノード中断ポリシーは、次のいずれかの HTTP プロキシ構成プロパティを変更するか、次のいずれかの操作を実行すると 、再イメージ化をトリガー します。

  • httpProxy: HTTP 接続のプロキシ URL
  • httpsProxy: HTTPS 接続のプロキシ URL
  • noProxy: プロキシから除外する宛先の一覧
  • trustedCa: Base64 でエンコードされた代替 CA 証明書
  • クラスターで HTTP プロキシを有効にする ( --enable-http-proxyを使用)
  • クラスターで HTTP プロキシを無効にする ( --disable-http-proxyを使用)
  • 以前に無効にしていたクラスターで HTTP プロキシを再び有効にする

カスタム CA 証明書 の更新

内部サービスとプライベート レジストリの TLS 検証に影響を与えるために、OS 信頼ストアに新しい CA 証明書をインストールする必要があります。

ノード中断ポリシーは、カスタム CA 証明書を追加、削除、または更新すると、 再イメージ化をトリガーします 。

Kubelet ID の 変更

ノード構成に新しい ID 資格情報を適用する必要があります。 これには、初期 ID の割り当て、ID の更新、サービス プリンシパル プロファイルのリセットが含まれます。

Kubelet のマネージド ID またはユーザー割り当てマネージド ID を更新すると、ノード中断ポリシーによって 再イメージ化がトリガー されます。

プライベート DNS ゾーンの変更

新しい DNS ゾーンを使用してプライベート API サーバー エンドポイントを解決するには、DNS リゾルバーの設定を更新する必要があります。

ノード中断ポリシーは、プライベート クラスター内のプライベート DNS ゾーン構成を変更すると 、再イメージ化をトリガー します。

API Server VNet 統合 の有効化

委任されたサブネットに投影される内部ロード バランサー IP を介して API サーバーと通信するようにノードを再構成する必要があります。

以前に使用していなかった既存のクラスターで API Server VNet 統合を有効にすると、ノード中断ポリシーによって 再イメージ化がトリガーされます 。 この変更は、 apiServerAccessProfile.enableVnetIntegration プロパティ (内部的には privateConnectProfile.enabled フィールド) を false (または未設定) から trueに変更する場合に対応します。

差出人 〜へ
apiServerAccessProfile.enableVnetIntegration: false または未設定 apiServerAccessProfile.enableVnetIntegration: true

eBPF ホスト・ルーティング の変更

高パフォーマンスのパケット転送 (BpfVeth アクセラレーション モード) を提供する eBPF プログラムをインストールまたは削除する必要があります。

次の表は、 再イメージ化をトリガーする eBPF ホスト・ルーティング変更の概要を示しています。

差出人 〜へ
標準ルーティング eBPF ホスト・ルーティングが有効
eBPF ホスト・ルーティングが有効 標準ルーティング

ノード プール レベルでの操作

これらの操作は、変更を行う特定のノード プールにのみ影響します。 それらのノード プール内でローリング再イメージ化を開始します。

ローカル DNS プロファイルの更新

ノード レベルで DNS キャッシュ デーモンと DNS 転送規則に変更を適用する必要があります。

LocalDNS プロファイル構成を変更すると、ノード中断ポリシーによって 再イメージ化がトリガーされます 。

信頼できる起動 のセキュリティの変更

実行中の VM で VM ファームウェアの構成とブート プロセスの設定を変更することはできません。 これらの変更を行うには、VM を再作成する必要があります。

次の表は、 再イメージ化をトリガーするトラステッド起動セキュリティの変更の概要を示しています。

コンフィギュレーション 差出人 〜へ
vTPM (仮想トラステッド プラットフォーム モジュール) Disabled Enabled
vTPM (仮想トラステッド プラットフォーム モジュール) Enabled Disabled
セキュア ブート Disabled Enabled
セキュア ブート Enabled Disabled

アーティファクト ストリーミングの 変更

オンデマンドでイメージ レイヤーをストリーミングしてコンテナー イメージのプルを高速化するには、アーティファクト ストリーミング コンポーネントをインストールまたは削除する必要があります。

次の表は、 再イメージ化をトリガーする成果物ストリーミングの変更の概要を示しています。

差出人 〜へ
Disabled Enabled
Enabled Disabled

WINDOWS GMSA プロファイルの更新 (Windows ノード プールのみ)

Windows ノードにActive Directory統合するには、新しい GMSA 設定、DNS サーバー構成、およびドメイン参加資格情報を適用する必要があります。

GMSA の変更で新しいノード構成を適用する必要がある場合、ノード中断ポリシーによって、Windows ノード プールの再イメージ化がトリガーされます。

差出人 〜へ 再イメージ化を開始
GMSA は無効 GMSA が有効 Yes
GMSA が有効 (DNS サーバー/ルート ドメイン セットまたは変更済み) 更新された DNS サーバーまたはルート ドメインで GMSA が有効になっている Yes
GMSA が有効 (DNS サーバー セット) GMSA 無効 Yes
GMSA が有効 (DNS サーバー セットなし) GMSA は無効です いいえ (適用するノード構成なし)

容量予約グループ のアタッチ

基になる VM を再作成して、容量予約グループ (CRG) の予約容量から割り当てるようにする必要があります。 既存のノードは CRG に対してプロビジョニングされていないため、AKS はノード プールを再イメージ化して予約に関連付ける必要があります。

まだ存在しない既存のノード プールに容量予約グループをアタッチすると、ノード中断ポリシーによって 再イメージ化がトリガーされます 。

差出人 〜へ 再イメージ化を開始する
容量予約グループがアタッチされていません 容量予約グループ関連付け済み Yes

ノード中断ポリシーの対象になっていない操作

次の構成変更では、ノードの再イメージ化が必要ですが 、ノード中断ポリシーはまだ適用されていません。 今後の Kubernetes マイナー バージョンの更新では、この変更によって新しい動作が導入されるため、これらの変更について説明します。
これらの構成変更を行った後、az aks nodepool upgradeを使用して--node-image-onlyを手動で実行して、ノードに変更を適用する必要があります。

  • SSH 構成の変更: SSH アクセス方法 (無効な SSH、Entra ID ベースの SSH、またはローカル ユーザー SSH) の変更、またはノード プールでの SSH 公開キーの更新。
  • IMDS 制限の 変更: インスタンス メタデータ サービス (IMDS) 制限を有効または無効にして、IMDS エンドポイントへのポッド アクセスをブロックします。
  • ブートストラップ プロファイルの変更: artifactSourceとDirectの間でCacheを切り替える、containerRegistryId (ネットワーク分離クラスターに使用されるAzure Container Registry) の変更など、ブートストラップ プロファイルを変更します。
  • 送信の種類 の変更: クラスターの送信接続の種類 (loadBalancer、userDefinedRouting、managedNATGateway、または userAssignedNATGateway) の変更。

ノード中断ポリシーによって制御されないアップグレード操作

ノード中断ポリシー では、次の アップグレード操作は制御されません。 これらのアップグレード操作は、ポリシー設定に関係なく続行されます。 アップグレードは、お客様が開始するか、計画メンテナンス期間内に AKS によって開始されます。 これらの操作をスケジュールどおりに続行できるようにするには、ノード中断ポリシーのスコープから意図的に除外します。 追加的に、ノード中断ポリシーの対象となる操作がアップグレードと同じ構成変更に含まれている場合、それらはノード中断ポリシーによって制御されません。

  • ノード イメージのバージョン の更新: 新しいノード OS イメージ バージョンへのアップグレード (手動または自動アップグレード チャネルを使用)。 この操作は最も一般的な再イメージ化操作であり、セキュリティ パッチ、OS 更新プログラム、AKS ノード イメージのリリースが含まれます。
  • Kubernetes バージョンの アップグレード: ノード プール上の Kubernetes バージョンのアップグレード。新しい Kubernetes バイナリ、更新された kubelet 構成、OS レベルの変更が適用されます。

ノード中断ポリシーによって制御されない復旧操作

ノード中断ポリシー では、 次の自動復旧操作は制御されません。 これらの操作は、クラスターの正常性と回復を確保するためのポリシー設定に関係なく発生する可能性があります。

  • ノード プール構成のロールバック: 無効な構成またはインフラストラクチャの問題によってノード プールの更新操作が失敗した場合、AKS は自動的に最後の既知の正常な状態にロールバックし、ノードを再イメージ化して構成を元に戻します。
  • 管理クラスターの復元操作: Azure サポートエンジニアがインシデントの解決中に管理クラスターの復元を実行すると、ノードが再イメージ化され、コントロール プレーンの状態とノードの構成の整合性が確保されます。
  • ノード ID 資格情報の更新: AKS は、セキュリティとコンプライアンスのためにノード ID 資格情報を定期的に更新します。 これらのシステム開始更新プログラムは、ノードの再イメージ化をトリガーして、すべてのノード プールに新しい資格情報を適用します。

計画メンテナンスとの統合

ノード中断ポリシーは AKS の計画メンテナンス ウィンドウとシームレスに連携して動作します。 ポリシーを AllowDuringMaintenanceWindowに設定すると、中断を伴う操作が aksManagedNodeOSUpgradeSchedule のメンテナンス期間に合わせて調整され、次のことが保証されます。

  • 変更は、承認された時間枠内にのみ行われます。
  • 操作は、他のスケジュールされたメンテナンスと連携します。
  • Teams は、中断が発生する可能性があるタイミングを認識します。

この統合により、クラスターの変更を管理し、実行中のワークロードへの影響を最小限に抑えるための包括的なアプローチが提供されます。

Note

AllowDuringMaintenanceWindowを使用する場合は、aksManagedNodeOSUpgradeScheduleメンテナンス時間帯を設定する必要があります。 defaultメンテナンス期間またはaksManagedAutoUpgradeSchedule (クラスターの自動アップグレード) を使用しても、この要件は満たされません。 AllowDuringMaintenanceWindow ウィンドウを構成せずにaksManagedNodeOSUpgradeScheduleを設定すると、中断を伴うすべての操作が許可されます (ポリシーにはゲートするウィンドウがありません)。 メンテナンス期間の設定の詳細については、「計画メンテナンスを使用して、Azure Kubernetes Service クラスターのアップグレードをスケジュールおよび制御する」を参照してください。

ベスト プラクティス

ノード中断ポリシーを実装する場合は、次の推奨事項を考慮してください。

  • 運用環境に AllowDuringMaintenanceWindow を使用する: 計画メンテナンス期間と組み合わせて、運用環境で中断が発生するタイミングを制御します。
  • 重要な期間中に Block を設定する: トラフィックの多いイベント、製品の起動、インシデント対応中に中断を伴う操作を一時的にブロックします。 Blockを無期限に使用しないでください。 Blockは短期的な凍結 (計画されたイベント、インシデント対応) に適しています。
  • 非運用環境での柔軟性を実現する: 迅速な反復が安定性よりも重要な開発環境とテスト環境で Allow を使用します。
  • ポリシーの変更を伝える: チームが現在のポリシーを理解し、操作がブロックされる可能性があるタイミングを把握していることを確認します。
  • メンテナンス期間を適切に計画する: 実行する必要がある操作に合わせてメンテナンス期間のサイズを設定します。
  • ポリシーの動作をテストする: 運用クラスターに適用する前に、非運用環境でポリシー設定を検証します。
  • ブロックされた操作を監視する: メンテナンス スケジュールを最適化するために、操作がブロックされたタイミングを追跡します。

関連するコンテンツ

  • Last updated on