Azure Kubernetes Service (AKS) のクラスターを削除しようとしたら、いつまで経っても削除が終わらず、VNet やサブネットを消してしまったせいで状態が Failed のまま固まる──そんな「沼」にハマると、リソース グループの整理も進まず非常にストレスです。本記事では、実際に発生した「DNCCleanupServiceError により AKS クラスターが削除できない」事例をベースに、原因の整理から自力で試せる対処、最終的に Azure サポートへエスカレーションすべきポイント、再発防止策までを詳しく解説します。
AKS クラスターが削除できない障害の全体像
今回のケースでは、未使用になった AKS クラスターを整理しようとして、以下のような状況に陥りました。
- クラスター削除時に以下のようなエラーが表示される。
DNCCleanupServiceError: Failed to clean up pod networking resources.OperationNotAllowed: Cannot run operation because deletion has been initiated on the cluster.
- VNet／サブネット／Public IP／MC_ リソース グループ内のリソースを、すでに手動で削除済み。
az aks delete --yes --no-waitや REST API で削除要求を出しても、ProvisioningState は Failed のまま変化なし。- ノードプールは UI／CLI 上は残っているが、削除しようとしても「既に削除処理が走っている」といった趣旨のエラーで拒否される。
まとめると、「クラスターは削除中のつもりだが、ネットワーク周りのクリーンアップに失敗し、Failed 状態で固まっている」「その結果、ユーザー側からは削除やノードプール操作を行えない」という非常にやっかいな状態です。
| 現象 | 典型的なメッセージ | ユーザー側の感触 |
|---|---|---|
| 削除中に失敗 | DNCCleanupServiceError | 「ネットワーク周りの後始末に失敗しているらしい…」 |
| 再削除できない | OperationNotAllowed | 「削除は始まっていると言われるが、終わる気配がない」 |
| ノードプール操作不能 | 操作は常に失敗 | 「何をしてもクラスタの状態が変わらない」 |
まずは、この状態に陥ったときに「自力でできること」と「自力ではどうにもならない領域」を切り分けることが重要です。
AKS 削除エラーの背景：DNC とネットワーク依存関係
今回のキーワードとなるのが DNC (Dynamic Network Controller) です。AKS では、ポッド用 IP アドレスの割り当てや解放、VNet との接続など、ネットワークまわりの制御を DNC コンポーネントが担っています。
クラスター削除の裏側では、概ね次のような流れで処理が行われます。
- AKS コントロールプレーンが「クラスター削除」を受付。
- DNC に対して「ポッド ネットワークを解放せよ」という要求が飛ぶ。
- DNC が VNet／サブネット／NIC／ロードバランサーなどのリソースをクリーンアップ。
- ネットワークリソースが正常に解放されたことを確認してから、MC_ リソース グループやマネージド リソースの削除に進む。
ところが、ユーザーが先に VNet やサブネットを手動で削除してしまうと、DNC は「存在するはずのネットワークリソースにアクセスできない」状態となり、ポッドネットワークのクリーンアップに失敗します。その結果、
- クラスターの ProvisioningState は Failed に遷移。
- 内部的には「削除中」の状態が続いている扱いになり、追加の操作が
OperationNotAllowedで拒否される。 - 失敗した DNC のクリーンアップを、ユーザー側でやり直す手段は用意されていない。
つまり、一度この状態になると、「ユーザー側でできるのは状況を整理して Azure サポートに情報を渡すことまで」であり、実際の再クリーンアップやロック解除は、Azure のバックエンド オペレーションに依存することになります。
自力でチェックすべき残存リソースの総点検
とはいえ、すべての「削除できない AKS」が即サポート案件になるわけではありません。単純に関連リソースが残っているだけの場合、ユーザー側の操作で削除が完了するケースも多くあります。まずは以下の観点でチェックしましょう。
クラスタ内リソースの確認
クラスターにまだアクセス可能な場合は、Kubernetes オブジェクトが大量に残っていないかを確認します。
kubectl get pods --all-namespaces
kubectl get services --all-namespaces
kubectl get deployments --all-namespaces
- 長時間 Pending の Pod や、外部ロードバランサー付き Service などが残っていると、背後のネットワークリソース削除を妨げることがあります。
- ただし、今回のようにすでに VNet を削除してしまった場合、ここでの対処余地は小さくなります。
AKS リソースの状態を Azure 側で確認
CLI で AKS クラスターの現在の状態を確認します。
az aks show -g <RG> -n <AKS>
特に確認したいポイントは以下です。
| 項目 | 見たい値 | ポイント |
|---|---|---|
provisioningState | Succeeded / Deleting / Failed | Failed かつ操作不能であればサポート案件になりやすい |
| nodeResourceGroup | MC_<RG>_<AKS>_<Region> | この MC_ リソース グループを先に消さないのが原則 |
| networkProfile | VNet / サブネット情報 | 既に削除済みの VNet を指していると、DNC が失敗しやすい |
NIC / ロードバランサー / ALB Association の残骸
特に CNI 利用時や ALB Gateway 連携環境では、ネットワーク関連のリソースが中途半端に残っていることがあります。代表的なものは次のとおりです。
- クラスター名や MC_ リソース グループ名を含む NIC
- ロードバランサー、パブリック IP
- ALB Association（ALB 連携構成時）
NIC の例:
az network nic list \
--query "[?contains(name, '<cluster-name>')]" \
-o table
ALB Association の例（該当構成のみ）:
az network alb association delete \
-g MC_<RG> \
-n <association-name> \
--alb-name <alb-name>
なお、MC_ リソース グループ配下の一部リソースはポータル上で非表示になっている場合があります。「Manage views ▶ Show hidden」を有効にして、隠れているリソースが残っていないか丁寧に確認することをおすすめします。
標準的な AKS クラスター削除フロー
ネットワークや MC_ リソース グループを直接消してしまう前に、本来は次のような順序で削除を行うのが安全です。
ノードプールを先に削除する
まずはクラスター上のノードプールを整理します。
# ノードプール一覧
az aks nodepool list \
--resource-group <RG> \
--cluster-name <AKS>
# 不要なノードプールを削除
az aks nodepool delete \
--resource-group <RG> \
--cluster-name <AKS> \
--name <POOL>
プールごとに削除を行い、すべてのノードプールが削除済みであることを確認してから、クラスター本体を削除します。
クラスター本体の削除
続いてクラスターを削除します。失敗時のトラブルシュートのため、--debug を付けておくとログが詳細に出力されます。
az aks delete \
--resource-group <RG> \
--name <AKS> \
--yes \
--no-wait \
--debug
このとき、実行ユーザーまたはマネージド ID に十分な権限が付与されているかどうかも要チェックです。
- サブスクリプションまたはリソース グループに対する Contributor 以上のロール。
- VNet を別リソース グループに分けている場合は、その VNet 側にも必要な権限（例: Network Contributor）。
権限不足により途中で失敗しているケースもあるため、Activity Log で RBAC 関連のエラーが出ていないか確認しておきましょう。
REST API での直接削除とログ確認
ポータルや az コマンドの削除操作がうまくいかない場合、REST API を直接呼び出して削除をリクエストする方法もあります。これは「特別な強制削除」ではありませんが、フロントエンド側の問題を切り分ける際に役立ちます。
az rest --method delete \
--uri "https://management.azure.com/subscriptions/<SUB>/resourceGroups/<RG>/providers/Microsoft.ContainerService/managedClusters/<AKS>?api-version=2024-01-01"
実行後、Azure ポータルの Activity Log で該当操作を開き、「Status」「詳細メッセージ」を確認します。
| ログ項目 | 確認ポイント |
|---|---|
| Operation name | ManagedClusters Delete の操作になっているか |
| Status | Succeeded / Failed / In Progress のいずれか |
| エラーメッセージ | DNCCleanupServiceError / OperationNotAllowed などの詳細 |
ここで DNCCleanupServiceError が繰り返し記録されている場合、すでに DNC が何度もクリーンアップを試みて失敗している可能性が高く、自力での復旧は難しいフェーズに入っていると考えられます。
それでも削除できない場合：強制削除はあるのか？
結論から言うと、ユーザー側から実行できる「AKS クラスターの強制削除」手段はありません。ProvisioningState が Failed＋Deleting に固定され、ネットワーククリーンアップに失敗している状態では、次のような制約があります。
- 新たに
az aks deleteを実行しても、OperationNotAllowedで弾かれる。 - ノードプールの削除やスケール変更も同様に拒否される。
- VNet／サブネットなどの関連リソースはすでに削除済みのため、ユーザー側で「やり直し」もできない。
この状態に入ってしまうと、削除処理の再実行や DNC の手動クリーンアップは、Azure 内部の専用オペレーションに委ねるしかありません。つまり、適切なログと状況を整理したうえで、Azure サポートにチケットを起票するのが唯一の現実的な解決ルートになります。
Azure サポートに依頼する際にまとめておきたい情報
サポートにチケットを上げる際、状況を整理して伝えるほど、対応がスムーズになります。実際の事例を踏まえると、以下の情報をまとめておくとよいでしょう。
最低限伝えたい情報
- 対象サブスクリプション ID／リソース グループ名／AKS クラスター名。
- 問題が発生したおおよその日時（いつ削除を実行し、いつから Failed 状態になっているのか）。
- 実行したコマンド例と、その結果出力されたエラー メッセージ。
az aks deleteの出力（可能であれば--debugのログも要約）。- Activity Log に表示される
DNCCleanupServiceErrorのメッセージ内容。
- ユーザーが手動で削除したネットワークリソースの一覧。
- VNet 名／サブネット名。
- Public IP／ロードバランサー／NIC 名など。
サポートに依頼したい内容の例
サポートチケットでは、例えば次のように要望を伝えると話が早く進みます。
- AKS クラスター
<AKS>がFailed状態で削除できず、DNCCleanupServiceErrorが発生している。 - VNet／サブネット／Public IP／MC_ リソース グループ内のリソースは、すでにユーザー側で削除済みである。
- そのため DNC によるポッドネットワークのクリーンアップが完了できず、削除状態から進まないと考えている。
- バックエンド側で DNC のクリーンアップとネットワークロックの解除、削除処理のリトライを実施してほしい。
実際の事例では、サポート側で DNC 周りのロック解除とクリーンアップを実施してもらった後、ユーザー側で再度 az aks delete を実行することで、クラスター削除が無事完了しました。
再発防止策：AKS クラスター削除のベストプラクティス
同じ落とし穴には二度とはまらないよう、運用ルールとして次のポイントを押さえておくと安心です。
「AKS を先に、周辺リソースは後から」削除する
最も重要なのは、削除の順番です。
| 削除順序 | 推奨アクション | 備考 |
|---|---|---|
| 1 | AKS クラスターの削除（az / ポータル / REST） | ノードプールは事前に削除しておくとより安全 |
| 2 | AKS によって自動作成された MC_ リソース グループの削除 | クラスター削除が完了したことを確認してから |
| 3 | VNet／サブネット／Public IP 等の周辺リソースの削除 | 他のリソースと共有していないか要確認 |
「ネットワークを先に片付けたくなる」心理は理解できますが、DNC のクリーンアップが完了する前に VNet を消してしまうと、今回のように削除が行き詰るリスクが一気に高まります。
IaC (Bicep / Terraform) で削除順序をコントロール
手作業でリソースを削除していると、つい順序を間違えたり、どれが AKS 管理リソースなのか分からなくなったりします。可能であれば、Bicep や Terraform などの IaC ツールで構築・削除を一元管理し、次のような運用を目指しましょう。
- AKS クラスターを含むリソースセットを IaC で定義し、destroy 時にも依存関係が考慮されるようにする。
- Terraform の
depends_onや Bicep のモジュール依存関係で、「AKS → MC_ → ネットワーク」の順に削除されるように設計する。 - 手作業で削除する場合でも、事前に IaC の定義を見ながら依存関係を確認しておく。
ログ（特に --debug と Activity Log）を必ず保全する
削除に失敗したとき、「とりあえずもう一度実行してみる」を繰り返してしまうと、初回の失敗原因が分からなくなってしまいます。
az aks delete --debugの実行ログは、テキスト ファイルとして保存しておく。- Azure ポータルの Activity Log で、最初に失敗した削除操作の詳細メッセージをメモしておく。
- サポートに連絡する場合は、これらを添付／要約して提示する。
初回エラー時点の情報が揃っているだけで、サポート側の調査時間をかなり短縮でき、結果としてクラスター削除完了までの時間も短くなります。
実際の解決フローの例
最後に、今回のような「DNCCleanupServiceError により AKS クラスターが削除できない」ケースで、実際に辿った解決フローを整理しておきます。
- クラスター削除を実行したが、エラーで失敗。
- Activity Log に
DNCCleanupServiceErrorが記録されているのを確認。
- Activity Log に
- MC_ リソース グループやネットワークリソースを誤って手動削除してしまい、その後も削除を再試行するが
OperationNotAllowedとなる。 - 残存リソースを総点検。
- 隠しリソースを含め、MC_ リソース グループ配下を確認。
- NIC／Public IP／ALB Association などが残っていないことを再確認。
az aks deleteおよび REST API による削除要求を再実行するも、ProvisioningState はFailedから変化せず。- Azure サポートにチケットを起票し、状況とログを共有。
- バックエンドで DNC の手動クリーンアップとネットワークロック解除を実施してもらう。
- サポートから「クリーンアップ完了」の連絡を受けた後、再度
az aks deleteを実行。- 今度はクラスターが正常に削除され、MC_ リソース グループも安全に削除可能となった。
まとめ：AKS クラスター削除トラブル時の判断基準
AKS クラスターが削除できない問題は、一見すると「よくある削除エラー」のように見えますが、DNC やネットワークリソースが絡むと、ユーザー側で解消できない状態に陥ることがあります。本記事のポイントを最後にもう一度整理しておきます。
- VNet／サブネット／Public IP／MC_ リソース グループは、クラスター削除完了まで手動削除しない。
- 削除に失敗したら、まずは残存リソースの総点検と、ノードプール → クラスターの標準的な削除フローを試す。
DNCCleanupServiceErrorやOperationNotAllowedが繰り返し発生し、ProvisioningState がFailedのまま変わらない場合は、無理に操作を続けず Azure サポートに連絡する。- IaC による依存関係管理と削除順序のコントロール、ログ保全を日常の運用ルールとして組み込む。
AKS の削除トラブルは、一度ハマると長期戦になりがちですが、「どこまでが自分たちの守備範囲で、どこからはサポートに任せるべきか」を明確にしておくことで、復旧までの時間とストレスを大きく減らすことができます。日常的なクラスター運用の一環として、本記事の内容をチームのナレッジとして共有しておくと安心です。
コメント