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

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

創(chuàng)新互聯(lián)公司長期為數(shù)千家客戶提供的網(wǎng)站建設服務，團隊從業(yè)經(jīng)驗10年，關注不同地域、不同群體，并針對不同對象提供差異化的產(chǎn)品和服務；打造開放共贏平臺，與合作伙伴共同營造健康的互聯(lián)網(wǎng)生態(tài)環(huán)境。為鄂爾多斯企業(yè)提供專業(yè)的成都網(wǎng)站建設、網(wǎng)站設計，鄂爾多斯網(wǎng)站改版等技術服務。擁有十余年豐富建站經(jīng)驗和眾多成功案例,為您定制開發(fā)。

深度集成VPC的網(wǎng)絡方案

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

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

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

此方案具有以下優(yōu)勢：

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

創(chuàng)建Pod網(wǎng)絡過程：

刪除Pod網(wǎng)絡過程：

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

為了測試CNI插件的穩(wěn)定性，測試同學在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都要創(chuàng)建一個Pod， 每創(chuàng)建一個Pod，CNI插件需要申請一次VPC IP，當Pod被銷毀時，CNI插件需要釋放該VPC IP。 因此理論上，通過該CronJob每天需要進行1440次申請VPC IP和釋放VPC IP操作。

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

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

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

問題轉(zhuǎn)移到kubelet， 為什么kubelet會傳入一個空的CNI_NETNS環(huán)境變量參數(shù)給CNI插件？

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

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

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

1. 為什么會出現(xiàn)第二個Sandbox容器？

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

第二個Sandbox：我為何而生？

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

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

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

1. Pod被成功調(diào)度到某個工作節(jié)點，節(jié)點上的Kubelet通過Watch APIServer感知到創(chuàng)建Pod事件，開始創(chuàng)建Pod流程；

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

3. 主容器創(chuàng)建并啟動，觸發(fā)第二次PLEG事件。

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

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

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

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

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

對kubelet源碼(1.13.1)抽絲剝繭

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

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

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

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

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

SyncPod：我做錯了什么？

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

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

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

podSandboxChanged獲取了podCache中Sandbox容器結(jié)構(gòu)體實例，發(fā)現(xiàn)第一個Sandbox已經(jīng)被銷毀，處于NOT READY狀態(tài)，于是認為pod中已無可用的Sandbox容器，需要重建之，源碼如下圖所示。

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

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

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

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

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

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

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

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

為什么kubelet在刪除第二個Sandbox容器的時候， 調(diào)用CNI拆除容器網(wǎng)絡時，傳入了不正確的NETNS環(huán)境變量參數(shù)？

失去的NETNS

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

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

到此，問題的原因已經(jīng)確認。

問題解決

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

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

寫在最后

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

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

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

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

分享名稱：Kubernetes源碼探疑：PodIP泄露排查及解決
分享路徑：http://bm7419.com/article36/pcdesg.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站建設、用戶體驗、、手機網(wǎng)站建設、全網(wǎng)營銷推廣、品牌網(wǎng)站建設

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)