做者
湯英康，騰訊高級工程師、Kubernetes 開源協同 PMC，負責TEG信息安所有的容器化上雲相關工做。docker
引言
截止到2021年5月，TEG 信安運維團隊歷時一年，完成了 TKE 容器從0到1的平臺能力建設，集羣總規模超過60萬核，在資源成本、服務質量和運營效率上都取得了明顯的收益。 本文將介紹信安 TKE 容器的建設思路和歷程，分享各階段遇到的問題和方案，但願能給其餘上雲團隊提供一些參考。安全
背景
信安致力於提供專業的內容安全解決方案，承接了公司內外大量的業務安全需求，隨着業務量的迅速增加，信安內部的資源規模也日益增加，在機器成本、服務質量和交付效率方面也暴露了不少優化空間；自從公司倡導開源協同、自研上雲以來，TKE(Tencent Kubernetes Engine)成了內部首推的上雲方式，以 docker 和 kubernetes 爲核心的容器技術也早已成爲業界架構升級的主流選擇。網絡
所以，在2020上半年，信安聯合 TKE、智研和運管團隊協同建設，開啓了信安容器平臺的建設之路。架構
建設思路和整體規劃
信安對於容器平臺的建設思路和歷程，能夠總結歸納爲「一個方向、三個階段」：運維
【一個方向】向雲原生理念看齊，圍繞雲原生開源生態體系進行方案選型，緊跟業界先進的基礎架構升級方向；socket
【三個階段】雲原生有三駕馬車：容器雲 + Devops 運營體系 + 微服務，分別對應了容器化征途必經的三個階段，微服務
- 階段1：基礎平臺建設，將容器技術引入到服務架構並適配，完成從0到1的能力建設、業務改造和架構升級；
- 階段2：運營能力迭代，主要任務是圍繞容器平臺提高研效能力、完善數據運營能力，並創建穩定性保障體系；
- 階段3：雲原生成熟度提高，基於公司發佈的雲原生成熟度模型，以成熟度評分爲抓手，推進現有架構持續優化。
基礎平臺建設
平臺能力建設
在 TKEStack 團隊的協助下，信安順利地在深圳、廣州、上海、南京4個地區完成了CPU獨立集羣的搭建，結合 TKEStack 的控制檯頁面，快速具有了容器發佈和管理的基礎能力。 通用能力以外，在個性化需求的適配上，主要有：測試
- 實例固定 IP：經過 FloatingIP 插件實現，建立容器時在網絡模式中選擇浮動IP，IP回收策略選擇「縮容或刪除 APP 時回收」，便可實現
- CMDB 同步：經過 CMDB 控制器插件實現，實例啓動後，插件會自動將 pod IP 註冊到 annotation 中指定的業務模塊
- L5/北極星服務註冊：經過LBCF插件實現，實例 running 狀態後，能夠將實例IP和指定端口註冊到L5/北極星，實例被刪除時，能夠從L5/北極星下線
GPU 集羣也在深圳和上海完成搭建並投入使用，並設計了基於 Virtual Kubelet、將 GPU 集羣的CPU資源註冊到CPU 集羣中進行調度的方案，能更好地複用 GPU 機器上空閒的CPU資源。優化
業務容器化改造
具有平臺能力後，下一步就是對現有的 IDC/CVM 上部署的服務進行容器化改造。這裏的難點主要有：url
- 服務多樣性，包含無狀態、有狀態和 GPU 的服務，單個服務的包很大（最大可達幾十個G），服務有本身的依賴環境等
- 須要考慮多個研發運營流程節點：包括開發改造、測試流程規範、Dockerfile 鏡像製做、CICD 流程、運維變動規範等
咱們主要採起了以下幾個措施：
- 首先，梳理不一樣場景下服務的改造流程，在內部制定了統一的開發、測試和運維使用規範
- 在基礎鏡像的選擇上，咱們基於信安標準化的機器環境製做了基礎鏡像，減小服務由於環境問題致使異常的機率
- 抽象出 Dockerfile 模板，下降了服務改形成本（開發同窗幾乎0參與）
- 統一容器內的啓動入口（Entrypoint 和 CMD），在管理腳本中啓動服務
- 部分服務在啓動以前、須要將容器IP寫到配置文件中，咱們經過在管理腳本中實現
- 對於 size 過大的軟件包和鏡像，考慮將文件機型拆分管理，例如數據模型文件、經過服務啓動時再去文件下發系統拉取
資源利用優化
一方面，將每一個服務劃分到單獨的 namespace 空間，結合 ns 的 ResoureQuota 來配置和限制服務所能使用的資源；
另外一方面，爲了提高集羣總體的資源利用率，對每一個服務在實際部署時進行合理的 cpu 資源超賣，即 cpu 的 limits 值會大於 requests 值；通常會結合服務的當前利用率、目標利用率以及服務的重要性來考慮，具體的超賣比例計算公式爲：
目標利用率 / (當前利用率 * 服務權重)
經過這種方式，對於長期利用率低下的服務，在不調整實例的狀況下，就能夠極大地提高宿主機整機的 CPU 利用率。
調度管理
經過開啓 K8s 自己的 HPA 和 CA 能力，能夠實現總體架構從應用層、到集羣層的兩級彈性調度。
因爲咱們是跨地區多集羣部署，因此須要對多個服務、在多個集羣去配置管理HPA，而且按期根據實際的資源使用狀況，來判斷當前服務的 HPA 策略是否合理； 爲此，咱們設計開發了 HPA 管理系統，實現了：
- 將 HPA 策略分類管理，對於業務請求波動狀況、伸縮指標、閾值和優先級相近的服務，能夠用一個調度類來批量建立HPA策略
- 在跨集羣中，經過一個統一的入口來下發和配置 HPA，無需在每一個集羣單獨配置和管理，提高管理效率
- 經過定時拉取服務的監控指標，能夠輸出服務當前的資源實際使用狀況，判斷 HPA 策略合理性並修改
運營能力迭代
Devops 研效能力方案
【CICD】：基於現有的智研 CI 流水線，增長【智研-鏡像構建】和【智研-製品入庫】插件，將編譯生成的軟件包轉化成鏡像後推送到統一軟件源，實現 CI 和 TKE 的對接
【監控】：將 agent 注入到基礎鏡像中，隨管理腳本啓動
【日誌】：業務日誌直接上報到智研，k8s 集羣層面的 event 事件，經過事件持久化組件存儲到 Elasticsearch、供後續查詢
【配置管理】：將七彩石 agent 注入到基礎鏡像中，隨管理腳本啓動，服務統一用七彩石下發配置
數據運營系統建設
爲了更貼合業務運營場景，咱們設計並開發了 kbrain 系統，在後臺對接 k8s 集羣、拉取基礎數據並進行二次處理後存入 cdb 中，經過 grafana 配置展現業務維度的視圖數據和報表，並引入了健康度評分、成本收益、超賣比例、資源碎片實例等有價值的數據做爲運營參考。
對於已經配置了 HPA 彈性伸縮策略的服務，也能夠在 HPA 調度看板查看效果，以下圖所示：
這裏有4條曲線：當前利用率、目標利用率、當前副本數、目標副本數
趨勢圖證實：當前利用率提升時，目標副本數隨之提升，擴容完成後、利用率恢復到正常水平
穩定性保障體系
對於 TKE 這樣的大規模基礎平臺，完善的穩定性保障體系和平臺支撐是必不可少的。主要從如下幾個方面考慮：
- SLA規範：做爲業務方，和TKE平臺支撐方明確對齊SLA規範，包括不可用的定義、故障的響應機制和處理流程、平臺運維變動規範、節假日規範以及問題上升渠道等，這是穩定性的基礎
- 穩定性指標：整理全部可以反饋平臺和業務穩定性的指標，並經過後臺拉取後在grafana平臺匯聚展現
- 容量管理：實時監測集羣的剩餘資源水位，避免因容量不足致使的故障
- 預案機制：梳理全部可能產生的故障，並提早設計好快速恢復的應急預案
- 監控告警：檢查集羣和服務是否都接入和上報了有效的監控指標，出現問題時必須能第一時間收到告警
- 混沌工程：協同引入混沌工程oteam，圍繞TKE創建故障演練能力，檢驗SLA、穩定性指標、容量系統和預案機制的可靠性
雲原生成熟度提高
通過前兩個階段的基礎平臺建設和運營能力迭代，咱們基本完成了容器能力從0到一、從無到有的建設；下一步，是從「有」到「優」，把現有的容器架構和業務改造模式、往更加雲原生的方向靠攏。
富容器瘦身
在前期，因爲人力投入有限，咱們採用了富容器的方式改造業務，也就是把容器當成虛擬機用，在容器的基礎鏡像裏面注入了過多的基礎 agent。
基於雲原生理念和容器的正確打開姿式，咱們把容器進行瘦身，將原有的容器拆分紅：1個業務容器+多個基礎 agent 容器，將大文件從鏡像裏面徹底剝離、利用雲盤/雲存儲/文件分發系統實現。
拆分後，1個 pod 裏面會有多個容器，容器之間若是須要共享文件（例如 業務進程讀寫智研監控 agent 的 socket 文件），能夠採用 emptydir 卷掛載方式實現。
小核心改造+Overlay網絡優化
對於 TKE 容器集羣來講，若是大多數服務都是大核心配置（例如 36c、76c甚至更大），會產生較多的資源碎片，一部分節點的剩餘可分配資源（2c、4c、8c等）沒法真正分配出去，形成資源浪費。因此，從宏觀角度看，須要把大部分服務的容器資源配置儘量切小。
信安的服務在容器化改造以前，習慣了多進程的架構併爲之作了優化，單機常常運行48/76個進程（甚至更多）；容器化改造運行後，因爲超賣、基於獲取到的 cpu limits 值運行的進程數會遠高於 cpu requests 值，致使部分進程異常（沒法真正綁核運行）。
所以，須要修改服務運行配置、切換到小核心配置且 requests=limits 值的容器中運行。
然而，在容器切小核心的同時，服務的實例數也會增加。例如，從76核配置切換到38核，實例數會翻一倍；從76核到8核，實例數幾乎擴大到10倍。若是這時服務依然採用 FloatingIP 的網絡架構，對於集羣底層的IP資源又是一個巨大的開銷。
通常來講，切換到 Overlay 網絡便可，但Overlay網絡的延遲會高出20%，並且由於是集羣內惟一的虛擬IP、因此沒法註冊到L5/北極星、也不支持 monitor 監控。 通過和TKE團隊的調研論證，最終設計採用了基於Overlay改進的 HostPort 網絡方案：實例 Pod 依然拿到的是集羣內虛擬IP，可是能夠把 Pod 內部的服務端口映射到宿主機的隨機端口，再把宿主機IP+隨機端口 註冊到L5/北極星，從而既實現了服務註冊、又可以最大限度下降時延。
咱們針對試點服務（低俗識別）首先完成了小核心改造+Overlay 網絡的部署和測試，驗證獲得：
overlay+HostPort 網絡下的吞吐量與時延、和 FloatingIP 接近
成果小結
目前，信安已基本完成了 基礎平臺建設+運營能力迭代 這兩個階段的建設任務，正在努力提高雲原生成熟度。截止到2021年5月：
1）信安TKE集羣累計規模達62w+核，GPU卡容器化超2000卡
2）業務累計接入40+個信安服務，約佔33%的轉維服務
3）累計節省成本約20w核，質量和效率也有明顯的提高。
結語
技術圈有一句名言：「人們對於新技術每每都會短時間高估它的影響，可是大大低估它長期的影響」。
新的技術，從創造到落地必然須要經歷一個過程，它須要在短時間付出比較多的投入，架構的升級也會給團隊其餘項目和人員帶來陣痛；但只要論證清楚方向、並堅決地朝着它努力，咱們必將迎來質變、收穫咱們所希冀的饋贈。
路漫漫其修遠兮，但願你們都能在雲原生建設的道路上行得更遠、走得更好！
容器服務（Tencent Kubernetes Engine，TKE）是騰訊雲提供的基於 Kubernetes，一站式雲原生 PaaS 服務平臺。爲用戶提供集成了容器集羣調度、Helm 應用編排、Docker 鏡像管理、Istio服務治理、自動化DevOps以及全套監控運維體系的企業級服務。 【騰訊雲原生】雲說新品、雲研新術、雲遊新活、雲賞資訊，掃碼關注同名公衆號，及時獲取更多幹貨！！