Kubernetesネットワークの問題 - サービスnodePortに外部から到達できません

Question

私は3xノードkubernetesクラスタnode1（master）、node2、node3を持っています。私はノード3で現在スケジュールされているポッドを持っています。これは、クラスタの外部に公開したいと思っています。だから私は30080にnodePortを設定してnodePort型のサービスを持っています。私は正常にcurl localhost:30080を各ノード上でローカルに実行できます：node1、node2、node3。しかし、外部では、curl nodeX:30080はnode3に対してのみ動作します。他の2つのタイムアウト。 tcpdumpはnode1とnode2が要求を受信して​​いるが応答していないことを確認します。

3ノードすべてでこの作業を行うにはどうすればいいですか？現在、どのノードが現在予定されているノードを追跡する必要はありませんか？私の最高の推測は、ソースIPがlocalhostでない場合、これはiptablesの問題で、DNATトラフィックへのiptablesルールがないことです。それは、私はこれが問題であることを確認するためにどのようにトラブルシューティングを行うべきか、それを修正する方法を知らないと言われています。そのルールは自動的にそこにあるはずです。

ここにいくつかの情報に私の設定です：
KUBE-ravi196：10.163.148.196
KUBE-ravi197：10.163.148.197
KUBE-ravi198：10.163.148.198
CNI：運河（フランネル+キャラコ）
ホストはOS：ノードラヴィ-kube196からローカルホストをカールのUbuntu 16.04
kubeadmを通じて設定クラスタ

$ kubectl get pods --namespace=kube-system -l "k8s-app=kube-registry" -o wide 
NAME      READY  STATUS RESTARTS AGE  IP    NODE 
kube-registry-v0-1mthd 1/1  Running 0   39m  192.168.75.13 ravi-kube198 

$ kubectl get service --namespace=kube-system -l "k8s-app=kube-registry" 
NAME   CLUSTER-IP  EXTERNAL-IP PORT(S)   AGE 
kube-registry 10.100.57.109 <nodes>  5000:30080/TCP 5h 

$ kubectl get pods --namespace=kube-system -l "k8s-app=kube-proxy" -o wide 
NAME    READY  STATUS RESTARTS AGE  IP    NODE 
kube-proxy-1rzz8 1/1  Running 0   40m  10.163.148.198 ravi-kube198 
kube-proxy-fz20x 1/1  Running 0   40m  10.163.148.197 ravi-kube197 
kube-proxy-lm7nm 1/1  Running 0   40m  10.163.148.196 ravi-kube196 

注（404良い）成功しました。

deploy@ravi-kube196:~$ curl localhost:30080/test 
404 page not found 

しかし、クラスタ外部のマシンからIPをカールしようとすると失敗します。

ravi@rmac2015:~$ curl 10.163.148.196:30080/test 
(hangs) 

その後ポッドが作品に予定されているノードのIP：

​​ をカールしようとしています

196ノードのiptablesルールがあります：

deploy@ravi-kube196:~$ sudo iptables-save | grep registry 
-A KUBE-NODEPORTS -p tcp -m comment --comment "kube-system/kube-registry:registry" -m tcp --dport 30080 -j KUBE-MARK-MASQ 
-A KUBE-NODEPORTS -p tcp -m comment --comment "kube-system/kube-registry:registry" -m tcp --dport 30080 -j KUBE-SVC-JV2WR75K33AEZUK7 
-A KUBE-SEP-7BIJVD3LRB57ZVM2 -s 192.168.75.13/32 -m comment --comment "kube-system/kube-registry:registry" -j KUBE-MARK-MASQ 
-A KUBE-SEP-7BIJVD3LRB57ZVM2 -p tcp -m comment --comment "kube-system/kube-registry:registry" -m tcp -j DNAT --to-destination 192.168.75.13:5000 
-A KUBE-SEP-7QBKTOBWZOW2ADYZ -s 10.163.148.196/32 -m comment --comment "kube-system/glusterfs-dynamic-kube-registry-pvc:" -j KUBE-MARK-MASQ 
-A KUBE-SEP-7QBKTOBWZOW2ADYZ -p tcp -m comment --comment "kube-system/glusterfs-dynamic-kube-registry-pvc:" -m tcp -j DNAT --to-destination 10.163.148.196:1 
-A KUBE-SEP-DARQFIU6CIZ6DHSZ -s 10.163.148.198/32 -m comment --comment "kube-system/glusterfs-dynamic-kube-registry-pvc:" -j KUBE-MARK-MASQ 
-A KUBE-SEP-DARQFIU6CIZ6DHSZ -p tcp -m comment --comment "kube-system/glusterfs-dynamic-kube-registry-pvc:" -m tcp -j DNAT --to-destination 10.163.148.198:1 
-A KUBE-SEP-KXX2UKHAML22525B -s 10.163.148.197/32 -m comment --comment "kube-system/glusterfs-dynamic-kube-registry-pvc:" -j KUBE-MARK-MASQ 
-A KUBE-SEP-KXX2UKHAML22525B -p tcp -m comment --comment "kube-system/glusterfs-dynamic-kube-registry-pvc:" -m tcp -j DNAT --to-destination 10.163.148.197:1 
-A KUBE-SERVICES ! -s 192.168.0.0/16 -d 10.106.192.243/32 -p tcp -m comment --comment "kube-system/glusterfs-dynamic-kube-registry-pvc: cluster IP" -m tcp --dport 1 -j KUBE-MARK-MASQ 
-A KUBE-SERVICES -d 10.106.192.243/32 -p tcp -m comment --comment "kube-system/glusterfs-dynamic-kube-registry-pvc: cluster IP" -m tcp --dport 1 -j KUBE-SVC-E66MHSUH4AYEXSQE 
-A KUBE-SERVICES ! -s 192.168.0.0/16 -d 10.100.57.109/32 -p tcp -m comment --comment "kube-system/kube-registry:registry cluster IP" -m tcp --dport 5000 -j KUBE-MARK-MASQ 
-A KUBE-SERVICES -d 10.100.57.109/32 -p tcp -m comment --comment "kube-system/kube-registry:registry cluster IP" -m tcp --dport 5000 -j KUBE-SVC-JV2WR75K33AEZUK7 
-A KUBE-SVC-E66MHSUH4AYEXSQE -m comment --comment "kube-system/glusterfs-dynamic-kube-registry-pvc:" -m statistic --mode random --probability 0.33332999982 -j KUBE-SEP-7QBKTOBWZOW2ADYZ 
-A KUBE-SVC-E66MHSUH4AYEXSQE -m comment --comment "kube-system/glusterfs-dynamic-kube-registry-pvc:" -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-KXX2UKHAML22525B 
-A KUBE-SVC-E66MHSUH4AYEXSQE -m comment --comment "kube-system/glusterfs-dynamic-kube-registry-pvc:" -j KUBE-SEP-DARQFIU6CIZ6DHSZ 
-A KUBE-SVC-JV2WR75K33AEZUK7 -m comment --comment "kube-system/kube-registry:registry" -j KUBE-SEP-7BIJVD3LRB57ZVM2 

ノードから210

KUBE-プロキシログ：

deploy@ravi-kube196:~$ kubectl logs --namespace=kube-system kube-proxy-lm7nm 
I0105 06:47:09.813787  1 server.go:215] Using iptables Proxier. 
I0105 06:47:09.815584  1 server.go:227] Tearing down userspace rules. 
I0105 06:47:09.832436  1 conntrack.go:81] Set sysctl 'net/netfilter/nf_conntrack_max' to 131072 
I0105 06:47:09.836004  1 conntrack.go:66] Setting conntrack hashsize to 32768 
I0105 06:47:09.836232  1 conntrack.go:81] Set sysctl 'net/netfilter/nf_conntrack_tcp_timeout_established' to 86400 
I0105 06:47:09.836260  1 conntrack.go:81] Set sysctl 'net/netfilter/nf_conntrack_tcp_timeout_close_wait' to 3600 

Answer 1

私はサービスが外部に到達できなかった理由の原因を発見しました。それは、iptablesのFORWARDチェーンがパケットをドロップしていたためです。私はhttps://github.com/kubernetes/kubernetes/issues/39658にkubernetesの問題を提起しました。 （貧弱な）回避策は、デフォルトのFORWARDポリシーをACCEPTに変更することです。

更新1/10

運河特定の問題のように見えるように私は、運河、https://github.com/projectcalico/canal/issues/31と問題を提起しました。 flannel.1インターフェイスに転送されるトラフィックは減少しています。デフォルトのFORWARDポリシーをACCEPTに変更するよりも、flannel.1インターフェースのルールを追加するほうが簡単です。 sudo iptables -A FORWARD -o flannel.1 -j ACCEPT。