Kubernetes 网络问题 - 无法从外部访问服务节点端口答案

【问题标题】：Kubernetes networking issue - Service nodePort can't be reached externallyKubernetes 网络问题 - 无法从外部访问服务节点端口
【发布时间】：2017-05-19 16:16:53
【问题描述】：

我有一个 3x 节点 kubernetes 集群：node1（主）、node2 和 node3。我有一个当前计划在 node3 上的 pod，我希望将其暴露在集群外部。所以我有一个 nodePort 类型的服务，nodePort 设置为 30080。我可以在每个节点上本地成功地执行curl localhost:30080：node1、node2 和 node3。但在外部，curl nodeX:30080 仅适用于 node3。其他两个超时。 tcpdump 确认 node1 和 node2 正在接收请求但没有响应。

我怎样才能使这对所有三个节点都有效，这样我就不必跟踪 Pod 当前安排在哪个节点上？我最好的猜测是，这是一个 iptables 问题，如果源 IP 不是本地主机，我会错过 DNAT 流量的 iptables 规则。话虽如此，我不知道如何排除故障以确认这是问题，然后如何解决。似乎该规则应该自动存在。

这是我的设置的一些信息：
kube-ravi196：10.163.148.196
kube-ravi197：10.163.148.197
kube-ravi198：10.163.148.198
CNI：运河（法兰绒 + 印花布）
主机操作系统：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

请注意，来自节点 ravi-kube196 的 curl localhost 是成功的（404 很好）。

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

但尝试从集群外的机器卷曲 IP 失败：

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

然后尝试 curl 调度 pod 的节点 IP 工作。：

ravi@rmac2015:~$ curl 10.163.148.198:30080/test
404 page not found

这是我在 196 节点上为该服务/pod 设置的 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

来自 196 个节点的 kube-proxy 日志：

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

【问题讨论】：

您将无法从 master 访问该服务--您能否确认您无法从 10.163.148.197 访问该服务？
不，它在 197 和 196 （主）上超时。为什么你说我无法访问master的服务？据我了解，所有节点都应该将服务代理到调度了 pod 的节点。当我直接在主节点或任何小节点上运行curl localhost:30080 时，代理确实有效。只是在外部，它失败了。
抱歉——关于主节点的事情你是对的——我的错。

标签： networking kubernetes iptables flannel

【解决方案1】：

我找到了无法从外部访问服务的原因。这是因为 iptables FORWARD 链正在丢弃数据包。我在https://github.com/kubernetes/kubernetes/issues/39658 提出了一个关于 kubernetes 的问题，其中有更多细节。一个（糟糕的）解决方法是将默认的 FORWARD 策略更改为 ACCEPT。

1/10 更新

我向 Canal 提出了一个问题，https://github.com/projectcalico/canal/issues/31，因为它似乎是 Canal 特有的问题。转发到 flannel.1 接口的流量被丢弃。比将默认 FORWARD 策略更改为 ACCEPT 更好的解决方法是为 flannel.1 接口添加一条规则。 sudo iptables -A FORWARD -o flannel.1 -j ACCEPT.

【讨论】：