搭建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】很快確定問題在哪了。