Google Distributed Cloud の nettest は、クラスタ内の Kubernetes オブジェクト（Pod、Node、Service、一部の外部ターゲットなど）の接続の問題を特定します。nettest では、外部ターゲットから Pod、Node、Service への接続は確認されません。このドキュメントでは、anthos-samples GitHub リポジトリにあるマニフェスト（nettest.yaml や nettest_rhel.yaml）のいずれかを使用し、nettest をデプロイして実行する方法について説明します。Red HatEnterprise Linux（RHEL）で Google Distributed Cloud を実行している場合は、nettest_rhel.yaml を使用します。Ubuntu で Google Distributed Cloud を実行している場合は、nettest.yaml を使用します。
また、このドキュメントは、nettest によって生成されたログを解釈して、クラスタとの接続性の問題を特定する方法についても説明します。
nettest の概要
nettest 診断ツールは、次の Kubernetes オブジェクトで構成されています。各オブジェクトは nettest YAML マニフェスト ファイルで指定されます。
cloudprober: ネットワーク接続ステータス（エラー率やレイテンシなど）の収集に使用される DaemonSet と Service。echoserver:cloudproberへの応答に使用され、ネットワーク接続の指標を提供する DaemonSet と Service。nettest:prometheusコンテナとnettestコンテナを含む Pod。prometheusはcloudproberから指標を収集します。nettestは、prometheusに対してクエリを実行し、ログでネットワーク テスト結果を表示します。
nettest-engine:nettestPod でnettestコンテナを構成するための ConfigMap。
マニフェストでは nettest 名前空間と専用の ServiceAccount も（ClusterRole と ClusterRoleBinding とともに）指定し、nettest を他のクラスタ リソースから分離します。
nettest を実行する
オペレーティング システムに応じて次のコマンドを実行し、nettest をデプロイします。nettest Pod が起動すると、テストが自動的に実行されます。テストの完了には、約 5 分かかります。
Ubuntu の場合:
kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-samples/main/anthos-bm-utils/abm-nettest/nettest.yaml
RHEL の場合:
kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-samples/main/anthos-bm-utils/abm-nettest/nettest_rhel.yaml
テスト結果を取得する
テストが完了したら（nettest マニフェストをデプロイしてから約 5 分後）、次のコマンドを実行して nettest の結果を確認します。
kubectl -n nettest logs nettest -c nettest
nettest の実行中に、次のようなメッセージが stdout に送信されます。
I0413 03:33:04.879141 1 collectorui.go:130] Listening on ":8999"
I0413 03:33:04.879258 1 prometheus.go:172] Running prometheus controller
E0413 03:33:04.879628 1 prometheus.go:178] Prometheus controller: failed to
retries probers: Get "http://127.0.0.1:9090/api/v1/targets": dial tcp 127.0.0.1:9090:
connect: connection refused
接続エラーを特定せずに nettest が正常に実行されると、次のログエントリが確認できます。
I0211 21:58:34.689290 1 validate_metrics.go:78] Metric validation passed!
nettest が接続の問題を検出した場合は、次のようなログエントリが書き込まれます。
E0211 06:40:11.948634 1 collector.go:65] Engine error: step validateMetrics failed:
"Error rate in percentage": probe from "10.200.0.3" to "172.26.115.210:80" has value 100.000000,
threshold is 1.000000
"Error rate in percentage": probe from "10.200.0.3" to "172.26.27.229:80" has value 100.000000,
threshold is 1.000000
"Error rate in percentage": probe from "192.168.3.248" to "echoserver-hostnetwork_10.200.0.2_8080"
has value 2.007046, threshold is 1.000000
デフォルトのしきい値は 1%（1.000000）ですが、5% 以下のエラー率は無視しても問題ありません。たとえば、上記の例では、IP アドレス 192.168.3.248 から echoserver-hostnetwork_10.200.0.2_8080 への接続のエラー率が約 2%（2.007046）です。これは、無視できる接続の問題の報告例です。
テスト結果を解釈する
nettest が終了し、接続の問題が見つかると、nettest Pod のログで次のエントリが確認できます。
"Error rate in percentage": probe from {src} to {dst} has value 100.000000, threshold is 1.000000
ここで、{src} と {dst} は次のいずれかです。
echoserverPod IP: ノード上の Pod との間の接続。- Node IP: ノードとの接続。
- Service IP（詳細については、下の説明をご覧ください）
また、{dst} は次のいずれかになります。
google.com: 外部接続。dns: DNS を介したhostNetwork以外の Service への接続。つまり「echoserver-non-hostnetwork.nettest.svc.cluster.local」。Service IP の詳細は、次の例のように、JSON 形式の probe エントリにあります。次の probe の例は、
172.26.27.229:80がservice-clusteripのアドレスであることを示しています。このtargets値を持つ probe は 2 つあり、1 つは Pod（pod-service-clusterip）用、もう 1 つは Node（node-service-clusterip）用です。probe { name: "node-service-clusterip" … targets { host_names: "172.26.27.229:80" }
修正を検証する
報告されたすべての接続の問題に対処したら、nettest Pod を削除し、nettest マニフェストを再適用して接続のテストを再実行します。
たとえば、Ubuntu で nettest を再実行するには、次のコマンドを実行します。
kubectl -n nettest delete pod nettest
kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-samples/main/anthos-bm-utils/abm-nettest/nettest.yaml
nettest をクリーンアップする
テストが完了したら、次のコマンドを実行して nettest リソースをすべて削除します。
kubectl delete namespace nettest
kubectl delete clusterroles nettest:nettest
kubectl delete clusterrolebindings nettest:nettest