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

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

1、宜信容器雲平臺背景

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

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

• DevOps整合。DevOps和敏捷開發的理論已經提出不少年了，爲何DevOps一直沒有獲得很好的推動和實踐呢？由於缺少一種工具把Dev和Ops聯繫起來，而容器的誕生很好地解決了這個問題。開發人員在開發完代碼並完成測試之後，能夠拿着測試的產物直接到生產環境部署上線，而部署的問題能夠直接反饋給開發，造成閉環。也就是說，經過容器的方式，能夠實現一次構建屢次運行。因而可知，經過容器的方式實現DevOps是最佳的方案，企業亟需一套成熟的平臺幫助開發和運維人員保持各個環境的一致性和快速發佈、快速回滾。

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

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

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

上圖左側是宜信容器雲平臺的主要功能，包括：服務管理、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、容器容器雲平臺落地實踐

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

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容器雲優秀案例」。

4、宜信容器雲將來規劃

前文介紹了宜信容器雲平臺目前取得的一些小成就，即宜信容器雲平臺的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平臺負責人 陳曉宇

來源：宜信技術學院