Kubernetes源碼探疑：Pod IP泄露排查及解決

UK8S是UCloud推出的Kubernetes容器云產品，完全兼容原生API，為用戶提供一站式云上Kubernetes服務。我們團隊自研了CNI（Container Network Interface）網絡插件，深度集成VPC，使UK8S容器應用擁有與云主機間等同的網絡性能（目前最高可達10Gb/s, 100萬pps），并打通容器和物理云/托管云的網絡。過程中，我們解決了開源kubelet創建多余Sandbox容器導致Pod IP莫名消失的問題，確保CNI插件正常運行，并準備將修復后的kubelet源碼提交給社區。

深度集成VPC的網絡方案

按照我們的設想，開發者可以在UK8S上部署、管理、擴展容器化應用，無需關心Kubernetes集群自身的搭建及維護等運維類工作。UK8S完全兼容原生的Kubernetes API， 以UCloud 公有云資源為基礎， 通過自研的插件整合打通了ULB、UDisk、EIP等公有云網絡和存儲產品，為用戶提供一站式云上Kubernetes服務。

其中VPC既保障網絡隔離，又提供靈活的IP地址定義等，是用戶對網絡的必備需求之一。UK8S研發團隊經過考察后認為，UCloud基礎網絡平臺具有原生、強大的底層網絡控制能力，令我們能拋開Overlay方案，把VPC的能力上移到容器這一層，通過VPC的能力去實現控制和轉發。 UK8S每創建一個Pod都為其申請一個VPC IP并通過VethPair配置到Pod上，再配置策略路由。 原理如下圖所示。

cdn.xitu.io/2019/4/12/16a108f5ce1ae05e?w=640&h=329&f=jpeg&s=18936">

此方案具有以下優勢：

無Overlay，網絡性能高。50臺Node下的測試數據表明，容器與容器之間的網絡性能，相對于云主機與云主機之間，只有輕微差異（小包場景下，pps 會有 3~5% 損耗），而且Pod網絡性能各項指標(吞吐量，包量，延遲等)不會隨著節點規模增大而削減。而Flannel UDP，VXLan模式和Calico IPIP的模式存在明顯的性能消耗。
Pod能直通公有云和物理云。對于使用公有云和物理云的用戶而言，業務上K8S少了一層障礙，多了一份便利。而Flannel的host gw模式下，容器無法訪問公有云和物理云主機。
而CNI的工作流程如下所示。

創建Pod網絡過程：

刪除Pod網絡過程：

Pod IP 消失問題的排查與解決

為了測試CNI插件的穩定性，測試同學在UK8S上部署了一個CronJob，每分鐘運行一個Job任務，一天要運行1440個任務。該CronJob定義如下：

apiVersion: batch/v1beta1 kind: CronJob metadata: name: hello spec: schedule: "/1 *" jobTemplate: spec: template: spec: containers: - name: hello image: busybox args: - /bin/sh - -c - date; echo Hello from the Kubernetes cluster restartPolicy: OnFailure

每運行一次Job都要創建一個Pod， 每創建一個Pod，CNI插件需要申請一次VPC IP，當Pod被銷毀時，CNI插件需要釋放該VPC IP。 因此理論上，通過該CronJob每天需要進行1440次申請VPC IP和釋放VPC IP操作。

然而，經過數天的測試統計，發現通過該CronJob，集群每天申請IP次數高達2500以上， 而釋放的的IP次數也達到了1800。申請和釋放次數都超過了1440，而且申請次數超過了釋放次數，意味著，部分分配給Pod的VPC IP被無效占用而消失了。

CNI：待刪除的IP去哪兒了？

仔細分析CNI插件的運行日志，很快發現，CNI在執行拆除SandBox網絡動作（CNI_COMMAND=DEL）中，存在不少無法找到Pod IP的情況。由于UK8S 自研的CNI查找Pod IP依賴正確的Pod網絡名稱空間路徑(格式：/proc/10001/net/ns)，而kubelet傳給CNI的NETNS環境變量參數為空字符串，因此，CNI無法獲取待釋放的VPC IP，這是造成IP泄露的直接原因，如下圖所示。

問題轉移到kubelet， 為什么kubelet會傳入一個空的CNI_NETNS環境變量參數給CNI插件？

隨后跟蹤kubelet的運行日志，發現不少Job Pod創建和銷毀的時候，生成了一個額外的Sandbox容器。Sandbox容器是k8s pod中的Infra容器，它是Pod中第一個創建出來的容器，用于創建Pod的網絡名稱空間和初始化Pod網絡，例如調用CNI分配Pod IP，下發策略路由等。它執行一個名為pause的進程，這個進程絕大部分時間處于Sleep狀態，對系統資源消耗極低。奇怪的是，當任務容器busybox運行結束后，kubelet為Pod又創建了一個新的Sandbox容器，創建過程中自然又進行了一次CNI ADD調用，再次申請了一次VPC IP。

回到UK8S CNI，我們再次分析重現案例日志。這一次有了更進一步的發現，所有kubelet傳遞給NETNS參數為空字符串的情形都發生在kubelet試圖銷毀Pod中第二個Sandbox的過程中。反之，kubelet試圖銷毀第二個Sandbox時，給CNI傳入的NETNS參數也全部為空字符串。

到這里，思路似乎清晰了不少，所有泄露的VPC IP都是來自第二個Sandbox容器。因此，我們需要查清楚兩個問題：

1. 為什么會出現第二個Sandbox容器？

2. 為什么kubelet在銷毀第二個Sandbox容器時，給CNI傳入了不正確的NETNS參數？

第二個Sandbox：我為何而生？

在了解的第二個Sandbox的前世今生之前，需要先交待一下kubelet運行的基本原理和流程。

kubelet是kubernetes集群中Node節點的工作進程。當一個Pod被kube-sheduler成功調度到Node節點上后， kubelet負責將這個Pod創建出來，并把它所定義的各個容器啟動起來。kubelet也是按照控制器模式工作的，它的工作核心是一個控制循環，源碼中稱之為syncLoop，這個循環關注并處理以下事件：

Pod更新事件，源自API Server；
Pod生命周期(PLEG)變化， 源自Pod本身容器狀態變化， 例如容器的創建，開始運行，和結束運行；
kubelet本身設置的周期同步（Sync）任務；
Pod存活探測（LivenessProbe）失敗事件；
定時的清理事件（HouseKeeping）。
在上文描述的CronJob任務中， 每次運行Job任務都會創建一個Pod。這個Pod的生命周期中，理想情況下，需要經歷以下重要事件：

1. Pod被成功調度到某個工作節點，節點上的Kubelet通過Watch APIServer感知到創建Pod事件，開始創建Pod流程；

2. kubelet為Pod創建Sandbox容器，用于創建Pod網絡名稱空間和調用CNI插件初始化Pod網絡，Sandbox容器啟動后，會觸發第一次kubelet PLEG(Pod Life Event Generator)事件。

3. 主容器創建并啟動，觸發第二次PLEG事件。

4. 主容器date命令運行結束，容器終止，觸發第三次PLEG事件。

5. kubelet殺死Pod中殘余的Sandbox容器。

6. Sandbox容器被殺死，觸發第四次PLEG事件。

其中3和4由于時間間隔短暫，可能被歸并到同一次PLEG事件（kubelet每隔1s進行一次PLEG事件更新）。

然而，在我們觀察到的所有VPC IP泄露的情況中，過程6之后“意外地”創建了Pod的第二個Sandbox容器，如下圖右下角所示。在我們對Kubernetes的認知中，這不應該發生。

對kubelet源碼(1.13.1)抽絲剝繭

前文提到，syncLoop循環會監聽PLEG事件變化并處理之。而PLEG事件，則來源kubelet內部的一個pleg relist定時任務。kubelet每隔一秒鐘執行一次relist操作，及時獲取容器的創建，啟動，容器，刪除事件。

relist的主要責任是通過CRI來獲取Pod中所有容器的實時狀態，這里的容器被區分成兩大類：Sandbox容器和非Sandbox容器，kubelet通過給容器打不同的label來識別之。CRI是一個統一的容器操作gRPC接口，kubelet對容器的操作，都要通過CRI請求來完成，而Docker，Rkt等容器項目則負責實現各自的CRI實現，Docker的實現即為dockershim，dockershim負責將收到的CRI請求提取出來，翻譯成Docker API發給Docker Daemon。

relist通過CRI請求更新到Pod中Sandbox容器和非Sandbox容器最新狀態，然后將狀態信息寫入kubelet的緩存podCache中，如果有容器狀態發生變化，則通過pleg channel通知到syncLoop循環。對于單個pod，podCache分配了兩個數組，分別用于保存Sandbox容器和非Sandbox容器的最新狀態。

syncLoop收到pleg channel傳來事件后，進入相應的sync同步處理流程。對于PLEG事件來說，對應的處理函數是HandlePodSyncs。這個函數開啟一個新的pod worker goroutine，獲取pod最新的podCache信息，然后進入真正的同步操作：syncPod函數。

syncPod將podCache中的pod最新狀態信息(podStatus)轉化成Kubernetes API PodStatus結構。這里值得一提的是，syncPod會通過podCache里各個容器的狀態，來計算出Pod的狀態(getPhase函數)，比如Running，Failed或者Completed。然后進入Pod容器運行時同步操作：SyncPod函數，即將當前的各個容器狀態與Pod API定義的SPEC期望狀態做同步。下面源碼流程圖可以總結上述流程。

SyncPod：我做錯了什么？

SyncPod首先計算Pod中所有容器的當前狀態與該Pod API期望狀態做對比同步。這一對比同步分為兩個部分：

檢查podCache中的Sandbox容器的狀態是否滿足此條件：Pod中有且只有一個Sandbox容器，并且該容器處于運行狀態，擁有IP。如不滿足，則認為該Pod需要重建Sandbox容器。如果需要重建Sandbox容器，Pod內所有容器都需要銷毀并重建。
檢查podCache中非Sandbox容器的運行狀態，保證這些容器處于Pod API Spec期望狀態。例如，如果發現有容器主進程退出且返回碼不為0，則根據Pod API Spec中的RestartPolicy來決定是否重建該容器。
回顧前面提到的關鍵線索：所有的VPC IP泄露事件，都源于一個意料之外的Sandbox容器，被泄露的IP即為此Sandbox容器的IP。剛才提到，SyncPod函數中會對Pod是否需要重建Sandbox容器進行判定，這個意外的第二個Sandbox容器是否和這次判定有關呢？ 憑kubelet的運行日志無法證實該猜測，必須修改源碼增加日志輸出。重新編譯kubelet后，發現第二個Sandbox容器確實來自SyncPod函數中的判定結果。進一步確認的是，該SyncPod調用是由第一個Sandbox容器被kubelet所殺而導致的PLEG觸發的。

那為什么SyncPod在第一個Sandbox容器被銷毀后認為Pod需要重建Sandbox容器呢？進入判定函數podSandboxChanged仔細分析。

podSandboxChanged獲取了podCache中Sandbox容器結構體實例，發現第一個Sandbox已經被銷毀，處于NOT READY狀態，于是認為pod中已無可用的Sandbox容器，需要重建之，源碼如下圖所示。

注意本文前面我們定位的CronJob yaml配置， Job模板里的restartPolicy被設置成了OnFailure。SyncPod完成Sandbox容器狀態檢查判定后，認為該Pod需要重建Sandbox容器，再次檢查Pod的restartPolicy為OnFailure后，決定重建Sandbox容器，對應源碼如下。

可以看出kubelet在第一個Sandbox容器死亡后觸發的SyncPod操作中，只是簡單地發現唯一的Sandbox容器處于NOT READY狀態，便認為Pod需要重建Sandbox，忽視了Job的主容器已經成功結束的事實。

事實上，在前面syncPod函數中通過podCache計算API PodStatus Phase的過程中，kubelet已經知道該Pod處于Completed狀態并存入apiPodStatus變量中作為參數傳遞給SyncPod函數。如下圖所示。

Job已經進入Completed狀態，此時不應該重建Sandbox容器。而SyncPod函數在判定Sandbox是否需要重建時， 并沒有參考調用者syncPod傳入的apiPodStatus參數，甚至這個參數是被忽視的。

第二個Sandbox容器的來源已經水落石出，解決辦法也非常簡單，即kubelet不為已經Completed的Pod創建Sandbox，具體代碼如下所示。

重新編譯kubelet并更新后，VPC IP泄露的問題得到解決。

下圖可以總結上面描述的第二個Sandbox容器誕生的原因。

事情離真相大白還有一段距離。還有一個問題需要回答：

為什么kubelet在刪除第二個Sandbox容器的時候， 調用CNI拆除容器網絡時，傳入了不正確的NETNS環境變量參數？

失去的NETNS

還記得前面介紹kubelet工作核心循環syncLoop的時候，里面提到的定期清理事件(HouseKeeping)嗎？HouseKeeping是一個每隔2s運行一次的定時任務，負責掃描清理孤兒Pod，刪除其殘余的Volume目錄并停止該Pod所屬的Pod worker goroutine。HouseKeeping發現Job Pod進入Completed狀態后，會查找該Pod是否還有正在運行的殘余容器，如有則請理之。由于第二個Sandbox容器依然在運行，因此HouseKeeping會將其清理，其中的一個步驟是清理該Pod所屬的cgroup，殺死該group中的所有進程，這樣第二個Sandbox容器里的pause進程被殺，容器退出。

已經死亡的第二個Sandbox容器會被kubelet里的垃圾回收循環接管，它將被徹底停止銷毀。然而由于之前的Housekeeping操作已經銷毀了該容器的cgroup, 網絡名稱空間不復存在，因此在調用CNI插件拆除Sandbox網絡時，kubelet無法獲得正確的NETNS參數傳給CNI，只能傳入空字符串。

到此，問題的原因已經確認。

問題解決

一切水落石出后，我們開始著手解決問題。為了能確保找到所刪除的Pod對應的VPC IP，CNI需要在ADD操作成功后，將PodName，Sandbox容器ID，NameSpace，VPC IP等對應關聯信息進行額外存儲。這樣當進入DEL操作后，只需要通過kubelet傳入的PodName，Sandbox容器ID和NameSpace即可找到VPC IP，然后通過UCloud 公有云相關API刪除之，無需依賴NETNS操作。

考慮到問題的根因是出現在kubelet源碼中的SyncPod函數，UK8S團隊也已修復kubelet相關源碼并準備提交patch給Kubernetes社區。

寫在最后

Kubernetes依然是一個高速迭代中的開源項目，生產環境中會不可用避免遇見一些異常現象。UK8S研發團隊在學習理解Kubernetes各個組件運行原理的同時，積極根據現網異常現象深入源碼逐步探索出問題根因，進一步保障UK8S服務的穩定性和可靠性，提升產品體驗。

2019年內UK8S還將支持節點彈性伸縮(Cluster AutoScaler)、物理機資源、GPU資源、混合云和ServiceMesh等一系列特性，敬請期待。

歡迎掃描下方二維碼，加入UCloud K8S技術交流群，和我們共同探討Kubernetes前沿技術。

如顯示群人數已加滿，可添加群主微信zhaoqi628543，備注K8S即可邀請入群。