摘要：容器云的背景伴隨著微服務(wù)的架構(gòu)的普及，結(jié)合開源的和等微服務(wù)框架，宜信內(nèi)部很多業(yè)務(wù)線逐漸了從原來的單體架構(gòu)逐漸轉(zhuǎn)移到微服務(wù)架構(gòu)。

伴隨著微服務(wù)的架構(gòu)的普及，結(jié)合開源的Dubbo和Spring Cloud等微服務(wù)框架，宜信內(nèi)部很多業(yè)務(wù)線逐漸了從原來的單體架構(gòu)逐漸轉(zhuǎn)移到微服務(wù)架構(gòu)。應(yīng)用從有狀態(tài)到無狀態(tài)，具體來說將業(yè)務(wù)狀態(tài)數(shù)據(jù)如：會(huì)話、用戶數(shù)據(jù)等存儲(chǔ)到中間件中服務(wù)中。

微服務(wù)的拆分雖然將每個(gè)服務(wù)的復(fù)雜度降低，但服務(wù)實(shí)例的數(shù)目卻呈現(xiàn)出爆炸式增長(zhǎng)，這給運(yùn)維增加難度，一方面是服務(wù)部署、升級(jí)，另一方面是服務(wù)的監(jiān)控故障恢復(fù)等。

在2016年，容器技術(shù)尤其是Docker迅速流行起來，公司內(nèi)部開始嘗試將容器放到容器內(nèi)運(yùn)行，雖然通過容器解決了服務(wù)發(fā)布問題，但很多容器的運(yùn)維仍然讓運(yùn)維捉襟見肘。宜信是一家金融科技公司，在引入開源組件的時(shí)候，穩(wěn)定可靠是作為考量的最重要標(biāo)準(zhǔn)，在2017年初kubernetes慢慢成熟，成為容器的管理標(biāo)準(zhǔn)，并且被國(guó)內(nèi)外很多公司采用，在這種背景下，宜信借鑒開源社區(qū)和商業(yè)PAAS平臺(tái)產(chǎn)品，基于kubernetes自研一套容器管理平臺(tái)。

整個(gè)架構(gòu)圍繞kubernetes構(gòu)建，分為四個(gè)層級(jí)，最底層主要是基礎(chǔ)資源，包括網(wǎng)絡(luò)、計(jì)算、存儲(chǔ)，所有的容器都是部署在物理服務(wù)器上，容器掛載商業(yè)NAS存儲(chǔ)，網(wǎng)絡(luò)通過vxlan互連；中間層核心的是資源調(diào)度層，主要完成多集群的管理、發(fā)布部署、智能調(diào)度、自動(dòng)伸縮等，這層主要是資源管理和服務(wù)編排；左側(cè)面是提供系統(tǒng)安全，主要是為了系統(tǒng)安全和容器鏡像安全，右側(cè)面是一套代碼自動(dòng)編譯、自動(dòng)構(gòu)建、自動(dòng)部署系統(tǒng)；中間件層主要提供常用的中間件服務(wù)，Nginx配置和監(jiān)控告警等；最上層的是用戶接入層，主要提供用戶的操作入口。整體架構(gòu)如下圖所示：

公司大部分的服務(wù)都是通過Nginx反向代理對(duì)外提供服務(wù)，為了服務(wù)的隔離和負(fù)載均衡，總計(jì)十幾套的Nginx集群，這些nginx的版本、配置方式各有不同，導(dǎo)致單純靠人工去運(yùn)維的成本非常高而且容易出錯(cuò)，并且容器的IP地址不固定，無法直接配置到nginx后端。自研了一套nginx管理系統(tǒng)，主要是為了解決nginx的模板化配置，如下圖所示：

Nginx-mgr提供HTTP請(qǐng)求，負(fù)責(zé)接收nginx配置請(qǐng)求，并更新到etcd，每個(gè)nginx-agent通過watch Etcd批量刷新nginx的配置。在實(shí)際的生產(chǎn)環(huán)境里，部署的是阿里開源的Tengine而并非nginx，由于配置基本相同不做區(qū)分。每個(gè)服務(wù)都配置了健康檢查，這樣能夠保障在后端故障中自動(dòng)切換。如果有虛擬機(jī)場(chǎng)景需要手動(dòng)切換，下圖展示了手動(dòng)切換nginx的頁面：

由于很多業(yè)務(wù)都是虛擬機(jī)和容器混跑的情況下，如果后端是容器，我們通過kubernetes的API獲取容器的IP地址動(dòng)態(tài)刷新。

雖然kubernetes本身存在采用高可用的部署架構(gòu)，避免單點(diǎn)故障，但這遠(yuǎn)遠(yuǎn)還不夠，一方面是因?yàn)閱蝹€(gè)kubernetes集群部署在一個(gè)機(jī)房，如果發(fā)生機(jī)房級(jí)別的故障，將會(huì)導(dǎo)致服務(wù)中斷，另一方面由于單個(gè)kubernetes集群本身故障，如集群的網(wǎng)絡(luò)配置錯(cuò)誤導(dǎo)致整個(gè)網(wǎng)絡(luò)故障等，都將會(huì)影響業(yè)務(wù)的正常使用，在宜信將kubernetes部署在多個(gè)機(jī)房?jī)?nèi)，機(jī)房之間通過專線互連。那么多集群的管理將成為主要難點(diǎn)：第一是如何分配資源，當(dāng)用戶選擇多集群部署后，系統(tǒng)根據(jù)每個(gè)集群的資源用量，決定每個(gè)集群分配的容器數(shù)量，并且保證每個(gè)集群至少有一個(gè)容器。集群自動(dòng)伸縮時(shí)，也會(huì)按照此比例創(chuàng)建和回收容器。第二是故障遷移，如圖中的集群控制器主要為了解決多集群的自動(dòng)伸縮和集群故障時(shí)的容器遷移，控制器定時(shí)檢測(cè)集群的多個(gè)節(jié)點(diǎn)，如果多次失敗后將觸發(fā)集群容器遷移的操作，保障服務(wù)可靠運(yùn)行。

第三是網(wǎng)絡(luò)和存儲(chǔ)的互連，由于跨機(jī)房的網(wǎng)絡(luò)需要互連，我們采用vxlan的網(wǎng)絡(luò)方案實(shí)現(xiàn)，存儲(chǔ)也是通過專線互連。容器的鏡像倉庫采用Harbor，多集群之間設(shè)置同步策略，并且在每個(gè)集群都設(shè)置各自的域名解析，分別解析到不同的鏡像倉庫。

由于業(yè)務(wù)人員對(duì)容器技術(shù)還存在疑慮，所以大部分應(yīng)用都是虛擬機(jī)和容器的混合部署，容器通過域名訪問虛擬機(jī)和虛擬機(jī)通過域名訪問容器都是普遍存在的，為了統(tǒng)一管理域名，我們沒有采用kubernetes自帶的kube-dns（coreDns）而采用bind提供域名解析。通過kubernetes支持的Default DNS策略將容器的域名指向公司的DNS服務(wù)器，并配置域名管理的API動(dòng)態(tài)添加。

kubernetes的CNI的網(wǎng)絡(luò)方案有很多種，主要分為二層、三層和overlay方案。一方面機(jī)房并不允許跑BGP協(xié)議，并且需要跨機(jī)房的主機(jī)互連，所以我們采用了flannel的vxlan方案，為了實(shí)現(xiàn)跨機(jī)房的互通，兩個(gè)集群的flannel連接到同一個(gè)etcd集群，這樣保障網(wǎng)絡(luò)配置的一致性。老版本的Flannel存在很多問題，包括：路由條數(shù)過多，ARP表緩存失效等問題。建議修改成網(wǎng)段路由的形式，并且設(shè)置ARP規(guī)則永久有效，避免因?yàn)閑tcd等故障導(dǎo)致集群網(wǎng)絡(luò)癱瘓。

Flannel的使用還需要注意一些配置優(yōu)化，默認(rèn)情況下每天都會(huì)申請(qǐng)Etcd的租約，如果申請(qǐng)失敗會(huì)刪除etcd網(wǎng)段信息。為了避免網(wǎng)段變化，可以將etcd數(shù)據(jù)節(jié)點(diǎn)的ttl置為0（永不過期）；Docker默認(rèn)是會(huì)masq所有離開主機(jī)的數(shù)據(jù)包，導(dǎo)致flannel中無法獲取源容器的IP地址，通過設(shè)置Ipmasq添加例外，排除目標(biāo)地址為flannel網(wǎng)段數(shù)據(jù)包；由于flannel使用vxlan的方式，開啟網(wǎng)卡的vxlan offloading對(duì)性能提升很高。Flannel本身沒有網(wǎng)絡(luò)隔離，為了實(shí)現(xiàn)kubernetes的network policy我們采用canal，它是calico實(shí)現(xiàn)kubernetes的網(wǎng)絡(luò)策略的插件。

為了支持Devops流程，在最初的版本我們嘗試使用Jenkins的方式執(zhí)行代碼編譯，但Jenkins對(duì)多租戶的支持比較差。在第二版通過kubernetes的Job機(jī)制，每個(gè)用戶的編譯都會(huì)啟動(dòng)一個(gè)編譯的Job，首先會(huì)下載用戶代碼，并根據(jù)編譯語言選擇對(duì)應(yīng)的編譯鏡像，編譯完成后生成執(zhí)行程序，如果jar或者war文件。通過Dockerfile打成Docker鏡像并推送到鏡像倉庫，通過鏡像倉庫的webhook觸發(fā)滾動(dòng)升級(jí)流程。

系統(tǒng)設(shè)計(jì)了應(yīng)用的邏輯概念，kubernetes雖然有服務(wù)的概念，但缺少服務(wù)的關(guān)聯(lián)關(guān)系，一個(gè)完整的應(yīng)用通常包括前端、后端API、中間件等多個(gè)服務(wù)，這些服務(wù)存在相互調(diào)用和制約的關(guān)系，通過定義應(yīng)用的概念，不僅可以做到服務(wù)啟動(dòng)先后順序的控制，還可以統(tǒng)一規(guī)劃啟停一組服務(wù)。

容器的日志歸集使用公司自研的watchdog日志系統(tǒng)，每臺(tái)宿主機(jī)上通過DaemonSet方式部署日志采集Agent，Agent通過Docker API獲取需要采集的容器和日志路徑，采集日志并發(fā)送到日志中心，日志中心基于elasticsearch開發(fā)，提供多維度日志檢索和導(dǎo)出。

容器本身資源監(jiān)控的性能監(jiān)控通過Cadvisor + Prometheus的方式，容器內(nèi)業(yè)務(wù)的監(jiān)控集成開源的APM監(jiān)控系統(tǒng)uav（https://github.com/uavorg/uav...），完成應(yīng)用的性能監(jiān)控。uav的鏈路跟蹤基于JavaAgent技術(shù)，如果用戶部署應(yīng)用勾選了使用uav監(jiān)控，系統(tǒng)在構(gòu)建鏡像時(shí)將uav的agent植入到鏡像內(nèi)，并修改啟動(dòng)參數(shù)。

除了上述幾個(gè)模塊外，系統(tǒng)還集Harbor完成容器鏡像的多租戶管理和鏡像掃描功能；日志審計(jì)是記錄用戶在管理界面的操作，webshell提供用戶的web控制臺(tái)接入，為了支持安全審計(jì)，后臺(tái)會(huì)截獲用戶所有在webshell的操作命令并記錄入庫；存儲(chǔ)管理主要是集成公司商業(yè)的NAS存儲(chǔ)，為容器直接提供數(shù)據(jù)共享和持久化；應(yīng)用商店主要是通過kubernetes的operator提供開發(fā)和測(cè)試使用的場(chǎng)景中間件服務(wù)。

在容器推廣的初期業(yè)務(wù)開發(fā)人員對(duì)容器還不是很熟悉，會(huì)下意識(shí)認(rèn)為容器就是虛擬機(jī)，其實(shí)他們不僅是使用方式的區(qū)別，更是實(shí)現(xiàn)方式和原理的差異，虛擬機(jī)是通過模擬硬件指令虛擬出操作系統(tǒng)的硬件環(huán)境，而容器是在共享內(nèi)核的前提下提供資源的隔離和限制。下圖展示了4.8內(nèi)核中l(wèi)inux支持的7種namespace。

換句話說，其他的都沒有差異，譬如，時(shí)鐘，所有容器和操作系統(tǒng)都共享同一個(gè)時(shí)鐘，如果修改了操作系統(tǒng)的時(shí)間，所有容器都時(shí)間都會(huì)變化。除此之外，容器內(nèi)proc文件系統(tǒng)也是沒有隔離，看到的都是宿主的信息，這給很多應(yīng)用程序帶來困擾，JVM初始的堆大小為內(nèi)存總量的1/4，如果容器被限制在2G的內(nèi)存上限，而宿主機(jī)通常都是200+G內(nèi)存，JVM很容易觸發(fā)OOM, 解決方案通常是啟動(dòng)時(shí)根據(jù)內(nèi)存和CPU的限制設(shè)置JVM，或者借助lxcfs等。

Cgroup的資源限制目前對(duì)網(wǎng)絡(luò)和磁盤IO的限制比較弱，v1的cgroup只支持direct IO的限制，但實(shí)際的生產(chǎn)環(huán)境都是些緩存的。目前我們也在測(cè)試cgroup v2關(guān)于IO的限制。當(dāng)最新的CNI已經(jīng)支持網(wǎng)絡(luò)限速，結(jié)合tc可以很好的達(dá)到這個(gè)效果。

Kubernetes自帶了很多調(diào)度算法，在啟動(dòng)容器之前會(huì)通過調(diào)度的算法，這些算法都是需要過濾所有的節(jié)點(diǎn)并打分排序，大大增加了容器的部署時(shí)間，通過刪除一些無用的調(diào)度算法，從而提高部署的速度。容器采用反親和的策略，降低物理機(jī)故障對(duì)服務(wù)造成的影響。

雖然kubernetes開啟了RBAC，但kubernetes token還是不建議掛載到業(yè)務(wù)容器內(nèi)，通過關(guān)閉ServiceAccountToken提升系統(tǒng)的安全。

Docker鏡像存儲(chǔ)使用direct-lvm的方式，這樣性能更優(yōu)，在部署的時(shí)候劃分多帶帶的vg，避免因?yàn)镈ocker問題影響操作系統(tǒng)。通過devicemapper存儲(chǔ)限制每個(gè)容器系統(tǒng)盤為10G，避免業(yè)務(wù)容器耗盡宿主機(jī)磁盤空間，容器運(yùn)行時(shí)需要限制每個(gè)容器的最大進(jìn)程數(shù)量，避免fork炸彈。

Etcd里面記錄了kubernetes核心數(shù)據(jù)，所以etcd個(gè)高可用和定時(shí)備份是必須的，在kubernetes集群超過一百個(gè)節(jié)點(diǎn)以后，查詢速度就會(huì)降低，通過SSD能夠有效提升速度。本系統(tǒng)在kubernetes之外通過數(shù)據(jù)庫保存服務(wù)和

關(guān)注證書的有效期，在部署kubernetes集群時(shí)候，很多都是自簽的證書，在不指定的情況下，openssl默認(rèn)一年的有效期，更新證書需要非常謹(jǐn)慎，因?yàn)檎麄€(gè)kubernetes的API都是基于證書構(gòu)建的，所有關(guān)聯(lián)的服務(wù)都需要修改。

Docker容器加K8S編排是當(dāng)前容器云的主流實(shí)踐之一，宜信容器集群管理平臺(tái)也采用這種方案。本文主要分享了宜信在容器云平臺(tái)技術(shù)上的一些探索和實(shí)踐。本文主要包含了Nginx自助管理、 多集群管理、DNS解析、網(wǎng)絡(luò)方案、CICD服務(wù)編排、 日志監(jiān)控、kubernetes 優(yōu)化一些技術(shù)工作，以及宜信內(nèi)部容器云平臺(tái)化的一些思考，當(dāng)然我們還有很多不足，歡迎各路英雄來宜信進(jìn)行深入溝通和交流！

宜信技術(shù)學(xué)院