calico node status显示为分别显示为Passive和Active Socket: Host is unreachable

搭建kubernetes集群时，三个节点，一个master，两个woker。

加入集群后，在woker节点通过calicoctl node status查询节点之间状态如下两图：

之所以不在master节点执行该查询命令，是因为执行时总报错。

从查询结果中可以看出，两个worker节点都与master节点成功建立连接，但它们俩之间却是不同的，并且显示的错误信息还不同。

这个存在了好长时间，一直解决不了，整个人都快被整郁闷了。

还好再快翻遍calico原理的情况，终于给解决了，现在记录下破案过程。

这个过程中一直重复了多遍节点的删除、初始化、加入集群、删除calico-node的过程，但都没有效果。

于是怀疑是IP-IN-IP模式的原因，把它禁掉后，除了多出好多路由外错误依旧。

此时终于明白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都不用，直接就连上了，一切正常。

抓紧看看官方文档咋说的。

果然需要放行，并且不同模式需要放行的端口还不一样。

终于弄清楚并解决了！！！

回顾整个破案过程，一直没解决的原因有两个。头一次弄，没经验，需要趟坑，这不算。

第一个是文档里说的，需要所有的host都放行179端口。不只是通过命令【kubectl apply –f calico.yaml】部署calico的主节点，还有所有的加入集群的worker都需要这样。除了ip地址最大的那个节点不用连别人，其它的都至少需要主动连接一个其它的节点。

第二个就是calico-node连接的问题。它在连接失败后就不再多次或重复尝试连接了，这样就无法通过命令【netstat –nt】很快确定问题在哪了。