ノードとポッドの正常性を調べる

2025-04-21

この記事はシリーズの一部です。概要から始めます。

前の手順で実行したクラスターのチェックが明確な場合は、Azure Kubernetes Service (AKS) ワーカーノードの正常性を確認します。この記事の 6 つの手順に従って、ノードの正常性を確認し、異常なノードの理由を特定し、問題を解決します。

手順 1: ワーカーノードの正常性を確認する

さまざまな要因が、AKS クラスター内の異常なノードに影響を与える可能性があります。一般的な理由の1つは、コントロールプレーンとノード間の通信が断絶することです。この間違った通信は、多くの場合、ルーティングとファイアウォール規則の構成ミスが原因で発生します。

ユーザー定義ルーティング用に AKS クラスターを構成する場合は、ネットワーク仮想アプライアンス (NVA) またはファイアウォール (Azure ファイアウォールなど) を介してエグレスパスを構成する必要があります。構成ミスの問題に対処するには、 AKS エグレストラフィックのガイダンスに従って、必要なポートと完全修飾ドメイン名 (FQDN) を許可するようにファイアウォールを構成することをお勧めします。

異常なノードのもう 1 つの理由は、kubelet の負荷を生み出すコンピューティング、メモリ、またはストレージリソースが不十分である可能性があります。このような場合、リソースをスケールアップすると、問題を効果的に解決できます。

プライベート AKS クラスターでは、ドメインネームシステム (DNS) の解決の問題により、コントロールプレーンとノード間の通信の問題が発生する可能性があります。 Kubernetes API サーバーの DNS 名が API サーバーのプライベート IP アドレスに解決されることを確認する必要があります。カスタム DNS サーバーの正しくない構成は、DNS 解決エラーの一般的な原因です。カスタム DNS サーバーを使用する場合は、ノードがプロビジョニングされている仮想ネットワーク上の DNS サーバーとして正しく指定してください。また、カスタム DNS サーバーを介して AKS プライベート API サーバーを解決できることを確認します。

コントロールプレーンの通信と DNS 解決に関連するこれらの潜在的な問題に対処したら、AKS クラスター内のノードの正常性の問題に効果的に取り組んで解決できます。

次のいずれかの方法を使用して、ノードの正常性を評価できます。

Azure Monitor コンテナー正常性ビュー

AKS クラスター内のノード、ユーザーポッド、およびシステムポッドの正常性を表示するには、次の手順に従います。

Azure portal で Azure Monitor に移動します。
ナビゲーションウィンドウの [ Insights ] セクションで、[コンテナー] を選択 します。
監視対象の AKS クラスターの一覧については、[監視対象クラスター] を選択します。
一覧から AKS クラスターを選択して、ノード、ユーザーポッド、およびシステムポッドの正常性を表示します。

AKS ノードビュー

AKS クラスター内のすべてのノードが準備完了状態であることを確認するには、次の手順に従います。

Azure portal で、AKS クラスターに移動します。
ナビゲーションウィンドウの [設定] セクションで、[ ノードプール] を選択します。
[ノード] を選択します。
すべてのノードが準備完了状態であることを確認します。

Prometheus と Grafana を使用したクラスター内監視

AKS クラスターに Prometheus と Grafana をデプロイした場合は、 K8 クラスター詳細ダッシュボードを使用して分析情報を取得できます。このダッシュボードには、Prometheus クラスターメトリックが表示され、CPU 使用率、メモリ使用量、ネットワークアクティビティ、ファイルシステムの使用状況などの重要な情報が表示されます。また、個々のポッド、コンテナー、 および systemd サービスの詳細な統計情報も表示されます。

ダッシュボードで [ ノードの条件 ] を選択して、クラスターの正常性とパフォーマンスに関するメトリックを表示します。スケジュールの問題、ネットワーク、ディスクの負荷、メモリ負荷、比例積分派生 (PID) の負荷、ディスク領域など、問題が発生する可能性があるノードを追跡できます。これらのメトリックを監視して、AKS クラスターの可用性とパフォーマンスに影響を与える可能性のある問題を事前に特定して対処できるようにします。

Prometheus と Azure Managed Grafana のマネージドサービスを監視する

事前構築済みのダッシュボードを使用して、Prometheus メトリックを視覚化および分析できます。これを行うには、Prometheus の Monitor マネージドサービスで Prometheus メトリックを収集し、 Monitor ワークスペースを Azure Managed Grafana ワークスペースに接続するように AKS クラスターを設定する必要があります。これらのダッシュボードは、 Kubernetes クラスターのパフォーマンスと正常性の包括的なビューを提供します。

ダッシュボードは、 Managed Prometheus フォルダー内の指定された Azure Managed Grafana インスタンスにプロビジョニングされます。一部のダッシュボードには、次のものが含まれます。

Kubernetes / コンピューティングリソース / クラスター
Kubernetes / コンピューティングリソース / 名前空間 (ポッド)
Kubernetes / コンピューティングリソース / ノード (ポッド)
Kubernetes / コンピューティングリソース / ポッド
Kubernetes / コンピューティングリソース / 名前空間 (ワークロード)
Kubernetes / コンピューティングリソース / ワークロード
Kubernetes/Kubelet
Node Exporter / USE メソッド / Node
ノードエクスポーター/ノード
Kubernetes / コンピューティングリソース / クラスター (Windows)
Kubernetes / コンピューティングリソース / 名前空間 (Windows)
Kubernetes / コンピューティングリソース / ポッド (Windows)
Kubernetes / USE メソッド / クラスター (Windows)
Kubernetes / USE メソッド / Node (Windows)

これらの組み込みダッシュボードは、Prometheus と Grafana を使用して Kubernetes クラスターを監視するために、オープンソースコミュニティで広く使用されています。これらのダッシュボードを使用して、リソースの使用状況、ポッドの正常性、ネットワークアクティビティなどのメトリックを表示します。監視のニーズに合わせてカスタマイズされたカスタムダッシュボードを作成することもできます。ダッシュボードを使用すると、AKS クラスター内の Prometheus メトリックを効果的に監視および分析できます。これにより、パフォーマンスの最適化、問題のトラブルシューティング、および Kubernetes ワークロードの円滑な運用を実現できます。

Kubernetes/コンピューティングリソース/ノード (ポッド) ダッシュボードを使用して、Linux エージェントノードのメトリックを表示できます。各ポッドの CPU 使用率、CPU クォータ、メモリ使用量、メモリクォータを視覚化できます。

クラスターに Windows エージェントノードが含まれている場合は、 Kubernetes/USE メソッド/ノード (Windows) ダッシュボードを使用して、これらのノードから収集された Prometheus メトリックを視覚化できます。このダッシュボードでは、クラスター内の Windows ノードのリソース消費とパフォーマンスの包括的なビューが提供されます。

これらの専用ダッシュボードを利用して、Linux および Windows エージェントノードの両方の CPU、メモリ、およびその他のリソースに関連する重要なメトリックを簡単に監視および分析できます。この可視性により、潜在的なボトルネックを特定し、リソースの割り当てを最適化し、AKS クラスター全体で効率的な操作を確保できます。

手順 2: コントロールプレーンとワーカーノードの接続を確認する

ワーカーノードが正常な場合は、マネージド AKS コントロールプレーンとクラスターワーカーノードの間の接続を確認する必要があります。 AKS を使用すると、セキュリティで保護されたトンネル通信方法を使用して、 Kubernetes API サーバーと個々のノード kubelets 間の通信が可能になります。これらのコンポーネントは、異なる仮想ネットワーク上にある場合でも通信できます。トンネルは、相互トランスポート層セキュリティ (mTLS) 暗号化で保護されています。 AKS で使用されるプライマリトンネルは Konnectivity (旧称 apiserver-network-proxy) と呼ばれます。すべてのネットワーク規則と FQDN が、必要な Azure ネットワーク規則に準拠していることを確認します。

マネージド AKS コントロールプレーンと AKS クラスターのクラスターワーカーノードの間の接続を確認するには、 kubectl コマンドラインツールを使用できます。

Konnectivity エージェントポッドが正常に動作することを確認するには、次のコマンドを実行します。

kubectl get deploy konnectivity-agent -n kube-system

ポッドが準備完了状態であることを確認します。

コントロールプレーンとワーカーノード間の接続に問題がある場合は、必要な AKS エグレストラフィックルールが許可されていることを確認した後、接続を確立します。

次のコマンドを実行して、 konnectivity-agent ポッドを再起動します。

kubectl rollout restart deploy konnectivity-agent -n kube-system

ポッドを再起動しても接続が修正されない場合は、ログで異常がないか確認します。次のコマンドを実行して、 konnectivity-agent ポッドのログを表示します。

kubectl logs -l app=konnectivity-agent -n kube-system --tail=50

ログには、次の出力が表示されます。

I1012 12:27:43.521795       1 options.go:102] AgentCert set to "/certs/client.crt".
I1012 12:27:43.521831       1 options.go:103] AgentKey set to "/certs/client.key".
I1012 12:27:43.521834       1 options.go:104] CACert set to "/certs/ca.crt".
I1012 12:27:43.521837       1 options.go:105] ProxyServerHost set to "sethaks-47983508.hcp.switzerlandnorth.azmk8s.io".
I1012 12:27:43.521841       1 options.go:106] ProxyServerPort set to 443.
I1012 12:27:43.521844       1 options.go:107] ALPNProtos set to [konnectivity].
I1012 12:27:43.521851       1 options.go:108] HealthServerHost set to
I1012 12:27:43.521948       1 options.go:109] HealthServerPort set to 8082.
I1012 12:27:43.521956       1 options.go:110] AdminServerPort set to 8094.
I1012 12:27:43.521959       1 options.go:111] EnableProfiling set to false.
I1012 12:27:43.521962       1 options.go:112] EnableContentionProfiling set to false.
I1012 12:27:43.521965       1 options.go:113] AgentID set to b7f3182c-995e-4364-aa0a-d569084244e4.
I1012 12:27:43.521967       1 options.go:114] SyncInterval set to 1s.
I1012 12:27:43.521972       1 options.go:115] ProbeInterval set to 1s.
I1012 12:27:43.521980       1 options.go:116] SyncIntervalCap set to 10s.
I1012 12:27:43.522020       1 options.go:117] Keepalive time set to 30s.
I1012 12:27:43.522042       1 options.go:118] ServiceAccountTokenPath set to "".
I1012 12:27:43.522059       1 options.go:119] AgentIdentifiers set to .
I1012 12:27:43.522083       1 options.go:120] WarnOnChannelLimit set to false.
I1012 12:27:43.522104       1 options.go:121] SyncForever set to false.
I1012 12:27:43.567902       1 client.go:255] "Connect to" server="e9df3653-9bd4-4b09-b1a7-261f6104f5d0"

注

API サーバー仮想ネットワーク統合と、動的ポッド IP 割り当てがある Azure コンテナーネットワークインターフェイス (CNI) または Azure CNI を使用して AKS クラスターを設定する場合、Konnectivity エージェントをデプロイする必要はありません。統合 API サーバーポッドは、プライベートネットワークを介してクラスターワーカーノードとの直接通信を確立できます。

ただし、AZURE CNI オーバーレイと API サーバーの仮想ネットワーク統合を使用する場合や、独自の CNI (BYOCNI) を使用する場合は、API サーバーとポッド IP 間の通信を容易にするために Konnectivity がデプロイされます。 API サーバーとワーカーノード間の通信は引き続き直接行われます。

ログと監視サービスのコンテナーログを検索して、ログを取得することもできます。 aks-link 接続エラーを検索する例については、コンテナー分析情報からのログのクエリを参照してください。

次のクエリを実行してログを取得します。

ContainerLogV2 
| where _ResourceId =~ "/subscriptions/<subscription-ID>/resourceGroups/<resource-group-name>/providers/Microsoft.ContainerService/managedClusters/<cluster-ID>" // Use the IDs and names of your resources for these values.
| where ContainerName has "aks-link"
| project LogSource,LogMessage, TimeGenerated, Computer, PodName, ContainerName, ContainerId
| order by TimeGenerated desc
| limit 200

次のクエリを実行して、特定の名前空間で失敗したポッドのコンテナーログを検索します。

let KubePodInv = KubePodInventory
    | where TimeGenerated >= startTime and TimeGenerated < endTime
    | where _ResourceId =~ "<cluster-resource-ID>" // Use your resource ID for this value.
    | where Namespace == "<pod-namespace>" // Use your target namespace for this value.
    | where PodStatus == "Failed"
    | extend ContainerId = ContainerID
    | summarize arg_max(TimeGenerated, *)  by  ContainerId, PodStatus, ContainerStatus
    | project ContainerId, PodStatus, ContainerStatus;

    KubePodInv
    | join
    (
        ContainerLogV2
    | where TimeGenerated >= startTime and TimeGenerated < endTime
    | where PodNamespace == "<pod-namespace>" //update with target namespace
    ) on ContainerId
    | project TimeGenerated, PodName, PodStatus, ContainerName, ContainerId, ContainerStatus, LogMessage, LogSource

クエリまたは kubectl ツールを使用してログを取得できない場合は、 Secure Shell (SSH) 認証を使用します。この例では、SSH 経由でノードに接続した後に トンネルフロント ポッドを検索します。

kubectl pods -n kube-system -o wide | grep tunnelfront
ssh azureuser@<agent node pod is on, output from step above>
docker ps | grep tunnelfront
docker logs …
nslookup <ssh-server_fqdn>
ssh -vv azureuser@<ssh-server_fqdn> -p 9000
docker exec -it <tunnelfront_container_id> /bin/bash -c "ping bing.com"
kubectl get pods -n kube-system -o wide | grep <agent_node_where_tunnelfront_is_running>
kubectl delete po <kube_proxy_pod> -n kube-system

手順 3: エグレスを制限するときに DNS 解決を検証する

DNS 解決は、AKS クラスターの重要な側面です。 DNS 解決が正しく機能しない場合は、コントロールプレーンエラーまたはコンテナーイメージのプルエラーが発生する可能性があります。 Kubernetes API サーバーへの DNS 解決が正しく機能していることを確認するには、次の手順に従います。

kubectl exec コマンドを実行して、ポッドで実行されているコンテナーでコマンドシェルを開きます。
```
kubectl exec --stdin --tty your-pod --namespace <namespace-name> -- /bin/bash
```
nslookup または dig ツールがコンテナーにインストールされているかどうかを確認します。
どちらのツールもポッドにインストールされていない場合は、次のコマンドを実行して、同じ名前空間にユーティリティポッドを作成します。
```
kubectl run -i --tty busybox --image=busybox --namespace <namespace-name> --rm=true -- sh
```
AZURE portal で AKS クラスターの概要ページから API サーバーアドレスを取得することも、次のコマンドを実行することもできます。
```
az aks show --name <aks-name> --resource-group <resource-group-name> --query fqdn --output tsv
```
次のコマンドを実行して、AKS API サーバーの解決を試みます。詳細については、ポッド内からの DNS 解決エラーのトラブルシューティングを参照してください。ワーカーノードからのトラブルシューティングは行いません。
```
nslookup myaks-47983508.hcp.westeurope.azmk8s.io
```
ポッドからのアップストリーム DNS サーバーを調べて、DNS 解決が正しく機能しているかどうかを確認します。たとえば、Azure DNS の場合は、 nslookup コマンドを実行します。
```
nslookup microsoft.com 168.63.129.16
```
前の手順で分析情報が得られない場合は、いずれかのワーカーノードに接続し、ノードから DNS 解決を試みます。この手順は、問題が AKS とネットワーク構成のどちらに関連しているかを特定するのに役立ちます。
ノードから DNS 解決が成功したが、ポッドからは解決されない場合、問題は Kubernetes DNS に関連している可能性があります。ポッドから DNS 解決をデバッグする手順については、「 DNS 解決エラーのトラブルシューティング」を参照してください。

ノードから DNS 解決が失敗した場合は、ネットワークのセットアップを確認して、DNS 解決を容易にするために適切なルーティングパスとポートが開かれていることを確認します。

手順 4: kubelet エラーを確認する

各ワーカーノードで実行される kubelet プロセスの条件を確認し、負荷がかからないようにします。潜在的な負荷は、CPU、メモリ、またはストレージに関連している可能性があります。個々のノードの kubelets の状態を確認するには、次のいずれかの方法を使用できます。

AKS kubelet ワークブック

エージェントノードの kubelets が正しく動作することを確認するには、次の手順に従います。

Azure portal で、AKS クラスターに移動します。
ナビゲーションウィンドウの監視セクションで、ワークブックを選択します。
Kubelet ブックを選択します。
[ 操作] を選択し、すべてのワーカーノードの操作が完了していることを確認します。

Prometheus と Grafana を使用したクラスター内監視

AKS クラスターに Prometheus と Grafana をデプロイした場合は、 Kubernetes/Kubelet ダッシュボードを使用して、個々のノード kubelets の正常性とパフォーマンスに関する分析情報を取得できます。

Prometheus と Azure Managed Grafana のマネージドサービスを監視する

Kubernetes/Kubelet 事前構築済みダッシュボードを使用して、ワーカーノード kubelets の Prometheus メトリックを視覚化および分析できます。これを行うには、Prometheus の Monitor マネージドサービスで Prometheus メトリックを収集し、 Monitor ワークスペースを Azure Managed Grafana ワークスペースに接続するように AKS クラスターを設定する必要があります。

Kubelet が再起動すると圧力が高くなり、散発的で予測できない動作が発生します。エラー数が継続的に増加しないことを確認します。場合によってはエラーが発生してもかまいませんが、一定の増加は、調査して解決する必要がある根本的な問題を示しています。

手順 5: ノード問題検出 (NPD) ツールを使用してノードの正常性を確認する

NPD は、ノード関連の問題を特定して報告するために使用できる Kubernetes ツールです。これは、クラスター内のすべてのノードで systemd サービスとして動作します。 CPU 使用率、ディスク使用率、ネットワーク接続状態などのメトリックとシステム情報を収集します。問題が検出されると、NPD ツールによってイベントとノードの条件に関するレポートが生成されます。 AKS では、NPD ツールを使用して、Azure クラウドでホストされている Kubernetes クラスター内のノードを監視および管理します。詳細については、 AKS ノードの NPD を参照してください。

手順 6: 1 秒あたりのディスク I/O 操作 (IOPS) の調整を確認する

IOPS が調整されず、AKS クラスター内のサービスとワークロードに影響を与えないように、次のいずれかの方法を使用できます。

AKS ノードディスク I/O ワークブック

AKS クラスター内のワーカーノードのディスク I/O 関連メトリックを監視するには、ノードディスク I/O ブックを使用できます。ブックにアクセスするには、次の手順に従います。

Azure portal で、AKS クラスターに移動します。
ナビゲーションウィンドウの監視セクションで、ワークブックを選択します。
ノードディスク IO ワークブックを選択します。
I/O 関連のメトリックを確認します。

Prometheus と Grafana を使用したクラスター内監視

AKS クラスターに Prometheus と Grafana をデプロイした場合は、 USE メソッド/ノードダッシュボードを使用して、クラスターワーカーノードのディスク I/O に関する分析情報を取得できます。

Prometheus と Azure Managed Grafana のマネージドサービスを監視する

ノードエクスポーター/ノード事前構築済みダッシュボードを使用して、ワーカーノードからディスク I/O 関連のメトリックを視覚化および分析できます。これを行うには、Prometheus の Monitor マネージドサービスで Prometheus メトリックを収集し、 Monitor ワークスペースを Azure Managed Grafana ワークスペースに接続するように AKS クラスターを設定する必要があります。

IOPS と Azure ディスク

物理ストレージデバイスには、帯域幅と、処理できるファイル操作の最大数に固有の制限があります。 Azure ディスクは、AKS ノードで実行されるオペレーティングシステムを格納するために使用されます。ディスクには、オペレーティングシステムと同じ物理ストレージ制約が適用されます。

スループットの概念を考えてみましょう。平均 I/O サイズに IOPS を乗算して、1 秒あたりのスループット (MBps) を MB 単位で決定できます。 I/O サイズを大きくすると、ディスクの固定スループットが原因で IOPS が低下します。

ワークロードが Azure ディスクに割り当てられている最大 IOPS サービス制限を超えると、クラスターが応答しなくなり、I/O 待機状態になる可能性があります。 Linux ベースのシステムでは、ネットワークソケット、CNI、Docker、ネットワーク I/O に依存するその他のサービスなど、多くのコンポーネントがファイルとして扱われます。そのため、ディスクを読み取ることができない場合、エラーはこれらすべてのファイルに拡張されます。

次のようないくつかのイベントとシナリオで IOPS 調整をトリガーできます。

Docker I/O はオペレーティングシステムディスクを共有するため、ノードで実行されるコンテナーの数が多い。
セキュリティ、監視、およびログ記録に使用されるカスタムまたはサードパーティ製のツール。オペレーティングシステムディスクに追加の I/O 操作が生成される可能性があります。
ワークロードを強化したりポッドの数をスケーリングしたりするノードフェールオーバーイベントと定期的なジョブ。この負荷が増加すると制限が発生する可能性が高まり、I/O 操作が終了するまで、すべてのノードが 準備ができていない状態 に移行する可能性があります。

貢献者

この記事は Microsoft によって管理されています。当初の寄稿者は以下のとおりです。

主要な著者:

パオロサルヴァトリ |プリンシパルカスタマーエンジニア
フランシスコ・シミー・ナハレス |シニアテクニカルスペシャリスト

非公開の LinkedIn プロファイルを表示するには、LinkedIn にサインインします。

次のステップ

ワークロードのデプロイを監視する

次の方法で共有

ノードとポッドの正常性を調べる

手順 1: ワーカー ノードの正常性を確認する

Azure Monitor コンテナー正常性ビュー

AKS ノード ビュー

Prometheus と Grafana を使用したクラスター内監視

Prometheus と Azure Managed Grafana のマネージド サービスを監視する

手順 2: コントロール プレーンとワーカー ノードの接続を確認する

手順 3: エグレスを制限するときに DNS 解決を検証する

手順 4: kubelet エラーを確認する

AKS kubelet ワークブック

Prometheus と Grafana を使用したクラスター内監視

Prometheus と Azure Managed Grafana のマネージド サービスを監視する

手順 5: ノード問題検出 (NPD) ツールを使用してノードの正常性を確認する

手順 6: 1 秒あたりのディスク I/O 操作 (IOPS) の調整を確認する

AKS ノード ディスク I/O ワークブック

Prometheus と Grafana を使用したクラスター内監視

Prometheus と Azure Managed Grafana のマネージド サービスを監視する

IOPS と Azure ディスク

貢献者

次のステップ

関連リソース

フィードバック

その他のリソース

手順 1: ワーカーノードの正常性を確認する

AKS ノードビュー

Prometheus と Azure Managed Grafana のマネージドサービスを監視する

手順 2: コントロールプレーンとワーカーノードの接続を確認する

Prometheus と Azure Managed Grafana のマネージドサービスを監視する

AKS ノードディスク I/O ワークブック

Prometheus と Azure Managed Grafana のマネージドサービスを監視する