Azure Kubernetes Service（AKS）クラスターのアップグレードで重要なのは、「どの方法で上げるか」よりも先に「アップグレード中に止まって困る要素を洗い出すこと」です。2026年5月19日に公開された公式ドキュメント更新では、AKSのアップグレードオプションそのものを大きく変える新機能というより、Force upgrade、隔離されたノードの復旧、undrainable-node-behavior など、運用時にミスしやすいコマンドや設定の説明が明確化されています。(GitHub)
本記事では、Azure Kubernetes Serviceの「Upgrade Options and Recommendations for Azure Kubernetes Service (AKS) Clusters」で何を確認すべきかを、管理者・開発者の実務目線で整理します。結論から言えば、AKSクラスターを安全にアップグレードするには、maxSurge、maxUnavailable、Pod Disruption Budget、メンテナンスウィンドウ、IPアドレス容量、API廃止予定の確認を事前にセットで見直す必要があります。(Microsoft Learn)
Azure Kubernetes Serviceのアップグレードオプションで確認すべき変更点
今回の更新で特に注目したいのは、AKSのアップグレード手順そのものよりも、障害時・例外対応時に使うコマンドの明確化です。通常のアップグレードが問題なく進む環境では影響は限定的ですが、PDBによりノードのDrainが失敗する環境や、Force upgradeを検討する環境では確認必須です。
| 変更・明確化されたポイント | 内容 | 実務上の影響 |
|---|---|---|
--upgrade-override-until の例が具体日付から形式例に変更 | yyyy-mm-ddT13:00:00Z のように、将来日時をUTCで指定する形に整理 | 古い日付をそのままコピーして失敗するリスクを減らせる |
| バリデーション回避期間の説明を明確化 | 未指定の場合は現在時刻から3日間が既定 | Force upgradeを有効にする期間を運用チーム内で説明しやすくなる |
| 隔離ノードのラベル削除コマンドを修正 | kubectl label nodes <node-name> kubernetes.azure.com/upgrade-status- を使う | Quarantined 状態のノード復旧手順で誤ったラベル名を使うリスクを減らせる |
undrainableNodeBehavior の表記をCLIパラメータに合わせて修正 | --undrainable-node-behavior として案内 | Azure CLIでそのまま使えるコマンドとして確認しやすくなる |
この変更は、AKSを使うすべての利用者に即時の移行作業を求めるものではありません。ただし、アップグレード手順書や運用Runbookに該当コマンドを貼り付けている場合は、古い記述が残っていないか確認してください。特に、障害対応手順に古いラベル削除コマンドが残っていると、ノード復旧時に原因切り分けが長引く可能性があります。
対象者はAKS管理者だけではない
AKSのアップグレードは、Azure管理者だけで完結しません。ノードのDrain、Podの再配置、APIバージョンの変更、PDBの設定は、アプリケーション開発者やSREにも直接関係します。AKSのアップグレードではワーカーノードのローリング更新が行われ、Node DrainとPod Evictionにより、一時的なアプリケーション影響が発生する可能性があります。(Microsoft Learn)
| 対象者 | 確認すべきこと | 見落とすと起きやすい問題 |
|---|---|---|
| Azure管理者 | AKSのバージョン、ノードプール、サブネットIP、クォータ、メンテナンスウィンドウ | アップグレード開始後に容量不足やIP不足で停止する |
| Kubernetes管理者 / SRE | maxSurge、maxUnavailable、PDB、Drain timeout、Node soak time | Drain失敗、アップグレード長時間化、Podの同時停止 |
| アプリケーション開発者 | 廃止予定API、Deploymentのレプリカ数、Readiness Probe、StatefulSetの挙動 | アップグレード後にマニフェスト適用やPod再起動で失敗する |
| セキュリティ担当 | サポート期限、API breaking changes、ノードOSパッチ、脆弱性対応 | サポート外バージョンや未適用パッチを放置する |
| ネットワーク担当 | Azure CNI、maxPods、サブネットサイズ、Load Balancer関連リソース | Surgeノード作成時にIPが足りずアップグレードが失敗する |
実務では、「Azure側のアップグレード予定日」だけを共有しても不十分です。アプリ担当には「どのPodが退避されるか」「PDBで退避を妨げていないか」「廃止予定APIを使っていないか」まで確認してもらう必要があります。
AKSのアップグレードは手動と自動を使い分ける
公式ドキュメントでは、AKSクラスターのアップグレード方法として、手動アップグレードと自動アップグレードが整理されています。手動アップグレードは実行タイミングや対象バージョンを細かく制御したい場合に向き、自動アップグレードはサポート中バージョンを維持しやすくするための選択肢です。(Microsoft Learn)
| 方式 | 向いているケース | 注意点 |
|---|---|---|
| 手動アップグレード | 本番環境、厳密な変更管理がある環境、事前検証を段階的に行いたい環境 | 作業計画、検証、ロールバック方針を自分たちで管理する必要がある |
| 自動アップグレード | 開発・検証環境、標準化された複数環境、サポート外バージョンを避けたい環境 | メンテナンスウィンドウやPDBを適切に設定しないと、想定外の時間帯に影響が出る可能性がある |
| Azure Kubernetes Fleet Managerによる複数クラスター更新 | 複数のAKSクラスターを段階的に管理したい場合 | クラスターごとの依存関係やアプリ影響を別途整理する必要がある |
| ノードプール単位のアップグレード | Windowsノード、GPUノード、特定ワークロード用ノードプールがある環境 | コントロールプレーンとノードプールのバージョン差に注意する |
自動アップグレードでは、コントロールプレーンが先に更新され、その後にエージェントプールが順番に更新されます。また、自動アップグレードを使っている場合、コントロールプレーンだけを先にアップグレードしてノードプールを個別に後回しにする運用はできません。(Microsoft Learn)
本番環境では、いきなり自動アップグレードを有効化するよりも、まず検証環境で同じPDB、同じmaxSurge、同じノードプール構成を再現して、アップグレード時間とアプリ影響を測るのが安全です。
Force upgradeは「最後の手段」として扱う
今回の更新で最も注意したいのが、Force upgradeまわりの記述です。Force upgradeは、Pod Disruption Budget（PDB）の制約をバイパスできる一方、Podが同時にDrainされ、サービス停止につながる可能性があります。公式ドキュメントでも、まずPDBの設定やレプリカ数を修正し、それでも重要なアップグレードを進める必要がある場合に限って使うべき選択肢として説明されています。(Microsoft Learn)
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 は、バリデーション回避をいつまで有効にするかを指定するパラメータです。値は将来日時である必要があり、Z はUTCを意味します。指定しない場合、既定では現在時刻から3日間のウィンドウになります。(Microsoft Learn)
ここで重要なのは、Force upgradeを「PDBエラーを無視する便利なオプション」として扱わないことです。PDBが退避を妨げているということは、アプリケーション側が「このPodはこれ以上落とせない」と宣言している状態です。Force upgradeで強制的に進める前に、次の順番で確認してください。
| 確認項目 | 判断基準 |
|---|---|
PDBのminAvailableが厳しすぎないか | レプリカ数2なのにminAvailable: 2など、1Podも退避できない設定になっていないか |
maxUnavailableを設定できるか | 重要サービスでも、最低1Podの退避を許容できる構成にできないか |
| レプリカ数を一時的に増やせるか | アップグレード前にHPAやDeploymentのreplicasを増やして退避余地を作れるか |
| メンテナンス時間帯を調整できるか | Force upgradeよりも、低トラフィック時間帯で通常Drainを待てないか |
| 事前にステージングで再現したか | 本番で初めてForce upgradeを実行していないか |
DrainできないノードはCordonで隔離する選択肢がある
PDBを尊重しながらアップグレード失敗を避けたい場合は、--undrainable-node-behavior を使う選択肢があります。公式ドキュメントでは、Drainできないノードの扱いとして、既定のScheduleと推奨されるCordonが説明されています。Cordonを使うと、対象ノードはスケジュール対象外になり、kubernetes.azure.com/upgrade-status=Quarantined というラベルが付与されます。(Microsoft Learn)
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隔離されたノードを確認するには、次のようにノードのラベルを表示します。
kubectl get nodes --show-labels=truePDBを修正し、ノードを復旧させる場合は、原因となったPDBを見直したうえで、必要に応じて次のコマンドで隔離ラベルを削除します。
kubectl label nodes <node-name> kubernetes.azure.com/upgrade-status-5月19日の更新では、このラベル削除コマンドが正しい形式に修正されています。運用手順書で<label-name>のような抽象的な記述を使っている場合、障害時に迷わないよう、実際のラベル名を明記しておくと安全です。(GitHub)
なお、Force upgradeを有効にした場合、Drain関連の他の設定よりもForce upgradeが優先されます。つまり、PDBを尊重したい場合にForce upgradeを併用するのは矛盾した運用になりやすいため、どちらの方針で進めるかを事前に決めてください。(Microsoft Learn)
maxSurgeとmaxUnavailableは速度と安定性のバランスを決める
AKSのアップグレードでよくある失敗は、maxSurgeを上げすぎて容量やIPが足りなくなるケースと、逆に保守的にしすぎてアップグレードが長時間化するケースです。
公式ドキュメントでは、本番環境ではmaxSurge=33%、maxUnavailable=1、開発・検証環境ではmaxSurge=50%、maxUnavailable=2が例として示されています。ただし、これはすべての環境にそのまま適用できる絶対値ではありません。ノード数、サブネットサイズ、PDB、可用性要件を見て調整する必要があります。(Microsoft Learn)
| 設定 | 役割 | 向いている状況 | 注意点 |
|---|---|---|---|
maxSurge | 一時的に追加ノードを作ってアップグレードを進める | 余剰クォータとIPアドレスがある環境 | GPUなど特殊SKUやIP不足の環境では失敗しやすい |
maxUnavailable | 既存ノードを一部利用不可にして進める | 追加ノードを作る余力が少ない環境 | 同時に落ちるPod数をPDBと合わせて慎重に見る |
drain-timeout | Pod退避を待つ時間を調整する | 停止処理に時間がかかるアプリがある環境 | 長くしすぎると全体のアップグレード時間が伸びる |
| Node soak time | ノード更新間の待機時間を設ける | 段階的に影響を観察したい本番環境 | 既定は0分のため、必要なら明示的に設計する |
ポイントは、maxSurgeだけを見ないことです。たとえば、10ノード構成でmaxSurge=50%にすると、最大5台分の追加ノードを作る余地が必要になります。Azure CNIを使っていてmaxPodsが大きい場合、ノード用IPだけでなくPod用IPも考慮しなければなりません。
IP不足はアップグレード失敗の典型原因
Surgeノードを作るアップグレードでは、追加ノードとPodに使うIPアドレスが必要です。公式ドキュメントでは、必要IP数の考え方として Total IPs = (Number of nodes + maxSurge) * (1 + maxPods) が示されています。(Microsoft Learn)
たとえば、現在20ノード、maxPods=30、maxSurge=5の場合、単純計算では次のようになります。
(20 + 5) * (1 + 30) = 775 IPこの規模のクラスターを小さなサブネットで運用していると、アップグレード時にSubnetIsFullのようなエラーで止まる可能性があります。対策としては、アップグレード前にサブネットを拡張する、未使用IPを整理する、maxSurgeを下げる、必要に応じてmaxUnavailableを使う、といった選択肢があります。
IP不足は、平常時には気づきにくい問題です。アプリが動いているから問題ないと判断せず、アップグレード時の追加容量まで含めて確認してください。
可用性ゾーンをまたぐノードプールではSurge数に注意する
複数の可用性ゾーンにまたがるノードプールでは、アップグレード中のSurgeノードがどのゾーンに作成されるかを事前に完全には予測できません。AKSはアップグレード後にSurgeノードを削除して元のゾーンバランスを復元しますが、アップグレード中は一時的にゾーン間のバランスが崩れる可能性があります。(Microsoft Learn)
公式ドキュメントでは、ゾーンバランスを保つためにSurgeを3の倍数にすることが推奨されています。また、Azure Locally Redundant Storageのディスクを使うPersistent Volume Claimはゾーンに紐づくため、Surgeノードが別ゾーンに作られるとステートフルワークロードで影響が出る可能性があります。(Microsoft Learn)
ステートフルアプリケーションでは、次の点を事前に確認してください。
- Persistent Volumeがどのゾーンに紐づいているか
- StatefulSetのPodが再スケジュールされた場合にボリューム再アタッチが問題なく行われるか
- PDBが厳しすぎてDrainを妨げていないか
- ノードプールをゾーン別に分けるべきか
- ブルーグリーンデプロイや新クラスター移行のほうが安全ではないか
Planned Maintenanceは自動アップグレードの必須設定として考える
自動アップグレードを使う場合、AKS Planned Maintenanceを組み合わせることで、アップグレードやノードOS更新の実行タイミングを制御できます。公式ドキュメントでは、クラスターのKubernetesバージョンアップグレードにはaksManagedAutoUpgradeSchedule、ノードOSセキュリティパッチにはaksManagedNodeOSUpgradeScheduleを使うことが推奨されています。(Microsoft Learn)
また、自動アップグレードで正しく機能させるため、メンテナンスウィンドウは4時間以上にすることが推奨されています。(Microsoft Learn)
az aks maintenanceconfiguration add \
--resource-group $RESOURCE_GROUP \
--cluster-name $CLUSTER_NAME \
--name aksManagedAutoUpgradeSchedule \
--config-file ./autoUpgradeWindow.jsonただし、Planned Maintenanceは「その時間帯以外は絶対にメンテナンスが走らない」という保証ではありません。緊急または重要なリアクティブメンテナンスでは、定義したメンテナンスウィンドウや除外期間を外れて実行される可能性があると説明されています。(Microsoft Learn)
つまり、Planned Maintenanceは影響を下げるための制御であり、唯一の安全策ではありません。PDB、レプリカ数、Readiness Probe、監視、アラートを合わせて整備する必要があります。
アップグレード前に必ず確認すべきバリデーション項目
AKSはアップグレード前に複数の検証を実行します。公式ドキュメントでは、API breaking changes、Kubernetesバージョンのアップグレードパス、PDB設定、クォータ、サブネット、証明書やサービスプリンシパル、マネージドリソースグループのリソースロックなどが検証対象として挙げられています。(Microsoft Learn)
| 確認項目 | 実務での確認方法 | 対応の考え方 |
|---|---|---|
| API breaking changes | 廃止予定APIの利用状況を確認 | マニフェストを新しいAPIバージョンへ移行する |
| アップグレードパス | 現在バージョンと対象バージョンを確認 | マイナーバージョンを飛ばさない計画にする |
| PDB | kubectl get pdb -A で確認 | 1Podも退避できない設定を避ける |
| Azureクォータ | VM SKU、vCPU、GPUなどを確認 | Surgeノード分の余力を確保する |
| サブネットIP | ノード数、maxSurge、maxPodsから計算 | IP不足ならサブネット拡張または設定変更を行う |
| 証明書・サービスプリンシパル | 期限切れや認証情報の状態を確認 | アップグレード前に更新する |
| リソースロック | マネージドリソースグループのロックを確認 | AKSが必要なリソースを変更できる状態にする |
特に見落とされやすいのは、マネージドリソースグループのロックです。Azure運用では誤削除防止のためにロックを設定することがありますが、AKSアップグレードではAKSが管理対象リソースを変更できる必要があります。手順書には、AKSクラスター本体だけでなく、マネージドリソースグループのロック確認も入れておくと安全です。
廃止予定APIは開発者側で先に直す
AKSアップグレードでは、Kubernetes APIの変更がアプリケーションに影響することがあります。公式FAQでは、AKSがアップグレード開始前の12時間に非推奨APIの使用状況を検証し、該当APIの使用が見つかるとアップグレードをブロックする場合があると説明されています。(Microsoft Learn)
開発者側では、次のようなマニフェストを確認してください。
kubectl get all -A
kubectl get ingress -A -o yaml
kubectl get pdb -A -o yaml
kubectl get cronjob -A -o yamlCI/CDでKubernetesマニフェストを管理している場合は、クラスター内の実リソースだけでなく、Gitリポジトリ内のYAML、Helm chart、Kustomize、Terraformで生成されるマニフェストも確認対象です。
特に注意したいのは、普段は変更しない古いIngress、CronJob、PodSecurityPolicy相当の設定、古いAPIバージョンを含むCRDです。AKSのアップグレード作業日に初めて発見すると、クラウド管理者とアプリ開発者の間で責任分界が曖昧になり、復旧が遅れます。
なお、AKSではKubernetes 1.30および1.27 LTS以降でBeta APIが既定で無効化される旨もFAQで説明されています。対象バージョンへ進む場合は、Beta API依存がないかも確認してください。(Microsoft Learn)
サポート外バージョンからの復旧は「新クラスター移行」も検討する
AKSクラスターがかなり古いバージョンやサポート外バージョンになっている場合、単純にアップグレードを何段階も繰り返すより、新しいクラスターを作成してワークロードを移行するほうが安全な場合があります。公式FAQでも、サポート外または大きく古いAKSクラスターでは、サポートされるKubernetesバージョンの新クラスターを作り、ワークロードを移行し、複数バージョンをまたぐアップグレードを避けることが推奨されています。(Microsoft Learn)
判断基準は次のとおりです。
| 状況 | 推奨される方針 |
|---|---|
| 1マイナーバージョン程度の差で、PDBやAPI移行も整理済み | 既存クラスターを段階的にアップグレード |
| 複数マイナーバージョン遅れている | 新クラスター移行を含めて比較 |
| マニフェストが古く、API移行が多い | 新クラスターで検証しながら移行 |
| ステートフルワークロードが多い | データバックアップ、復旧手順、段階移行を優先 |
| 本番停止が許容できない | ブルーグリーン、カナリア、Fleet Managerなどを検討 |
古いクラスターほど、アップグレード作業は「Azureのバージョンを上げる作業」ではなく、「アプリケーション基盤を作り直す作業」に近づきます。作業時間だけで判断せず、トラブル時の復旧可能性まで含めて計画してください。
実務で使えるAKSアップグレード前チェックリスト
AKSのアップグレード前には、次の順番で確認すると抜け漏れを減らせます。
| 順番 | 確認内容 | 具体的なアクション |
|---|---|---|
| 1 | 現在のAKSバージョンと対象バージョン | az aks show やAzureポータルで確認 |
| 2 | サポート中バージョンか | サポート外なら新クラスター移行も検討 |
| 3 | 廃止予定API | kubentなどのツールやマニフェストレビューで確認 |
| 4 | PDB | maxUnavailable=0や厳しすぎるminAvailableを修正 |
| 5 | レプリカ数 | 重要アプリは最低2以上、可能ならゾーン分散 |
| 6 | maxSurge / maxUnavailable | 容量と可用性のバランスで調整 |
| 7 | サブネットIP | SurgeノードとPod分まで計算 |
| 8 | Azureクォータ | VM、vCPU、GPU、特殊SKUを確認 |
| 9 | メンテナンスウィンドウ | 低トラフィック時間帯に4時間以上を確保 |
| 10 | 監視と通知 | Azure Monitor、アラート、AKS Communication Managerを確認 |
| 11 | 復旧手順 | 隔離ノード、PDB削除、スケール復旧、Runbookを確認 |
| 12 | ステージング検証 | 本番と同じ設定でアップグレードをリハーサル |
チェックリストの中でも、PDB、IP、クォータはトラブルの原因になりやすい項目です。アップグレード当日に確認するのではなく、少なくとも事前検証の段階で数値として確認してください。
開発者が確認すべきアプリケーション側のポイント
AKSのアップグレードでは、インフラ担当が成功しても、アプリケーション側の設計が不十分だとユーザー影響が出ます。開発者は次の点を確認してください。
Deploymentは退避を前提に設計する
1Pod構成のアプリは、ノードDrain時に一時停止しやすくなります。重要なWeb APIやバックエンドサービスは、レプリカ数、HPA、PDB、Readiness Probeをセットで確認してください。
悪い例です。
replicas: 1本番で可用性が必要な場合は、最低でも複数レプリカを検討します。
replicas: 3ただし、レプリカ数だけを増やしても、PDBが厳しすぎるとDrainできません。レプリカ数3であれば、たとえば次のように1Podの停止を許容する設計を検討します。
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
name: web-pdb
spec:
maxUnavailable: 1
selector:
matchLabels:
app: webReadiness Probeで「受け入れ可能なPod」だけに通信させる
アップグレード中はPodが別ノードで再起動することがあります。起動直後にまだDB接続やキャッシュ初期化が終わっていないPodへ通信が流れると、短時間のエラーが増えます。
Readiness Probeは、単にPodが起動したかではなく、実際にリクエストを処理できる状態かを判定するように設計してください。
StatefulSetはデータ保護を先に確認する
StatefulSetのPodもアップグレード中に退避・再スケジュールされます。CSIドライバーによりPersistent Volumeの再アタッチが行われるとはいえ、アプリケーションの停止許容時間、バックアップ、復旧手順は別途確認が必要です。(Microsoft Learn)
DB、メッセージキュー、検索エンジンなどをAKS上で動かしている場合は、アップグレード手順の前に、スナップショット、バックアップ、復元テスト、Pod再配置時の整合性を確認してください。
管理者向けの安全な展開手順
本番AKSクラスターをアップグレードする場合は、次の流れで進めると安全です。
事前調査
まず、現在のクラスター状態を把握します。
az aks show \
--resource-group <resource-group-name> \
--name <cluster-name> \
--query "{kubernetesVersion:kubernetesVersion,provisioningState:provisioningState}"
kubectl get nodes -o wide
kubectl get pods -A -o wide
kubectl get pdb -Aこの段階で、ノードプールごとのOS、SKU、ノード数、Pod配置、PDBを確認します。
ステージングで同じ設定を検証
ステージング環境が本番と大きく違うと、検証の意味が薄れます。最低限、次の設定は本番に近づけてください。
- ノードプール数
maxSurgemaxUnavailable- PDB
- 主要アプリのレプリカ数
- Azure CNIや
maxPods - メンテナンスウィンドウ
- 監視とアラート
ステージングでDrain失敗やIP不足が起きた場合、本番でも同じ問題が起きる可能性が高いです。
本番のメンテナンスウィンドウを設定
自動アップグレードを使う場合は、aksManagedAutoUpgradeScheduleを設定します。ノードOS更新も管理する場合は、aksManagedNodeOSUpgradeScheduleも分けて設定します。(Microsoft Learn)
az aks maintenanceconfiguration list \
--resource-group <resource-group-name> \
--cluster-name <cluster-name>既存のメンテナンスウィンドウがある場合、チームの運用時間、バッチ処理、バックアップ時間、リリース時間と重ならないか確認します。
アップグレード中はイベントとPod状態を見る
アップグレード実行中は、Azureポータルだけでなく、Kubernetes側のイベントも確認します。
kubectl get nodes
kubectl get pods -A
kubectl get events -A --sort-by=.lastTimestampDrain失敗が出た場合は、まずPDBと対象Podを確認します。いきなりForce upgradeへ進まず、PDB修正、レプリカ追加、Drain timeout調整、--undrainable-node-behavior Cordonの利用を検討してください。
アップグレード後の確認
アップグレード後は、バージョンだけでなく、アプリケーションの健全性を確認します。
kubectl get nodes
kubectl get pods -A
kubectl get pdb -A
kubectl get deployments -A次の状態が残っていないかも確認します。
NotReadyのノードCrashLoopBackOffのPodPendingのPodQuarantinedラベルが残ったノード- スケール数が一時対応のまま戻っていないDeployment
- 一時的に緩和したPDBが戻っていない状態
アップグレード後に「動いているように見える」だけで完了にしないことが大切です。メトリクス、ログ、エラーレート、レイテンシ、外形監視まで確認してから完了判断を行いましょう。
失敗しやすいポイントと対策
AKSアップグレードで失敗しやすいポイントは、公式ドキュメントでもシナリオとして整理されています。特に、容量制約、Node Drain失敗、アップグレードの長時間化、IP枯渇は代表的なトラブルです。(Microsoft Learn)
| 失敗しやすいポイント | 典型的な症状 | 対策 |
|---|---|---|
| 容量不足 | SKUNotAvailable、AllocationFailed、OverconstrainedAllocationRequest | maxSurgeを下げる、maxUnavailableを使う、別SKUや別リージョンを検討 |
| PDBによるDrain失敗 | Cannot evict pod as it would violate the pod's disruption budget | PDBを緩和、レプリカ数を増やす、Drain timeoutを延長 |
| アップグレード長時間化 | ノード更新が進まない、メンテナンス時間を超える | maxSurge、maxUnavailable、Node soak timeを見直す |
| IP枯渇 | SubnetIsFull、PodがPending | サブネット拡張、未使用IP整理、maxSurgeを下げる |
| ゾーン偏り | 特定ゾーンにPodが偏る、一時的な可用性低下 | Surgeを3の倍数にする、PDBとゾーン分散を確認 |
| 古いAPI | アップグレード前検証でブロック | マニフェスト、Helm chart、CRDを事前修正 |
| リソースロック | AKSが管理リソースを変更できない | マネージドリソースグループのロックを確認 |
トラブル対応で重要なのは、アップグレード中の問題を「AKSの不具合」と決めつけないことです。実際には、PDB、IP設計、クォータ、古いAPI、運用Runbookの誤記が原因になることが多くあります。
まとめ：次にやるべきこと
Azure Kubernetes Serviceの「Upgrade Options and Recommendations for Azure Kubernetes Service (AKS) Clusters」の更新は、AKSアップグレード運用をより実践的に整理する内容です。2026年5月19日の更新では、Force upgradeの日時指定、隔離ノードのラベル削除、--undrainable-node-behaviorの表記など、障害対応時にミスしやすい箇所が明確化されました。(GitHub)
まずやるべきことは、現在の運用手順書に古いコマンドが残っていないか確認することです。次に、AKSクラスターごとにmaxSurge、maxUnavailable、PDB、メンテナンスウィンドウ、サブネットIP、廃止予定APIを棚卸ししてください。
本番アップグレードでは、Force upgradeに頼るのではなく、PDBとレプリカ数を整え、ステージングで検証し、メンテナンスウィンドウと監視を準備したうえで実行するのが基本です。AKSのアップグレードは一度の作業ではなく、継続的に安全性を維持する運用プロセスとして管理しましょう。
コメント