如果以容器云上生產為目標，那么整個容器云平臺的設計、建設和優化對于銀行來說是一個巨大的挑戰。如何更好地利用云原生技術，幫助銀行實現敏捷、輕量、快速、高效地進行開發、測試、交付和運維一體化，從而重構業務，推動金融科技的發展，是個長期課題。
本期云原生漫談，將和您共同探索，云原生時代智能運維的進階之路。
隨著金融業務的快速發展，支撐業務的IT基礎設施的變化節奏也大大加快。
金融IT運維團隊對IT基礎設施運維的任務，比以往任何時候都要更加艱巨。核心是保障生產安全運營，并提高軟硬件環境的交付質量。然而在今天的金融IT3.0時代，IT需求變得越來越強，變化越來越快，服務器等數量爆增，管理起來日益繁雜。同時，運維管理規模的不斷擴大，運維人員的不斷擴充，使得日常運維工作面臨著雙重的壓力與風險。
以容器、微服務為代表的云原生技術催生了新一代云原生運維技術體系，可以幫助金融企業最大化釋放運維效能。基于多年來的實踐經驗，我們對于來自金融行業一線的運維問題進行了回答：
相較于虛擬機，容器的運維和監控有什么優劣勢？
為什么說基于K8s的容器是實現智能運維的必然選擇？
高并發場景下，如何實現容器的自動擴縮容？
如何快、準、狠地排查容器中的應用問題？
容器的智能運維有無成功實踐案例？
希望本篇文章能為您提供借鑒。
相較于虛擬機，容器的運維和監控有什么優劣勢？
從運維的角度來看，容器的輕量化使得運維更加靈活高效，更方便應用自動化來提升運維效率。
相較于傳統運維，容器可以實現：
更快速部署和交付：對于應用系統的部署可以極大地節省時間成本和人力成本；
更標準化交付物：容器的標準交付物為鏡像，包含應用程序和依賴環境，一次構建多次使用，大大簡化了應用交付模式；
更高效的資源利用：容器不需要虛擬機額外的管理程序，依賴內核運行，在運維資源開銷上要低的多；
更加敏捷的遷移和擴展：容器可以跨操作系統、跨環境運行，實現無縫遷移的效果，以及高并發場景下的自動擴縮容。
從監控的角度來看，輕量化的容器也帶來了監控的復雜度，特別是大量容器運行的平臺如何排錯和根因分析。
由于容器是黑盒運行，在運維中容器問題的診斷比較復雜；由于容器運行的密度比較大，需要面對的運維實體和對象數量會很龐大；由于容器的自身特性，容器的創建、銷毀等生命周期過程，各類運維數據的采集是個挑戰。另外容器啟動后，監控系統怎么發現，同時需要對其做哪些數據采集，這些問題都是容器監控自動化過程需要解決的。
在監控這個領域，除了目前比較熱門的純軟件層全鏈路監控以及混沌工程，建議應該結合硬件的監控和檢測實現端到端的監控和測試，以提升平臺的穩定性和效能。
為什么說基于K8s的容器是實現智能運維的必然選擇？
隨著容器的不斷成熟，越來越多的金融企業選擇利用容器來搭建業務系統。可是，大家在實際操作中發現，像Docker之類的容器引擎，更適合管理少量容器，而如今的云原生應用、機器學習任務或者大數據分析業務，動輒就要使用成百上千的容器，K8s就自然而然地成為了實現智能運維的必然選擇。
首先是K8s采用聲明式API，讓開發者可以專注于應用自身，而非系統執行細節。比如，在Kubernetes之上，提供了Deployment、StatefulSet、Job等不同類型應用負載的抽象。聲明式API是云原生重要的設計理念，有助于將系統復雜性下沉，交給基礎設施進行實現和持續優化。
此外，K8s提供了可擴展性架構，所有K8s組件都是基于一致的、開放的API進行實現和交互。開發者也可通過CRD（CustomResourceDefinition）/Operator等方式提供領域相關的擴展，極大拓寬了K8s的應用場景。
最后，K8s提供平臺無關的技術抽象：如CNI網絡插件,CSI存儲插件等等，可以對上層業務應用屏蔽基礎設施差異。
高并發場景下如何實現容器的自動擴縮容？
首先，建議先做好容器云平臺配套的監控、日志的建設，再去建設自動擴縮容的自動化能力。
一般可以在高并發場景下使用K8s的HorizontalPodAutoscaling（以下簡稱HPA）,通過HPA功能，可以實現容器的自動彈性擴縮容功能。對于K8s集群來說，在高并發場景下HPA可以實現多種緯度的自動化功能，例如當工作負載上升的時候，可以創建新的實例副本來保證業務系統穩定運行，當工作負載并發下降的時候，可以銷毀副本實例來減少資源消耗。當前的自動伸縮的指標包括：CPU，內存，并發數，網絡傳輸等。
此外，從整體實施的角度來看，建議聚焦于場景驅動，先從某個業務應用開始逐步試點和推廣，運維團隊逐步積累到各個場景下業務應用的擴縮容的觸發指標、閥值和評估擴縮容成效，最終實現全面的自動擴縮容。
如何快、準、狠地排查容器中的應用問題？
建議可以從以下三個層面來排查容器中的應用問題：
業務層面
通常我們說的微服務鏈路追蹤、流量追蹤用來解決業務層的問題說的微服務鏈路追蹤、流量追蹤用來解決業務層的問題，正常情況下會引入服務網格平臺，好處是不會受開發語言限制（當然SpringCloud也是可以，只是局限在Java應用里），可實現鏈路追蹤，發現業務API調用關系，對處理業務故障拍錯很有幫助。
容器層面
容器層面的問題解決相當于傳統情況下對包、配置、進程、OS等進行分析和調優，這點通過切入容器環境進行排障分析。值得一提的是在靈雀云的產品中，提供對容器debug的獨特功能，可以通過臨時添加debug容器到目標pod中的方式對目標容器進行各類測試，避免直接登錄進入業務容器而導致風險或業務容器中沒有需要的debug工具。
網絡和數據包層面
可以通過trace、tcpdump、流量鏡像等方式對數據包分析，這點通常需要CNI插件支持，一般的calico、flannel都無法做到，可以考慮采用開源的Kube-OVN插件作為容器CNI，可以有效幫助解決網絡層排障的問題。
容器的智能運維有無成功實踐案例？
我們以某大型車企的云原生容器應用為例，2018年，在高并發訪問、高吞吐量以及車輛的車聯網接入需求推動下，其智能網聯應用做微服務的改造和應用容器化，“智能網聯開發院”和“數字化部門”聯合起來對整個平臺架構進行了相應的設計，在平臺建設中核心痛點就是需要引入一個微服務的治理平臺，以及一個業務應用的管理平臺，來支撐整個智能網聯平臺的開發需要。
項目依托于靈雀云ACP管理平臺，配合微服務治理平臺，實現了業務應用的運行以及業務應用治理的工作。項目一期實現部分服務器的納管，形成計算資源池，為業務應用提供部署資源。同時，通過微服務治理功能，實現為業務應用的不同部門或者不同開發團隊，適配相應的容器化集群。
當然，平臺的落地并不能只是把工具提供給了客戶，讓客戶更好地用起來，也是一個非常大的挑戰，尤其對于微服務這樣比較新的概念來說。靈雀云在項目當中也為客戶提供了微服務治理咨詢服務，對于微服務的拆分，微服務改造，以及如何更好地使用平臺的各種功能都提供了有針對性的咨詢服務。
經過幾年的努力，該車企的營銷數字化業務的不同業務系統都逐漸遷移到這個平臺上來。這么大規模的平臺和業務應用，運維人員可能只需要3~5個人。
對于他們來說，能得到的收益，首先就是統一業務系統的開發架構，第二是統一了業務系統的部署架構，第三是極大地減少了復雜的業務系統運維，少量的人員就可以支持大量的業務系統的運維工作，同時，通過平臺的資源自動伸縮、微服務治理能力，實現了智能化的業務運行、運維和業務治理。
搭建云原生運維體系非一蹴而就，需要循序漸進，在安全可控的基礎上逐步擴展。在技術層面，合適的云原生技術平臺可以幫助企業釋放運維的巨大壓力，并保證安全穩定。我們相信，在數字化轉型的大背景下，減少人力參與的智能運維勢必會成為未來IT運維的發展方向。我們也期待著能夠幫助更多企業實現云原生時代的智能運維進階。
