主講人介紹

[[287112]]

陳曉宇：宜信高級(jí)架構(gòu)師 & 宜信PaaS平臺(tái)負(fù)責(zé)人

導(dǎo)讀：宜信公司從2018年初開(kāi)始建設(shè)容器云，至今，容器云的常用基本功能已經(jīng)趨于完善，主要包括服務(wù)管理、應(yīng)用商店、Nginx配置、存儲(chǔ)管理、CI/CD、權(quán)限管理等，支持100+業(yè)務(wù)線、3500+的容器運(yùn)行。伴隨公司去VMware以及DevOps、微服務(wù)不斷推進(jìn)的背景，后續(xù)還會(huì)有更多的業(yè)務(wù)遷移到容器云上，容器云在宜信發(fā)揮著越來(lái)越重要的作用。本次分享將圍繞容器云展開(kāi)，主要介紹其設(shè)計(jì)思想、技術(shù)架構(gòu)和核心功能，以及容器云在宜信落地的實(shí)踐經(jīng)驗(yàn)。

分享大綱：

一、宜信容器云平臺(tái)背景

二、宜信容器云平臺(tái)主要功能

三、容器容器云平臺(tái)落地實(shí)踐

四、宜信容器云未來(lái)規(guī)劃

以下為直播視頻，可點(diǎn)擊回放，時(shí)長(zhǎng)59m21s，建議在WiFi環(huán)境下觀看。

分享實(shí)錄

 宜信公司從2018年初開(kāi)始建設(shè)容器云，至今，容器云的常用基本功能已經(jīng)趨于完善，主要包括服務(wù)管理、應(yīng)用商店、Nginx配置、存儲(chǔ)管理、CI/CD、權(quán)限管理等，支持100+業(yè)務(wù)線、3500+的容器運(yùn)行。伴隨公司去VMware以及DevOps、微服務(wù)不斷推進(jìn)的背景，后續(xù)還會(huì)有更多的業(yè)務(wù)遷移到容器云上，容器云在宜信發(fā)揮著越來(lái)越重要的作用。本次分享主要介紹宜信容器云平臺(tái)的背景、主要功能、落地實(shí)踐及未來(lái)規(guī)劃。

一、容器云平臺(tái)的產(chǎn)生背景

宜信容器云平臺(tái)的建設(shè)背景主要包括：

• 提高資源利用率。容器云建設(shè)之前，每臺(tái)物理機(jī)上平均運(yùn)行的虛擬機(jī)大概是20個(gè)，使用了容器云之后，每臺(tái)物理機(jī)上平均運(yùn)行的容器數(shù)達(dá)到50個(gè)；之前的CPU利用率大概在10%左右，遷移到容器云后，CPU利用率提高到20%以上，整個(gè)資源利用率得到了極大的提升。 
• 提升服務(wù)可靠性。傳統(tǒng)的虛擬機(jī)運(yùn)維方式下，當(dāng)機(jī)器宕機(jī)或系統(tǒng)故障時(shí)，需要運(yùn)維手動(dòng)重啟虛擬機(jī)和服務(wù)，整個(gè)過(guò)程最快需要幾十分鐘到幾個(gè)小時(shí)才能解決；使用容器云后，通過(guò)健康檢查的方式，一旦發(fā)現(xiàn)有問(wèn)題就自動(dòng)重啟恢復(fù)服務(wù)，可以達(dá)到分鐘級(jí)甚至秒級(jí)的恢復(fù)。 
• 節(jié)約成本。通過(guò)容器云提高了資源利用率，同時(shí)也節(jié)約了成本。公司每年會(huì)采購(gòu)一些商業(yè)化軟件，如虛擬化軟件、商業(yè)存儲(chǔ)等，費(fèi)用動(dòng)輒千萬(wàn)。我們基于開(kāi)源技術(shù)自研一套容器解決方案，每年為公司節(jié)省上千萬(wàn)的軟件采購(gòu)和維保費(fèi)用。 
• 彈性伸縮。我們公司每年都會(huì)組織財(cái)富峰會(huì)，在這里有一個(gè)很經(jīng)典的場(chǎng)景：秒殺，秒殺場(chǎng)景需要很快擴(kuò)展業(yè)務(wù)的計(jì)算能力。為了快速應(yīng)對(duì)互聯(lián)網(wǎng)突發(fā)流量，如上述的財(cái)富峰會(huì)、APP線上活動(dòng)，我們?yōu)榉?wù)設(shè)置了自動(dòng)伸縮的策略：當(dāng)CPU利用率達(dá)到60%的時(shí)候，自動(dòng)做容器擴(kuò)容，應(yīng)對(duì)突發(fā)的業(yè)務(wù)流量，提高響應(yīng)速度；活動(dòng)過(guò)后，自動(dòng)回收資源，提高資源的利用率。

• DevOps整合。DevOps和敏捷開(kāi)發(fā)的理論已經(jīng)提出很多年了，為什么DevOps一直沒(méi)有得到很好的推進(jìn)和實(shí)踐呢？因?yàn)槿狈σ环N工具把Dev和Ops聯(lián)系起來(lái)，而容器的誕生很好地解決了這個(gè)問(wèn)題。開(kāi)發(fā)人員在開(kāi)發(fā)完代碼并完成測(cè)試以后，可以拿著測(cè)試的產(chǎn)物直接到生產(chǎn)環(huán)境部署上線，而部署的問(wèn)題可以直接反饋給開(kāi)發(fā)，形成閉環(huán)。也就是說(shuō)，通過(guò)容器的方式，可以實(shí)現(xiàn)一次構(gòu)建多次運(yùn)行。由此可見(jiàn)，通過(guò)容器的方式實(shí)現(xiàn)DevOps是最佳的方案，企業(yè)亟需一套成熟的平臺(tái)幫助開(kāi)發(fā)和運(yùn)維人員保持各個(gè)環(huán)境的一致性和快速發(fā)布、快速回滾。

在上述背景下，我們結(jié)合宜信的業(yè)務(wù)場(chǎng)景開(kāi)發(fā)建設(shè)宜信容器云平臺(tái)。

二、宜信容器云平臺(tái)主要功能

宜信容器云平臺(tái)經(jīng)過(guò)一年多時(shí)間的建設(shè)和開(kāi)發(fā)，基本的常用功能已經(jīng)具備。如圖所示。

2.1 宜信容器云平臺(tái)架構(gòu)

• Cluster-mgr，負(fù)責(zé)多個(gè)Kubernetes集群之間的管理和調(diào)度，在一個(gè)Kubernetes集群出現(xiàn)問(wèn)題后，將該集群的容器遷移到其他可用的Kubernetes集群，并且負(fù)責(zé)資源的計(jì)量。
• Ipaas，負(fù)責(zé)對(duì)接各種資源，如調(diào)用Kubernetes API創(chuàng)建容器、對(duì)接Ceph創(chuàng)建存儲(chǔ)、對(duì)接Harbor獲取鏡像等。前端頁(yè)面通過(guò)Ipaas獲取容器相關(guān)的新聞數(shù)據(jù)、監(jiān)控指標(biāo)等。
• Codeflow，負(fù)責(zé)代碼構(gòu)建。通過(guò)對(duì)接Jenkins實(shí)現(xiàn)代碼編譯、打包鏡像以及服務(wù)的滾動(dòng)升級(jí)等工作。
• Nginx-mgr，一個(gè)對(duì)接多個(gè)Nginx集群的管理系統(tǒng)，負(fù)責(zé)將用戶在頁(yè)面配置的規(guī)則轉(zhuǎn)成Nginx配置，并下發(fā)到對(duì)應(yīng)的Nginx集群。
• Dophinsync，和公司CMDB系統(tǒng)打通，從CMDB系統(tǒng)同步公司所有項(xiàng)目和服務(wù)的相關(guān)數(shù)據(jù)和信息。

2.2 宜信容器云功能模塊

• 底層是硬件層面的計(jì)算、存儲(chǔ)、網(wǎng)絡(luò)；
• 其上是資源管理層，負(fù)責(zé)容器、存儲(chǔ)、域名、鏡像、集群管理；
• 往上是中間件層，包括Kafka、MySQL等中間件服務(wù)；
• 再往上是應(yīng)用層，提供給用戶使用的終端；
• 兩側(cè)分別是CI/CD的構(gòu)建流程和安全認(rèn)證相關(guān)的功能組件。

2.2.1 主要功能點(diǎn)——服務(wù)管理

• 容器列表。上側(cè)的菜單是服務(wù)管理的列表，進(jìn)入到某一個(gè)服務(wù)管理，就可以對(duì)服務(wù)進(jìn)行具體操作，包括基本配置、升級(jí)、擴(kuò)縮容、域名管理、同步生產(chǎn)環(huán)境等。
• 歷史容器。服務(wù)升級(jí)或故障遷移之后，容器的名稱、IP地址等會(huì)發(fā)生變化，歷史容器的功能是記錄一個(gè)服務(wù)下面容器的變化情況，方便我們追蹤容器的變化，追溯性能監(jiān)控?cái)?shù)據(jù)，進(jìn)行故障定位。
• 日志下載。可以通過(guò)頁(yè)面方式直接下載用戶日志數(shù)據(jù)。終端信息與前面的日志輸出是有區(qū)別的。前面的日志下載是應(yīng)用把日志保存到容器里的某一個(gè)指定路徑下；終端信息是容器標(biāo)準(zhǔn)輸出的日志，Event信息里主要記錄容器的狀態(tài)信息，比如什么時(shí)候拉取鏡像、什么時(shí)候啟動(dòng)服務(wù)等。Webshell主要提供容器登錄，可以像SSH一樣通過(guò)頁(yè)面的方式登錄到終端。
• 非root登錄。為了保持容器生產(chǎn)環(huán)境的安全，我們以非root的方式登錄容器控制臺(tái)，避免誤刪數(shù)據(jù)。
• Debug容器實(shí)現(xiàn)，通過(guò)啟動(dòng)一個(gè)工具容器，掛載到業(yè)務(wù)容器里，共享網(wǎng)絡(luò)、進(jìn)程等數(shù)據(jù)。傳統(tǒng)的方式希望容器鏡像盡可能小、安裝的軟件盡可能少，這樣啟動(dòng)更快、安全性更高，但由于容器本身只安裝了程序必要的依賴，導(dǎo)致排查文件困難。為了解決這個(gè)問(wèn)題，我們基于開(kāi)源技術(shù)開(kāi)發(fā)了debug容器功能：debug容器掛載到業(yè)務(wù)容器中，共享業(yè)務(wù)容器的網(wǎng)絡(luò)內(nèi)存和主機(jī)相關(guān)的各種信息，這樣一來(lái)，就相當(dāng)于在業(yè)務(wù)容器中執(zhí)行了debug命令，既方便運(yùn)維和業(yè)務(wù)人員排查故障，保障了容器的快速安全，又為業(yè)務(wù)提供了一種更好的debug方式。安裝的客戶端如Reids客戶端、MySQL客戶端、Tcpdump等。
• 容器性能監(jiān)控，包括CPU、內(nèi)存、網(wǎng)絡(luò)IO、磁盤(pán)IO等監(jiān)控指標(biāo)。
• 審計(jì)，用戶所有操作命令都會(huì)通過(guò)審計(jì)工具進(jìn)行審核。
• 摘除實(shí)例，主要是針對(duì)一些異常容器的故障定位，將流量從負(fù)載均衡上摘除。
• 銷毀功能，當(dāng)容器需要重建時(shí)會(huì)用到銷毀功能。

2.2.2 主要功能點(diǎn)——應(yīng)用商店

2.2.3 主要功能點(diǎn)——CI/CD

• 非root構(gòu)建。我們的后端其實(shí)是在一個(gè)Jenkins集群下構(gòu)建的，這樣就存在一個(gè)問(wèn)題：如果用戶在編輯腳本的時(shí)候，不小心寫(xiě)錯(cuò)代碼就可能會(huì)將整個(gè)主機(jī)上的東西都刪除，非常不安全。為了解決這個(gè)問(wèn)題，我們?cè)谡麄€(gè)構(gòu)建過(guò)程中采用非root構(gòu)建的方式，避免某個(gè)用戶因編譯腳本執(zhí)行某些特權(quán)操作而影響系統(tǒng)安全。
• 自定義Dockerfile。支持某些用戶使用自己的Dockerfile構(gòu)建鏡像，用戶通過(guò)上傳Dockerfile的方式，覆蓋系統(tǒng)生成的Dockerfile。
• 預(yù)處理腳本，主要針對(duì)Python類的鏡像構(gòu)建，Python類的鏡像構(gòu)建本身不需要編譯源代碼，但運(yùn)行環(huán)境需要依賴很多第三方的包和庫(kù)，如果將這些依賴包都安裝到基礎(chǔ)鏡像，不僅會(huì)導(dǎo)致基礎(chǔ)鏡像過(guò)大，而且后期維護(hù)也很麻煩。為了支持Python軟件容器化的運(yùn)行，我們提供了預(yù)處理腳本，即在業(yè)務(wù)鏡像之前先執(zhí)行預(yù)處理腳本，幫用戶安裝好所需要的依賴包，然后再把用戶的代碼拷貝過(guò)來(lái)，基于預(yù)處理腳本之后的鏡像去生成業(yè)務(wù)鏡像，下次構(gòu)建的時(shí)候，只要預(yù)處理腳本不變，就可以直接構(gòu)建業(yè)務(wù)鏡像了。
• Webhook觸發(fā)和Gitlab集成，通過(guò)Gitlab的Webhook，當(dāng)用戶在提交代碼或者merge pr的時(shí)候便可以觸發(fā)codeflow，執(zhí)行自動(dòng)上線流程。

2.2.4 主要功能點(diǎn)——文件存儲(chǔ)

2.2.5 主要功能點(diǎn)——Nginx配置

2.2.6 主要功能點(diǎn)——配置文件管理

2.2.7 主要功能點(diǎn)——告警管理

 三、容器容器云平臺(tái)落地實(shí)踐

3.1 實(shí)踐——自定義日志采集

3.2 實(shí)踐——TCP代理出口

3.3 實(shí)踐——自動(dòng)擴(kuò)容

3.4 實(shí)踐——多集群管理

• 存儲(chǔ)遷移。底層提供了多機(jī)房共享的分布式存儲(chǔ)，可以隨著容器的遷移而遷移。 
• 網(wǎng)絡(luò)互通。網(wǎng)絡(luò)是通過(guò)Flannel + 共享etcd的方案，實(shí)現(xiàn)跨機(jī)房容器互通及業(yè)務(wù)之間的相互調(diào)用。 
• 鏡像倉(cāng)庫(kù)間的數(shù)據(jù)同步。為了實(shí)現(xiàn)兩個(gè)鏡像倉(cāng)庫(kù)之間鏡像的快速拉取，我們?cè)趦蓚€(gè)機(jī)房?jī)?nèi)都部署了一個(gè)鏡像倉(cāng)庫(kù)，這兩個(gè)鏡像倉(cāng)庫(kù)之間的數(shù)據(jù)是互相同步的，這樣就不用跨機(jī)房拉取鏡像了。

3.5 實(shí)踐——如何縮短構(gòu)建時(shí)間

• 代碼pull替換clone。在構(gòu)建代碼的過(guò)程中，用pull替換clone的方式。用clone的方式拉取源代碼非常耗時(shí)，特別是有些源代碼倉(cāng)庫(kù)很大，拉取代碼要耗費(fèi)十幾秒的時(shí)間；而用pull的方式，如果發(fā)現(xiàn)代碼有更新，只需要拉取更新的部分就可以了，不需要重新clone整個(gè)源代碼倉(cāng)庫(kù)，從而提高了代碼拉取的速度。 
• 本地（私有）倉(cāng)庫(kù)、mvn包本地緩存。我們搭建了很多本地（私有）倉(cāng)庫(kù)，包括Java、Python的倉(cāng)庫(kù)，不需要再去公網(wǎng)拉取依賴包，這樣不僅更安全，而且速度更快。 
• 預(yù)處理腳本。只在第一次構(gòu)建時(shí)觸發(fā)，之后便可以基于預(yù)處理腳本構(gòu)建的鏡像自動(dòng)構(gòu)建。 
• SSD加持。通過(guò)SSD硬件的加持，也提高了整個(gè)代碼構(gòu)建的速度。

3.6 實(shí)踐——什么樣的程序適合容器

• 無(wú)操作系統(tǒng)依賴。目前主流容器方案都是基于Linux內(nèi)核的cgroup和namespace相關(guān)技術(shù)實(shí)現(xiàn)的，這就意味著容器只能在Linux系統(tǒng)運(yùn)行，如果是Windows或者C#之類的程序是無(wú)法運(yùn)行到容器里面的。 
• 無(wú)固定IP依賴。這個(gè)其實(shí)不算硬性要求，雖然容器本身是可以實(shí)現(xiàn)固定IP地址的，但固定的IP地址會(huì)為Deployment的自動(dòng)伸縮以及集群遷移帶來(lái)很多麻煩。 
• 無(wú)本地?cái)?shù)據(jù)依賴。容器的重新發(fā)布是通過(guò)拉取新的鏡像啟動(dòng)新的容器進(jìn)程的方式，這就希望用戶不要將數(shù)據(jù)保存到容器的本地，而是應(yīng)該借助外部的中間件或者分布式存儲(chǔ)保存這些數(shù)據(jù)。

3.7 避坑指南

3.7.1 為啥我的服務(wù)沒(méi)有起來(lái)？

3.7.2 為啥服務(wù)啟動(dòng)/訪問(wèn)變慢？

3.7.3 為啥服務(wù)會(huì)異常重啟？

3.7.4 本地編譯可以，為啥服務(wù)器上代碼編譯失?。?/span>

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

3.7.6 為啥IP地址會(huì)變化？

3.7.7 為啥流量會(huì)打到異常容器？

• 第一種情況會(huì)導(dǎo)致訪問(wèn)報(bào)錯(cuò)，這種場(chǎng)景一般是通過(guò)配合健康檢查策略完成的，它會(huì)檢查容器服務(wù)到底起沒(méi)起來(lái)，如果檢查OK就會(huì)把新的流量打過(guò)來(lái)，這樣就解決了新容器啟動(dòng)流量的異常。 
• 第二種情況是和容器的優(yōu)雅關(guān)閉相結(jié)合的，容器如果沒(méi)有匹配優(yōu)雅關(guān)閉，會(huì)導(dǎo)致K8s先去關(guān)閉容器，此時(shí)容器還沒(méi)有從K8s的Service中摘除，所以還會(huì)有流量過(guò)去。解決這個(gè)問(wèn)題需要容器里面應(yīng)用能夠支持優(yōu)雅關(guān)閉，發(fā)送優(yōu)雅關(guān)閉時(shí)，容器開(kāi)始自己回收，在優(yōu)雅關(guān)閉時(shí)間后強(qiáng)制回收容器。

3.7.8 為啥沒(méi)法登錄容器？

3.7.9 Nginx后端應(yīng)該配置幾個(gè)？OOM？Cache？

3.8 faketime

4.1 對(duì)象存儲(chǔ)

4.2 站點(diǎn)監(jiān)控

4.3 大數(shù)據(jù)容器云

4.4 混合部署

4.5 未來(lái)規(guī)劃——DevOps平臺(tái)

【本文是51CTO專欄機(jī)構(gòu)宜信技術(shù)學(xué)院的原創(chuàng)文章，微信公眾號(hào)“宜信技術(shù)學(xué)院( id: CE_TECH)”】

戳這里，看該作者更多好文