搭建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】很快确定问题在哪了。