39.6. ノード間通信のデバッグ
機能していないエンドポイントの一覧を使用して、ノードに対する接続をテストする必要があります。
すべてのノードに予想される IP アドレスがあることを確認します。
# oc get hostsubnet NAME HOST HOST IP SUBNET rh71-os1.example.com rh71-os1.example.com 192.168.122.46 10.1.1.0/24 rh71-os2.example.com rh71-os2.example.com 192.168.122.18 10.1.2.0/24 rh71-os3.example.com rh71-os3.example.com 192.168.122.202 10.1.0.0/24
DHCP を使用している場合はそれらが変更されている可能性があります。ホスト名、IP アドレス、およびサブネットが予想される内容に一致していることを確認します。ノードの詳細が変更されている場合は、
oc edit hostsubnetを使用してエントリーを訂正します。ノードアドレスおよびホスト名が正しいことを確認した後に、エンドポイント IP およびノード IP を一覧表示します。
# oc get pods --selector=docker-registry \ --template='{{range .items}}HostIP: {{.status.hostIP}} PodIP: {{.status.podIP}}{{end}}{{"\n"}}' HostIP: 192.168.122.202 PodIP: 10.128.0.4以前にメモしたエンドポイント IP アドレスを見つけ、これを
PodIPエントリーで検索し、対応するHostIPアドレスを見つけます。次に、HostIPからのアドレスを使用してノードホストレベルで接続をテストします。-
ping -c 3 <IP_address>: 応答がないことは、中間ルーターが ICMP トラフィックを消費している可能性があることを意味しています。 tracepath <IP_address>: ICMP パケットがすべてのホップによって返される場合、ターゲットにつながる IP ルートを表示します。tracepathとpingの両方が失敗する場合、ローカルまたは仮想ネットワークの接続の問題を探します。
-
ローカルネットワークの場合は、以下を確認します。
追加設定なしの状態のパケットのターゲットアドレスへのルートを確認します。
# ip route get 192.168.122.202 192.168.122.202 dev ens3 src 192.168.122.46 cache上記の例では、ソースアドレスが
192.168.122.46のens3という名前のインターフェイスから、ターゲットに直接つながります。これが予想される結果である場合はip a show dev ens3を使用してインターフェイスの詳細を取得し、このインターフェイスが予想されるインターフェイスであることを確認します。または、結果が以下になる可能性もあります。
# ip route get 192.168.122.202 1.2.3.4 via 192.168.122.1 dev ens3 src 192.168.122.46
これは、正しくルーティングされるために
via値をパススルーします。トラフィックが正しくルーティングされていることを確認します。ルートトラフィックのデバッグについては、本書では扱われません。
ノード間ネットワークの他のデバッグオプションについては、以下を確認して解決できます。
-
両端にイーサネットリンクはありますか ?
ethtool <network_interface>の出力で、Link detected: yesを検索します。 -
デュプレックス設定とイーサネット速度は、両端で正しく設定されていますか ?残りの
ethtool <network_interface>情報を確認します。 - ケーブルは適切にプラグインされていますか ?正しいポートにプラグインされていますか ?
- スイッチは適切に設定されていますか ?
ノード間設定が適切であることを確認した後は、両サイドで SDN 設定を確認する必要があります。
