在金融行業數字化轉型的驅動下，國有銀行、股份制銀行和各級商業銀行也紛紛步入容器化的程式。
如果以容器雲上生產為目標，那麼整個容器雲平臺的設計、建設和優化對於銀行來說是一個巨大的挑戰。如何更好地利用雲原生技術，幫助銀行實現敏捷、輕量、快速、高效地進行開發、測試、交付和運維一體化，從而重構業務，推動金融科技的發展，是個長期課題。
本期金融雲原生漫談，將和您共同探索，雲原生時代智慧運維的進階之路。
隨著金融業務的快速發展，支撐業務的IT基礎設施的變化節奏也大大加快。
金融IT運維團隊對IT基礎設施運維的任務，比以往任何時候都要更加艱鉅。核心是保障生產安全運營，並提高軟硬體環境的交付質量。然而在今天的金融IT 3.0時代，IT需求變得越來越強，變化越來越快，伺服器等數量爆增，管理起來日益繁雜。同時，運維管理規模的不斷擴大，運維人員的不斷擴充，使得日常運維工作面臨著雙重的壓力與風險。
以容器、微服務為代表的雲原生技術催生了新一代雲原生運維技術體系，可以幫助金融企業最大化釋放運維效能。基於多年來的實踐經驗，我們對於來自金融行業一線的運維問題進行了回答：
- 相較於虛擬機器，容器的運維和監控有什麼優劣勢？
- 為什麼說基於K8s的容器是實現智慧運維的必然選擇？
- 高併發場景下，如何實現容器的自動擴縮容？
- 如何快、準、狠地排查容器中的應用問題？
- 容器的智慧運維有無成功實踐案例？
希望本篇文章能為您提供借鑑。
相較於虛擬機器，容器的運維和監控有什麼優劣勢？
從運維的角度來看，容器的輕量化使得運維更加靈活高效，更方便應用自動化來提升運維效率。
相較於傳統運維，容器可以實現：
- 更快速部署和交付：對於應用系統的部署可以極大地節省時間成本和人力成本；
- 更標準化交付物：容器的標準交付物為映象，包含應用程式和依賴環境，一次構建多次使用，大大簡化了應用交付模式；
- 更高效的資源利用：容器不需要虛擬機器額外的管理程式，依賴核心執行，在運維資源開銷上要低的多；
- 更加敏捷的遷移和擴充套件：容器可以跨作業系統、跨環境執行，實現無縫遷移的效果，以及高併發場景下的自動擴縮容。
從監控的角度來看，輕量化的容器也帶來了監控的複雜度，特別是大量容器執行的平臺如何排錯和根因分析。
由於容器是黑盒執行，在運維中容器問題的診斷比較複雜；由於容器執行的密度比較大，需要面對的運維實體和物件數量會很龐大；由於容器的自身特性，容器的建立、銷燬等生命週期過程，各類運維資料的採集是個挑戰。另外容器啟動後，監控系統怎麼發現，同時需要對其做哪些資料採集，這些問題都是容器監控自動化過程需要解決的。
在監控這個領域，除了目前比較熱門的純軟體層全鏈路監控以及混沌工程，建議應該結合硬體的監控和檢測實現端到端的監控和測試，以提升平臺的穩定性和效能。
為什麼說基於K8s的容器是實現智慧運維的必然選擇？
隨著容器的不斷成熟，越來越多的金融企業選擇利用容器來搭建業務系統。可是，大家在實際操作中發現，像 Docker 之類的容器引擎，更適合管理少量容器，而如今的雲原生應用、機器學習任務或者大資料分析業務，動輒就要使用成百上千的容器， K8s就自然而然地成為了實現智慧運維的必然選擇。
首先是 K8s 採用宣告式 API，讓開發者可以專注於應用自身，而非系統執行細節。比如，在 Kubernetes 之上，提供了 Deployment、StatefulSet、Job 等不同型別應用負載的抽象。宣告式 API 是雲原生重要的設計理念，有助於將系統複雜性下沉，交給基礎設施進行實現和持續優化。
此外，K8s 提供了可擴充套件性架構，所有 K8s 元件都是基於一致的、開放的 API 進行實現和互動。開發者也可通過 CRD（Custom Resource Definition）/ Operator等方式提供領域相關的擴充套件，極大拓寬了 K8s 的應用場景。
最後，K8s 提供平臺無關的技術抽象：如 CNI 網路外掛, CSI 儲存外掛等等，可以對上層業務應用遮蔽基礎設施差異。
高併發場景下如何實現容器的自動擴縮容？
首先，建議先做好容器雲平臺配套的監控、日誌的建設，再去建設自動擴縮容的自動化能力。
一般可以在高併發場景下使用 K8s 的Horizontal Pod Autoscaling（以下簡稱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運維的發展方向。我們也期待著能夠幫助更多企業實現雲原生時代的智慧運維進階。