- 刚刚解决了这个莫名其妙的问题,一个k8s集群,里面有3个节点,算上master总共4个,日子过得其乐融融
- 闲着没事加入了一个小四进去,然后就莫名其妙的出了问题,小四上面的pod不能域名解析
- 首先考虑的就是iptables有问题,所以想办法来调试iptables,查看正常的和不正常的节点,访问
cluster ip
有什么不同,于是学习了如何对某个连接进行跟踪,以查看它到底经历了怎样的艰辛才走出防火墙
- 加载netfilter的log模块:
modprobe nf_log_ipv4
- 开启nf的日志记录:
sysctl net.netfilter.nf_log.2=nf_log_ipv4
- 检查
/etc/rsyslog.conf
文件中的 kern.*
是否配置到了输出文件 - 重启rsyslog
systemctl restart rsyslog
- 在防火墙的
raw
链上,加入想要追踪的条件。raw链只在 PREROUTING
和 OUTPUT
两个过程中生效。如 iptables -t raw -j TRACE -p tcp --dport 80 -I PREROUTING 1
- 然后就可以在配置的kern.*文件中查看日志了,详细记载了请求走过的链、
- 没啥效果,感觉k8s的节点应该是先从
ServiceName
解析成 ClusterIP
,再由防火墙转换成 Pod IP
,然后再由 Pod Network Plugin
转换成 Real IP
。所以我这一通折腾没啥意义,看起来都是转换成了Pod IP
- 接下来是考虑到了,应该是
Pod IP
转换成 Real IP
的过程中,出了问题。
- 我当时使用的是
calico
作为Pod的网络插件,calico使用的是BGP协议,听起来挺厉害,hhh kubectl get pod -A -o wide
,查看所有的Pod,发现里面有个 calico-xxxxxx,状态是 1/2
,说明有一个没启动起来- 登录到k8s集群的MASTER,在这个链接中,找到指引,下载
calicoctl
,根据这个页面的指引,来配置一个文件 /etc/calico/calicoctl.cfg
,模板就在页面上 - 运行
./calicoctl node status
,发现有个节点的IP明显有问题,是什么 172.17.0.1
还是啥,扯犊子的 - 用
./calicoctl get node NODENAME -o yaml > now.yaml
,编辑这个文件,删除包括 TimeStamp
一类的“独有的”内容,仅仅保留必要的部分(如果不做删减,会出现update conflict);更新IP为正确的 - 运行
./calicoctl apply -f now.yaml
,更新成功
本文链接:
https://omen.ltd/archives/5/