宜信公司從2018年初開始建設容器雲，至今，容器雲的常用基本功能已經趨於完善，主要包括服務管理、應用商店、Nginx配置、儲存管理、CI/CD、許可權管理等，支援100+業務線、3500+的容器執行。伴隨公司去VMware以及DevOps、微服務不斷推進的背景，後續還會有更多的業務遷移到容器雲上，容器雲在宜信發揮著越來越重要的作用。本次分享主要介紹宜信容器雲平臺的背景、主要功能、落地實踐及未來規劃。

一、宜信容器雲平臺背景

宜信容器雲平臺的建設背景主要包括：

提高資源利用率。容器雲建設之前，每臺物理機上平均執行的虛擬機器大概是20個，使用了容器雲之後，每臺物理機上平均執行的容器數達到50個；之前的CPU利用率大概在10%左右，遷移到容器雲後，CPU利用率提高到20%以上，整個資源利用率得到了極大的提升。
提升服務可靠性。傳統的虛擬機器運維方式下，當機器當機或系統故障時，需要運維手動重啟虛擬機器和服務，整個過程最快需要幾十分鐘到幾個小時才能解決；使用容器雲後，透過健康檢查的方式，一旦發現有問題就自動重啟恢復服務，可以達到分鐘級甚至秒級的恢復。
節約成本。透過容器雲提高了資源利用率，同時也節約了成本。公司每年會採購一些商業化軟體，如虛擬化軟體、商業儲存等，費用動輒千萬。我們基於開源技術自研一套容器解決方案，每年為公司節省上千萬的軟體採購和維保費用。
彈性伸縮。我們公司每年都會組織財富峰會，在這裡有一個很經典的場景：秒殺，秒殺場景需要很快擴充套件業務的計算能力。為了快速應對網際網路突發流量，如上述的財富峰會、APP線上活動，我們為服務設定了自動伸縮的策略：當CPU利用率達到60%的時候，自動做容器擴容，應對突發的業務流量，提高響應速度；活動過後，自動回收資源，提高資源的利用率。

DevOps整合。DevOps和敏捷開發的理論已經提出很多年了，為什麼DevOps一直沒有得到很好的推進和實踐呢？因為缺乏一種工具把Dev和Ops聯絡起來，而容器的誕生很好地解決了這個問題。開發人員在開發完程式碼並完成測試以後，可以拿著測試的產物直接到生產環境部署上線，而部署的問題可以直接反饋給開發，形成閉環。也就是說，透過容器的方式，可以實現一次構建多次執行。由此可見，透過容器的方式實現DevOps是最佳的方案，企業亟需一套成熟的平臺幫助開發和運維人員保持各個環境的一致性和快速釋出、快速回滾。

在上述背景下，我們結合宜信的業務場景開發建設宜信容器雲平臺。

二、宜信容器雲平臺主要功能

宜信容器雲平臺經過一年多時間的建設和開發，基本的常用功能已經具備。如圖所示。

上圖左側是宜信容器雲平臺的主要功能，包括：服務管理、CI/CD、代理出口、配置管理、檔案儲存、告警策略、映象管理、使用者管理、許可權管理、系統管理等。右側是一個服務管理的介面，從中可以看到服務列表、服務名稱、服務狀態及當前服務數量，還有當前映象版本及更新時間。

2.1 宜信容器雲平臺架構

上圖所示為整個容器雲平臺的架構圖，在各種開源元件（包括Harbor映象倉庫、Kubernetes容器管理、Prometheus 監控、Jenkins構建、Nginx流量轉發和Docker容器虛擬化等）的基礎之上，我們自研開發了5個核心模組。

Cluster-mgr，負責多個Kubernetes叢集之間的管理和排程，在一個Kubernetes叢集出現問題後，將該叢集的容器遷移到其他可用的Kubernetes叢集，並且負責資源的計量。
Ipaas，負責對接各種資源，如呼叫Kubernetes API建立容器、對接Ceph建立儲存、對接Harbor獲取映象等。前端頁面透過Ipaas獲取容器相關的新聞資料、監控指標等。
Codeflow，負責程式碼構建。透過對接Jenkins實現程式碼編譯、打包映象以及服務的滾動升級等工作。
Nginx-mgr，一個對接多個Nginx叢集的管理系統，負責將使用者在頁面配置的規則轉成Nginx配置，並下發到對應的Nginx叢集。
Dophinsync，和公司CMDB系統打通，從CMDB系統同步公司所有專案和服務的相關資料和資訊。

最上面是對使用者提供的web-portal頁面，一個使用者自助的終端。

本次分享的標題是《宜信容器雲的A點與B點》，之所以稱為A點和B點，這與我們的公司文化有關，我們以“A點”代指現在已經做到的事情，以“B點”代指未來或者下個階段要做的事情。

目前整個宜信容器雲平臺已經完成了大部分主要功能點的開發，這部分已經實現的功能即為“A點”，包括服務管理、應用商店、域名管理、CI/CD、映象管理、檔案儲存、監控告警、定時任務、配置管理等。後續還有部分功能需要新增和完善，即為“B點”，主要包括：物件儲存、大資料容器雲、全面日誌收集、自定義指標伸縮、智慧排程和混部、多叢集管理、安全隔離、站點監控等，

2.2 宜信容器雲功能模組

上圖為宜信容器雲平臺的整體功能圖，其中藍色代表已經完成的功能、黃色代表需要最佳化和改善的功能。

整個系統從資源管理的角度來看：

底層是硬體層面的計算、儲存、網路；
其上是資源管理層，負責容器、儲存、域名、映象、叢集管理；
往上是中介軟體層，包括Kafka、MySQL等中介軟體服務；
再往上是應用層，提供給使用者使用的終端；
兩側分別是CI/CD的構建流程和安全認證相關的功能元件。

下面將透過頁面截圖的方式，詳細介紹容器雲的主要功能點。

2.2.1 主要功能點——服務管理

上圖是服務管理頁面的截圖，逐一介紹各個功能。

容器列表。上側的選單是服務管理的列表，進入到某一個服務管理，就可以對服務進行具體操作，包括基本配置、升級、擴縮容、域名管理、同步生產環境等。
歷史容器。服務升級或故障遷移之後，容器的名稱、IP地址等會發生變化，歷史容器的功能是記錄一個服務下面容器的變化情況，方便我們追蹤容器的變化，追溯效能監控資料，進行故障定位。
日誌下載。可以透過頁面方式直接下載使用者日誌資料。終端資訊與前面的日誌輸出是有區別的。前面的日誌下載是應用把日誌儲存到容器裡的某一個指定路徑下；終端資訊是容器標準輸出的日誌，Event資訊裡主要記錄容器的狀態資訊，比如什麼時候拉取映象、什麼時候啟動服務等。Webshell主要提供容器登入，可以像SSH一樣透過頁面的方式登入到終端。
非root登入。為了保持容器生產環境的安全，我們以非root的方式登入容器控制檯，避免誤刪資料。
Debug容器實現，透過啟動一個工具容器，掛載到業務容器裡，共享網路、程式等資料。傳統的方式希望容器映象儘可能小、安裝的軟體儘可能少，這樣啟動更快、安全性更高，但由於容器本身只安裝了程式必要的依賴，導致排查檔案困難。為了解決這個問題，我們基於開源技術開發了debug容器功能：debug容器掛載到業務容器中，共享業務容器的網路記憶體和主機相關的各種資訊，這樣一來，就相當於在業務容器中執行了debug命令，既方便運維和業務人員排查故障，保障了容器的快速安全，又為業務提供了一種更好的debug方式。安裝的客戶端如Reids客戶端、MySQL客戶端、Tcpdump等。
容器效能監控，包括CPU、記憶體、網路IO、磁碟IO等監控指標。
審計，使用者所有操作命令都會透過審計工具進行稽核。
摘除例項，主要是針對一些異常容器的故障定位，將流量從負載均衡上摘除。
銷燬功能，當容器需要重建時會用到銷燬功能。

除了上文介紹的一排容器按鈕以外，還有一些針對服務的相關操作，比如服務的基本配置：環境變數、域名解析、健康檢查，服務的升級，替換映象、擴縮容等操作。

2.2.2 主要功能點——應用商店

很多業務場景有這樣的需求：希望可以在測試環境裡實現一鍵啟動中介軟體服務，如MySQL、Zookerper 、Redis、Kafka等，不需要手動去配置kafka等叢集。因此我們提供了中介軟體容器化的解決方案，將一些常用的中介軟體匯入容器中，後端透過Kubernetes維護這些中介軟體的狀態，這樣使用者就可以一鍵建立中介軟體服務。

但由於這些中介軟體服務本身相對來說比較複雜，所以目前我們的應用商店功能主要是為大家提供測試環境，等這部分功能成熟之後，會把應用商店這些常用的中介軟體擴充到生產環境上，到時候就可以在生產環境使用容器化的中介軟體服務了。

2.2.3 主要功能點——CI/CD

CI/CD是程式碼構建流，我們內部稱為codeflow。其實程式碼構建流程非常簡單，一句話概括起來，就是：拉取倉庫原始碼，透過使用者指定的編譯指令碼構建出執行程式，將執行程式放到使用者指定部署路徑，並透過啟動命令啟動這個服務。系統會為每個codeflow生成對應的Dockerfile用於構建映象，使用者不需要具備Docker使用經驗。

上面的流程是程式碼編譯，下面是透過系統預先生成的Dockerfile，幫使用者打包成Docker Image，這就是從程式碼拉取、程式碼編譯、打包到Docker Image並推送到映象倉庫的整個流程。

使用者完成配置並點選提交程式碼後，就可以透過手動或Webhook的方式觸發整個構建流程。也就是說只要使用者一提交程式碼，就會觸發整個構建流程，編譯原始碼、打包Docker映象、推送映象倉庫並觸發滾動升級，使用者可以在分鐘級別看到效果。在這裡我們還做了一些小的功能：

非root構建。我們的後端其實是在一個Jenkins叢集下構建的，這樣就存在一個問題：如果使用者在編輯指令碼的時候，不小心寫錯程式碼就可能會將整個主機上的東西都刪除，非常不安全。為了解決這個問題，我們在整個構建過程中採用非root構建的方式，避免某個使用者因編譯指令碼執行某些特權操作而影響系統安全。
自定義Dockerfile。支援某些使用者使用自己的Dockerfile構建映象，使用者透過上傳Dockerfile的方式，覆蓋系統生成的Dockerfile。
預處理指令碼，主要針對Python類的映象構建，Python類的映象構建本身不需要編譯原始碼，但執行環境需要依賴很多第三方的包和庫，如果將這些依賴包都安裝到基礎映象，不僅會導致基礎映象過大，而且後期維護也很麻煩。為了支援Python軟體容器化的執行，我們提供了預處理指令碼，即在業務映象之前先執行預處理指令碼，幫使用者安裝好所需要的依賴包，然後再把使用者的程式碼複製過來，基於預處理指令碼之後的映象去生成業務映象，下次構建的時候，只要預處理指令碼不變，就可以直接構建業務映象了。
Webhook觸發和Gitlab整合，透過Gitlab的Webhook，當使用者在提交程式碼或者merge pr的時候便可以觸發codeflow，執行自動上線流程。

2.2.4 主要功能點——檔案儲存

容器通常需要業務進行無狀態的改造，所謂“無狀態”是需要把一些狀態資料放在外部的中介軟體或儲存裡。

我們提供了兩種儲存方式：NFS和Cephfs檔案儲存。使用者在頁面選擇儲存的容量，然後點選建立，就可以直接建立一個Cephfs檔案儲存，並且可以在服務管理頁面指定將這一儲存掛載到容器的某一個路徑下，當容器重啟或者遷移後，檔案儲存會保持之前的目錄掛載，從而保障資料不丟失。

2.2.5 主要功能點——Nginx配置

公司有大概100多個Nginx叢集，之前這些Nginx叢集都是透過運維人員手動方式變更配置和維護，配置檔案格式不統一，且容易配置錯誤，問題和故障定位都很困難。為此我們在容器雲整合了Nginx配置管理，透過模板的方式生產Nginx配置。Nginx配置的功能比較多，包括健康檢查規則、灰度釋出策略等相關配置。

上圖是一個系統管理員可以看到的頁面，其中部分專案開放給業務使用者，允許使用者自己定義部分Nginx配置，如upstream列表，從而將公司域名配置模板化。

除此之外，我們還做了配置檔案的多版本對比，Nginx的每次配置都會生成一個對應的版本號，這樣就可以看到在什麼時間Nginx被誰修改了哪些內容等，如果發現Nginx配置修改有問題，可以點選回滾到Nginx的歷史版本。

泛域名解析，主要適用於測試環境。之前每一個測試服務都需要聯絡運維人員單獨申請一個域名，為了節省使用者申請域名的時間，我們為每個服務建立一個域名，系統透過泛域名解析的方式，將這些域名都指定到特定的Nginx叢集。

Nginx後端可以包含容器也可以包含虛擬機器，這是在業務遷移過程中非常常見的，因為很多業務遷移到容器都並非一蹴而就，而是先將部分流量切換到容器內執行。

2.2.6 主要功能點——配置檔案管理

現在的架構提倡程式碼和配置分離，即在測試環境和生產環境使用相同的程式碼，不同的配置檔案。為了能夠動態變更配置檔案，我們透過Kubernetes的Configmap實現了配置檔案管理的功能：將配置檔案掛載到容器內，使用者可以在頁面上傳或者編輯配置檔案，儲存後，系統將配置檔案更新到容器內。

就是說當使用者在頁面上傳或編譯某個配置檔案以後，平臺會自動把配置檔案重新整理到容器裡，容器就可以使用最新的配置檔案了。為了避免使用者誤刪配置檔案，當系統發現配置檔案被使用則不允許刪除。

2.2.7 主要功能點——告警管理

告警管理功能基於Prometheus實現。平臺會把所有的監控資料，包括容器相關的（CPU、記憶體、網路IO等）、Nginx相關的、各個元件狀態相關的資料，都錄入到Prometheus裡，使用者可以基於這些指標設定監控閾值，如果達到監控閾值，則向運維人員或業務人員傳送告警。

值得一提的是，我們提供了一種特殊的告警：單個容器效能指標。按常理，每個容器監控指標應該是類似的，沒有必要針對單個容器設定告警，但在實際生產環境中，我們遇到過多次由於某個特定請求觸發的bug導致CPU飆升的場景，所以開發了針對單個容器的效能告警。

三、容器容器雲平臺落地實踐

前面介紹了系統的一些常用功能，接下來介紹宜信容器雲平臺落地過程中的實踐。

3.1 實踐——自定義日誌採集

容器的使用方式建議使用者將日誌輸出到控制檯，但傳統應用的日誌都是分級別儲存，如Debug日誌、Info日誌、Error日誌等，業務需要採集容器內部指定目錄的日誌，怎麼實現呢？

我們透過二次開發Kubelet，在容器啟動前判斷是否有“KUBERNETES_FILELOGS”這個環境變數，如果存在，則將“KUBERNETES_FILELOGS”指定的容器目錄掛載到宿主的“/logs/容器名稱”這個目錄下面，配合公司自研的日誌採集外掛Watchdog便可以將宿主機上這個目錄下的檔案統一收集。

3.2 實踐——TCP代理出口

在實際過程中我們經常遇到網路對外提供服務的場景，系統中除了Nginx提供的 HTTP反向代理以外，還有一些需要透過TCP的方式對外提供的服務，我們透過系統中指定的兩臺機器安裝Keepalive和配置虛IP的方式，對外暴露TCP服務。

3.3 實踐——自動擴容

自動擴容，主要是針對業務指標的一些突發流量可以做業務的自動伸縮。其原理非常簡單：因為我們所有的效能指標都是透過Prometheus統一採集，而Cluster-mgr負責多叢集管理，它會定時（預設30s）去Prometheus獲取容器的各種效能指標，透過上圖的公式計算出每個服務的最佳副本個數。公式很簡單：就是每個容器的效能指標求和，除以使用者定義目標指標值，所得結果即為最佳副本數。然後Cluster-mgr會呼叫Ipaas操作多個叢集擴容和縮容副本數。

舉個例子，現在有一組容器，我希望它的CPU利用率是50%，但當前4個副本，每個副本都達到80%，求和為320，320除以50，最大副本數為6，得到結果後就可以自動擴容容器的副本了。

3.4 實踐——多叢集管理

傳統模式下，單個Kubernetes叢集是很難保證服務的狀態的，單個叢集部署在單個機房，如果機房出現問題，就會導致服務不可用。因此為了保障服務的高可用，我們開發了多叢集管理模式。

多叢集管理模式的原理很簡單：在多個機房分別部署一套Kubernetes叢集，並在服務建立時，把應用部署到多個Kubernetes叢集中，對外還是提供統一的負載均衡器，負載均衡器會把流量分發到多個Kubernetes叢集裡去。避免因為一個叢集或者機房故障，而影響服務的可用性。

如果要建立Kubernetes相關或Deployment相關的資訊，系統會根據兩個叢集的資源用量去分配Deployment副本數；而如果要建立PV、PVC以及Configmap等資訊，則會預設在多個叢集同時建立。

叢集控制器的功能是負責檢測Kubernetes叢集的健康狀態，如果不健康則發出告警，通知運維人員切換叢集，可以將一個叢集的服務遷移到另一個叢集。兩個叢集之外透過Nginx切換多叢集的流量，保障服務的高可用。

這裡有3點需要注意：

儲存遷移。底層提供了多機房共享的分散式儲存，可以隨著容器的遷移而遷移。
網路互通。網路是透過Flannel + 共享etcd的方案，實現跨機房容器互通及業務之間的相互呼叫。
映象倉庫間的資料同步。為了實現兩個映象倉庫之間映象的快速拉取，我們在兩個機房內都部署了一個映象倉庫，這兩個映象倉庫之間的資料是互相同步的，這樣就不用跨機房拉取映象了。

3.5 實踐——如何縮短構建時間

如何加速整個CI/CD構建的流程？這裡總結了四點：

程式碼pull替換clone。在構建程式碼的過程中，用pull替換clone的方式。用clone的方式拉取原始碼非常耗時，特別是有些原始碼倉庫很大，拉取程式碼要耗費十幾秒的時間；而用pull的方式，如果發現程式碼有更新，只需要拉取更新的部分就可以了，不需要重新clone整個原始碼倉庫，從而提高了程式碼拉取的速度。
本地（私有）倉庫、mvn包本地快取。我們搭建了很多本地（私有）倉庫，包括Java、Python的倉庫，不需要再去公網拉取依賴包，這樣不僅更安全，而且速度更快。
預處理指令碼。只在第一次構建時觸發，之後便可以基於預處理指令碼構建的映象自動構建。
SSD加持。透過SSD硬體的加持，也提高了整個程式碼構建的速度。

3.6 實踐——什麼樣的程式適合容器

什麼樣的程式適合執行在容器裡？

無作業系統依賴。目前主流容器方案都是基於Linux核心的cgroup和namespace相關技術實現的，這就意味著容器只能在Linux系統執行，如果是Windows或者C#之類的程式是無法執行到容器裡面的。
無固定IP依賴。這個其實不算硬性要求，雖然容器本身是可以實現固定IP地址的，但固定的IP地址會為Deployment的自動伸縮以及叢集遷移帶來很多麻煩。
無本地資料依賴。容器的重新發布是透過拉取新的映象啟動新的容器程式的方式，這就希望使用者不要將資料儲存到容器的本地，而是應該藉助外部的中介軟體或者分散式儲存儲存這些資料。

3.7 避坑指南

在實踐過程中會遇到很多問題，本節將列舉一些已經踩過的坑，逐一與大家分享我們的避坑經驗。

3.7.1 為啥我的服務沒有起來？

這種情況可能是因為服務被放在了後臺啟動，容器的方式和之前虛擬機器的方式有很大區別，不能把容器服務放在後臺啟動，容器啟動的程式的PID是1，這個程式程式是容器裡唯一的啟動程式，如果程式退出了容器就結束了，這就意味著程式不能退出。如果把程式放到後臺啟動，就會出現程式起來了但容器服務沒有起來的情況。

3.7.2 為啥服務啟動/訪問變慢？

之前使用虛擬機器的時候，由於配置比較高（4核8G），很多業務人員沒有關心過這個問題。使用容器之後，平臺預設會選中1核1G的配置，執行速度相對較慢，這就導致了業務在訪問業務的時候會覺得服務啟動和訪問變慢。

3.7.3 為啥服務會異常重啟？

這和配置的健康檢查策略有關，如果某應用的配置健康檢查策略不透過的話，Kubernetes的Liveness探針將會重啟該應用；如果業務是健康的，但提供的健康檢查介面有問題或不存在，也會重啟這個容器，所以業務要特別注意這個問題。

3.7.4 本地編譯可以，為啥伺服器上程式碼編譯失敗？

這個問題非常常見，大多是由於編譯環境和伺服器環境的不一致導致的。很多業務在本地編譯的時候，本地有一些開發工具的加持，有一些工作開發工具幫助完成了，而伺服器上沒有這些工具，因此會出現這個問題。

3.7.5 為啥我的歷史日誌找不到了？

這個問題和容器使用相關，容器裡預設會為使用者儲存最近兩天的日誌，主機上有一個清理的功能，日誌超過兩天就會被清理掉。那這些超過兩天的日誌去哪裡檢視呢？我們公司有一個統一的日誌採集外掛Watchdog，負責採集儲存歷史日誌，可以在日誌檢索系統中檢索到這些歷史日誌。

3.7.6 為啥IP地址會變化？

每次容器重啟，其IP地址都會發生變化，希望業務人員的程式碼不要依賴這些IP地址去配置服務呼叫。

3.7.7 為啥流量會打到異常容器？

容器已經異常了，為什麼還有流量過來？這個問題具體表現為兩種情況：業務沒起來，流量過來了；業務已經死了，流量還過來。這種兩種情況都是不正常的。

第一種情況會導致訪問報錯，這種場景一般是透過配合健康檢查策略完成的，它會檢查容器服務到底起沒起來，如果檢查OK就會把新的流量打過來，這樣就解決了新容器啟動流量的異常。
第二種情況是和容器的優雅關閉相結合的，容器如果沒有匹配優雅關閉，會導致K8s先去關閉容器，此時容器還沒有從K8s的Service中摘除，所以還會有流量過去。解決這個問題需要容器裡面應用能夠支援優雅關閉，傳送優雅關閉時，容器開始自己回收，在優雅關閉時間後強制回收容器。

3.7.8 為啥沒法登入容器？

很多時候這些容器還沒有起來，此時當然就無法登陸。

3.7.9 Nginx後端應該配置幾個？OOM？Cache？

這幾個問題也經常遇到。在業務使用過程中會配置CPU、記憶體相關的東西，如果沒有合理配置，就會導致容器的OOM。我們新版的容器映象都是自適應、自動調整JVM引數，不需要業務人員去調整配置，

3.8 faketime

容器不是虛擬機器，所以有些容器的使用方式並不能和虛擬機器完全一致。在我們的業務場景裡還有一個問題：業務需要調整時鐘。

容器和虛擬機器的其中一個區別是：虛擬機器是獨立的作業系統，修改其中一個虛擬機器裡的任何東西都不會影響其他虛擬機器。而容器除了前面說的幾種隔離以外，其他東西都不是隔離的，所有的容器都是共享主機時鐘的，這就意味著如果你改了一個容器的時鐘，就相當於改了整個所有容器的時鐘。

如何解決這個問題呢？我們在網上找到一種方案：透過劫持系統呼叫的方式修改容器的時鐘。但這個方案有一個問題：faketime不能睡著了。

3.9 使用情況

經過幾年的推廣，目前宜信容器雲平臺上已經支援了100多條業務線，執行了3700個容器，累計釋出17萬次，還榮獲了“CNCF容器雲優秀案例”。

四、宜信容器雲未來規劃

前文介紹了宜信容器雲平臺目前取得的一些小成就，即宜信容器雲平臺的A點，接下來介紹宜信容器雲的B點，即未來的一些規劃。

4.1 物件儲存

公司有很多檔案需要對外提供訪問，如網頁中的圖片、影片、pdf、word文件等，這些檔案大部分都是零散地儲存在各自系統的儲存中，沒有形成統一的儲存管理。如果檔案需要對外提供訪問，則是透過Nginx反向代理掛載NAS儲存的方式，這些檔案的維護成本非常高，安全性也得不到保障。

我們基於Ceph開發一個統一的物件儲存服務，把公司零散在各個系統的小檔案集中到物件儲存中去，對於可以提供外網或公網訪問的部分，生成外網訪問的HTTP的URL。目前物件儲存已經在業務的測試環境上線。

4.2 站點監控

站點監控是一個正在重點研發的功能。公司開源了智慧運維工具UAVstack，側重於應用的監控，還缺乏服務外部的站點監控。站點監控是為了監控服務介面的執行狀態，併傳送告警。

我們透過在公司外部部署採集Agent，這些Agetnt會根據使用者定義的監控URL定時呼叫介面是否正常執行，如果介面返回資料不符合使用者設定條件則發出告警，如HTTP返回5xx錯誤或者返回的body中包含ERROR字元等。

4.3 大資料容器雲

在大部分業務遷移到容器後，我們開始嘗試將各種大資料中介軟體（如Spark、Flink等）也遷移到Kubernetes叢集之上，利用Kubernetes提供的特性更好地運維這些中介軟體元件，如叢集管理、自動部署、服務遷移、故障恢復等。

4.4 混合部署

公司有很多長任務，這些長任務有一個非常明顯的特點：白天訪問量較高，晚上訪問量較低。對應的是批處理任務，批處理主要指公司的跑批任務，如報表統計、財務賬單等，其特點是每天凌晨開始執行，執行時對CPU和記憶體的消耗特別大，但只執行十幾分鍾或幾個小時，白天基本空閒。

為了得到更高的資源利用率，我們正在嘗試透過歷史資料進行建模，將批處理任務和長任務混合部署。

4.5 未來規劃——DevOps平臺

最後介紹我們整個平臺的DevOps規劃。

回到之前容器雲的背景，業務需要一套統一的DevOps平臺，在這個平臺上，可以幫助業務完成程式碼構建、自動化測試、容器釋出以及應用監控等一系列功能。

其實這些功能我們基礎研發部門都有所涉及，包括自動化測試平臺 Gebat、應用監控UAVStack、容器雲平臺等，但是業務需要登入到不同的平臺，關聯不同的資料，而各個平臺之間的資料不一致、服務名稱不對應，沒辦法直接互通，操作起來非常麻煩。我們希望透過建立一個統一的DevOps平臺，把程式碼釋出、自動化測試、容器執行和監控放到同一個平臺上去，讓使用者可以在一個平臺完成所有操作。

內容來源：宜信技術學院第7期技術沙龍-線上直播|宜信容器雲的A點與B點

主講人：宜信高階架構師 & 宜信PaaS平臺負責人陳曉宇

來源：宜信技術學院

支援100+業務線、累計釋出17萬次|宜信容器雲的A點與B點（分享實錄）