1.問題描述
客戶側在變更容器安全組之後出現網絡不通。
2.問題排查
1）接到客戶反饋 Kubernetes 託管版集群出現網絡問題，電話溝通後授權進行查看：Pod 網絡通暢，域名解析出現異常；（ping IP 可通，但ping域名不通）
2）結合客戶操作，懷疑與安全組配置有關，嘗試進一步排查安全組問題。詳細排查無問題後，決定重啟 coredns POD。重啟後 coredns POD 漂移到其它 ECS上，集群中大部分主機恢復正常；
3）確認coredns原宿主機存在網絡連接問題，將該主機踢出集群后，集群恢復正常；
4）經過環境測試後最終定位原因在於客戶側誤解 Kubernetes 集群安全組頁面“解綁實例”功能為解綁安全組，導致誤操作解綁和綁定ENI 網卡，同時產品健康檢查機制存在缺陷，無法探測到輔助網卡的鏈路問題，導致問題無法快速發現並解決，最終導致客戶集群網絡無法聯通。
3.優化改進
1）優化安全組頁面存在“解綁實例”功能文案，同時增加由 Kubernetes 集群創建的網卡在用戶解綁時的風險提示，避免客戶誤操作引發業務中斷；
2）優化健康檢查機制，確保輔助網卡鏈路異常場景能夠被快速發現。
4.問題復現
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 baidu.com測試解析是否正常
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是採取什麼策略去提供解析服務呢？
5.問題分析
利用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正常現象
我們是阿里雲智能全球技術服務-SRE團隊，我們致力成為一個以技術為基礎、面向服務、保障業務系統高可用的工程師團隊；提供專業、體系化的SRE服務，幫助廣大客戶更好地使用雲、基於雲構建更加穩定可靠的業務系統，提升業務穩定性。我們期望能夠分享更多幫助企業客戶上雲、用好雲，讓客戶雲上業務運行更加穩定可靠的技術，您可用釘釘掃描下方二維碼，加入阿里雲SRE技術學院釘釘圈子，和更多雲上人交流關於雲平臺的那些事。
