この記事では、AKS クラスターのアップグレード オプションについて説明し、一般的なアップグレードの課題に関するシナリオベースの推奨事項を示します。
- Kubernetes の基本的なバージョンのアップグレードについては、「 AKS クラスターのアップグレード」を参照してください。
- 複数のノード プールまたは Windows Server ノードを持つクラスターについては、「 AKS でのノード プールのアップグレード」を参照してください。
- クラスターを完全にアップグレードせずに特定のノード プールをアップグレードするには、「 特定のノード プールのアップグレード」を参照してください。
アップグレード オプション
手動アップグレードの実行
手動アップグレードを使用すると、クラスターを新しい Kubernetes バージョンにアップグレードするタイミングを制御できます。 特定のバージョンのテストまたはターゲット設定に役立ちます。
- AKS クラスターのアップグレード
- ノード イメージのアップグレード
- ノード サージ アップグレードのカスタマイズ
- ノードの OS の更新プログラムの処理
- Azure Kubernetes Fleet Manager 経由で複数の AKS クラスターをアップグレードする
自動アップグレードを構成する
自動アップグレードでは、クラスターはサポートされているバージョンと最新の状態に維持されます。 これは、設定して忘れたい場合です。
- AKS クラスターを自動的にアップグレードする
- 計画メンテナンスを使用してアップグレードをスケジュールおよび制御する
- API の破壊的変更時に AKS クラスターのアップグレードを自動的に停止する (プレビュー)
- AKS クラスター ノードのオペレーティング システム イメージを自動的にアップグレードする
- GitHub Actions を使って AKS ノードにセキュリティ更新プログラムを自動的に適用する
複数の可用性ゾーンにまたがるノード プールに関する特別な考慮事項
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
が大きすぎる場合に発生する可能性があります。
防止または解決するための推奨事項
maxUnavailable
を使用して、新しいノードを急増させる代わりに、既存のノードを使用してアップグレードします。 詳細については、こちらを参照してください。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
ドレインできないノードの解決
責任ある PDB を削除します。
kubectl delete pdb <pdb-name>
kubernetes.azure.com/upgrade-status: Quarantined
ラベルを削除します。kubectl label nodes <node-name> <label-name>
必要に応じて、ブロックされたノードを削除します。
az aks nodepool delete-machines --cluster-name <cluster-name> --machine-names <machine-name> --name <node-pool-name> --resource-group <resource-group-name>
この手順を完了した後は、ここで説明するオプションのフィールドを指定せずにアップグレード操作を実行することで、クラスターの状態を調整できます。 または、ノード プールを、アップグレードされたノードの数と同じ数のノードにスケーリングすることもできます。 このアクションにより、ノード プールが意図した元のサイズに到達します。 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 など) をテストします。 - プロセス全体でアップグレード イベントとクラスターの正常性を監視します。
Azure Kubernetes Service