呂亞霖，作業幫基礎架構 - 架構研發團隊負責人。
負責技術中臺和基礎架構工作。
在作業幫期間主導了雲原生架構演進、推動實施容器化改造、服務治理、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 內。
-
-
針對第一個問題：
EKS 提供映象快取的功能，第一次拉取的時候稍微慢一些，拉下來後預設會快取一段時間，同一個業務第二次啟動就不需要再拉取映象，所有映象下載慢的問題基本就沒有了。
針對第二個問題：
業務要求的啟動時間誤差在 3s 內，所以我們和 騰訊雲 EKS 團隊溝通後，為這種大規模、高頻、短時的計算作業場景進行了針對性最佳化，提升了頻繁啟動的效率並降低了執行環境初始化的時間。
總結
透過 TKE + EKS 虛擬節點的方式，我們將正常線上任務和定時任務隔離開，有效保障了線上業務的穩定性，結合 自研 Job 任務排程器、EKS 映象快取、pod 啟動加速等能力，實現 任務pod 秒級排程並啟動，同時 TKE + 虛擬節點 都是標準的 K8s API ，做到了業務平滑遷移。最重要的是，我們固定的叢集不需要再為 CronJob 類任務預留資源，
釋放了叢集裡 10% 的資源，結合 EKS 隨用隨取、按量計費的特性，
定時任務的資源成本降低了 70%左右。
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/69984638/viewspace-2845889/，如需轉載，請註明出處，否則將追究法律責任。