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

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

前の手順で実行したクラスターのチェックが明確な場合は、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 クラスター内のノード、ユーザー ポッド、システム ポッドの正常性を表示するには、次の手順に従います。

1. Azure portal で Azure Monitor に移動します。
2. ナビゲーション ウィンドウの [分析情報 セクションで、[コンテナー] を選択します。
3. 監視されている AKS クラスターの一覧については、[監視対象クラスター] を選択します。
4. 一覧から AKS クラスターを選択して、ノード、ユーザー ポッド、システム ポッドの正常性を表示します。

AKS ノード ビュー

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

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

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

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

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

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

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

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

• Kubernetes/コンピューティング リソース/クラスター
• Kubernetes/コンピューティング リソース/名前空間 (ポッド)
• Kubernetes/コンピューティング リソース/ノード (ポッド)
• Kubernetes/コンピューティング リソース /ポッド
• Kubernetes/コンピューティング リソース/名前空間 (ワークロード)
• Kubernetes/コンピューティング リソース/ワークロード
• Kubernetes / Kubelet
• ノード エクスポーター/USE メソッド/ノード
• ノード エクスポーター/ノード
• Kubernetes/コンピューティング リソース/クラスター (Windows)
• Kubernetes/コンピューティング リソース/名前空間 (Windows)
• Kubernetes/コンピューティング リソース/ポッド (Windows)
• Kubernetes/USE メソッド/クラスター (Windows)
• Kubernetes/USE メソッド/ノード (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"

Note

API サーバー仮想ネットワーク統合と Azure コンテナー ネットワーク インターフェイス (CNI) または動的ポッド IP 割り当てがある 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 を介してノードに接続した後、tunnelfront ポッドを検索しています。

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 解決が正しく機能していることを確認するには、次の手順に従います。

1. kubectl exec コマンドを実行して、ポッドで実行されているコンテナーでコマンド シェルを開きます。

   kubectl exec --stdin --tty your-pod --namespace <namespace-name> -- /bin/bash
   

2. nslookup または dig ツールがコンテナーにインストールされているかどうかを確認します。

3. どちらのツールもポッドにインストールされていない場合は、次のコマンドを実行して、同じ名前空間にユーティリティ ポッドを作成します。

   kubectl run -i --tty busybox --image=busybox --namespace <namespace-name> --rm=true -- sh
   

4. Azure portal で AKS クラスターの概要ページから API サーバー アドレスを取得することも、次のコマンドを実行することもできます。

   az aks show --name <aks-name> --resource-group <resource-group-name> --query fqdn --output tsv
   

5. 次のコマンドを実行して、AKS API サーバーの解決を試みます。 詳細については、「ワーカー ノードからではなくポッド内から発生した DNS 解決エラーをトラブルシューティングする」を参照してください。

   nslookup myaks-47983508.hcp.westeurope.azmk8s.io
   

6. ポッドからアップストリームの DNS サーバーを確認すると、DNS 解決が正しく機能しているかどうかを確認できます。 たとえば、Azure DNS の場合は、nslookup コマンドを実行します。

   nslookup microsoft.com 168.63.129.16
   

7. 前の手順で分析情報が得られない場合は、ワーカー ノードのいずれかに接続し、ノードから DNS 解決を試みます。 この手順は、問題が AKS とネットワーク構成のどちらに関連しているかを特定するのに役立ちます。

8. ノードから DNS 解決が成功したが、ポッドからは解決されない場合、問題は Kubernetes DNS に関連している可能性があります。 ポッドから DNS 解決をデバッグする手順については、「DNS 解決エラーのトラブルシューティング」を参照してください。

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

手順 4: kubelet エラーを調べる

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

AKS kubelet ブック

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

1. Azure portal で、AKS クラスターに移動します。

2. ナビゲーション ウィンドウの [監視] セクションで [ブック] を選択します。

3. Kubelet ブックを選択します。

   

4. [操作] を選択し、すべてのワーカー ノードの操作が完了していることを確認します。

   

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

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

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

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

kubelet の再起動時に負荷が増加し、散発的で予測できない動作が発生します。 エラー数が増え続けていないことを確認します。 散発的なエラーは許容されますが、増え続けている場合は、調べて解決する必要がある根本的な問題があることを示します。

手順 5: Node Problem Detector (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 ブックを使用できます。 次の手順に従いブックにアクセスします。

1. Azure portal で、AKS クラスターに移動します。

2. ナビゲーション ウィンドウの [監視] セクションで [ブック] を選択します。

3. ノード ディスク IO ブックを選択します。

   

4. I/O 関連のメトリックを確認します。

   

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

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

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

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

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 によって保守されています。 当初の寄稿者は以下のとおりです。

プリンシパルの作成者:

• Paolo Salvatori | プリンシパル カスタマー エンジニア
• Francis Simy Nazareth | シニア テクニカル スペシャリスト

パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。

次のステップ

• 仮想マシン ディスクの制限
• 仮想マシンとディスクのパフォーマンス

関連リソース

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