作者：鄭嘉揚、何杉
前言
享道出行是一家專注於出行服務的專業品牌，是上汽集團實現汽車產業“新四化”（即“電動化、智能網聯化、共享化、國際化”）的重要組成部分。作爲上汽集團移動出行戰略品牌，享道出行充分利用全產業鏈競爭優勢，從消費者對安全及品質的需求出發，通過爲消費者提供安全、高效、舒適、便捷的品質體驗，打造品質出行服務平臺。
在快速的業務發展過程中，基礎設施規模的不斷增長，爲企業管理者帶來了對於效率和成本的高度關注。容器技術作爲雲計算時代基礎設施的核心，自然成爲了我們關注的焦點。隨着容器技術及其生態的不斷成熟，對於企業級開發者來說，在提高部署速度、優化資源利用率以及降低環境間差異等方面展現出了巨大的潛力。然而，隨着容器數量的激增，如何管理和調度這些容器也成爲了一個挑戰。
業務架構與痛點
當前業務開發主要採用 Java 技術棧，應用部署架構如圖所示：
核心痛點
- 目前使用的 Kubernetes 原生 HPA 彈性擴縮容方案以及 CronHPA 方案，在容器算力準備階段流程長，包括算力資源準備、調度、鏡像拉取、容器創建、容器啓動以及應用啓動導致冷啓動基本是分鐘級彈性。
- 無法承接預期外流量，流量損失對業務有感。
- 需要運維人員通過編碼、維護程序自動化測算生產環境資源水位，評估擴縮容閾值，運維成本較高。測算結果不夠精準也會導致資源浪費或影響業務穩定。
解決方案
針對以上痛點，爲解決彈性滯後的問題同時兼顧成本最優，方案如下：
- ACK AHPA 智能彈性
- ECS、ECI 混合部署
作爲出行行業，享道的業務特徵具備明顯的潮汐效應，通過彈性架構改造，我們能夠充分發揮雲彈性算力的優勢，進一步提升了業務自身的容錯性。
ACK 智能彈性（AHPA）
針對傳統彈性能力所存在的問題，在方案設計階段我們採用了 阿里雲ACK 容器服務推出的 AHPA（Advanced Horizontal Pod Autoscaler）彈性預測，可以根據歷史 Pod 的 Ready Time 以及歷史 Metrics 自動學習規律，在業務量上漲之前的一個 Ready Time 開始擴容，在業務量上漲時 Pod 已提前準備，可以及時供給資源，解決彈性滯後的問題。
AHPA 彈性預測根據歷史數據自動規劃未來 24 小時每一分鐘的應用實例數，相當於進行 1440 個點（一天爲 1440 分鐘）的 CronHPA 定時配置。
預先擴容
由於業務具有很強的潮汐屬性，每日的漲潮落潮時間比較固定，AHPA 會根據過往的數據推測之後的所需要的 Pod 數量。例如，服務A根據以往雙休日情況預測出這個雙休日可能出現的 Pod 數量最大值爲 16，那麼就可以預先擴出來滿足這些額外 pod。
ECS、ECI 混合部署
如前文所述，AHPA 只能夠解決應用層的彈性滯後問題，並不能提前對底層資源是否足夠提前做出判斷。這也意味着當底層資源不足時，仍存在使應用擴容時間被無限拉長的風險。
彈性容器實例 ECI（Elastic Container Instance） 作爲一種純 Serverless 容器運行服務，對於用戶而言，無需管理底層服務器資源，同樣也不需要關心運行過程中的容量規劃，只需要提供打包好的 Docker 鏡像，即可運行容器，非常適合應對這種流量突發場景下的業務場景。
但從成本性上講，單位價格會相對裸金屬 ECS 較貴，該方案結合了各付費模式和底層架構的優勢，當前採取混合部署模式，兼顧成本及穩定性兩方面的業務目標。如下圖所示，未來目標是一半以上的應用作爲業務基線部署在裸金屬 ECS 上，對於週期型應用部署在按量付費的 ECS 資源，結合出行行業早晚高峯，剩餘 10% 以上的場景均通過 ECI 實例保障。
注： ECI 的計算資源與 ECS 等實例完全解耦，在每個可用區有單獨的資源劃分給到 Serverless 架構相關產品，對於大部分場景（CPU 數不超過 1 萬 Core），無需擔心資源不足的情況產生。因此 ECI 也是一種相對可靠的算力容量保障手段。
自定義彈性資源優先級調度
在資源的調度策略上，由於採用了 ECS 及 ECI 兩種部署模式，我們期望應用擴容和縮容行爲都是確定性的，當應用需要部署一個 Deployment，此時集羣中有對應的多種類型的資源，分別是包年包月的 ECS、按量付費的 ECS 和彈性實例 ECI。
那麼，部署的服務優先調度順序理論上依次爲：包年包月的 ECS、按量付費的 ECS、彈性實例 ECI。 同時在服務縮容時優先刪除 ECI 上的 Pod，釋放 ECI 的節點資源，然後刪除按量付費的 ECS 上的 Pod，最後刪除包年包月的 ECS 上的 Pod。
對於包年包月及按量付費兩種不同付費類型的節點需通過打上不同 label 標籤實現。然後創建 ResourcePolicy 自定義節點池調度順序。
ResourcePolicy 配置示例：
apiVersion: scheduling.alibabacloud.com/v1alpha1
kind: ResourcePolicy
metadata:
name: DEMO
namespace: demo-ns
spec:
units:
- max: 15
nodeSelector:
env: prd
resource: ecs
- max: 5
nodeSelector:
foo: bar
resource: ecs
- resource: eci
whenExceedMax: NeverEvict
這裏具體的調度策略可根據實際業務場景區分，若對於成本不敏感，且業務的波峯波谷抖動較大的場景，也可以考慮當 ECS 資源不足時，使用 ECI 彈性資源，進而加速 Pod 的啓動時間。
向虛擬節點 Pod 注入 Sidecar 容器
在享道的集羣架構中，存在採集微服務日誌的場景，日誌採集器會在 ECS 節點上通過 DaemonSet 方式部署 Agent，但虛擬節點不是真實節點，不支持運行 DaemonSet Pod，如何讓調度到虛擬節點的 Pod 也支持上述 Agent 的同等能力呢？答案是向虛擬節點 Pod 注入 Sidecar 容器。
在實施過程中，我們希望做到：
- 維護一份 Deployment 發佈模板。在資源調度部署時，自動對底層 ECS 和 ECI 做區分，當 Pod 被調度到 ECS 節點時，無需注入 Sidecar 容器，當 Pod 被調度到虛擬節點時，則自動向 Pod 中注入 Sidecar 容器，從而實現通過維護一份 Deployment 發佈模版，即可同時滿足不同架構下的兼容性需求。
- 對已有存量業務入侵儘可能小。根據軟件設計開閉原則，應該對修改關閉，避免改動線上已經運行穩定的存量業務（如 DaemonSet），只增加新的或對新增內容做改變。
使用一個 Deployment 在原生 K8s 架構中無法做到，原因是添加 Sidecar 容器需要修改 Pod Spec，而原生 K8s 架構中 Pod Spec 落到 etcd 之後就不允許修改了，但 Pod 是否調度到虛擬節點是在 Pod Spec 落到 etcd 後由調度器決定的。因此，使用 OpenKruise 原生 SidecarSet，因爲採用 Admission Webhook 機制，在 Pod 創建階段通過 Label 的匹配所有符合條件的 Pod，此時 Pod 還未調度到虛擬節點，無法僅對調度到虛擬節點的 Pod 生效。
注： SidecarSet 是阿里雲開源的雲原生應用自動化引擎 OpenKruise 的核心功能之一。使用 SidecarSet 可以爲集羣中創建的符合條件的 Pod 自動注入 Sidecar 容器，實現 Sidecar 容器（如監控、日誌等 agent）的定義和生命週期與業務容器解耦。
虛擬節點支持 SidecarSet 就是專門用於解決該問題。藉助虛擬節點組件（ACK Virtual Node）僅爲調度到虛擬節點上的 Pod 自動注入 Sidecar 容器，來解耦虛擬節點 Pod 的 Sidecar 容器與業務容器。其原理如下圖所示：
通過標籤 Serverless.alibabacloud.com/virtual-node:"true" 指定，該標籤會在 Pod 確定調度到虛擬節點後自動打上。同時，該方案與 OpenKrusie 原生 SidecarSet 完全兼容，對於後續 Sidecar 容器的升級、運維等操作，仍可以繼續使用OpenKrusie原生 SidecarSet 實現。
自定義彈性指標
如上文所述，基於 CPU/內存的彈性指標無法同真實業務工作複雜完全擬合。很多場景下，用戶期望根據自定義指標對應用進行擴縮容。AHPA 所提供的 External Metrics 機制，結合 alibaba-cloud-metrics-adapter 組件，可以爲應用提供更豐富的擴縮容機制。
業務價值
當前享道出行已經規模化上線智能容器彈性能力，在保證穩定性的前提下，大大節省了資源成本，並能很好地應對突發流量。 如圖所示：當閾值設置爲 50，指標有到 50 的趨勢時，即會觸發彈性擴容，能夠更好地應對突發流量，保障業務穩定性的同時，也能夠實現可觀的降本效果。
