part1 初露端倪
part2 一波剛平一波又起
part3 慢=不可用
part4 問題的真相只有乙個！
所以pod 容器telnet不通雲資料庫3306埠的原因也真相大白了。因為pod telnet雲資料庫的資料報沒有走eth1，而是走了eth0，資料報傳送至雲資料庫後，雲資料庫的回包發給了pod的子網閘道器。sdn網路ovs判斷來包是從node子網閘道器發出（eth0），而回包卻是發往pod子網（eth1）源和目的位址不一致，因此將資料報丟棄。pod也就無法收到資料庫的回包了。之前可以ping通是因為icmp協議是代答的，即使源和目的位址不一致，也可以正常收到回包。
那麼，pod的所有網路請求正常是應該通過雲主機上的輔助網絡卡收發的，為什麼走了雲主機主網絡卡了呢？正常的k8s集群節點上配置了table 2路由規則，定義了pod的網路請求預設路由的下一跳是pod子網閘道器，並且走輔助網絡卡，如下圖所示
而在客戶的應用pod所在節點執行ip r show table 2，我們看到的結果和第一次抓包一樣，空空如也。。。路由是由k8s集群的網路外掛程式維護，路由缺失問題在網路外掛程式日誌中沒有發現任何線索，具體原因不得而知。當務之急是修復問題。
可以通過重啟ipamd容器恢復table 2路由。
執行docker ps | grep ipamd | grep sh找到ipamd的容器id，
然後執行docker restart 容器id重啟容器。
再次執行ip r show table 2，終於看到了路由規則！
finally，此時在應用pod內測試可以telnet通雲資料庫的3306埠。客戶的應用呼叫也終於可以成功返回結果。
然鵝，如果各位看官覺得這個case到這裡就結束了，那就和當時排障的攻城獅一樣圖樣圖森破了。
就在攻城獅以為一切都恢復正常時，客戶的追加反饋表明這個問題只是進入了下乙個階段。客戶反饋應用雖然可以正常呼叫，但是一次呼叫要超過一分鐘才能有返回結果，之前正常的速度是僅需幾秒就可以返回結果。現在這樣的速度完全不能滿足業務要求，相當於還是不可用的。問題尚未解決，攻城獅仍需努力！分析應用呼叫返回慢的問題，一是著眼於應用流程的各個環節，如客戶端，服務端對業務請求的處理時間，另外乙個就是排查資料傳輸鏈路是否有延遲。在客戶的場景下，就是確認pod和雲資料庫在處理請求上是否有瓶頸，還有就是pod到雲資料庫之間的網路傳輸是否有延遲。在pod內ping雲資料庫ip，沒有超時丟包，延遲很低。
要想確認pod和雲資料庫在處理請求時的時長，還是要依靠tcpdump工具抓包分析。於是我們在pod對資料庫發起一次完整的請求過程中，依然使用tcpdump -i eth1 host 10.176.46.4 -w /tmp/mysql.cap命令在pod所在節點抓包。將資料報取出後分析發現，一次完整的業務請求，pod會對資料庫做13次查詢。對比第一次查詢和最後一次查詢的時間，如圖所示
可以發現13次請求用了1分鐘左右，與業務呼叫耗時吻合。排查雲資料庫監控，發現記憶體
使用接近100%
同時例項慢查詢日誌中有大量慢sql記錄，可以看到幾乎每次查詢都耗時較長
可見如果業務呼叫的13次請求，每次都是慢查詢，耗時4秒左右，就會導致我們看到的完整請求耗時一分鐘左右。因此判斷瓶頸應該主要在雲資料庫上，建議客戶對資料庫慢查詢進行優化，降低記憶體負載。然後觀察應用呼叫時長是否恢復正常。
與客戶確認，客戶反饋oss網域名稱解析的ip貌似不對。在業務架構規劃時，為了保證客戶pod與oss的網路效能，配置了通過專線連線oss。當前解析的ip沒有走專線網段，而是走了普通的網段，無法滿足效能要求。正常走專線的網域名稱解析ip應該是10.219.226.2。但是網域名稱解析為什麼會出現問題呢？
各位童鞋是否還記得part1中我們提到客戶的pod使用的是kube-dns提供的dns解析，而kube-dns配置的上游伺服器是客戶自建的dns伺服器？經過客戶測試發現，自建dns伺服器對oss網域名稱的解析就是100.64.249.132。應該是近期客戶側維護dns伺服器的時候誤操作修改了解析導致的。。。將自建dns伺服器的網域名稱解析位址修改回正確位址後。再次在pod內測試，結果如下
再次測試應用呼叫，終於恢復到了正常的時長！可喜可賀！
至此客戶的問題卍解，總結問題排查過程，有幾點值得分享：
1、 k8s集群如果使用kube-dns服務，coredns pod務必配置多副本，避免單點故障導致集群dns服務不可用。
2、 排查k8s集**od網路問題時，可以在pod所在節點抓取pod使用的輔助網絡卡的相應網路資料報，避免直接在pod內抓包。
3、 應用系統效能排查涉及到各個節點裝置和網路傳輸，務必了解清楚完整的系統架構，呼叫流程，再針對涉及的每個環節逐一分析。
一鍵部署k8s集群（四）
本教程是 fabric實戰教程之一步步走向生產 系列教程的第四篇，主要介紹k8s的一鍵部署，為後面章節搭建生產級的fabric網路做準備。簡介 基於docker部署最簡fabric網路 基於docker部署多機fabric網路 一鍵部署k8s集群 基於helm一鍵部署fabric網路 國內網路下的網...
k8s一次滾動更新的異常
問題來自於乙個朋友，不是筆者親身經歷 由於kube apiserver的日誌中同樣無法提取出能夠幫助解決問題的有用資訊，起初我們只能猜測可能是kube apiserver的快取更新異常導致的。正要從這個切入點解決問題的時候，有乙個詭異的問題 建立的pod無法通過kubectl 查詢到 那麼問題來了 ...
k8s集群安裝 一 安裝方案介紹
目前k8s的安裝大概可以分為三種情況使用二進位制檔案安裝 kubeadm 廠商整合。官方文件 使用現成的二進位制檔案 所謂的二進位制檔案也就是一些三方打包好的映象安裝方式，還有早起kube的原始碼安裝方式都歸納到此。原始碼安裝就不說了，我接觸k8s的時候剛好出了kubeadm，所以嘗試了一次失敗後就...