次の方法で共有

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

この記事では、アップグレード オプションと一般的なシナリオについて説明することで、Azure Kubernetes Service (AKS) クラスターのアップグレードの技術的基盤を提供します。 ニーズに合わせた詳細なガイダンスについては、この記事の最後にあるシナリオベースのナビゲーション パスを使用してください。

この記事の内容

このテクニカル リファレンスでは、以下に関する包括的な AKS アップグレードの基礎について説明します。

  • 手動アップグレードオプションと自動アップグレード オプション、および各オプションを使用するタイミング。
  • 特定の推奨事項を含む一般的なアップグレード シナリオ。
  • パフォーマンスと中断を最小限に抑える最適化手法。
  • 容量、排水不良、タイミングの問題に関するトラブルシューティングのガイド。
  • 検証プロセスとアップグレード前のチェック。

このハブは、アップグレードのしくみの理解、問題のトラブルシューティング、アップグレード設定の最適化、技術的な実装の学習を支援するのに最適です。

詳細については、次の関連記事を参照してください。

AKS のアップグレードを初めて使用する場合は、ガイド付きのシナリオ ベースのサポートのために アップグレード シナリオ ハブ から始めてください。

クイック ナビゲーション

あなたの状況 推奨パス
運用クラスターにアップグレードが必要 運用アップグレード戦略
データベース/ステートフル ワークロード ステートフル ワークロード パターン
初回アップグレードまたは基本クラスター 基本的な AKS クラスターのアップグレード
複数の環境またはフリート アップグレード シナリオ ハブ
ノード プールまたは Windows ノード ノード プールのアップグレード
特定のノード プールのみ 単一ノード プールのアップグレード

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

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

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

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

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

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

AKS では、ノード グループでのベストエフォート ゾーン バランシングが使用されます。 アップグレードサージ中、仮想マシン スケール セット内のサージ ノードのゾーンは事前に不明であり、一時的にゾーン構成が不均衡になる可能性があります。 AKS は、アップグレード後にサージ ノードを削除し、元のゾーンバランスを復元します。

ゾーンのバランスを維持するには、サージを 3 つのノードの倍数に設定します。 Azure ローカル冗長ストレージ ディスクを使用する永続ボリューム要求はゾーン バインドされており、サージ ノードが別のゾーンにある場合にダウンタイムが発生する可能性があります。 ドレイン中に高可用性を維持するには、ポッド中断バジェット (PDB)を使用します。

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

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

  • 計画メンテナンス期間: トラフィックの少ない期間中に自動アップグレードをスケジュールします。 少なくとも 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: 容量の制約

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

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

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

アップグレードでは、ノードのドレイン (ポッドの削除) が必要です。 ポッドの終了が遅延する場合や、厳密な Pod Disruption Budget (PDB) によりポッドの退去が妨げられる場合、ドレインが失敗する可能性があります。

エラーの例:

Code: UpgradeFailed
Message: Drain node ... failed when evicting pod ... Cannot evict pod as it would violate the pod's disruption budget.

オプション 1: アップグレードを強制する (PDB をバイパスする)

Warnung

強制的にアップグレードすると、ポッド中断予算 (PDB) 制約がバイパスされ、すべてのポッドを同時にドレインすることでサービスの中断が発生する可能性があります。 このオプションを使用する前に、まず PDB の構成ミスを修正してみてください (PDB minAvailable/maxUnavailable 設定を確認し、適切なポッド レプリカを確認し、PDB ですべての削除がブロックされていないことを確認してください)。

強制アップグレードは、PDB が重要なアップグレードを妨げるので解決できない場合にのみ使用します。 これにより、PDB 保護がオーバーライドされ、アップグレード中にサービスが完全に使用できなくなる可能性があります。

必要条件： Azure CLI 2.79.0 以降または AKS API バージョン 2025-09-01 以降

az aks upgrade \
  --name $CLUSTER_NAME \
  --resource-group $RESOURCE_GROUP_NAME \
  --kubernetes-version $KUBERNETES_VERSION \
  --enable-force-upgrade \
  --upgrade-override-until 2023-10-01T13:00:00Z

注

  • upgrade-override-until パラメーターは、検証バイパスがいつ終了するかを定義します (将来の日付/時刻である必要があります)
  • 指定しない場合、ウィンドウは既定で現在の時刻から 3 日に設定されます
  • 'Z' は UTC/GMT タイム ゾーンを示します

Warnung

強制アップグレードを有効にすると、他のすべてのドレイン構成よりもこれが優先されます。 強制的なアップグレードがアクティブな場合、非対応ノード動作設定 (オプション 2) は適用されません。

オプション 2: 使用できないノードを処理する (PDB を優先する)

アップグレードの失敗を防ぎながら PDB を優先するには、この保守的なアプローチを使用します。

排出不能ノードの動作を設定します。

az aks nodepool update \
  --resource-group <resource-group-name> \
  --cluster-name <cluster-name> \
  --name <node-pool-name> \
  --undrainable-node-behavior Cordon \
  --max-blocked-nodes 2 \
  --drain-timeout 30

動作オプション:

  • スケジュール (既定値): ブロックされたノードを削除し、置換を急増させます
  • Cordon（推奨）: ノードを制限し、kubernetes.azure.com/upgrade-status=Quarantinedとしてラベル付けします

ブロックされた最大ノード数 (プレビュー):

  • ドレインに失敗するノードが許容される数を指定します。
  • undrainable-node-behaviorを設定する必要があります
  • 指定されていない場合は、maxSurge 値 (通常は 10%) が既定値となります。
ブロックされたノードの最大数の前提条件

  • 最大ブロック ノード機能を使用するには、Azure CLI aks-preview 拡張機能バージョン 18.0.0b9 以降が必要です。

    # Install or update the aks-preview extension
az extension add --name aks-preview
az extension update --name aks-preview
最大ブロックノードの構成例
az aks nodepool update \
  --cluster-name jizenMC1 \
  --name nodepool1 \
  --resource-group jizenTestMaxBlockedNodesRG \
  --max-surge 1 \
  --undrainable-node-behavior Cordon \
  --max-blocked-nodes 2 \
  --drain-timeout 5

ドレインエラーを防ぐための推奨事項

  • 少なくとも 1 つのポッドの削除を許可するように PDB に maxUnavailable を設定する
  • 中断許容予算の要件を満たすためにポッドレプリカを増やす
  • ワークロードにより多くの時間が必要な場合は、ドレイン タイムアウトを延長します。 (既定値は 30 分です)。
  • ステージングで PDB をテストし、アップグレード イベントを監視し、重要なワークロードにブルーグリーンデプロイを使用します。 詳細については、「 AKS クラスターのブルーグリーンデプロイ」を参照してください。
使用できないノードを確認する

  • ブロックされたノードはポッドに対してスケジュール解除され、ラベル "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. この手順を完了したら、 az aks で説明されているオプションのフィールドを指定せずに更新操作を実行することで、クラスターの状態を調整できます。 または、ノード プールを、アップグレードされたノードの数と同じ数のノードにスケーリングすることもできます。 このアクションにより、ノード プールが意図した元のサイズに到達します。 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 Container Networking Interface、高い 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 をクリーンアップし、大規模なクラスターのサブネットのサイズ設定を計画します。

よく寄せられる質問

検証にオープンソース ツールを使用できますか?

Yes. 多くのオープンソース ツールは、AKS アップグレード プロセスとうまく統合されています。

  • kube-no-trouble (kubent): アップグレード前に非推奨の API をスキャンします。
  • Trivy: コンテナー イメージと Kubernetes 構成のセキュリティ スキャン。
  • Sonobuoy: Kubernetes 準拠テストとクラスター検証。
  • kube-bench: セキュリティ ベンチマークは、Center for Internet Security 標準に対してチェックします。
  • Polaris: Kubernetes のベスト プラクティスの検証。
  • kubectl-neat: 検証のために Kubernetes マニフェストをクリーンアップします。

アップグレードする前に API の互換性を検証するにはどうすればよいですか?

kubent などのツールを使用して、非推奨チェックを実行します。

# Install and run API deprecation scanner
kubectl apply -f https://github.com/doitintl/kube-no-trouble/releases/latest/download/knt-full.yaml

# Check for deprecated APIs in your cluster
kubectl run knt --image=doitintl/knt:latest --rm -it --restart=Never -- \
  -c /kubeconfig -o json > api-deprecation-report.json

# Review findings
cat api-deprecation-report.json | jq '.[] | select(.deprecated==true)'

AKS のアップグレードが他の Kubernetes プラットフォームと異なる理由

AKS には、いくつかの固有の利点があります。

  • Azure Traffic Manager、Azure Load Balancer、およびネットワークとのネイティブ Azure 統合。
  • 調整されたマルチクラスター アップグレード用の Azure Kubernetes Fleet Manager。
  • 手動ノード管理を使用しないノード イメージの自動修正。
  • クォータ、ネットワーク、資格情報の組み込み検証機能。
  • アップグレード関連の問題に対する Azure のサポート。

アップグレード パスを選択する

この記事では、技術的な基盤を提供しました。 次に、シナリオベースのパスを選択します。

実行する準備はできましたか?

お持ちの場合... 次に、[...] に移動します。
運用環境 運用環境のアップグレード戦略: ダウンタイムなしのアップグレードのテスト済みパターン
データベースまたはステートフル アプリ ステートフル ワークロード パターン: データ永続化のための安全なアップグレード パターン
複数の環境 アップグレード シナリオ ハブ: 複雑なセットアップのデシジョン ツリー
基本的なクラスター AKS クラスターのアップグレード: クラスターのアップグレードのステップ バイ ステップ

まだ決定しますか?

「アップグレード シナリオ ハブ」を使用すると、次の要素を考慮したガイド付きデシジョン ツリーを利用できます。

  • ダウンタイムの許容範囲
  • 環境の複雑さ
  • リスク プロファイル
  • タイムラインの制約

次のタスク

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