库伯内特斯吊舱没有出站互联网

Question

我目前有一个具有两个节点的集群：

• node1 - 192.168.1.20 (硕士、工人)
• node2- 192.168.1.30 (工人)

在任何一个节点上运行结荚时，都没有出站互联网连接。

这个问题似乎与DNS无关，因为即使点击google.com的公共IP地址也不起作用。

pod1-node1$  traceroute to google.com (216.58.215.46), 30 hops max, 46 byte packets
 1  192-168-1-20.kubernetes.default.svc.home-cloud.local (192.168.1.20)  0.008 ms  0.009 ms  0.009 ms
 2  *

节点可以上网，所有的东西都可以在那里工作。

node1$ ping 216.58.215.46 -> OK
node2$ ping 216.58.215.46 -> OK

主节点上的Ip表：

-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT
-N DOCKER
-N DOCKER-INGRESS
-N KUBE-FIREWALL
-N KUBE-KUBELET-CANARY
-N KUBE-LOAD-BALANCER
-N KUBE-MARK-DROP
-N KUBE-MARK-MASQ
-N KUBE-NODE-PORT
-N KUBE-POSTROUTING
-N KUBE-SERVICES
-A PREROUTING -m comment --comment "kubernetes service portals" -j KUBE-SERVICES
-A PREROUTING -m addrtype --dst-type LOCAL -j DOCKER-INGRESS
-A PREROUTING -m addrtype --dst-type LOCAL -j DOCKER
-A OUTPUT -m comment --comment "kubernetes service portals" -j KUBE-SERVICES
-A OUTPUT -m addrtype --dst-type LOCAL -j DOCKER-INGRESS
-A OUTPUT ! -d 127.0.0.0/8 -m addrtype --dst-type LOCAL -j DOCKER
-A POSTROUTING -m comment --comment "kubernetes postrouting rules" -j KUBE-POSTROUTING
-A POSTROUTING -o docker_gwbridge -m addrtype --src-type LOCAL -j MASQUERADE
-A POSTROUTING -s 172.17.0.0/16 ! -o docker0 -j MASQUERADE
-A POSTROUTING -s 172.18.0.0/16 ! -o docker_gwbridge -j MASQUERADE
-A POSTROUTING -s 172.17.0.2/32 -d 172.17.0.2/32 -p tcp -m tcp --dport 9000 -j MASQUERADE
-A POSTROUTING -s 172.17.0.3/32 -d 172.17.0.3/32 -p udp -m udp --dport 34197 -j MASQUERADE
-A POSTROUTING -s 172.17.0.3/32 -d 172.17.0.3/32 -p tcp -m tcp --dport 27015 -j MASQUERADE
-A DOCKER -i docker0 -j RETURN
-A DOCKER -i docker_gwbridge -j RETURN
-A DOCKER ! -i docker0 -p tcp -m tcp --dport 9000 -j DNAT --to-destination 172.17.0.2:9000
-A DOCKER ! -i docker0 -p udp -m udp --dport 34197 -j DNAT --to-destination 172.17.0.3:34197
-A DOCKER ! -i docker0 -p tcp -m tcp --dport 27015 -j DNAT --to-destination 172.17.0.3:27015
-A DOCKER-INGRESS -p tcp -m tcp --dport 3306 -j DNAT --to-destination 172.18.0.2:3306
-A DOCKER-INGRESS -p tcp -m tcp --dport 9980 -j DNAT --to-destination 172.18.0.2:9980
-A DOCKER-INGRESS -j RETURN
-A KUBE-FIREWALL -j KUBE-MARK-DROP
-A KUBE-LOAD-BALANCER -j KUBE-MARK-MASQ
-A KUBE-MARK-DROP -j MARK --set-xmark 0x8000/0x8000
-A KUBE-MARK-MASQ -j MARK --set-xmark 0x4000/0x4000
-A KUBE-NODE-PORT -p tcp -m comment --comment "Kubernetes nodeport TCP port for masquerade purpose" -m set --match-set KUBE-NODE-PORT-TCP dst -j KUBE-MARK-MASQ
-A KUBE-POSTROUTING -m comment --comment "Kubernetes endpoints dst ip:port, source ip for solving hairpin purpose" -m set --match-set KUBE-LOOP-BACK dst,dst,src -j MASQUERADE
-A KUBE-POSTROUTING -m mark ! --mark 0x4000/0x4000 -j RETURN
-A KUBE-POSTROUTING -j MARK --set-xmark 0x4000/0x0
-A KUBE-POSTROUTING -m comment --comment "kubernetes service traffic requiring SNAT" -j MASQUERADE --random-fully
-A KUBE-SERVICES -m comment --comment "Kubernetes service lb portal" -m set --match-set KUBE-LOAD-BALANCER dst,dst -j KUBE-LOAD-BALANCER
-A KUBE-SERVICES ! -s 10.233.64.0/18 -m comment --comment "Kubernetes service cluster ip + port for masquerade purpose" -m set --match-set KUBE-CLUSTER-IP dst,dst -j KUBE-MARK-MASQ
-A KUBE-SERVICES -m addrtype --dst-type LOCAL -j KUBE-NODE-PORT
-A KUBE-SERVICES -m set --match-set KUBE-CLUSTER-IP dst,dst -j ACCEPT
-A KUBE-SERVICES -m set --match-set KUBE-LOAD-BALANCER dst,dst -j ACCEPT

从舱内我得到一个奇怪的ip路由结果。我的对接覆盖网络是'10.233.64.0/18‘配置了水布。

pod1-node1$ ip route
default via 169.254.1.1 dev eth0 
169.254.1.1 dev eth0 scope link

我也安装了metallb，它安装了一个kube代理，但不确定它到底是如何工作的，或者它是否与问题有关。

任何建议都是非常感谢的。干杯，亚历克斯

编辑:集群是裸金属，安装了祈祷，我还没有手动安装任何CNI

Answer 1

原来是Calico的一个窃听器。

我手动地将我的祈祷中的纸版设置为3.22.1，问题就解决了。

然后，我遇到了节点之间的其他连接问题，并选择使用法兰绒。从那以后一切都很好。

经过一周的研究，我给别人的建议是：

• 容器网络是艰难的

慢慢来，不要偷工减料！如果你缺少一些关于某一主题的知识--在继续之前，停止并至少学习该主题的基础知识。

• 诊断您的问题最常见的是DNS或数据包路由：

。

在另一台机器上获取google.com的IP，并在一个pod中对IP进行ping --如果它工作正常，那么如果它不相关的话，您就有一个DNS问题(数据包路由)。

• 学习解决方案如何工作以及如何配置

。

这将允许您检查什么DNS实际使用在您的节点和您的吊舱内。

• 了解kubernetes DNS的工作原理以及需要它的原因：

它允许吊舱服务于通讯和其他工作。它还需要上游DNS地址，以便能够解决集群之外的问题。

• 学习IP表如何工作以及伪装如何工作

它允许您了解如何使用网桥接口在节点和豆荚之间路由网络数据包。

• 学习什么是桥接口

docker0桥接口允许您的所有容器(以及扩展的豆荚)与外部世界对话。

• 阅读了这篇关于calico如何与您的IP表交互以动态创建nat伪装规则的文章：

。

https://medium.com/@bikramgupta/pod-network-troubleshooting-while-using-calico-on-kubernetes-ee78b731d4d8