第41章 OpenShift SDN のトラブルシューティング

SDN のドキュメントで説明されているように、あるコンテナーから別のコンテナーへのトラフィックを適切に渡すために作成されるインターフェースには複数のレイヤーがあります。接続の問題をデバッグするには、スタックの複数のレイヤーをテストして問題の原因を判別する必要があります。本書は複数のレイヤーを調べて問題を特定し、解決するのに役立ちます。

問題の原因の一部は OpenShift Container Platform が複数の方法で設定でき、ネットワークが複数の異なる場所で正しく設定されない可能性がある点にあります。本書では、いくつかのシナリオを使用しますが、これらのシナリオは大半のケースに対応していることが予想されます。実際に生じている問題がこれらのシナリオで扱われていない場合には、導入されている各種のツールおよび概念を使用してデバッグ作業を行うことができます。

以下の図は、外部アクセスに関係するすべての構成部分を示しています。

クラスター外のマシンを使用している場合で、クラスターで提供されるリソースにアクセスしようとしている場合、パブリック IP アドレスでリッスンし、クラスター内のトラフィックを「ルーティング」する Pod でプロセスが実行されている必要があります。この場合、OpenShift Container Platform ルーターは、HTTP、HTTPS (SNI を使用)、WebSockets または TLS (SNI を使用) について使用できます。

クラスター外より HTTP サービスにアクセスできないことを想定し、障害が発生しているマシンのコマンドラインを使って問題を再現します。以下を実行します。

curl -kv http://foo.example.com:8000/bar    # But replace the argument with your URL

成功する場合は、正しい場所からバグを再現しているかどうかを確認します。サービスに機能する Pod と機能しない Pod が含まれる可能性もあります。したがって、「ルーターのデバッグ」 セクションを参照してください。

失敗した場合は、IP アドレスに対して DNS 名を解決します (ないことを想定します)。

dig +short foo.example.com                  # But replace the hostname with yours

IP アドレスが返されない場合は、DNS をトラブルシューティングする必要がありますが、これについては本書では扱いません。

次に ping -c address および tracepath address を使用して、ルーターホストに到達できることを確認します。それらが ICMP パケットに応答しない場合もあり、この場合はそれらのテストは失敗しますが、ルーターマシンにはアクセスできる場合があります。この場合、コマンドを使ってルーターのポートに直接アクセスしてみます。

telnet 1.2.3.4 8000

以下が表示される場合があります。

Trying 1.2.3.4...
Connected to 1.2.3.4.
Escape character is '^]'.

この場合、IP アドレスのポートでリッスンしているものがあることを示しています。ctrl-] を押してから enter キーを押し、close を入力して telnet を終了します。「ルーターのデバッグ」 セクションに移行してルーターの他のものを確認します。

または、以下が表示される可能性があります。

Trying 1.2.3.4...
telnet: connect to address 1.2.3.4: Connection refused

これは、ルーターがそのポートでリッスンしていないことを示します。ルーターの設定方法における追加のポイントについては、「ルーターのデバッグ」セクションを参照してください。

または、以下が表示される場合があります。

Trying 1.2.3.4...
  telnet: connect to address 1.2.3.4: Connection timed out

これは、IP アドレス上のいずれとも通信できないことを示します。ルーティング、ファイアウォールを確認し、IP アドレスでリッスンしているルーターがあることを確認します。ルーターをデバッグするには、「ルーターのデバッグ」セクションを参照してください。IP ルーティングおよびファイアウォールの問題については、本書では扱いません。

IP アドレスを使用し、そのマシンに対して ssh を実行してルーターソフトウェアがそのマシン上で実行されており、正しく設定されていることを確認する必要があります。ここで ssh を実行し、管理者の OpenShift Container Platform 認証情報を取得します。

$ oc login -u system:admin -n default

ルーターが実行されていることを確認します。

# oc get endpoints --namespace=default --selector=router
NAMESPACE   NAME              ENDPOINTS
default     router            10.128.0.4:80

このコマンドが失敗する場合、OpenShift Container Platform 設定は破損しています。この設定の修正については、本書では扱われません。

1 つ以上のルーターエンドポイントが一覧表示されますが、エンドポイント IP アドレスはクラスター内の Pod アドレスの 1 つであるため、それらが指定の外部 IP アドレスでマシン上で実行されているかどうかを識別することはできません。ルーターホスト IP アドレスの一覧を取得するには、以下を実行します。

# oc get pods --all-namespaces --selector=router --template='{{range .items}}HostIP: {{.status.hostIP}}   PodIP: {{.status.podIP}}{{end}}{{"\n"}}'
HostIP: 192.168.122.202   PodIP: 10.128.0.4

外部アドレスに対応するホスト IP が表示されるはずです。表示されない場合は、ルーターのドキュメントを参照して、適切なノードで実行されるようにルーター Podを設定するか (アフィニティーを適切に設定する)、またはルーターが実行されている IP アドレスに一致するよう DNS を更新します。

(本書の) この時点では、ノードでルーター Pod を実行しても HTTP 要求を機能させることはできません。まず、ルーターが外部 URL を正しいサービスにマップしていること、またそれが機能している場合は、そのサービスの詳細を調べてすべてのエンドポイントがアクセス可能であることを確認する必要があります。

OpenShift Container Platform が認識するすべてのルートを一覧表示します。

# oc get route --all-namespaces
NAME              HOST/PORT         PATH      SERVICE        LABELS    TLS TERMINATION
route-unsecured   www.example.com   /test     service-name

URL のホスト名およびパスが返されるルートの一覧のいずれにも一致しない場合はルートを追加する必要があります。ルーターのドキュメントを参照してください。

ルートが存在する場合、エンドポイントへのアクセスをデバッグする必要があります。これはサービスに関する問題をデバッグしている場合と同様のプロセスです。そのため、次の 「サービスのデバッグ」 セクションに進んでください。

クラスター内からサービスと通信できない場合 (サービスが直接通信できないか、またはルーターを使用していてクラスターに入るまですべてが正常に機能している場合)、サービスに関連付けられているエンドポイントを判別し、それらをデバッグする必要があります。

最初にサービスを取得します。

# oc get services --all-namespaces
NAMESPACE   NAME              LABELS                                    SELECTOR                  IP(S)            PORT(S)
default     docker-registry   docker-registry=default                   docker-registry=default   172.30.243.225   5000/TCP
default     kubernetes        component=apiserver,provider=kubernetes   <none>                    172.30.0.1       443/TCP
default     router            router=router                             router=router             172.30.213.8     80/TCP

サービスが一覧に表示されます。表示されない場合は、サービスを定義する必要があります。

サービス出力に一覧表示される IP アドレスは Kubernetes サービス IP アドレスであり、これは Kubernetes がサービスをサポートする Pod のいずれかにマップするものです。このの IP アドレスと通信できるはずですが、通信できたとしても、すべての Pod にアクセスできる訳ではありません。また、通信できない場合もすべての Pod がアクセスできない訳ではありません。これは kubeproxy が接続している 1 つ の IP アドレスのステータスのみを示しています。

サービスをテストします。ノードのいずれかより以下を実行します。

curl -kv http://172.30.243.225:5000/bar                  # Replace the argument with your service IP address and port

次にサービスをサポートしている Pod を見つけます (docker-registry を破損したサービスの名前に置き換えます)。

# oc get endpoints --selector=docker-registry
NAME              ENDPOINTS
docker-registry   10.128.2.2:5000

ここではエンドポイントは 1 つだけであることを確認できます。そのため、サービステストが成功し、ルーターテストに成功した場合には、極めて稀なことが生じている可能性があります。ただし、複数のエンドポイントがあるか、またはサービステストが失敗した場合には、それぞれの エンドポイントについて以下を試行します。機能していないエンドポイントを特定できたら、次のセクションに進みます。

最初に、それぞれのエンドポイントをテストします (適切なエンドポイント IP、ポートおよびパスを持つように URL を変更します)。

curl -kv http://10.128.2.2:5000/bar

これが機能する場合は、次のエンドポイントをテストします。失敗した場合はその情報をメモしておきます。次のセクションでその原因を判別します。

すべてが失敗した場合は、ローカルノードが機能していない可能があります。その場合は、「ローカルネットワークのデバッグ」 セクションに移行してください。

すべてが機能する場合は、「Kubernetes のデバッグ」 セクションに移行してサービス IP アドレスが機能しない理由を判別します。

機能していないエンドポイントの一覧を使用して、ノードに対する接続をテストする必要があります。

ノード間ネットワークの他のデバッグオプションについては、以下を確認して解決できます。

ノード間設定が適切であることを確認した後は、両サイドで SDN 設定を確認する必要があります。

ここで通信できないものの、ノード間通信が設定された 1 つ以上のエンドポイントの一覧が表示されます。それぞれのエンドポイントについて問題点を特定する必要がありますが、まずは SDN が複数の異なる Pod についてノードでネットワークをどのように設定しているかについて理解する必要があります。

# ip route
default via 192.168.122.1 dev ens3
10.128.0.0/14 dev tun0  proto kernel  scope link                        # This sends all pod traffic into OVS
10.128.2.0/23 dev tun0  proto kernel  scope link  src 10.128.2.1        # This is traffic going to local pods, overriding the above
169.254.0.0/16 dev ens3  scope link  metric 1002                        # This is for Zeroconf (may not be present)
172.17.0.0/16 dev docker0  proto kernel  scope link  src 172.17.42.1    # Docker's private IPs... used only by things directly configured by docker; not OpenShift
192.168.122.0/24 dev ens3  proto kernel  scope link  src 192.168.122.46 # The physical interface on the local subnet

# ovs-vsctl list-br
br0

# ovs-ofctl -O OpenFlow13 dump-ports-desc br0
OFPST_PORT_DESC reply (OF1.3) (xid=0x2):
 1(vxlan0): addr:9e:f1:7d:4d:19:4f
     config:     0
     state:      0
     speed: 0 Mbps now, 0 Mbps max
 2(tun0): addr:6a:ef:90:24:a3:11
     config:     0
     state:      0
     speed: 0 Mbps now, 0 Mbps max
 8(vethe19c6ea): addr:1e:79:f3:a0:e8:8c
     config:     0
     state:      0
     current:    10GB-FD COPPER
     speed: 10000 Mbps now, 0 Mbps max
 LOCAL(br0): addr:0a:7f:b4:33:c2:43
     config:     PORT_DOWN
     state:      LINK_DOWN
     speed: 0 Mbps now, 0 Mbps max

# ovs-ofctl -O OpenFlow13 dump-flows br0

Pod から外部サービスへのアクセスを試行する場合、以下の例のようになります。

curl -kv github.com

DNS が適切に解決されていることを確認します。

dig +search +noall +answer github.com

これにより、github サーバーの IP アドレスが返されるはずですが、正しいアドレスが返されていることを確認します。アドレスが返されない場合やお使いのマシンのいずれかのアドレスが返される場合、ローカル DNS サーバーのワイルドカードエントリーに一致している可能性があります。

これを修正するには、ワイルドカードエントリーを持つ DNS サーバーが /etc/resolv.conf の nameserver として一覧表示されていないことを確認するか、または ワイルドカードドメインが search 一覧に一覧表示されていないことを確認する必要があります。

正しい IP アドレスが返される場合、「ローカルネットワークのデバッグ」 の前述のデバッグに関するアドバイスに従ってください。通常、トラフィックはポート 2 の Open vSwitch から iptables ルールおよびルートテーブルを通過するはずです。

次を実行します: journalctl -u atomic-openshift-node.service --boot | less

Output of setup script: 行を検索します。'+' で始まるすべての行については、その下にスクリプト手順が記述されます。この部分で明らかなエラーがあるかどうかを調べます。

スクリプトを追ってみると、Output of adding table=0 という行を見つけることができるはずです。これは OVS ルールであり、エラーは存在しないはずです。

iptables -t nat -L を確認して、サービスがローカルマシンでkubeproxy の適切なポートに NAT されていることを確認します。

クラスター管理者として診断ツールを実行し、共通するネットワークの問題を診断します。

# oc adm diagnostics NetworkCheck

診断ツールは、指定したコンポーネントのエラー状態をチェックする一連のチェックを実行します。詳細は、「診断ツール」のセクションを参照してください。

デフォルトで、 oc adm diagnostics NetworkCheck はエラーのログを /tmp/openshift/ に記録します。これは --network-logdir オプションで設定できます。

# oc adm diagnostics NetworkCheck --network-logdir=<path/to/directory>