记一次问题排查:为什么在POD无法通过Service访问自己?

目录

问题现象

创建一个nginx pod,并配置了service访问,service后端指向pod。

进入pod中使用service ip 或者service 域名,无法访问。

一开始以为是环境配置或者k8s版本(1.9)的问题,在其他1.13的kubernetes环境下也试了,还是同样的问题。

环境配置

使用的cni插件是flannel,但不是容器化安装,也不是标准化的通过kubelet指定cni plugin(–cni-bin-dir,–cni-conf-dir参数),而是通过dockerd 提供的-bip参数指定容器的子网,而这个值是从/run/flannel/subnet.env(flannel会将获取到的子网写入到该文件)

排查过程

1、首先尝试通过pod ip尝试是否可访问,已验证是可通的。

2、尝试对docker0网桥进行抓包

1
tcpdump -i docker0

神奇的在这里,再次尝试通过service 访问是居然可以通,发现只要tcpdump断开就不行了。

到这里的时候有点觉得诡异了

在pod内通过service访问的时候网络的流向应该是

1
pod内部访问service->docker0网桥->宿主机的iptables规则->docker0网桥->pod内部

查阅了相关资料后,看到kubelet有个--hairpin-mod参数:

文档说明:

如果网络没有为“发夹模式”流量生成正确配置,通常当 kube-proxy 以 iptables 模式运行,并且 Pod 与桥接网络连接时,就会发生这种情况。Kubelet 公开了一个 hairpin-mode 标志,如果 pod 试图访问它们自己的 Service VIP,就可以让 Service 的端点重新负载到他们自己身上。hairpin-mode 标志必须设置为 hairpin-veth 或者 promiscuous-bridge。

可是我设置之后还是没有还是不行,翻了一下kubelet里面的代码,发现cni组件并没有取这个值做任何才做(在kubnet中有)

查看这个讨论: https://github.com/kubernetes/kubernetes/issues/45790

大致结论是,应该由cni插件来根据这个值来做对应的操作。

还是没解决我的问题?

不过我看到hairpin开启的标志位是通过/sys/devices/virtual/net/docker0/brif/veth-xxx/hairpin_mod 内容设置为1开启的。

所以我将所有veth该文件内容设置1

1
for intf in /sys/devices/virtual/net/docker0/brif/*; do echo 1> $intf/hairpin_mod; done

可以访问了。😺

解疑:promiscuous-bridge 与 hairpin-veth

为什么我无法访问

bridge不允许包从收到包的端口发出,比如这种情况,在pod内通过docker0访问service,后续又通过docker0网桥进来,所以需要开启hairpin_mod

为什么使用tcpdump 可以让访问可通?

因为tcpdump要抓取所有经过该网卡,所以需要开启混杂模式。可以在/var/log/message看到device docker0 entered promiscuous mode的log。

混杂模式(英語:promiscuous mode)是电脑网络中的术语。 是指一台机器的网卡能够接收所有经过它的数据流,而不论其目的地址是否是它。 一般计算机网卡都工作在非混杂模式下,此时网卡只接受来自网络端口的目的地址指向自己的数据。 当网卡工作在混杂模式下时,网卡将来自接口的所有数据都捕获并交给相应的驱动程序。

手动开关命令: ifconfig docker0 promisc on/off

总结

其实我们集群通过这种比较另类的方式来分配POD IP也用了了很久了,之所以没出问题,应该是业务基本没遇到这种pod内通过service访问自己的情况。

所以还是要跟着标准的k8s方式来安装cni,避免入坑,比如flannel就已经提供给了hairpinMode 参数来进行配置开启。


关注公众号,获取最新文章推送