騰訊基于Kubernetes的企業(yè)級容器云架構(gòu)

技術(shù)創(chuàng)新，變革未來

騰訊基于kubernetes的企業(yè)級容器云架構(gòu)目錄架構(gòu)簡介企業(yè)級容器云解決方案Next企業(yè)級容器云架構(gòu)產(chǎn)品功能企業(yè)級容器云解決方案易用全組件自動(dòng)化部署、統(tǒng)一配置管理、多策略灰度升級提供可視化、自動(dòng)化的運(yùn)維能力，降低使用者的人力成本和學(xué)習(xí)成本可靠舉例：1.4升級1.9版本Pod

Hash發(fā)生變化Container名稱發(fā)生變化，點(diǎn)分隔改為了下劃線分隔容器標(biāo)簽發(fā)生變化pause容器的標(biāo)簽=POD改為io.kubernetes.docker.type=podsandboxio.kubernetes.container.restartCount改為annotation.io.kubernetes.container.restartCounCgroup目錄結(jié)構(gòu)發(fā)生變化，新增Pod層級平臺容災(zāi)所有組件無單點(diǎn)；平臺本身支持熱升級；組件自身HA機(jī)制，如docker；多地域多可用區(qū)的容災(zāi)設(shè)計(jì)管理機(jī)掛掉：對應(yīng)用無影響計(jì)算節(jié)點(diǎn)掛掉：跨機(jī)遷移應(yīng)用容災(zāi)健康探針①

存活探針②

就緒探針負(fù)載均衡重啟機(jī)制① 區(qū)分異常原因② 本地重啟/跨機(jī)重啟黑名單機(jī)制數(shù)據(jù)容災(zāi)集群核心數(shù)據(jù)的備份和恢復(fù)① Etcd② 核心數(shù)據(jù)庫云盤機(jī)制保護(hù)應(yīng)用數(shù)據(jù)企業(yè)內(nèi)部各個(gè)集群灰度運(yùn)營。可靠資源管理CPUMemoryDiskSpaceNetworkTXNetworkRXDiskIO(includebuffer

IO)GPU一次現(xiàn)網(wǎng)事故一個(gè)用戶需求背景：廣告業(yè)務(wù)，8個(gè)集群，4個(gè)在線集群，4個(gè)離線集群，分布在四個(gè)地區(qū)：北京、天津、成都、深圳。需求：減少機(jī)器，降低成本。手段：在線離線集群做合并。問題：容器只能管理CPU和內(nèi)存，不能對網(wǎng)絡(luò)和磁盤IO做管理，導(dǎo)致在線應(yīng)用受離線業(yè)務(wù)影響?？煽吭O(shè)計(jì)目標(biāo)?在某個(gè)cgroup網(wǎng)絡(luò)繁忙時(shí)，能保證其設(shè)定配額不會(huì)被其他cgroup擠占?在某個(gè)cgroup沒有用滿其配額時(shí)，其他cgroup可以自動(dòng)使用其空閑的部分帶寬?在多個(gè)cgroup分享其他cgroup的空閑帶寬時(shí)，優(yōu)先級高的優(yōu)先；

優(yōu)先級相同時(shí)，

配額大的占用多，配額小的占用少?盡量減少為了流控而主動(dòng)丟包下圖是兩個(gè)進(jìn)程都拼命爭搶網(wǎng)絡(luò)帶寬時(shí)的效果。兩個(gè)進(jìn)程的帶寬和時(shí)延都得不到任何程度的保證。?隊(duì)列：

不增加隊(duì)列，

對每個(gè)報(bào)文直接在正常代碼路徑上進(jìn)行決策?Cgroup區(qū)分(標(biāo)記)：

在正常處理流程中，報(bào)文查找到目標(biāo)socket結(jié)構(gòu)之后，根據(jù)socket的owner

process來確定cgroup?報(bào)文決策：

令牌桶

+

共享令牌池

+

顯式借令牌?限速方式：

ECN標(biāo)記

+

TCP滑窗

+

丟包可靠短信Email微信自定義渠道4種告警方式——可隨時(shí)修改158項(xiàng)告警87項(xiàng)指標(biāo)采集通用不同的應(yīng)用可以選擇不同的網(wǎng)絡(luò)模式同一主機(jī)的不同容器可以選擇不同的網(wǎng)絡(luò)模式自研容器網(wǎng)絡(luò)解決方案Galaxy（CNI網(wǎng)絡(luò)插件+調(diào)度器插件+控制器），面向所有場景：高性能互聯(lián)網(wǎng)業(yè)務(wù)、離線業(yè)務(wù)、在線離線混合場景、傳統(tǒng)有狀態(tài)服務(wù)、公有云…2219072611646248611744255482146168280500010000150002000025000性能Overlay方案性能TCP_RR(r/s)hostvxlanipipTCP_CRR(r/s)gateway2354083682212776752100772310500010000150002000025000TCP_RR(64)TCP_CRR(64)Underlay方案性能HostBridge NATIPIP+Gateway混合Overlay方案短鏈接IPIP包量比Vxlan多14.1%Gateway比Vxlan多40.5%方案被Flannel社區(qū)合并Underlay方案Bridge方式僅比Host差6%，一般overlay比Host差20~40%SRIOV方式比Bridge

CPU下降38.3%，包量+6%性能Docker、Docket、GaiastackP2P

Agent下載鏡像對比Registry與P2P

Agent流量占比對比鏡像下載引入BT協(xié)議對Docker

Daemon零入侵每層分別做種優(yōu)化blob下載策略發(fā)表論文：《FID:

A

Faster

Image

DistributionSystemfor

Docker

Platform》2017IEEE2ndInternationalWorkshopsonFASW安全能力擴(kuò)展：彈性伸縮PodPodPod微服務(wù)/通用服務(wù)AutoscalercontrollerprometheusMetrics-serverAPP彈性伸縮：主動(dòng)擴(kuò)縮容擴(kuò)容可以指定新版本縮容可以定點(diǎn)裁撤自動(dòng)擴(kuò)縮容資源閾值自定義指標(biāo)閾值實(shí)例個(gè)數(shù)范圍周期性自動(dòng)伸縮AutoscalercontrollerApiservercluster-agentCloud

API集群彈性伸縮：監(jiān)控節(jié)點(diǎn)資源使用率自動(dòng)遷移低負(fù)載Node上的Pod，完成縮容一定數(shù)量Pod因資源不足pending時(shí)，自動(dòng)擴(kuò)容能力擴(kuò)展：灰度升級在GPU集群中有一個(gè)長時(shí)間服務(wù)應(yīng)用prd-cloud-str-003-p40-cluster1。該應(yīng)用有25個(gè)實(shí)例，每個(gè)實(shí)例需要2個(gè)GPU卡。用來提供圖片識別的OCR服務(wù)。當(dāng)該服務(wù)要升級新的版本時(shí)，如果對所有實(shí)例停止，則會(huì)造成服務(wù)中斷；如果采用滾動(dòng)升級，無法保證升級過程是否有異常，以及無法充分驗(yàn)證新版本的可用性（即使經(jīng)過了測試階段的測試）。通常采用灰度升級的方式：即選擇某一個(gè)或N個(gè)實(shí)例先升級到新版本，在充分穩(wěn)定驗(yàn)證后，再考慮升級其他實(shí)例，而該灰度的過程可以分為任意批次。有時(shí)為了驗(yàn)證多個(gè)版本，一個(gè)應(yīng)用內(nèi)也可以同時(shí)又多個(gè)版本并行存在。充分保證現(xiàn)網(wǎng)的服務(wù)質(zhì)量以及版本的可控性。能力升級：灰度升級如左圖所示，對某一個(gè)實(shí)例從v7升級到v8版本。2018-02-06

11:46:38

V7版本開時(shí)候運(yùn)行2018-02-09

09:33:02

對該實(shí)例做灰度升級，從V7版本升級到V8版本2018-02-09

09:33:02

開始pull

V8版本的imagePS：灰度升級屬于原地升級，因此不需要重新過調(diào)度，升級的效率也會(huì)提升。每次升級可以選擇要升級的實(shí)例個(gè)數(shù)以及具體哪些(個(gè))實(shí)例。能力擴(kuò)展：存儲(chǔ)場景物理硬ephc盤 cephFScephRBDRBD容containercontainercontainer本地磁盤container間上報(bào) 在線擴(kuò)quota權(quán)限管理空自動(dòng)調(diào)度共享云盤container內(nèi)置云盤container本地磁盤基于本機(jī)磁盤上報(bào)至調(diào)度器作為資源進(jìn)行調(diào)度2類存儲(chǔ)，3種場景本地磁盤：延時(shí)低，不可遷移共享云盤：云存儲(chǔ)，多容器共享，同時(shí)讀寫內(nèi)置云盤：云存儲(chǔ)，每容器獨(dú)享，用戶無感知云存儲(chǔ)支持在線擴(kuò)容、quota管理、權(quán)限管理共享云盤基于cephFS內(nèi)置云盤基于cephRBD騰訊內(nèi)部ceph版本，微信同款能力擴(kuò)展：GPU支持分布式存儲(chǔ)Ceph海量小數(shù)據(jù)讀寫優(yōu)化不同用戶配額管理任務(wù)帶盤遷移智能拓?fù)涓兄狦PU卡拓?fù)涓兄Y源訪問代價(jià)樹決策資源調(diào)度算法解決碎片化異構(gòu)GPU統(tǒng)一管理多種調(diào)度策略，多租戶管理GPU卡與CPU核自動(dòng)綁定支持單機(jī)多卡和多機(jī)多卡發(fā)表論文：《GaiaScheduler:

AKubernetes-based

Scheduler

Framework》TheIEEEISPA2018(16thIEEEInternationalSymposiumonParallelandDistributedProcessingwith

Applications)能力擴(kuò)展：GPU支持資源-訪問代價(jià)樹拓?fù)涔?jié)點(diǎn)中存儲(chǔ)3個(gè)信息：子節(jié)點(diǎn)的GPU通信方式(SOC、PXB、PHB或PIX)可用的GPU資源數(shù)(如果下屬n張GPU卡則為n)節(jié)點(diǎn)通信開銷(非GPU節(jié)點(diǎn)為0)GPU節(jié)點(diǎn)存儲(chǔ)3個(gè)信息：GPU

id可用的GPU資源數(shù)(GPU節(jié)點(diǎn)為1)節(jié)點(diǎn)通信開銷(數(shù)字越小，訪問代價(jià)越低)四類通信方式分類中，通信開銷最大的是SOC，其次是PXB，再次是PHB，PIX通信方式的GPU之間的通信開銷最小。Singularand

linkFragment成本GPU使用方式實(shí)現(xiàn)VCUDA在vm中構(gòu)建wrapper

library以攔截GPU調(diào)用并將這些調(diào)用重定向到宿主機(jī)執(zhí)行Amazon將設(shè)備直接掛在到vm中GPUvm在Zen的hypervisor層實(shí)現(xiàn)了全虛擬化。為了隔離運(yùn)行在物理GPU上的多個(gè)VM，GPUvm將物理GPU分成幾個(gè)部分，并將每個(gè)部分分配給單個(gè)VM。NVIDIA

GRID在硬件層面實(shí)現(xiàn)GPU虛擬化，每個(gè)容器可以綁定一個(gè)虛擬GPUNVIDIA

Docker通過將GPU設(shè)備及運(yùn)行時(shí)的庫轉(zhuǎn)為volume掛載到容器中實(shí)現(xiàn)了容器與驅(qū)動(dòng)的解耦。但是一個(gè)GPU設(shè)備僅能掛載到一個(gè)容器中，不支持容器間共享GPU設(shè)備ConvGPU僅支持內(nèi)存資源的共享且僅處理單個(gè)GPU容器使用GPU的問題：需要特定的硬件設(shè)備不支持容器共享僅支持內(nèi)存資源虛擬化僅支持單個(gè)GPU卡采用DevicePlugin：GPU資源的發(fā)現(xiàn)為任務(wù)分配相應(yīng)的硬件資源及配置容器運(yùn)行時(shí)環(huán)境在物理GPU上執(zhí)行一樣。Performance.

GaiaGPU應(yīng)當(dāng)保證vGPU的性能與原生GPU性能相近。Isolation.

GaiaGPU可以有效的分配和回收每個(gè)容器使用的GPU資源并實(shí)現(xiàn)不同容器間的資源隔離。Native_time(seconds)GaiaGPU_time(seconds)Difference(%)Tensorflow47.8247.880.13Caffe22.4722.500.15PyTorch69.3369.640.44CNTK7.397.410.27Numberof

vGPUs12345resourceper

vGPU50.2發(fā)表論文：《GaiaGPU: