客戶側在變更容器安全組之後出現網路不通。
1）接到客戶反饋 kubernetes 託管版集群出現網路問題，**溝通後授權進行檢視：pod 網路通暢，網域名稱解析出現異常；（ping ip 可通，但ping網域名稱不通）
2）結合客戶操作，懷疑與安全組配置有關，嘗試進一步排查安全組問題。詳細排查無問題後，決定重啟 coredns pod。重啟後 coredns pod 漂移到其它 ecs上，集群中大部分主機恢復正常；
3）確認coredns原宿主機存在網路連線問題，將該主機踢出集群後，集群恢復正常；
4）經過環境測試後最終定位原因在於客戶側誤解 kubernetes 集群安全組頁面「解綁例項」功能為解綁安全組，導致誤操作解綁和繫結eni 網絡卡，同時產品健康檢查機制存在缺陷，無法探測到輔助網絡卡的鏈路問題，導致問題無法快速發現並解決，最終導致客戶集群網路無法聯通。
1）優化安全組頁面存在「解綁例項」功能文案，同時增加由 kubernetes 集群建立的網絡卡在使用者解綁時的風險提示，避免客戶誤操作引發業務中斷；
2）優化健康檢查機制，確保輔助網絡卡鏈路異常場景能夠被快速發現。
4.1 環境準備
1）kubernetes託管版集群，網路模式為terway，kube-proxy**模式為ipvs，四節點，需要建立測試的應用pod；
圖1：初始環境
2）檢視coredns所在的宿主機，目前該pod存在於201、200機器上；
圖2：coredns pod
4.2 具體操作
1）模擬客戶側的操作在安全組介面「解綁coredns所在主機的輔助網絡卡」；
登入ecs控制台--例項--選擇機器--本例項彈性網絡卡介面檢視
圖3：例項彈性網絡卡
跳轉至安全組介面---選擇集群的安全組例項id---安全組內彈性網絡卡--搜尋剛剛查詢的彈性網絡卡--解綁例項
圖4：安全組內彈性網絡卡
2）解綁完成之後再次將輔助網絡卡繫結至原有例項；
圖5：檢視原有例項網絡卡
3）登入任意乙個應用pod內，利用dig 測試解析是否正常
kubectl exec -it centos-deployment-75765fbb54-x5f6v -- /bin/bash，進入pod內：
圖6：pod內測試
上圖就是一開始客戶側遇到的現象：ping網域名稱不通，ping ip可以通。
4）為什麼解綁之後重新繫結至原有例項還是不可以呢？原因就在於解綁後重新繫結網絡卡後該網絡卡的state仍然是down狀態，需要重新up網絡卡；
up網絡卡：ip link set eth1 up
圖7：up網絡卡
網絡卡在被up後，再次進入pod進行測試，會發現解析就可以正常執行了。
圖8：up網絡卡後測試
其實kube-dns後有兩個coredns pod，那麼這兩個coredns是採取什麼策略去提供解析服務呢？
利用ipvsadm可以看到coredns是按照rr的方式去提供服務的，並且設定了session的超時保持時間是10800（超時時間可以通過檢視kube-dns的yaml檔案）：
圖9：kube-dns的session時間
正是因為上述kube-dns的session的保持時間設定了10800，導致網域名稱解析的請求一直都是尋找壞的coredns pod（如coredns也就是被解綁後重新繫結輔助網絡卡的那台機器上的coredns），所以客戶側在解綁操作後續一直沒有無法進行正常解析，類似於下面的現象：
圖10：長ping失敗現象
測試下去掉該session設定，再次進行網域名稱解析測試（修改kube-dns svc的yaml中的sessionaffinity為none）：
圖11：svc yaml
圖12：dig圖
圖13：tcpdump抓包
所以修改sessionaffinity為none後，第一次的解析會走好的coredns，第二次請求就會走壞的coredns，這也就是證明coredns以rr策略提供服務的。
圖14：長ping正常現象
flip close Oops問題排查
1 問題描述 oops 1 cpu 0 0 00000000 00000001 64206e6f 838ceae0 4 838ceae0 83816140 00000001 00000007 8 0000080f 00000004 00000020 83934668 12 82fdb128 ffff...
404問題排查
當tomcat沒有日誌的時候，不一定訪問沒有到達tomcat 我們可以通過web.xml中的filter來攔截請求，把斷點打到第乙個filter smartfilterdispatcher 上，確定請求，然後檢視問題在 resource name add cust topic destination...
GC問題排查
一 使用jps檢視執行緒id 二 使用jstat gc 3331 250 20檢視gc情況，一般比較關注perm區的情況，檢視gc的增長情況。三 使用jstat gccause 額外輸出上次gc原因 四 使用jmap dump format b,file heapdump 3331生成堆轉儲檔案 五...