作者
呂亞霖，作業幫基礎架構 - 架構研發團隊負責人。負責技術中台和基礎架構工作。在作業幫期間主導了雲原生架構演進、推動實施容器化改造、服務治理、GO 微服務框架、DevOps 的落地實踐。
別路，作業幫基礎架構-高級研發工程師，在作業幫期間，負責多雲 K8s 集群建設、K8s 組件研發、Linux 內核優化調優相關工作。
背景
作業幫在雲原生容器化改造的過程中，隨着集群規模越來越大、業務混合部署的場景越來越復雜，面臨的集群問題也越來越多，走到了 Kubernetes 及容器化的深水區， 尤其是在上萬個 CronJob 容器化，和在線業務混合部署在同一個生產集群后，問題就更加明顯。
作業幫在線的生產業務使用 TKE 部署在黑石2.0 物理機上，單個機器規格比較大，部署的pod 也就比較多，而 cronjob 的特性是頻繁、定時啟動和銷毀，同時也需要給這部分業務預留一定的固定資源，所以這塊主要有 2 個問題；一是在大規模pod 頻繁創建銷毀場景下，cgroup 弱隔離性導致的節點穩定性問題，從而影響同一節點其他業務，二是資源預留導致的資源利用率低的問題。這兩個問題其實已經超出了 原生 Kubernetes 的能力覆蓋范圍，我們需要新的思路來解決。
下面將詳細介紹這兩個問題產生的原因及解決辦法。
問題一：集群內節點穩定性
由於業務上存在很多分鍾級執行的定時任務，導致 pod 的創建和銷毀非常頻繁，單個節點平均每分鍾有上百個容器創建和銷毀，機器的穩定性問題頻繁出現。
一個典型的問題是頻繁創建 pod 導致節點上 cgroup 過多，特別是 memory cgroup 不能及時回收，讀取/sys/fs/cgroup/memory/memory.stat 變慢，由於 kubelet 會定期讀取該文件來統計各個 cgroup namespace 的內存消耗，CPU 內核態逐漸上升，上升到一定程度時，部分 CPU 核心會長時間陷入內核態，導致明顯的網絡收發包延遲。
在節點 perf record cat /sys/fs/cgroup/memory/memory.stat 和 perf report 會發現，CPU 主要消耗在 memcg_stat_show 上：
而 cgroup-v1 的 memcg_stat_show 函數會對每個 CPU 核心遍歷多次 memcg tree，而在一個 memcg tress 的節點數量達到幾十萬級別時，其帶來的耗時是災難性的。
為什么 memory cgroup 沒有隨着容器的銷毀而立即釋放呢？主要是因為 memory cgroup 釋放時會遍歷所有緩存頁，這可能很慢，內核會在這些內存需要用到時才回收，當所有內存頁被清理后，相應的 memory cgroup 才會釋放。整體來看，這個策略是通過延遲回收來分攤直接整體回收的耗時，一般情況下，一台機器上創建容器不會太多，通常幾百到幾千基本都沒什么問題，但是在大規模定時任務場景下，一台機器每分鍾都有上百個容器被創建和銷毀，而節點並不存在內存壓力，memory cgroup 沒有被回收，一段時間后機器上的 memory cgroup 數量達到了幾十萬，讀取一次 memory.stat 耗時達到了十幾秒，CPU 內核態大幅上升，導致了明顯的網絡延遲。
除此之外，dockerd 負載過高、響應變慢、kubelet PLEG 超時導致節點 unready 等問題。
問題二：集群的節點資源利用率
由於我們使用的是 TKE vpc-cni 的網絡模式，這種網絡模式依賴節點綁定的彈性網卡數量，所以單個節點上的 pod ip 數量存在上限，節點有幾乎一半的 podip 是為定時任務的 pod 保留的，造成ip 浪費，另外定時任務的 pod 運行時間普遍很短，這就導致了集群為定時任務預留的資源產生了較多閑置，不利於整體的機器資源使用率提升。
其他問題：調度速度、服務間隔離性
在某些時段，比如每天 0 點，會同時產生幾千個 Job 需要運行。而原生調度器是 K8s 調度 pod 本身對集群資源分配，反應在調度流程上則是預選和打分階段是順序進行的，也就是串行。幾千個 Job 調度完成需要幾分鍾，而大部分業務是要求 00：00：00 准時運行或者業務接受誤差在 3s 內。
有些服務 pod 是計算或者 IO 密集型，這種服務會大量搶占節點 CPU 或者 IO，而 cgroup 的隔離並不徹底，所以會干擾其他正常在線服務運行。
解決思路及方案
所以，對 CronJob 型任務我們需要一個更徹底的隔離方式，更細粒度的節點，更快的調度模式。
為解決上訴問題，我們考慮將定時任務 pod 和普通在線服務的 pod 隔離開，但是由於很多定時任務需要和集群內服務互通，還不能通過分集群的方式隔離。
騰訊雲彈性容器服務 EKS 提供的虛擬節點，給我們解決上訴問題提供了一個新的思路，
EKS 的虛擬節點是 serverless 形態的kubernetes 服務，可以加入到現有的TKE 集群中，部署在虛擬節點上的 pod 具備與部署在正常 TKE 節點上的 pod 具備一致的網絡連通性，但虛擬節點上的pod 是在vm 層面做了隔離，又具有無需預留資源，按量計費的特性，可以很好的滿足我們這個場景的需求，所以我們將CronJob 這種類型的業務都調度到了虛擬節點，如圖所示：
任務調度器
為解決 K8s 默認串行調度慢的問題，我們針對 job 類任務，開發了任務調度器，所有 CronJob 型 workload 都使用任務調度器，任務調度器批量並行調度任務 pod 到 虛擬 節點，實現大規模pod 任務 ms 級調度，也支持 虛擬節點故障時或者資源不足時調度回標准 TKE 節點。
解決 TKE 節點和虛擬節點在運維方式上的差異
在使用 虛擬節點前，首先要解決 虛擬節點 pod 和運行在標准節點上的 pod 差異，做到對業務研發無感。
日志采集統一
在日志采集方面，由於 EKS 這種 nodeless 的形態，無法運行 DaemonSet，而我們的日志采集組件是以 DaemonSet 形式運行的，這就需要對虛擬節點上的日志做單獨的采集方案。EKS 虛擬節點 本身提供日志采集agent, 可以將容器的標准輸采集並吐到一個 Kafka topic，然后我們統一在這個 topic 里消費。
監控報警統一
在監控方面，我們對 虛擬節點 上的 pod 做了實時 CPU/內存/磁盤/網絡流量等監控，做到了和普通節點上的 pod 一致，暴露 pod sanbox 的 export 接口，promethus 負責統一采集，遷移到 虛擬節點 時做到了業務完全無感。
提升啟動性能
虛擬節點上的 Job 需要具備秒級的啟動速度才能滿足定時任務對啟動速度的要求，比如業務要求 00:00:00 准時運行或者業務接受誤差在 3s 內。
主要耗時在以下兩個步驟：
-
業務鏡像拉取加速
-
虛擬節點 pod 創建和初始化加速
針對第一個問題：EKS 提供鏡像緩存的功能，第一次拉取的時候稍微慢一些，拉下來后默認會緩存一段時間，同一個業務第二次啟動就不需要再拉取鏡像，所有鏡像下載慢的問題基本就沒有了。
針對第二個問題：業務要求的啟動時間誤差在 3s 內，所以我們和 騰訊雲 EKS 團隊溝通后，為這種大規模、高頻、短時的計算作業場景進行了針對性優化，提升了頻繁啟動的效率並降低了運行環境初始化的時間。
最終實現了虛擬節點上的 Pod 秒級啟動。
總結
通過 TKE + EKS 虛擬節點的方式，我們將正常在線任務和定時任務隔離開，有效保障了在線業務的穩定性，結合 自研 Job 任務調度器、EKS 鏡像緩存、pod 啟動加速等能力，實現 任務pod 秒級調度並啟動，同時 TKE + 虛擬節點 都是標准的 K8s API ，做到了業務平滑遷移。最終要的是，我們固定的集群不需要再為 CronJob 類任務預留資源，釋放了集群里 10% 的資源，結合 EKS 隨用隨取、按量計費的特性，定時任務的資源成本降低了 70%左右。
關於我們
更多關於雲原生的案例和知識，可關注同名【騰訊雲原生】公眾號~
福利：
①公眾號后台回復【手冊】，可獲得《騰訊雲原生路線圖手冊》&《騰訊雲原生最佳實踐》~
②公眾號后台回復【系列】，可獲得《15個系列100+篇超實用雲原生原創干貨合集》，包含Kubernetes 降本增效、K8s 性能優化實踐、最佳實踐等系列。
③公眾號后台回復【白皮書】，可獲得《騰訊雲容器安全白皮書》&《降本之源-雲原生成本管理白皮書v1.0》
【騰訊雲原生】雲說新品、雲研新術、雲游新活、雲賞資訊，掃碼關注同名公眾號，及時獲取更多干貨！！
