【速報】Microsoft Build 2025：AKS デバッグの効率化─問題を解決するテクニック（講演レポート）

米時間2025年5月19日～22日、シアトルにて開催されているMicrosoft主催の開発者向けイベント「Microsoft Build 2025」。

本記事では、「Streamlining AKS Debugging: Techniques to solve common & complex problems（AKS デバッグの効率化: 一般的な問題と複雑な問題を解決するテクニック）」の講演内容をまとめてご紹介します。

セッション概要（公式）

公式サイトで公開されているセッション概要は、以下の通りです。

このセッションでは、DNSの問題の解決、CPUとメモリを大量に消費しているプロセス (ポッドのクラッシュや OOMによる強制終了につながる可能性がある) の特定、ネットワークセキュリティ関連の難しい問題 (ファイアウォールの構成など) の解決など、AKSの一般的な問題と複雑な問題のトラブルシューティング方法を学習します。

魅力的なデモンストレーションを通じて、頻繁に発生するシナリオを順に説明し、システムを正常な状態に戻すのに役立つツール (オープンソースツールを含む) を共有します。

参考：Streamlining AKS Debugging: Techniques to solve common & complex problems

はじめに

Kubernetes（K8s）は、コンテナ化されたアプリケーションの管理を効率化する強力なプラットフォームですが、その複雑さゆえにトラブルシューティングは容易ではありません。表面上のエラーに惑わされず、ネットワークやインフラストラクチャの深層に潜む原因を的確に特定する必要があります。

このセッションは、エンジニアに明確なメンタルモデルと構造化されたワークフローを提供し、自信を持って問題に立ち向かえるようにすることを目的としています。

セッションは、登壇者の紹介に続き、参加者へのアンケートで幕を開けました。アンケート結果によると、約半数の参加者が週に一度はKubernetesのトラブルシューティングに取り組んでいると回答し、テーマの切実さが浮き彫りに。

本セッションは、ネットワーク問題、ノードの健全性、CRUD（作成、読み込み、更新、削除）の操作という3つの主要シナリオを中心に展開され、各シナリオではライブデモを通じて具体的な解決策が示されました。最後には、ベストプラクティスやAzureの新機能が紹介され、参加者とのQ&Aで実運用での疑問が深く掘り下げられました。

シナリオ① ネットワーク問題

最初に登壇したマイクロソフトのホセ・ブランキセット氏（以下、ホセ氏）は、Kubernetesにおけるネットワーク問題、特にDNSとTCPに焦点を当てました。

これらの問題は、HTTPやgRPC（Google が開発した高性能で汎用的なオープンソースのRPCフレームワーク）といった高レベルプロトコルで頻発し、Kubernetes特有の複雑なネットワーク環境ではデバッグが一筋縄ではいきません。

標準のLinuxツール、例えばtcpdumpは、ポッドやコンテナといったKubernetesリソースとの関連付けが難しく、出力結果を解釈するのに手間がかかります。

この課題の解決策として、講演ではオープンソースのトラブルシューティングツール「Inspektor Gadget」が紹介されました。Inspektor GadgetはKubernetesに対応しており、ログやリアルタイムデバッグを通じて問題を迅速に特定できるだけでなく、監視やセキュリティ用途にも活用可能です。

参考リンク：Inspektor GadgetのGitHubページ

デモ（Inspektor Gadgetを利用した、TCP接続エラーの解明）

デモは、AKS上で動作するeコマースアプリケーションを舞台に展開されます。ユーザーが商品をカートに追加したりチェックアウトしたりする際に、エラーが発生する状況を再現しました。

ストアフロントサービスのログを確認したところ、接続拒否エラーが検出されます。しかし、ログだけではIPアドレスやポートの情報がKubernetesリソースと関連付けられておらず、原因の特定は困難でした。そこで、Inspektor Gadgetのtrace TCPガジェットを使用し、特定のネームスペースとポッドに絞ってTCPイベントを追跡しました。

結果、ストアフロントがオーダーサービスに接続を試みる際に接続が拒否されていることが判明。YAMLファイルを確認すると、サービスのターゲットポートとコンテナのポートが一致していないという単純な設定ミスが原因でした。

この設定ミスを修正することで、アプリケーションは正常に動作を再開。ホセ氏は「解決策はシンプルでも、問題の特定が鍵」と強調し、会場は納得の空気に包まれました。

DNS問題、段階的な切り分けの重要性

続いて、ホセ氏はDNS関連の問題に取り組みました。同じアプリケーションで、特定の商品をチェックアウトする際に外部エンドポイントへの接続が失敗するケースを再現します。

オーダーサービスのログを確認すると、外部エンドポイントの名前解決に失敗していることがわかりました。また、Inspektor Gadgetのtrace_dnsガジェットを使用し、オーダーサービスとKubeDNS間の通信を追跡したところ、KubeDNSがサーバーエラーを返していることが判明しました。

さらに、上流DNS（カスタムDNS）との通信を調査するため、KubeDNSのネームスペースにフィルターを変更して追跡を行いました。結果、特定のクエリに対して上流DNSが応答していないことがわかりました。

すべてのDNSトラフィックを調査したところ、上流DNSは一部のクエリには正常に応答しているため、完全なダウンではなく、特定のエンドポイントに対する設定ミスが原因であると特定できました。

ホセ氏は、問題を段階的に切り分け、専用ツールを活用することで、複雑なネットワーク問題も効率的に解決できると解説しました。このデモは、参加者に「問題の切り分け方」の重要性を強く印象づけました。

ネットワークトラブルシューティングの教訓

この章では、環境を論理的に分割し、ログから始めて専用ツールで詳細を掘り下げるアプローチの有効性が学べました。Inspektor Gadgetは、ネットワークだけでなく、セキュリティやパフォーマンス監視にも活用できる多機能なツールとして、参加者の注目を集めました。

また、Windows環境向けにはアドバンストコンテナーネットワークサービスの利用も推奨され、幅広い運用環境に対応する柔軟性が示されました。

参考サイト：アドバンストコンテナーネットワークサービスとは何ですか?（Microsoft公式ページ）

シナリオ② ノードの健全性を維持する

次に登壇したマイクロソフトのジュアン・リー・パン氏（以下、パン氏）は、ノードが「Not Ready」状態になる問題のトラブルシューティングに焦点を当てました。

ノードの健全性は、アプリケーションの安定稼働に直結するため、迅速な原因特定が求められます。パン氏は、まずkubectl describe nodeコマンドやAzureポータルを使ってノードの状態を確認することを推奨しました。

AKSでは、Node Problem Detectorが標準でインストールされており、リソース圧迫やスケジュールイベント、システムの問題を検出できます。このツールは、Kubernetes標準のノード条件を拡張し、運用上の課題を可視化します。

ディスクとメモリの圧迫を解決

パン氏は、ディスク圧迫とメモリ圧迫という2つの典型的なノード問題を例に挙げました。ディスク圧迫は、ノードのストレージ不足を示す状態です。パン氏は、kubectl describe nodeで詳細を確認し、関連するイベントを調査する方法を解説しました。

例えば、コンテナイメージのガベージコレクションが失敗している場合、ストレージを消費しているファイルを特定するために、duやdfなどのLinuxコマンドを使用します。解決策としては、不要なファイルを削除するか、ディスク容量を増やすことが考えられます。

一方、メモリ圧迫では、OOM（Out of Memory）キルイベントが頻発するケースが取り上げられました。パン氏は、kubectl top podやメトリクスを活用して、リソースを過剰に消費しているポッドを特定する方法を紹介。解決策としては、ポッドのリクエストとリミットの調整や、仮想マシンのサイズアップが提案されました。

また、問題が再現しない場合でも、Kubernetesのイベントログを活用することで、過去の状態変化を追跡し、原因を特定できると説明。このアプローチは、問題の再現性が低い場合でも有効な手法です。

近日公開予定の、Node Not Ready Diagnostic

パン氏は、近日公開予定の「Node Not Ready Diagnostic」条件を紹介しました。この機能は、ノードが「Not Ready」状態になった際に、CPU、メモリ、I/O、ネットワークの主要な問題を特定し、トラブルシューティングを大幅に効率化します。

新発表、Azure Monitor Dashboards with Grafana（プレビュー版）

さらに、Azure Monitor Dashboards with Grafana（プレビュー版）が発表されました。このダッシュボードは、Azureポータル内でカスタマイズ可能なメトリクス表示を提供し、I/Oやネットワークのスループット問題を可視化します。

ポータル内で完結できるのは運用が楽になりそうで、実用性が高そうです。

参考サイト：Use Azure Monitor dashboards with Grafana（Microsoft公式ページ）

AKSのノード自動修復機能

また、AKSのノード自動修復機能についても触れられました。この機能では、ノードが10分以上「Not Ready」状態の場合、自動的に再起動、再イメージング、または再デプロイが行われます。ただし、頻繁な自動修復は根本的な問題の兆候であるため、原因の調査が不可欠です。

パン氏は、「自動修復は最後の防衛線。日々の監視で問題を未然に防ぐことが重要」と強調し、プロアクティブな運用姿勢を促しました。

シナリオ③ CRUD操作の失敗を克服

最後に登壇したマイクロソフトのアリトラ・ゴーシュ氏（以下、アリトラ氏）は、クラスタやノードプールのCRUD（作成、読み込み、更新、削除）操作に関するトラブルシューティングについて解説しました。

Kubernetesクラスタの運用では、アプリケーションの追加、クラスタのアップグレード、ノードイメージの更新、リソースの削除などが日常的に行われますが、これらの操作が失敗することは珍しくありません。アリトラ氏は、失敗した操作がクラスタ全体の健全性を示すものではなく、単に最後の操作が失敗したことを意味すると説明しました。

デモ（ノードプールスケーリングの失敗を解決）

アリトラ氏は、ノードプールのスケーリング操作が失敗したケースをライブデモで披露しました。

Azureポータルのクラスタ概要ページを確認すると、クラスタ自体は正常でしたが、特定のノードプールが「Failed」状態でした。「Last Operation Status」を確認したところ、ノードのドレインが失敗し、特定のポッドがPod Disruption Budget（PDB）を満たせなかったことが原因でした。

Azure Resource Graphを活用して操作履歴を調査し、ノードOSのアップグレードが失敗したことを確認しました。さらに、Copilotを使ってPDBの設定を調査したところ、NGINXデプロイメントのレプリカ数が不足していることが判明しました。

アリトラ氏は、PDBを緩和するか、NGINXのレプリカ数を増やすことで問題を解決できると提案。デモ中、Copilotで生成したコマンドをdry runモードで確認する様子が披露されました。

このデモは、ポータル、Resource Graph、Copilotを組み合わせることで、問題の特定から解決までをスムーズに進めるプロセスを鮮やかに示しました。

新機能、Last Operation StatusとResource Graph

アリトラ氏は、AzureポータルやAPIで利用可能な「Last Operation Status」機能が一般公開されたことを紹介しました。この機能は、失敗した操作の詳細とトラブルシューティングガイドを提供し、迅速な問題解決を支援します。

また、Azure Resource Graphを活用することで、アップグレード履歴やアラートの設定が容易に行えます。アリトラ氏は、「これらのツールを使えば、自動アップグレードの失敗もすぐに追跡できる」と語り、参加者に実運用での活用を促しました。

問題を未然に防ぐ、ベストプラクティス

セッションの締めくくりとして、トラブルシューティングを効率化し、問題を未然に防ぐためのベストプラクティスが紹介されました。

ノードの適切なサイジング、ネットワークの耐障害性の確保、適切なPDBの設定が重要です。特に、Azure Monitor推奨アラートは、ワンクリックで有効化でき、顧客のベストプラクティスに基づいた監視設定を提供します。

ホセ氏が紹介したInspektor Gadgetや、パン氏が触れたNode Problem Detectorなど、オープンソースプロジェクトへの参加も呼びかけられ、コミュニティとの連携の重要性が強調されました。

また新機能の発表では、Azure Monitor Dashboards with Grafanaや「Last Operation Status」の一般公開が、参加者の大きな関心を集めました。

Q&A

セッションの最後には、参加者からの質問を受け付ける時間が設けられ、活発な議論が繰り広げられました。質問と回答は以下の通りです。

Q1: eコマースアプリケーションのデモで表示されたエラーはクライアント側で発生したものですか、それともサーバー側で発生したものですか？
A: エラーはクラスタ内で発生し、HTTPレスポンスとしてクライアントに返されたものです。

Q2: Azureポータル内でGrafanaダッシュボードの統合性について教えてください。
A: Azureベースのメトリクス（ログアナリティクスやPrometheusメトリクスなど）を使用してカスタムダッシュボードを作成できますが、外部データソースを利用するにはAzure Managed Grafanaが必要です。