K8S トラブルシューティングガイド: ネットワークの問題のトラブルシューティングのアイデア

1. はじめに

プライベート化された環境では、顧客のネットワークアーキテクチャや使用されるクラウドプラットフォームが異なり、K8S ネットワークでさまざまな問題が発生する可能性があります。この記事では、このような問題のトラブルシューティング方法とアイデアに焦点を当てており、関連するネットワーク基盤技術については説明しません。

環境説明

k8s ネットワークコンポーネントはデフォルトで flannel を使用するため、ここで説明するクラスターネットワークはすべて flannel です。ただし、他の CNI コンポーネントを使用している場合でも、トラブルシューティングのアイデアについてはこの記事を参照できます。

2. 異常なシナリオ

k8s クラスターネットワークが異常かどうかを判断するにはどうすればよいでしょうか?

クラスター内の多数のポッドが異常であったり、ログに DNS 解決の失敗が記録されていたり、ノード間のネットワーク接続が失敗していたりする場合は、クラスターネットワークが異常であると判断できます。

以下の方法でトラブルシューティングを行うことができます。いずれかのメソッドの結果が予期しないものである場合、k8s クラスターネットワークに異常があることが確認されます。

トラブルシューティングの手順

テストノードが互いにpingする

以下の手順に従ってください。

ノード名、podcidr、アドレスを照会して出力します。

 [root@localhost ~]# kubectl get nodes -o jsonpath='{range .items[*]}[name:{.metadata.name} , podCIDR:{.spec.podCIDR} , ipaddr:{.status.addresses[0].address}]{"\n"} {end}' [name:10.28.87.59 , podCIDR:172.27.1.0/24 , ipaddr:10.28.87.59] [name:10.28.87.60 , podCIDR:172.27.0.0/24 , ipaddr:10.28.87.60] [name:10.28.87.61 , podCIDR:172.27.2.0/24 , ipaddr:10.28.87.61] [name:10.28.87.62 , podCIDR:172.27.4.0/24 , ipaddr:10.28.87.62] [name:10.28.87.63 , podCIDR:172.27.3.0/24 , ipaddr:10.28.87.63] [name:10.28.87.64 , podCIDR:172.27.5.0/24 , ipaddr:10.28.87.64]

このコマンドはすべてのノードで実行する必要があります。デプロイメントマシンで ansible を使用して、上記のコマンドで取得した CIDR アドレスを呼び出し、ping 操作を実行できます。 seq はノードの数に応じて設定されます。

上記の結果から、合計 6 つの K8S ノードがあり、サブネットは 172.27.0 ～ 172.27.5 であることがわかります。

次のシェルスクリプトを使用して、ポッドサブネットをテストします。正常に動作した場合は、「up」と印刷されます。

 [root@localhost ~]# for ip in $(seq 0 5);do ping -c2 -W1 -q 172.27.$ip.1 2>1 &>/dev/null && echo "172.27.$ip.1 up" || echo "172.27.$ip.1 down";done 172.27.0.1 up 172.27.1.1 up 172.27.2.1 up 172.27.3.1 up 172.27.4.1 up 172.27.5.1 up

予期しない結果: 特定のノードで固定 ping 例外が発生した場合、対応するノード間のvxlan通信が異常であると考えられます。対応するノードのネットワークを確認するだけです。

TCP、UDPクエリ

これはすべてのノードで実行する必要があり、単一のマシン上で Ansible を使用して呼び出すことができます。

ping 操作は第 3 層操作に属します。一部の環境ではpingが禁止されているため、以下のコマンドで確認できます。

HTTP リクエストを使用して、coredns メトリックインターフェースにアクセスします。ステータスコード 200 は通常の動作を示し、ステータスコード 000 はネットワーク障害を示します。

 [root@CentOS76 ~]# kubectl get pods -n kube-system -o wide | grep coredns | awk '{print $6}' | xargs -i curl --connect-timeout 2 -o /dev/null -s -w "%{http_code}\n" http://{}:9153/metrics 200 200 200 200 200 200

DNS を使用して kubernetes.default アドレスを照会します。戻りがあれば正常ということになります。

 [root@localhost ~]# kubectl get pods -n kube-system -o wide | grep coredns | awk '{print $6}' | xargs -l nslookup -type=a kubernetes.default.svc.cluster.local Server: 172.27.2.23 Address: 172.27.2.23#53 Name: kubernetes.default.svc.cluster.local Address: 172.26.0.1 --------- Server: 172.27.1.131 Address: 172.27.1.131#53 Name: kubernetes.default.svc.cluster.local Address: 172.26.0.1 --------- Server: 172.27.3.57 Address: 172.27.3.57#53 Name: kubernetes.default.svc.cluster.local Address: 172.26.0.1 --------- Server: 172.27.0.29 Address: 172.27.0.29#53 Name: kubernetes.default.svc.cluster.local Address: 172.26.0.1 --------- Server: 172.27.5.53 Address: 172.27.5.53#53 Name: kubernetes.default.svc.cluster.local Address: 172.26.0.1 --------- Server: 172.27.4.65 Address: 172.27.4.65#53 Name: kubernetes.default.svc.cluster.local Address: 172.26.0.1 ---------

予期しない結果: DNS クエリは接続がタイムアウトしたことを報告します。サーバーにアクセスできず、curl は 000 を報告します。どちらもネットワーク異常が発生している可能性があることを示しています。

3. 異常なシナリオ

上記の方法でクラスターノードに異常があることを確認したら、次のアイデアを使用して 1 つずつ確認することができます。

ip_forwardカーネルは0にリセットされます
フランネル通信異常
ファイアウォールを有効にする
セキュリティソフトウェアが有効
ip_forward

用語集：ip_forwardはルーティング転送機能を表します。 0 の場合は無効になります。 1 に設定すると有効になります。 vxlan のクロスレイヤー 3 機能により、クラスターノードは、ターゲットホストが自身のものではないデータパケットを転送する必要があります。
影響範囲: この値を 0 に設定すると、ノード間通信異常が発生します。

原因: 展開中に、永続的な効果を確保するために、net.ipv4.ip_forward=1 が /etc/sysctl.conf に追加されます。

問題箇所: クラスターを再起動すると、ポッドに異常があり、ネットワークに接続されていないことがわかります。 tcmdump パケットキャプチャにより、フランネルトラフィックが正常であることがわかります。

処理

ローカルマシンのカーネルパラメータを照会し、すべてのノードで実行します。 Ansible を使用して、デプロイメントマシン上で呼び出すことができます。これは読み取り操作であり、安心して実行できます。

 [root@localhost ~]# sysctl -n net.ipv4.ip_forward 0

sysctl ロードチェーンを印刷すると、関連するカーネルパラメータが変更されるため、実稼働環境では禁止されています (ip_forward が 0 の場合は使用できます)。

 [root@localhost ~]# sysctl --system * Applying /usr/lib/sysctl.d/00-system.conf ... ...... * Applying /usr/lib/sysctl.d/10-default-yama-scope.conf ... ..... * Applying /usr/lib/sysctl.d/50-default.conf ... ....... * Applying /etc/sysctl.d/99-sysctl.conf ... ....... * Applying /etc/sysctl.conf ... .......

ip_forward を 0 に変更したファイルを見つけて、そのファイルを変更し、カーネルパラメータを再ロードします。例外は認められません。

 [root@localhost ~]# sysctl -p

フランネル通信異常

用語集：vxlan は vlan の拡張プロトコルです。第3層ネットワークを貫通して第2層、つまり大規模な第2層ネットワークを拡張できるオーバーレイネットワークです。デフォルトでは、flannel はカプセル化プロトコルとして vxlan を使用し、ポートは 8472 です。
影響範囲: ノード間通信異常。
問題箇所: UDP 8472 ポートをキャプチャすると、送信トラフィックのみがあり、受信トラフィックがないことがわかりました。これは、異常なフランネル VXLAN 通信として識別できます。
原因: セキュリティグループのブロック、vxlan ポートの競合、ネットワークカードの異常など。フランネル例外の原因は多数あるため、この記事では一般的な状況についてのみ説明します。特定の問題を具体的に分析することをお勧めします。
問題の処理: nc およびその他の関連コマンドを使用してテストします。パケットキャプチャ後に受信トラフィックが見つからず、他の UDP ポートが正常な場合は、ポートを変更できます。

ポートフィールドを追加し、通信ポートを 8475 に変更します。

 [root@localhost ~]# kubectl edit cm -n kube-system kube-flannel-cfg net-conf.json: | { "Network": "172.27.0.0/16", "Backend": { "Type": "vxlan", "Port": 8475 } }

変更後、関連するデーモンセットポッドを再起動する必要があります。

 [root@localhost ~]# kubectl get pods -n kube-system | grep flannel | xargs kubectl delete pods -n kube-system

ポートの変更が有効にならない場合は、host-gw を使用できます。イントラネット内のノードがレイヤー 2 で相互接続されている場合は、互換性が高くネットワーク効率の高い host-gw モードを使用できます。

 [root@localhost ~]# kubectl edit cm -n kube-system kube-flannel-cfg net-conf.json: | { "Network": "172.27.0.0/16", "Backend": { "Type": "host-gw", }

問題が見つからない場合は、パケットをキャプチャすることで問題を特定できます。

たとえば、coredns ネットワークにアクセスできない場合は、curl を使用してテストします。

 curl -I 10.187.1.24:9153/metrics

次に、別のウィンドウを開いてパケットをキャプチャします。

 tcpdump -nn -i flannel.1 host 10.187.1.24 and port 9153 -vv

ファイアウォールのトラブルシューティング

用語集: ここでのファイアウォールは、Cenots では firewalld、UOS では UFW と呼ばれる Linux ソフトウェアファイアウォールを指します。デフォルトのソフトウェアファイアウォールにより、関連するデータベースがブロックされます。
影響範囲: 特定のサービスへの異常なアクセスおよびクラスターノード間の異常な通信。
問題の場所: iptables チェーンを分析した結果、予期しないルールが見つかりました。これは、他のファイアウォールルールが存在することを意味します。
原因: お客様がセキュリティソフトウェアをインストールしたか、予期しないソフトウェアの動作が発生しました。
トラブルシューティング:

一般的に、ufw、public、zone はおそらくデフォルトのシステムファイアウォールです。

 [root@localhost ~]# iptables-save | egrep "^:" | egrep -v "KUBE|CNI|DOCKER" :FORWARD_IN_ZONES - [0:0] :FORWARD_IN_ZONES_SOURCE - [0:0] :FORWARD_OUT_ZONES - [0:0] :FORWARD_OUT_ZONES_SOURCE - [0:0]

Centos7 を例に、検出後に手動でシャットダウンします。

 [root@localhost ~]# systemctl stop firewalld

iptables FORWARD 転送チェーンは、ACCEPT ルールの上にある REJECT ルールを追加します。

ルールを削除した後は正常に動作します。

 iptables -D FORWARD -j REJECT --reject-with icmp-host-prohibited

一般的なセキュリティソフトウェアのトラブルシューティング。

 qaxsafed # 奇安信， sangfor_watchdog # 深信服安全软件YDservice #qcloud安全软件，影响pod和docker桥接网络Symantec #赛门铁克的安全软件start360su_safed #360安全软件gov_defence_service gov_defence_guard # ps aux | grep defence wsssr_defence_daemon # 奇安信服务器安全加固软件wsssr_defence_service wsssr_defence_agent #影响pod网络kesl #卡巴斯基安全软件，影响容器通信

用語集: Windows 環境と同様に、XC の背景には、Qi'anxin、Sangfor など、Linux 用のさまざまなセキュリティソフトウェアもあります。
影響の範囲: 特定のサービスアクセスの例外。
問題の場所: 上記のトラブルシューティング方法をすべて試した場合は、この方向でトラブルシューティングを行うことができます。
原因: 顧客のセキュリティソフトウェアがカーネルネットワークレイヤー内の対応する機能をフックし、関連するルールが特定のアプリケーションデータベースをフィルター処理した結果、例外が発生します。

<<: クラウドにおけるアプリケーションの依存関係の管理: 戦略とベストプラクティス

>>: クラウドコンピューティングの主なセキュリティリスク