小編今天帶大家了解基于kubernetes自研容器管理平臺(tái)的技術(shù)實(shí)踐是怎樣的，文中知識(shí)點(diǎn)介紹的非常詳細(xì)。覺(jué)得有幫助的朋友可以跟著小編一起瀏覽文章的內(nèi)容，希望能夠幫助更多想解決這個(gè)問(wèn)題的朋友找到問(wèn)題的答案，下面跟著小編一起深入學(xué)習(xí)“基于kubernetes自研容器管理平臺(tái)的技術(shù)實(shí)踐是怎樣的”的知識(shí)吧。
目前成都創(chuàng)新互聯(lián)公司已為成百上千家的企業(yè)提供了網(wǎng)站建設(shè)、域名、網(wǎng)頁(yè)空間、網(wǎng)站托管運(yùn)營(yíng)、企業(yè)網(wǎng)站設(shè)計(jì)、徐匯網(wǎng)站維護(hù)等服務(wù)，公司將堅(jiān)持客戶導(dǎo)向、應(yīng)用為本的策略，正道將秉承"和諧、參與、激情"的文化，與客戶和合作伙伴齊心協(xié)力一起成長(zhǎng)，共同發(fā)展。伴隨著微服務(wù)的架構(gòu)的普及，結(jié)合開源的Dubbo和Spring Cloud等微服務(wù)框架，宜信內(nèi)部很多業(yè)務(wù)線逐漸了從原來(lái)的單體架構(gòu)逐漸轉(zhuǎn)移到微服務(wù)架構(gòu)。應(yīng)用從有狀態(tài)到無(wú)狀態(tài)，具體來(lái)說(shuō)將業(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迅速流行起來(lái)，公司內(nèi)部開始嘗試將容器放到容器內(nèi)運(yùn)行，雖然通過(guò)容器解決了服務(wù)發(fā)布問(wèn)題，但很多容器的運(yùn)維仍然讓運(yùn)維捉襟見(jià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ò)通過(guò)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ù)都是通過(guò)Nginx反向代理對(duì)外提供服務(wù)，為了服務(wù)的隔離和負(fù)載均衡，總計(jì)十幾套的Nginx集群，這些nginx的版本、配置方式各有不同，導(dǎo)致單純靠人工去運(yùn)維的成本非常高而且容易出錯(cuò)，并且容器的IP地址不固定，無(wú)法直接配置到nginx后端。自研了一套nginx管理系統(tǒng)，主要是為了解決nginx的模板化配置，如下圖所示：
Nginx-mgr提供HTTP請(qǐng)求，負(fù)責(zé)接收nginx配置請(qǐng)求，并更新到etcd，每個(gè)nginx-agent通過(guò)watch Etcd批量刷新nginx的配置。在實(shí)際的生產(chǎn)環(huán)境里，部署的是阿里開源的Tengine而并非nginx，由于配置基本相同不做區(qū)分。每個(gè)服務(wù)都配置了健康檢查，這樣能夠保障在后端故障中自動(dòng)切換。如果有虛擬機(jī)場(chǎng)景需要手動(dòng)切換，下圖展示了手動(dòng)切換nginx的頁(yè)面：
由于很多業(yè)務(wù)都是虛擬機(jī)和容器混跑的情況下，如果后端是容器，我們通過(guò)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ī)房之間通過(guò)專線互連。那么多集群的管理將成為主要難點(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ǔ)也是通過(guò)專線互連。容器的鏡像倉(cāng)庫(kù)采用Harbor，多集群之間設(shè)置同步策略，并且在每個(gè)集群都設(shè)置各自的域名解析，分別解析到不同的鏡像倉(cāng)庫(kù)。
由于業(yè)務(wù)人員對(duì)容器技術(shù)還存在疑慮，所以大部分應(yīng)用都是虛擬機(jī)和容器的混合部署，容器通過(guò)域名訪問(wèn)虛擬機(jī)和虛擬機(jī)通過(guò)域名訪問(wèn)容器都是普遍存在的，為了統(tǒng)一管理域名，我們沒(méi)有采用kubernetes自帶的kube-dns（coreDns）而采用bind提供域名解析。通過(guò)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存在很多問(wèn)題，包括：路由條數(shù)過(guò)多，ARP表緩存失效等問(wèn)題。建議修改成網(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（永不過(guò)期）；Docker默認(rèn)是會(huì)masq所有離開主機(jī)的數(shù)據(jù)包，導(dǎo)致flannel中無(wú)法獲取源容器的IP地址，通過(guò)設(shè)置Ipmasq添加例外，排除目標(biāo)地址為flannel網(wǎng)段數(shù)據(jù)包；由于flannel使用vxlan的方式，開啟網(wǎng)卡的vxlan offloading對(duì)性能提升很高。Flannel本身沒(méi)有網(wǎng)絡(luò)隔離，為了實(shí)現(xiàn)kubernetes的network policy我們采用canal，它是calico實(shí)現(xiàn)kubernetes的網(wǎng)絡(luò)策略的插件。
為了支持Devops流程，在最初的版本我們嘗試使用Jenkins的方式執(zhí)行代碼編譯，但Jenkins對(duì)多租戶的支持比較差。在第二版通過(guò)kubernetes的Job機(jī)制，每個(gè)用戶的編譯都會(huì)啟動(dòng)一個(gè)編譯的Job，首先會(huì)下載用戶代碼，并根據(jù)編譯語(yǔ)言選擇對(duì)應(yīng)的編譯鏡像，編譯完成后生成執(zhí)行程序，如果jar或者war文件。通過(guò)Dockerfile打成Docker鏡像并推送到鏡像倉(cāng)庫(kù)，通過(guò)鏡像倉(cāng)庫(kù)的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)系，通過(guò)定義應(yīng)用的概念，不僅可以做到服務(wù)啟動(dòng)先后順序的控制，還可以統(tǒng)一規(guī)劃啟停一組服務(wù)。
容器的日志歸集使用公司自研的watchdog日志系統(tǒng)，每臺(tái)宿主機(jī)上通過(guò)DaemonSet方式部署日志采集Agent，Agent通過(guò)Docker API獲取需要采集的容器和日志路徑，采集日志并發(fā)送到日志中心，日志中心基于elasticsearch開發(fā)，提供多維度日志檢索和導(dǎo)出。
容器本身資源監(jiān)控的性能監(jiān)控通過(guò)Cadvisor + Prometheus的方式，容器內(nèi)業(yè)務(wù)的監(jiān)控集成開源的APM監(jiān)控系統(tǒng)uav（https://github.com/uavorg/uavstack），完成應(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的操作命令并記錄入庫(kù)；存儲(chǔ)管理主要是集成公司商業(yè)的NAS存儲(chǔ)，為容器直接提供數(shù)據(jù)共享和持久化；應(yīng)用商店主要是通過(guò)kubernetes的operator提供開發(fā)和測(cè)試使用的場(chǎng)景中間件服務(wù)。
在容器推廣的初期業(yè)務(wù)開發(fā)人員對(duì)容器還不是很熟悉，會(huì)下意識(shí)認(rèn)為容器就是虛擬機(jī)，其實(shí)他們不僅是使用方式的區(qū)別，更是實(shí)現(xiàn)方式和原理的差異，虛擬機(jī)是通過(guò)模擬硬件指令虛擬出操作系統(tǒng)的硬件環(huán)境，而容器是在共享內(nèi)核的前提下提供資源的隔離和限制。下圖展示了4.8內(nèi)核中l(wèi)inux支持的7種namespace。
換句話說(shuō)，其他的都沒(méi)有差異，譬如，時(shí)鐘，所有容器和操作系統(tǒng)都共享同一個(gè)時(shí)鐘，如果修改了操作系統(tǒng)的時(shí)間，所有容器都時(shí)間都會(huì)變化。除此之外，容器內(nèi)proc文件系統(tǒng)也是沒(méi)有隔離，看到的都是宿主的信息，這給很多應(yīng)用程序帶來(lái)困擾，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ì)通過(guò)調(diào)度的算法，這些算法都是需要過(guò)濾所有的節(jié)點(diǎn)并打分排序，大大增加了容器的部署時(shí)間，通過(guò)刪除一些無(wú)用的調(diào)度算法，從而提高部署的速度。容器采用反親和的策略，降低物理機(jī)故障對(duì)服務(wù)造成的影響。
雖然kubernetes開啟了RBAC，但kubernetes token還是不建議掛載到業(yè)務(wù)容器內(nèi)，通過(guò)關(guān)閉ServiceAccountToken提升系統(tǒng)的安全。
Docker鏡像存儲(chǔ)使用direct-lvm的方式，這樣性能更優(yōu)，在部署的時(shí)候劃分單獨(dú)的vg，避免因?yàn)镈ocker問(wèn)題影響操作系統(tǒng)。通過(guò)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集群超過(guò)一百個(gè)節(jié)點(diǎn)以后，查詢速度就會(huì)降低，通過(guò)SSD能夠有效提升速度。本系統(tǒng)在kubernetes之外通過(guò)數(shù)據(jù)庫(kù)保存服務(wù)和
關(guān)注證書的有效期，在部署kubernetes集群時(shí)候，很多都是自簽的證書，在不指定的情況下，openssl默認(rèn)一年的有效期，更新證書需要非常謹(jǐn)慎，因?yàn)檎麄€(gè)kubernetes的API都是基于證書構(gòu)建的，所有關(guān)聯(lián)的服務(wù)都需要修改。
感謝大家的閱讀，以上就是“基于kubernetes自研容器管理平臺(tái)的技術(shù)實(shí)踐是怎樣的”的全部?jī)?nèi)容了，學(xué)會(huì)的朋友趕緊操作起來(lái)吧。相信創(chuàng)新互聯(lián)小編一定會(huì)給大家?guī)?lái)更優(yōu)質(zhì)的文章。謝謝大家對(duì)創(chuàng)新互聯(lián)網(wǎng)站的支持！
另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)cdcxhl.cn，海內(nèi)外云服務(wù)器15元起步，三天無(wú)理由+7*72小時(shí)售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國(guó)服務(wù)器、虛擬主機(jī)、免備案服務(wù)器”等云主機(jī)租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡(jiǎn)單易用、服務(wù)可用性高、性價(jià)比高”等特點(diǎn)與優(yōu)勢(shì)，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場(chǎng)景需求。
重慶分公司
重慶分公司
