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

適用対象: ✔️ AKS 自動 ✔️ AKS Standard

ほとんどの運用ワークロードでは、AKS Automatic が推奨される既定のクラスターエクスペリエンスです。管理されたアップグレード動作、組み込みのセーフガード、運用オーバーヘッドの削減など、クラスターとノードのライフサイクル操作に対して運用対応の既定値が提供されます。

AKS Standard は、アップグレードのしくみ、ネットワークの選択、またはノードプールの動作をより詳細に手動で制御する必要があるシナリオで引き続き使用できます。

この記事では、アップグレードオプション、一般的なシナリオ、AKS Automatic と AKS Standard の両方の推奨事項を取り上げて、AKS アップグレードの技術的基盤を提供します。

この記事の内容

このテクニカルリファレンスでは、次の内容について説明します。

AKS Automatic が、ほとんどのワークロードに推奨される運用環境対応の既定値である理由。
AKS Automatic と AKS Standard のアップグレード動作の違い。
手動アップグレードパスと自動アップグレードパス、および各パスを使用するタイミング。
特定の推奨事項を含む一般的なアップグレードシナリオ。
パフォーマンスと中断を最小限に抑える最適化手法。
検証プロセスとアップグレード前のチェック。

関連するガイダンスについては、次の手順に従います。

AKS 自動の概要と既定値については、「Azure Kubernetes Service (AKS)自動の概要」を参照してください。
運用指向の AKS アップグレード戦略の詳細については、 AKS の運用アップグレード戦略に関するページを参照してください。
ステートフルワークロードのアップグレードパターンについては、「ステートフルワークロードのアップグレードパターン」を参照してください。
シナリオ主導のガイダンスについては、「 AKS アップグレードシナリオ: パスを選択する」を参照してください。
AKS のアップグレードを初めて使用する場合は、ガイド付きサポートのためにアップグレードシナリオハブから始めてください。

あなたの状況	推奨パス
特別なカスタマイズ要件のない新規または既存の運用ワークロード	AKS 自動クラスターを作成する
厳密なカスタムアップグレード制御を使用した運用クラスター	運用アップグレード戦略
データベースまたはステートフルワークロード	ステートフルワークロードパターン
AKS Standard の初回アップグレード	基本的な AKS クラスターのアップグレード
複数の環境またはフリート運用	アップグレードシナリオハブ
AKS Standard のノードプールまたはWindows ノード	ノードプールのアップグレード
特定のノードプールのみ	単一ノードプールのアップグレード

オペレーティングモデルのアップグレード

AKS 自動 (推奨される運用環境の既定値)

AKS Automatic は、既定で運用環境に対応した操作用に設計されています。アップグレードの場合、AKS Automatic では次の機能が提供されます。

マネージドシステムノードプール。
プラットフォームで管理される既定値を使用したクラスターの自動アップグレード動作。
セキュリティに重点を置いた周期でのノード OS イメージの自動アップグレード動作。
非推奨の Kubernetes API の組み込みチェック。
計画メンテナンススケジュール対応。

手動アップグレードオーケストレーションを最小限に抑え、運用クラスターをサポートされているバージョンに合わせて維持する場合は、AKS Automatic を使用します。

AKS Standard (高度な制御モデル)

AKS Standard では、アップグレードのシーケンス処理とチューニングを直接制御できます。選択と管理を行います:

手動または自動のアップグレード構成。
更新チャネルの選択。
ノードプールとサージ動作。
メンテナンス期間とワークロード中断予算に関する運用手順。

環境で AKS 自動既定値を超えるカスタマイズが必要な場合は、AKS Standard を使用します。

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

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

主に AKS Standard または特殊な運用ワークフローに適用されます。

手動アップグレードを使用すると、クラスターを新しい Kubernetes バージョンにアップグレードするタイミングを制御できます。これらのアップグレードは、テスト、段階的なロールアウト、およびターゲットバージョンの導入に役立ちます。

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

AKS Standard の場合、自動アップグレードは、ポリシーとスケジュールの制御を維持しながら、サポートされているバージョンでクラスターを維持するのに役立ちます。 AKS Automatic では、アップグレード自動化とガードレールは既に既定の運用モデルの一部です。

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

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

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

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

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

AKS Automatic

AKS 自動では、プラットフォームレベルのアップグレード動作が事前に構成されています。ワークロードの回復性と容量の準備にチューニングを集中します。

ポッド中断の予算とレプリカ数を検証します。
予想される増加に備え、クォータとサブネットの容量を確保します。
トラフィックの少ない期間に合わせて計画メンテナンススケジュールを設定します。
アップグレードイベントと重要なワークロードの準備状況を監視します。

AKS Standard

AKS Standard では、アップグレードコントロールを直接調整します。

計画メンテナンス期間: トラフィックの少ない期間中に自動アップグレードをスケジュールします。少なくとも 4 時間を使用します。
最大サージ: 値が大きいほどアップグレードが高速化されますが、ワークロードが中断される可能性があります。運用環境には 33% を使用します。
最大使用不可: 容量が制限されている場合に使用します。
ポッド停止制限: アップグレード中にポッドの停止を制限するように設定します。サービスを検証します。
ノードドレインタイムアウト: ポッドの削除の待機時間を構成します。既定値は 30 分です。
ノードのソーク時間: アップグレードをずらしてダウンタイムを最小限に抑えます。既定値は、0 分です。

アップグレード設定	追加ノードの使用方法	予想される動作
`maxSurge=5`、`maxUnavailable=0`	5 つのサージノード	アップグレードのために 5 つのノードが急増します。
`maxSurge=5`、`maxUnavailable=0`	0-4 個のサージノード	サージノードが不足しているため、アップグレードが失敗します。
`maxSurge=0`、`maxUnavailable=5`	N/A	アップグレードのために、既存の 5 つのノードがドレインされます。

注

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

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

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

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

これらのチェックは、AKS 全体に適用されます。 AKS Automatic では、管理されたアップグレードパスに統合されます。AKS Standard では、これらは運用ワークフローの一部です。

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

シナリオ 1: 容量の制約

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

AKS 自動ガイダンス

計画メンテナンス期間を維持します。
想定されるアップグレード時期の前に、サブスクリプションのクォータとサブネットの余裕を確認してください。
ワークロードのスケーリングと中断の予算をメンテナンス期間に合わせて維持します。

AKS Standard ガイダンス

maxUnavailableを使用して、新しいノードを急増させる代わりに、既存のノードを使用してアップグレードします。詳細については、「アップグレード中に使用できないノードをカスタマイズする」を参照してください。
maxSurgeを小さくして、追加の容量ニーズを削減します。詳細については、「ノードサージアップグレードのカスタマイズ」を参照してください。
セキュリティのみの更新プログラムの場合は、サージノードを必要としないセキュリティパッチの再イメージ化を使用します。詳細については、「 Azure Kubernetes Service の Linux ノードにセキュリティ更新プログラムとカーネル更新プログラムを適用する」を参照してください。

シナリオ 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.

AKS 自動ガイダンス

PDB とレプリカの戦略を主要な信頼性コントロールとして扱います。
運用環境のロールアウトの前に、ステージングでの中断予算を検証します。
重要なワークロードがローリング退避に正常に対応できるよう構成しておきます。

AKS Standard ガイダンス

オプション 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 yyyy-mm-ddT13: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

動作オプション:

スケジュール (既定): ブロックされたノードを削除し、置き換えノードを追加で起動します。
コードン (推奨): コードンノードと 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

オプション 3: PDB の自動管理 (プレビュー)

PDB の自動管理拡張機能を使用して、PDB 保護をバイパスしたり、検疫済みノードを手動でクリーンアップしたりする必要なく、PDB でブロックされたドレインを事前に解決します。 PDB の自動管理は、PDB が切断されたノードでの削除をブロックし、中断予算が満たされるようにデプロイのレプリカを一時的にスケールアップするタイミングを検出します。ドレインが完了すると、レプリカは元の数にスケールバックされます。

自動 PDB 管理では、PDB がないデプロイ用の PDB を自動的に作成して、アップグレードのドレイン中にワークロードを確実に保護することもできます。インストールと構成の詳細については、「 AKS のアップグレード中にポッド中断予算を自動的に管理する」を参照してください。

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

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

使用できないノードを確認する

ブロックされたノードはポッドに対してスケジュール解除され、ラベル "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> kubernetes.azure.com/upgrade-status-
```

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

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

この手順を完了したら、 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値が低い (並列処理が制限されます)。
待機時間が長い (ノードのアップグレード間の長い待機時間)。
ドレインエラー ( ノードドレイン障害を参照)。

AKS 自動ガイダンス

メンテナンススケジュールを最新の状態に保ちます。
アップグレードイベントの正常性とワークロードの準備状況を監視します。
遅延が長くなるのを防ぐために、PDB または容量の問題のブロックを迅速に解決します。

AKS Standard ガイダンス

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

シナリオ 4: IP 枯渇

サージノードには、より多くの IP が必要です。サブネットの容量が近い場合、ノードのプロビジョニングが失敗する可能性があります (たとえば、 Error: SubnetIsFull)。このシナリオは、Azure Container Networking Interface、高い maxPods、または大規模なノード数で一般的です。

AKS 自動ガイダンス

運用環境を拡張する前に、サブネットと容量の計画を検証します。
定期的な操作の一部としてネットワーク使用率を監視します。

AKS Standard ガイダンス

サブネットに、すべてのノード、サージノード、ポッドに十分な 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 Automatic または AKS Standard を使用する必要がありますか?

ほとんどの運用ワークロードでは、AKS Automatic を使用します。これは、マネージドアップグレード動作と組み込みのガードレールを備えた運用環境対応の既定値として設計されています。

アップグレードシーケンス、インフラストラクチャの選択、またはノードプールの操作を高度に手動で制御する必要がある場合は、AKS Standard を使用します。

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

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

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 には、いくつかの固有の利点があります。

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

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

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

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

お持ちの場合...	次に、[...] に移動します。
本番ワークロード、かつ特別なカスタマイズ要件なし	AKS 自動クラスターを作成する
高度なカスタムアップグレードニーズを備えた運用環境	運用アップグレード戦略
データベースまたはステートフルアプリ	ステートフルワークロードパターン
複数の環境	アップグレードシナリオハブ
基本的な AKS Standard クラスター	AKS クラスターをアップグレードする

まだ決定しますか?

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

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

最終的な推奨事項

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

フィードバック

このページはお役に立ちましたか?

Last updated on 2026-06-24

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

この記事の内容

クイック ナビゲーション

オペレーティング モデルのアップグレード

AKS 自動 (推奨される運用環境の既定値)

AKS Standard (高度な制御モデル)

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

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

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

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

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

AKS Automatic

AKS Standard

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

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

シナリオ 1: 容量の制約

AKS 自動ガイダンス

AKS Standard ガイダンス

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

AKS 自動ガイダンス

AKS Standard ガイダンス

オプション 1: アップグレードの強制、PDB 制約のバイパス

オプション 2: PDB を受け入れながら、使用できないノードを処理する

ブロックされたノードの最大数の前提条件

最大ブロックノードの構成例

オプション 3: PDB の自動管理 (プレビュー)

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

使用できないノードを確認する

使用できないノードを解決する

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

AKS 自動ガイダンス

AKS Standard ガイダンス

シナリオ 4: IP 枯渇

AKS 自動ガイダンス

AKS Standard ガイダンス

よく寄せられる質問

運用環境のアップグレードに AKS Automatic または AKS Standard を使用する必要がありますか?

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

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

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

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

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

まだ決定しますか?

最終的な推奨事項

フィードバック

その他のリソース

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

クイックナビゲーション

オペレーティングモデルのアップグレード

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

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

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

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

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

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

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