次の方法で共有

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

この記事では、AKS クラスターのアップグレード オプションについて説明し、一般的なアップグレードの課題に関するシナリオベースの推奨事項を示します。

アップグレード オプション

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

手動アップグレードを使用すると、クラスターを新しい Kubernetes バージョンにアップグレードするタイミングを制御できます。 特定のバージョンのテストまたはターゲット設定に役立ちます。

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

自動アップグレードでは、クラスターはサポートされているバージョンと最新の状態に維持されます。 これは、設定して忘れたい場合です。

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

AKS では、ノード グループでのベストエフォート ゾーン バランシングが使用されます。 アップグレードのサージ中、仮想マシン スケール セット内のサージ ノードのゾーンは事前に不明であり、一時的にゾーン構成が不均衡になる可能性があります。 AKS は、アップグレード後にサージ ノードを削除し、元のゾーンバランスを復元します。 ゾーンのバランスを維持するには、サージを 3 つのノードの倍数に設定します。 Azure LRS ディスクを使用する PVC はゾーン バインドであり、サージ ノードが別のゾーンにある場合にダウンタイムが発生する可能性があります。 ドレイン中に高可用性を維持するために、ポッド中断バジェットを使用してください。

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

計画メンテナンス期間、最大サージ、ポッド中断バジェット、ノードドレインタイムアウト、ノードソーク時間を組み合わせて、中断の少ないアップグレードが成功する可能性を高めます。

  • 計画メンテナンス期間: トラフィックの少ない期間中に自動アップグレードをスケジュールする (少なくとも 4 時間をお勧めします)
  • 最大サージ: より高い値はアップグレードを高速化しますが、ワークロードを中断する可能性があります。運用環境には 33% をお勧めします
  • 最大使用不可: 容量が制限されている場合に使用します
  • ポッド中断バジェット: アップグレード時のポッドのダウンを制限するために設定します。サービスに対して検証します
  • ノード ドレイン タイムアウト: ポッドの削除の待機時間を構成する (既定の 30 分)
  • ノードのソーク時間: アップグレードをずらしてダウンタイムを最小限に抑える (既定の 0 分)
アップグレード設定 追加ノードの使用方法 予想される動作
maxSurge=5、maxUnavailable=0 5 つのサージ ノード アップグレードのために 5 つのノードが急増しました
maxSurge=5、maxUnavailable=0 0-4 個のサージ ノード サージ ノードが不足しているため、アップグレードに失敗する
maxSurge=0、maxUnavailable=5 なし アップグレードのために 5 つの既存のノードをドレイン

注

アップグレードする前に、API の破壊的変更を確認し、中断を避けるために AKS リリース ノート を確認してください。

アップグレード プロセスで使用される検証

AKS では、クラスターの正常性を確保するためにアップグレード前の検証が実行されます。

  • API の破壊的変更: 非推奨の API を検出します。
  • Kubernetes アップグレード バージョン: 有効なアップグレード パスを確認します。
  • PDB の構成: 正しく構成されていない PDB (例: maxUnavailable=0) を確認します。
  • クォータ： 急増ノードに十分なクォータがあることを確認します。
  • サブネット： 十分な IP アドレスを検証します。
  • 証明書/サービス プリンシパル: 有効期限が切れた資格情報を検出します。

これらのチェックは、アップグレードの失敗を最小限に抑え、問題を早期に把握するのに役立ちます。

一般的なアップグレード シナリオと推奨事項

シナリオ 1: 容量の制約

クラスターが SKU またはリージョンの容量によって制限されている場合、サージ ノードをプロビジョニングできないときにアップグレードが失敗する可能性があります。 これは、特殊な SKU (GPU ノードなど) やリソースが限られているリージョンで一般的です。 SKUNotAvailable、AllocationFailed、OverconstrainedAllocationRequestなどのエラーは、使用可能な容量に対してmaxSurgeが大きすぎる場合に発生する可能性があります。

防止または解決するための推奨事項

シナリオ 2: ノード ドレインエラーと PDB

アップグレードでは、ノードのドレイン (ポッドの削除) が必要です。 ドレインは次の理由で故障する可能性があります。

  • ポッドの終了が遅い (長いシャットダウンフックまたは持続的な接続)。
  • 厳格なポッド中断バジェット (PDB) がポッドの削除をブロックする。

エラー メッセージの例:

Code: UpgradeFailed
Message: Drain node ... failed when evicting pod ... failed with Too Many Requests error. This is often caused by a restrictive Pod Disruption Budget (PDB) policy. See https://aka.ms/aks/debugdrainfailures. Original error: Cannot evict pod as it would violate the pod's disruption budget. PDB debug info: ... blocked by pdb ... with 0 unready pods.

防止または解決するための推奨事項

  • PDB で maxUnavailable を設定して、少なくとも 1 つのポッドを削除できるようにします。

  • 中断バジェットが削除を許容できるように、ポッド レプリカを増やします。

  • undrainableNodeBehaviorを使用して、一部のノードをドレインできない場合でもアップグレードを続行できるようにします。

    • スケジュール (既定): ノードとサージ交換が削除され、容量が減少する可能性があります。
    • Cordon (推奨): ノードは切断され、 kubernetes.azure.com/upgrade-status=Quarantinedとしてラベル付けされます。

      • コマンドの例:

        az aks nodepool update \
  --resource-group <resource-group-name> \
  --cluster-name <cluster-name> \
  --name <node-pool-name> \
  --undrainable-node-behavior Cordon

        次の出力例は、アップグレードされた、読み取り不可能なノードの動作を示しています。

        "upgradeSettings": {
"drainTimeoutInMinutes": null,
"maxSurge": "1",
"nodeSoakDurationInMinutes": null,
"undrainableNodeBehavior": "Cordon"
}

  • ワークロードにさらに時間が必要な場合は、ドレイン タイムアウトを延長します (既定値は 30 分)。

  • ステージングで PDB をテストし、アップグレード イベントを監視し、重要なワークロードにブルーグリーンデプロイを使用します。 詳細については、こちらを参照してください。

ドレインできないノードの確認

  • ブロックされたノードはポッドに対してスケジュール解除され、ラベル "kubernetes.azure.com/upgrade-status: Quarantined" でマークされます。

  • アップグレード時にドレイン ノードの障害が発生したときに、ブロックされているノードのラベルを確認します。

    kubectl get nodes --show-labels=true

ドレインできないノードの解決

  1. 責任ある PDB を削除します。

    kubectl delete pdb <pdb-name>

  2. kubernetes.azure.com/upgrade-status: Quarantined ラベルを削除します。

    kubectl label nodes <node-name> <label-name>

  3. 必要に応じて、ブロックされたノードを削除します。

    az aks nodepool delete-machines --cluster-name <cluster-name> --machine-names <machine-name> --name <node-pool-name> --resource-group <resource-group-name>

  4. この手順を完了した後は、ここで説明するオプションのフィールドを指定せずにアップグレード操作を実行することで、クラスターの状態を調整できます。 または、ノード プールを、アップグレードされたノードの数と同じ数のノードにスケーリングすることもできます。 このアクションにより、ノード プールが意図した元のサイズに到達します。 AKS は、ブロックされたノードの削除に優先順位を付けます。 また、このコマンドは、クラスターのプロビジョニング状態を Succeeded に復元します。 この例では、2 はアップグレードされたノードの合計数です。

    # Update the cluster to restore the provisioning status
az aks update --resource-group <resource-group-name> --name <cluster-name>

# Scale the node pool to restore the original size
az aks nodepool scale --resource-group <resource-group-name> --cluster-name <cluster-name> --name <node-pool-name> --node-count 2

シナリオ 3: アップグレードが遅い

保守的な設定やノード レベルの問題によってアップグレードが遅れる可能性があり、修正プログラムや機能強化を使用して最新の状態を維持する機能に影響を与えます。

アップグレードが遅くなる一般的な原因は次のとおりです。

  • maxSurge値またはmaxUnavailable値が低い (並列処理が制限されます)。
  • 待機時間が長い (ノードのアップグレード間の長い待機時間)。
  • ドレイン エラー ( 「ノードドレインエラー」を参照)。

防止または解決するための推奨事項

  • 本番環境の場合: maxSurge=33%、 maxUnavailable=1。
  • 開発/テストの場合: maxSurge=50%、 maxUnavailable=2。
  • OS セキュリティ パッチを使用して、高速でターゲットを絞った修正プログラムを適用します (ノードの完全な再イメージ化を回避します)。
  • アップグレード の阻害要因を回避するには、 undrainableNodeBehavior を有効にします。

シナリオ 4: IP 枯渇

サージ ノードには追加の IP が必要です。 サブネットの容量が近い場合、ノードのプロビジョニングが失敗する可能性があります (例: Error: SubnetIsFull)。 これは、Azure CNI、高い maxPods、または大規模なノード数で一般的です。

防止または解決するための推奨事項

  • サブネットに、すべてのノード、サージ ノード、ポッドに十分な IP があることを確認します。

    • 式: Total IPs = (Number of nodes + maxSurge) * (1 + maxPods)

  • 未使用の IP を再利用するか、サブネットを展開します (例: /24 から /22)。

  • サブネットの拡張が不可能な場合は、 maxSurge を小さくします。

    az aks nodepool update \
  --resource-group <resource-group-name> \
  --cluster-name <cluster-name> \
  --name <node-pool-name> \
  --max-surge 10%

  • Azure Monitor またはカスタム アラートを使用して IP 使用状況を監視します。

  • ノードあたりの maxPods を減らし、孤立したロード バランサー IP をクリーンアップし、大規模なクラスターのサブネットのサイズ設定を計画します。

次のステップ

  • アップグレードを開始する前に 、AKS パッチとアップグレードのガイダンス でベスト プラクティスと計画のヒントを確認してください。
  • API の破壊的変更を常に確認し、ワークロードのターゲット Kubernetes バージョンとの互換性を検証します。
  • 運用環境のリスクを最小限に抑えるために、ステージング環境でアップグレード設定 ( maxSurge、 maxUnavailable、PDB など) をテストします。
  • プロセス全体でアップグレード イベントとクラスターの正常性を監視します。