＊內容提要：
1. Kube-proxy長連線優雅斷開機制及IPVS模式實現
2. 10/29--11/19 bug fix彙總分析
3. 1.9.11重要bug fix彙總
在本週的跟蹤分析中，以1.11版本為例，共有9條bug fix，其中大部分是叢集部署、第三方雲提供商、測試相關的內容，與Kubernetes核心內容無關。而有一條Kube-proxy相關的bug fix比較重要，本文會作具體分析。
另外1.9版本已經停止維護，本週開始，將從1.9.11開始，持續更新1.9小版本的重要bug fix及簡單分析，敬請關注。
1 bug fix解讀
IPVS模式支援優雅刪除
背景
IPVS模式是Kube-proxy的代理模式之一，Kube-proxy在1.9開始引入IPVS模式，1.11宣佈該特性GA。關於IPVS模式的優勢和具體介紹可以檢視這篇文章：
基於IPVS的叢集內負載均衡深入解讀
IPVS模式得益於底層的底層的lvs，擁有高吞吐、低延時等諸多優勢，同樣也由於底層實現的差異，導致IPVS原生不能支援優雅刪除。
Pod的優雅刪除在kube-proxy層面是指，當pod刪除時，外部與該pod不能建立新的網路連結，但是外部與該pod已經存在的長連線也不會被馬上斷掉。這樣就允許pod內部的容器收到終止訊號後主動傳送斷鏈請求，實現長連線正常斷開。
問題分析
Kube-proxy的iptables和IPVS模式分別通過建立不同的規則實現流量service到後端例項的路由分發，其中iptables模式通過建立iptables規則實現，IPVS模式則是通過建立iptables規則和IPVS規則實現，具體規則建立邏輯可分別參見：
Iptables:https://github.com/kubernetes/kubernetes/blob/master/pkg/proxy/iptables/proxier.go#L780-L1318
IPVS: https://github.com/kubernetes/kubernetes/blob/master/pkg/proxy/ipvs/proxier.go#L760-L1048
Iptables原生支援連結延時斷開，即當iptables規則刪除時，新的連結不能建立，已經有的長連結鏈路也不會被主動刪除，因此iptables模式實現優雅刪除功能不需要任何的程式碼，以來底層機制即可。
IPVS卻並沒有這個機制，刪除IPVS規則後長連結也會馬上斷開。這導致很多原來的應用切換到IPVS模式時不能正常工作。
解決方案
為了解決這個問題，IPVS模式的程式碼需要有專門的機制處理pod刪除到長連線斷開，連結被徹底刪除這段時間的邏輯，其依賴的邏輯是：
IPVS後端的real server有權重機制，用於高階流量排程。當權重為0時，real server上已有的連結不會被斷開，也不會有新的連結被分發過來。
因此解決方案的基本思路是，當pod被刪除時，配置其對應的後端real server權重為0，等待到該real server的長連線全部斷開之後再將其刪除。
具體執行過程又會涉及到，比如real server還沒完全刪除期間重新新增該real server的問題，已刪除service的清理邏輯，系統自帶的權重為0的IPVS規則處理。
看具體程式碼實現，本bug fix新增了一個專門針對IPVS模式的GracefulTerminationManager，對外提供的主要方法如下：
// GracefulDeleteRS用於優雅刪除後端，替代原來的DeleteRS
// 該方法檢查對應RS的長連線，長連線存在的話則直接刪除RS，不存在的話將權重置為0並加入優雅刪除佇列
func GracefulDeleteRS(vs, rs) error
// InTerminationList用於檢視某個rs是否在刪除佇列中
func InTerminationList(uniqueRS string) bool
// MoveRSOutofGracefulDeleteList將某個RS從優雅刪除佇列移提前移除
func MoveRSOutofGracefulDeleteList(uniqueRS string) error
// Run建立一個協程，以1min為間隔，週期性檢查佇列中RS的長連線情況，一旦沒有長連線就將其刪除並移出佇列
func Run()
PR資訊
下面是該bug fix的PR號，大家感興趣的話可以去社群自行檢視原始PR，issue資訊，瞭解該bug fix的更多資訊。
2 一週bug fix資料分析
本週更新過去兩週（10月29號--11月19號）1.11版本的bug fix資料。
在關注的時間段，1.11版本有9條bug fix，其分佈情況如圖所示：
其中cloud、volume、cluster均為雲平臺提供商相關，包括gce、azure、vsphere等，test則是社群使用的e2e測試更新，也無需太多關注。Kube-proxy有一條bug fix，即我們上面詳細介紹的，該bug fix在1.11和1.12版本均有涉及，大家可以根據自己的需要，在1.11或者1.12的下個小版本及時升級修復。
Bug fix嚴重程度統計，2及以下的bug fix有8個，但主要是對特定的雲平臺會產生影響，如果沒有使用上述雲平臺，也不用在意。
3 1.9.11重要bug fix解讀
