最近环境上碰到了一个k8s的节点挂掉了，node的status是not ready。接下来记一下过程 注意cni的目录记住以下几个目录会涉及到数据的修复

1
2
3
4

/etc/kubernetes
/var/run/calico
/var/log/calico/cni
/etc/cni/net.d

注意需要观察节点是否正常启动，尤其是kube-apiserver 很重要，关注apiserver是否正常启动。 注意出现的报错为 unable to connect to BIRDv4 socket: dial unix /var/run/bird/bird.ctl: connect : no such file or directory。 这是因为bird对应的目录下的配置文件没有正常生成，这个目录下文件的正常的生成需要靠apisever来提供，下载配置信息来进行配置，所以保证apiserver正常启动，才可以。 修复apiserver即可。 查找问题策略是看，cni的日志文件的报错信息，来进行定位到地方， 注意当calico的状态正常时，输入calico node status 得到的时如下图所示的状态 注意经常会碰到passive的状态，这是代表链路没有正常建立 一种原因是：179的端口是否被拦截 或者这个179的端口是否开启 此时终于明白IP-IN-IP的好处，通过它的封装，各个节点只需要其它节点就可以了，如果没有它，各个节点需要知道其它节点上的所有pod。

如果存在10个节点，每个节点上存在10个pod，采用IP-IN-IP模式，每个节点只需要建立10条到其它节点的路由即可，整个集群新增100条路由，但如果禁用IP-IN-IP模式，那每个节点都需要建立到其它所有pod的1000条路由，整个集群新增10000条路由。

继续来说破案。

Passive是被动的意思，那为什么节点会处于Passive？ 通过dashboard进入报Passive错误节点的calico-node中，执行【cat /etc/calico/confd/config/bird.cfg】，显示出了下图内容：

对于master节点（31.151），它不是Passive，而对于另一个worker节点（31.153）它却是【Passive on】。

这可能就是原因，但为什么这么区分？难道对于master类型特殊处理？

通过这个文件的注解行可知，这个配置文件是通过模板生成的。那生成的时候为什么要区别对待呢？

上源码！

模板文件的注解说的就比较清楚了，为了避免节点间同时向对方连接导致的路由抖动，采用一方被动一方主动方式。

那谁主动谁被动呢？

规则：【{{if gt $onode_ip $node_ip}}】。

也就是说谁ip地址小谁被动，谁ip地址大谁主动。

这也解释了在master节点的calico-node中，它的配置文件bird.cfg里，它相对于其它节点都是【Passive on】的，不是因为它的master身份，仅仅是因为它的ip地址最小。

这同时也明晰了一件事，那就是在calico-node启动时，根据配置文件，主动方会向【Passive on】方发起连接。

那去产生错误的主动方节点上看看有没有等待建立的连接？

咦？竟然没有向被动方（192.168.31.152）发起的连接请求？难道又搞错了？

再重启calico-node试试。

还是没用。

那是怎么回事？

既然已经和master（31.151）建立了连接，那看看都建立了那些连接？

179？好熟悉的端口。

记得在看calico配置的时候见过这个端口，并且在master节点的防火墙上放行了这个端口。

难道152没开这个端口？赶紧去查查！

果然！开了防火墙，没放行这个端口。

抓紧加上，重启防火墙！

哈哈！果然是它！

开了179端口，连重启calico-node都不用，直接就连上了，一切正常。