轉(zhuǎn)載：Kubernetes實戰(zhàn)——談?wù)勎⒉?yīng)對春晚等突發(fā)峰值流量的經(jīng)驗
導(dǎo)讀：本文由Kubernetes在微博落地的具體工作整理而成义黎。通過圍繞業(yè)務(wù)需求和大家分享下企業(yè)內(nèi)部如何使用Kubernetes來解決具體的業(yè)務(wù)問題和相應(yīng)的方案廉涕。文中分享了基于Kubernetes的PaaS層彈性混合部署方案狐蜕，其中有Kubernetes的優(yōu)點层释，也有部分Kubernetes在企業(yè)落地的缺陷贡羔，歡迎大家一起討論和建設(shè)Kubernetes乖寒。希望本文對大家有一定的借鑒意義楣嘁。
彭濤珍逸，主要負責(zé)微博容器平臺的開發(fā)工作谆膳。Kubernetes代碼貢獻者摹量。曾就職于百度基礎(chǔ)架構(gòu)部缨称，百度公有云事業(yè)部睦尽。長期從事云計算行業(yè)当凡。熟悉網(wǎng)絡(luò)虛擬化沿量，SDN朴则，OpenStack乌妒，Kubernetes撤蚊。致力于推動Kubernetes在微博的應(yīng)用落地侦啸，構(gòu)建高效的PaaS平臺
王琨光涂，微博平臺高級產(chǎn)品運維工程師顶捷，主要負責(zé)微博feed服赎、用戶關(guān)系、架構(gòu)業(yè)務(wù)的運維支撐及改造工作践付。擅長大規(guī)模分布式系統(tǒng)集群的管理與運維永高，疑難問題分析命爬，故障定位與處理饲宛。致力于推進運維自動化艇抠，構(gòu)建微博平臺高效的運維平臺家淤。
一絮重、微博容器平臺
2016年微博平臺實現(xiàn)基于混合云的彈性平臺DCP绿鸣，提升了Feed、手機微博痴施、廣告辣吃、搜索神得、話題哩簿、視頻节榜、直播等多個核心業(yè)務(wù)熱點應(yīng)對能力宗苍。2017年微博平臺率先探索基于Kubernetes的PAAS層彈性混合部署解決方案讳窟，并且積極的和社區(qū)保持同步丽啡。2018年實現(xiàn)CI/CD與生產(chǎn)環(huán)境混合部署碌上，2019年春晚實現(xiàn)部分核心業(yè)務(wù)混合部署與彈性伸縮馏予。
本文主要介紹微博平臺落地Kubernetes過程中的一些經(jīng)驗教訓(xùn)霞丧。
二后豫、為什么選擇Kubernetes
因為歷史原因挫酿，微博docker容器治理是采用獨占物理機（虛擬機）模式早龟，直接使用物理機的網(wǎng)絡(luò)協(xié)議棧葱弟，服務(wù)治理采用服務(wù)池方式芝加。隨著設(shè)備計算能力的提升藏杖，這種治理方式有幾個問題急需解決：
1.?利用率問題：一個服務(wù)池內(nèi)新制市、老設(shè)備共存祥楣，因為業(yè)務(wù)容器需要兼容老設(shè)備規(guī)格误褪，導(dǎo)致服務(wù)無法充分發(fā)揮出新設(shè)備應(yīng)有的計算能力兽间。
2.?容器網(wǎng)絡(luò)問題：因為直接采用物理機網(wǎng)絡(luò)棧嘀略，導(dǎo)致業(yè)務(wù)混合部署只能采用調(diào)整業(yè)務(wù)監(jiān)聽端口的方式咒程，造成接入成本帐姻、管理成本高饥瓷。
3.?調(diào)度治理問題：因為默認采用獨占策略呢铆，服務(wù)池之間資源相互隔離刺洒，不同類型的業(yè)務(wù)類型無法共享資源，導(dǎo)致資源總是相對緊缺渔肩。
Kubernetes提供標(biāo)準(zhǔn)化的容器管理抹剩，CNI網(wǎng)絡(luò)虛擬化澳眷，自定義彈性調(diào)度策略钳踊，能夠很好的解決上述問題拓瞪。但是Kubernetes面向公有PAAS的實現(xiàn)方案在內(nèi)網(wǎng)環(huán)境下有些方面不適用祭埂，主要有如下幾個方面：
1.?網(wǎng)絡(luò)虛擬化：在BGP的虛擬網(wǎng)絡(luò)方案和隧道的虛擬網(wǎng)絡(luò)方案中都會引入iptables來完成流量牽引，和防火墻的相關(guān)功能喉誊，在企業(yè)內(nèi)網(wǎng)使用的過程中并沒有很強烈的防火墻需求，引入iptables往往會造成性能下降（nf_conntrack表被打滿，NAT性能太低）垃你。所以微博平臺現(xiàn)階段沒有使用BGP虛擬化網(wǎng)絡(luò)方案和隧道虛擬化網(wǎng)絡(luò)方案
2.?滾動發(fā)布：目前的Kubernetes的滾動發(fā)布（Deployment）不支持In-place rolling updates 缔御，每次一個Pod都有可能被分配不同的IP地址耕突，在企業(yè)內(nèi)部使用容器的時候，固定IP的需求往往很強烈上祈，所以我們拋棄了Kubernetes而選擇了整合了公司內(nèi)部的滾動發(fā)布系統(tǒng)
3.?資源隔離：原生的內(nèi)存隔離策略中不支持swap的限制登刺，容器會占用物理機的swap纸俭，我們修改了內(nèi)存隔離限制揍很。
4.?負載均衡：原生的Service模式會引入iptables來做NAT女轿，同時Service的負載是硬負載沒法調(diào)整流量權(quán)重傅寡。
我們基于Kubernetes搭建了一套PaaS平臺荐操，對Kubernetes進行了改進托启，提供了以下功能：
1.?網(wǎng)絡(luò)虛擬化：基于CNI攘宙，提供了隔離內(nèi)網(wǎng)和公有云網(wǎng)絡(luò)差異的虛擬化網(wǎng)絡(luò)方案
2.?調(diào)度管理：基于kube-scheduler屯耸，提供了鎖定IP的調(diào)度系統(tǒng)，該系統(tǒng)支持帶寬初篩蹭劈，硬盤初篩疗绣，機房就近調(diào)度，返回庫存狀態(tài)铺韧，提前鎖定IP功能等功能
3.?CI/CD：一鍵發(fā)布代碼，替代Kubernetes的Deployment進行滾動發(fā)布
4.?資源隔離：在原有的隔離策略上哈打，擴展出計算資源隔離塔逃，網(wǎng)絡(luò)資源隔離，存儲資源隔離
5.?負載均衡：整合已有的調(diào)度系統(tǒng)料仗，利用微服務(wù)快速部署+彈性調(diào)度提前鎖定IP湾盗，減少服務(wù)抖動耗時。
6.?模塊化運維：把已有的物理機運維工具整合到容器中立轧，在Pod里面共享存儲淹仑，共享網(wǎng)絡(luò)
7.?彈性擴縮容：通過對DCP的整合丙挽，使其具有了容器彈性擴縮容的功能肺孵。
8.?監(jiān)控：通過模塊化的運維體系匀借，整合了監(jiān)控所需日志，無縫連接已有功能
三平窘、整體方案
圖一
整體方案如圖一吓肋，微博容器平臺劃分出如下幾層：
1.?服務(wù)層：平臺的主要入口提供容器擴縮容、上下線瑰艘、維護服務(wù)池是鬼、負載均衡，監(jiān)控管理等功能
2.?PaaS層：提供容器管理和調(diào)度管理等相關(guān)功能紫新，負責(zé)將服務(wù)層的請求轉(zhuǎn)化成對應(yīng)容器的操作
3.?IaaS層：提高機器資源均蜜、網(wǎng)絡(luò)資源、存儲資源供PaaS生成的容器使用芒率，負責(zé)對容器使用資源進行管理
三囤耳、容器彈性化擴縮容平臺建設(shè)
微博容器彈性擴縮容平臺，是在Kubernetes基礎(chǔ)上進行了改進偶芍，充分利用了微博平臺已有的資源充择。避免重復(fù)造輪子。具體的工作如下：
3.1 基礎(chǔ)建設(shè)之網(wǎng)絡(luò)虛擬化
之前已經(jīng)說過了匪蟀，微博的容器會獨占物理機的網(wǎng)絡(luò)協(xié)議棧椎麦，雖然能夠做到網(wǎng)絡(luò)效率的最大化，但是會導(dǎo)致多容器部署時出現(xiàn)端口沖突材彪。為了解決端口沖突需要使用虛擬化網(wǎng)絡(luò)技術(shù)提供容器獨立的IP地址观挎。多個容器獨立IP需要解決以下的三個問題：
1.?容器的IP地址分配問題；
2.?容器的IP路由問題段化；
3.?虛擬化網(wǎng)絡(luò)對網(wǎng)絡(luò)的性能損失要最小化嘁捷；
第一個問題因為采用Kubernetes IP分配都是通過記錄在etcd中，所以不會出現(xiàn)分配重復(fù)或者分配錯誤的問題穗泵，而第二個問題社區(qū)里面通常會采用隧道類型方案和BGP方案普气。以下是隧道模式和BGP模式的優(yōu)缺點對比如表一, 性能測試如表二（BGP主要工作是路由交換，轉(zhuǎn)發(fā)等不受影響佃延，等同于物理機性能现诀。）
表一
表二
在測試結(jié)果中顯示vxlan因為需要封裝和解封隧道導(dǎo)致帶寬損耗過5%，所以隧道方案不適用于內(nèi)網(wǎng)的網(wǎng)絡(luò)環(huán)境履肃。而BGP的方案Calico會引入iptables去做ACL仔沿，不僅在業(yè)務(wù)峰值流量的情況下會觸發(fā)nf_conntrack表被打滿丟包的風(fēng)險。而且BGP方案在公有云和內(nèi)網(wǎng)落地的時候也存在問題：
公有云方面：
1.?從公有云虛擬機發(fā)出的報文必須是Mac地址和IP地址匹配的尺棋，所以導(dǎo)致在公有云機器上BGP虛擬網(wǎng)絡(luò)的容器根本無法通信封锉。
內(nèi)網(wǎng)方面：
1.?內(nèi)網(wǎng)機器的上聯(lián)交換機上做了Vlan和IP的綁定，如果在內(nèi)網(wǎng)機器上起了一個其他網(wǎng)段的IP地址，報文發(fā)送不出本機成福。
接下來先來看看在網(wǎng)絡(luò)方案上我們做的一些工作（見圖二）碾局。
圖二
微博虛擬網(wǎng)絡(luò)主要是四方面內(nèi)容：
1.?對機房網(wǎng)絡(luò)進行改造，修改機器的上聯(lián)交換機為trunk模式奴艾，支持多Vlantag的網(wǎng)絡(luò)通信
2.?在物理機層面通過創(chuàng)建網(wǎng)卡子接口（如圖一左側(cè)）净当，通過對網(wǎng)卡子接口做MacVlan虛擬網(wǎng)卡插入Kubernetes的Pause容器中，把容器網(wǎng)絡(luò)與物理網(wǎng)絡(luò)打通蕴潦。
3.?公有云方面通過創(chuàng)建彈性網(wǎng)卡像啼，讓一個機器上有多個網(wǎng)卡，且每塊網(wǎng)卡帶獨立IP地址潭苞，然后對新加的網(wǎng)卡做host-device忽冻，將網(wǎng)卡的所屬network namespace 修改為Kubernetes的Pause容器，把容器和物理網(wǎng)絡(luò)打通此疹。
4.?對CNI插件進行修改僧诚，能夠給容器分配指定IP地址 ；
圖二左側(cè)是簡化后的內(nèi)網(wǎng)網(wǎng)絡(luò)拓撲秀菱，容器的虛擬網(wǎng)卡通過MacVlan與物理網(wǎng)卡的網(wǎng)卡子接口相連振诬，發(fā)出的報文會帶上網(wǎng)卡子接口的Vlantag，而這部分的流量上到上聯(lián)交換機之后就和物理機發(fā)出的沒有任何區(qū)別衍菱，之后的都是交換機和網(wǎng)關(guān)去解決掉路由的問題赶么。這個方案的設(shè)計對現(xiàn)有的環(huán)境依賴最小。同時改動量少脊串。實現(xiàn)機房物理網(wǎng)絡(luò)與容器網(wǎng)絡(luò)的扁平化辫呻，解決了容器網(wǎng)絡(luò)和物理網(wǎng)絡(luò)互聯(lián)互通的問題，由于沒有隧道解封性能問題琼锋。性能基本上持平物理機性能放闺。 本質(zhì)上這是一個私有云的網(wǎng)絡(luò)解決方案，但是很好的解決了問題缕坎。
圖二右側(cè)是簡化后的公有云網(wǎng)絡(luò)拓撲怖侦，通過把物理機上的網(wǎng)卡遷移到容器里面來間接的實現(xiàn)多IP。由于是虛擬機的彈性網(wǎng)卡谜叹，等同于虛擬機上的物理網(wǎng)卡匾寝，性能沒有問題。
3.1.1 ?虛擬網(wǎng)絡(luò)后續(xù)的演近
對Calico進行改進取消iptables依賴荷腊。利用Calico去解決內(nèi)網(wǎng)網(wǎng)絡(luò)方案中ip浪費的問題艳悔。同時可以對Calico做進一步的研究，如動態(tài)遷移容器如何保持ip漂移女仰。
3.2 基礎(chǔ)建設(shè)之調(diào)度管理?
容器調(diào)度猜年，其實是為了提高資源利用率抡锈，同時減少資源碎片化。Kubernetes的調(diào)度策略做的相對靈活乔外，對Pod的調(diào)度通過三個階段來實現(xiàn)床三，初篩階段用于篩選出符合基本要求的物理機節(jié)點，優(yōu)選階段用于得到在初篩的節(jié)點里面根據(jù)策略來完成選擇最優(yōu)節(jié)點袁稽。在優(yōu)選完畢之后勿璃，還有一個綁定過程，用于把Pod和物理機進行綁定推汽，鎖定機器上的資源。這三步完成之后歧沪，位于節(jié)點上的kubelet才能開始真正的創(chuàng)建Pod歹撒。在實際的接入過程中，Kubernetes的基礎(chǔ)調(diào)度策略不能滿足平臺的業(yè)務(wù)需求诊胞，主要有如下兩點：
1.?因為沒有規(guī)格的概念所以無法給出庫存狀態(tài)
2.?初篩的緯度太少暖夭，目前只支持CPU，內(nèi)存的初篩撵孤，優(yōu)選不支持同機房就近調(diào)度迈着。
3.2.1?整體方案
圖三
整體的調(diào)度管理分成如下幾層：
1.?接口層：
a.?用于接收請求返回特定規(guī)格，特定調(diào)度需求下的庫存數(shù)量邪码，同時返回鎖定好的虛擬IP地址裕菠。
b.?用于接收請求釋放虛擬IP地址。
2.?初篩層：對緩存中的節(jié)點信息進行初篩闭专，返回能部署規(guī)格的全部物理機節(jié)點信息
3.?優(yōu)選層：根據(jù)優(yōu)選結(jié)果奴潘，模擬部署Pod，統(tǒng)計整體庫存影钉。
4.?部署策略層：按照部署策略挑選物理機画髓，并且鎖定物理機上的虛擬IP地址，返回庫存信息
3.2.2?調(diào)度管理之接口層
鎖定庫存接口層的邏輯：
1.?把請求參數(shù)轉(zhuǎn)化為Kubernetes的Pod對象 -> ?v1.Pod平委。
2.?把scheduler的Cache進行一次深拷貝奈虾，后續(xù)的動作都會在這個深拷貝的Cache中完成
3.?請求監(jiān)控返回物理機的實時硬盤信息，實時帶寬信息廉赔。整合到深拷貝Cache中
4.?連同請求參數(shù)都傳遞給初篩層
釋放庫存接口層的邏輯：
1.?調(diào)用Kubernetes接口肉微，把物理機節(jié)點上虛擬IP的label改成unusing。
3.2.3?調(diào)度管理
圖四
初篩層：對上述的cache部分里面的Node節(jié)點進行CPU昂勉，內(nèi)存浪册，硬盤和帶寬的初步篩選，返回通過篩選的所有物理機節(jié)點岗照。
優(yōu)選層：對上述的物理機節(jié)點信息進行打分村象，對節(jié)點進行排序笆环。然后根據(jù)請求所需部署的容器數(shù)量，按照物理機節(jié)點的進行模擬部署（挑選物理機按照分數(shù)從高到低排列）厚者，直到全部節(jié)點上可部署容器數(shù)量為0躁劣，統(tǒng)計每個節(jié)點能部署的容器個數(shù)。
部署策略層：根據(jù)請求參數(shù)的不同（目前只支持集中/平鋪）库菲，鎖定物理機上的IP地址（調(diào)用kubernetes的API ?把物理機上虛擬IP的label置為Using狀態(tài)）账忘，并且返回這些IP地址。
3.2.6??整體流程圖
圖五
3.2.7??后續(xù)演進
支持調(diào)度優(yōu)先級熙宇，且能根據(jù)實際的資源使用情況進行調(diào)度而不是Kubernetes預(yù)分配的資源進行調(diào)度鳖擒。
3.3?基礎(chǔ)建設(shè)之資源隔離
Kubernetes支持CPU、內(nèi)存的隔離烫止。在宿主機層面支持驅(qū)逐模式蒋荚。通過虛擬化網(wǎng)絡(luò)的方案，主容器網(wǎng)絡(luò)和混部容器的網(wǎng)絡(luò)分割開來馆蠕。整體的資源隔離目標(biāo)是為了隔離開主容器和混部容器對資源的使用期升。以下是我們做的一些改進。
計算資源隔離
1.?K8S提供了內(nèi)存的限制能力互躬，是通過OOM來限制內(nèi)存的使用播赁。在此基礎(chǔ)上，我們還增加了限制容器使用物理機的swap吼渡。
存儲資源隔離
1.?K8S沒有提供基于物理機的存儲資源配額方案容为，但是提供了相關(guān)的框架接口。在此基礎(chǔ)上诞吱，開發(fā)了有配額大小限制的物理機靜態(tài)存儲解決方案舟奠。
網(wǎng)絡(luò)資源隔離
1.?針對容器的網(wǎng)絡(luò)限速方案，已經(jīng)在內(nèi)部測試通過房维，同時幫助社區(qū)完善了相關(guān)的限速代碼沼瘫。
3.3.1 后續(xù)的演進
資源隔離的后續(xù)方向很多，首先要解決的是Kubernetes如何能動態(tài)設(shè)置資源閾值咙俩。其后需要能夠設(shè)置內(nèi)存OOM優(yōu)先級耿戚，以及滿足資源超賣的需求
3.4 基礎(chǔ)建設(shè)之CI/CD
平臺于2018年基于gitlab開發(fā)了CI/CD，通過CI/CD和Kubernetes的配合來完成從代碼提交到上線的完整流程阿趁，其中使用Kubernetes的上線流程（如Deployment）的滾動發(fā)布存在著容器IP不固定膜蛔，動態(tài)化的問題。是因為Kubernetes的設(shè)計原則中對集群的管理尤其是服務(wù)升級過程中需要保持“無損”升級（升級過程中提供服務(wù)的副本數(shù)一直符合預(yù)期）脖阵。如果對一個Deployment進行滾動升級皂股，那么這個Deployment里面的IP地址和滾動升級之前的IP地址是不會相同的。而如果集群夠大命黔，一次滾動發(fā)布就會導(dǎo)致負載均衡變更 （集群副本數(shù)／滾動發(fā)布步長）次呜呐。對于微博服務(wù)來說就斤，頻繁變更會導(dǎo)致這個負載均衡轄下，所以后端實例的接口不穩(wěn)定蘑辑。
而平臺內(nèi)部的之前的上線系統(tǒng)是根據(jù)業(yè)務(wù)冗余度及業(yè)務(wù)實際需要來調(diào)整上線的步長洋机，減少在上線過程中業(yè)務(wù)的抖動，也就是通常說的In-place rolling updates洋魂。保證在上線過程中容器的IP不變绷旗。
整體流程的核心思路為：
1.?切斷容器的流量
2.?進行流量檢測，確保已經(jīng)沒有線上流量
3.?清理舊容器
4.?部署新容器
5.?檢測服務(wù)是否正常啟動（端口檢測副砍，接口驗證）
6.?接收線上流量衔肢，提供服務(wù)
針對該問題，容器平臺沒有使用Kubernetes的原生滾動發(fā)布而是做了以下幾個改進和適配：
1.?首先不使用DP址晕，RC的概念來完成滾動發(fā)布膀懈，只使用Pod的概念。
2.?集成已有的上線系統(tǒng)谨垃，來完成滾動發(fā)布，回滾功能
3.?流量引入/流量拒絕 利用Kubernetes容器生命周期管理的lifecycle（修改了其中的postStar的原生實現(xiàn)硼控，因為原生里面只調(diào)用一次刘陶，不管成功與否都會殺掉容器。改進成了如果不成功會按照指定的次數(shù)或時間進行重試）牢撼，服務(wù)檢查利用 liveness probe匙隔、 readiness probe來完成
主要流程有
1.?提前劃分給每個機器上劃分虛擬IP段，并給機器打上虛擬IP的label
2.?在原有的上線系統(tǒng)中增加對Kubernetes管理容器的上線流程熏版，上線過程中通過服務(wù)池中已有IP反查Pod Name纷责，然后刪掉舊Pod，然后用新的鏡像tag 生成Pod的json字符串（其中nodeSelect=${IP}）撼短，然后提交Kubernetes去創(chuàng)建新tag版本的Pod
3.?Kubelet接到創(chuàng)建請求之后再膳，提取其中的IP地址發(fā)給CNI，創(chuàng)建指定IP的新tag版本Pod
上線回滾的流程變成了刪除Pod曲横，創(chuàng)建Pod的固定化操作（見圖六）
圖六
由于給機器打好了虛擬IP標(biāo)簽喂柒，所以Pod的創(chuàng)建會被分配給固定的物理機去執(zhí)行，配合修改之后的CNI就能創(chuàng)建指定新tag+固定IP的Pod來提供服務(wù)禾嫉。滾動發(fā)布和回滾變成了刪除Pod灾杰，創(chuàng)建Pod的固定化操作。
3.5 基礎(chǔ)建設(shè)之模塊化運維
由于之前的容器是獨占物理機的模式熙参，所以對于容器的運維也是在物理機上進行的艳吠，一些功能如日志處理、域名解析孽椰、時鐘同步昭娩、運維Agent管理以及定時任務(wù)等都是在物理機層面操作凛篙。如果開始多容器混合部署，以上的功能都兼容改動工作量大题禀。再加上平臺面向的業(yè)務(wù)方眾多鞋诗，需求各不相同。例如日志推送的方式已經(jīng)出現(xiàn)scribe迈嘹、flume削彬、filebeat等不同的方式，業(yè)務(wù)運維需要根據(jù)自身去定制運維容器秀仲，由此可見模塊化運維的必要性融痛。我們基于Kubernetes的Pod概念做了如下的工作，整體架構(gòu)見圖七神僵。
圖七
1.?單獨做了運維容器雁刷，把運維相關(guān)的工具集成在容器里面；
2.?運維容器和業(yè)務(wù)容器共享網(wǎng)絡(luò)協(xié)議棧保礼，共享日志存儲沛励；
3.?在容器里面共享存儲是帶配額的靜態(tài)存儲；
3.5.1 模塊化運維之定時任務(wù)
物理機上的定時任務(wù)以來于crontab炮障，而crontab會由systemd來啟動目派。在容器中使用systemd啟動會涉及到提權(quán)問題，在實踐過程中發(fā)現(xiàn)用systemd如果權(quán)限控制不當(dāng)會造成容器被Kill的情況胁赢，所以單獨開發(fā)了兼容linux crontab語法的定時任務(wù)工具-gorun企蹭，把這個工具集成在了運維容器里面，替代了crontab來完成定時任務(wù)智末。
3.1.5.2 模塊化運維之日志處理
日志的處理主要包括監(jiān)控采集谅摄、日志推送、日志查詢系馆、日志壓縮清理四方面：
1.?日志推送：通過scribe送漠，flume等方式接收業(yè)務(wù)日志，推送給信息系統(tǒng)部等數(shù)據(jù)處理部門（如圖八）它呀。
圖八
2.?日志查詢：容器產(chǎn)生的日志需要能夠靜態(tài)存儲三天左右螺男，方便故障定位。所以日志會存儲基于Kubernetes的PVC概念開發(fā)的本地帶配額的靜態(tài)存儲里面纵穿。
3.?日志壓縮清理：磁盤空間有限下隧，打印的日志需要定期的清理和壓縮
4.?監(jiān)控采集：通過監(jiān)聽文件變化或者監(jiān)聽端口來采集需要的監(jiān)控數(shù)據(jù)
通過上述手段，能夠利用現(xiàn)有的日志體系谓媒，同時開發(fā)的工作量最小淆院，通過這樣的操作，以后的容器想要接入句惯，只需要在Pod的配置文件里面多寫一個container的配置即可土辩。
3.5.3 后續(xù)的演進
后續(xù)的運維容器將會進一步的拆分支救，做成標(biāo)準(zhǔn)化的服務(wù)，例如域名解析容器拷淘，日志推送容器各墨。讓業(yè)務(wù)的接入變得更加的容易。
3.6 基礎(chǔ)建設(shè)之彈性擴縮容
彈性伸縮在微博的應(yīng)用很廣启涯，作為支持了全公司春晚擴容的DCP系統(tǒng)其主要能力就是進行IAAS層虛擬機的彈性伸縮贬堵。是對業(yè)務(wù)進行保障的重要手段之一。彈性擴縮容保證在峰值流量來臨時通過擴容提高接口的可用性结洼，在業(yè)務(wù)量級下降后回收資源節(jié)省了成本黎做，而PaaS層的擴縮容比IaaS層的擴縮容更具有優(yōu)勢，一來是因為PaaS的啟動更輕松忍，沒有虛擬機的初始化階段蒸殿。所以啟動更快，二來是因為我們的彈性調(diào)度系統(tǒng)能提前鎖定IP鸣峭，可以做到業(yè)務(wù)容器和變更Nginx同步進行宏所。所以在PaaS層的彈性擴縮容，我們目前做到了如下幾點工作：
1.?定時擴縮容實現(xiàn)摊溶；
2.?自動化擴縮容的實現(xiàn)
定時擴縮容是復(fù)用了DCP系統(tǒng)的定時擴縮容功能楣铁，并做了一定的適配，目前可以選擇使用原生擴容模式（IaaS層）和Kubernetes擴容模式更扁。選擇好了模式之后需要填的就是Pod的調(diào)度參數(shù)和本身Pod的標(biāo)準(zhǔn)化json文件，之后就是常規(guī)功能赫冬。
自動化擴縮容的實現(xiàn)浓镜，是基于CI/CD系統(tǒng)中的放量系統(tǒng)完成的，CI/CD會在上線過程中有單機放量的步驟劲厌，其中會采集放量容器的監(jiān)控數(shù)據(jù)膛薛，業(yè)務(wù)數(shù)據(jù)和日志數(shù)據(jù)。橫向?qū)Ρ犬?dāng)前服務(wù)池的整體接口耗時和縱向?qū)Ρ葰v史七天內(nèi)單機的接口耗時补鼻。通過這套系統(tǒng)哄啄，把相關(guān)的閾值指標(biāo)導(dǎo)出之后，集成到監(jiān)控系統(tǒng)中风范，如果判斷接口的QPS和耗時產(chǎn)生了惡化咨跌，會相應(yīng)的觸發(fā)擴容操作，不同于IaaS層的擴容硼婿，PaaS的擴容在存量機器上是免費的的锌半。例如前端某接口的QPS過高，處理不過來了可以在機器學(xué)習(xí)服務(wù)池的機器上進行容器擴縮容去先扛住量寇漫。
3.1.7 基礎(chǔ)建設(shè)之負載均衡
微博平臺的7層負載均衡方案是使用Nginx刊殉。目前仍使用的是靜態(tài)文件的進行路由信息管理殉摔，nginx變更系統(tǒng)實現(xiàn)了一套動態(tài)的解決方案，將upstream與對應(yīng)的服務(wù)池進行關(guān)聯(lián)记焊，確保對應(yīng)的接口由對應(yīng)的服務(wù)池來提供服務(wù)逸月，當(dāng)服務(wù)池內(nèi)有節(jié)點變更時，自動觸發(fā)配置下發(fā)進行nginx的變更遍膜。
Kubernetes從最開始的Service上就開始了負載均衡和服務(wù)發(fā)現(xiàn)的嘗試碗硬，例如在Service上利用Iptables進行請求的隨機負載（問題在于后端某個實例的壓力已經(jīng)很高了，由于是iptables的硬負載不能感知到捌归，依然把請求傳遞過來）肛响。而且和網(wǎng)絡(luò)虛擬化一樣引入Iptables會有nf_conntrack打滿的風(fēng)險，考慮到公司內(nèi)部的已經(jīng)有成熟的負載均衡系統(tǒng)惜索，這塊進行了一個適配特笋。
由于彈性調(diào)度的功能，我們會在創(chuàng)建Pod之前就可以鎖定的IP地址巾兆。當(dāng)IP地址鎖定后猎物，我們可以同步的變更我們的負載均衡系統(tǒng)+啟動我們的業(yè)務(wù)容器。能夠更快的響應(yīng)業(yè)務(wù)請求（見圖九）角塑。
圖九
3.8 基礎(chǔ)建設(shè)之監(jiān)控系統(tǒng)
監(jiān)控和日志都是平臺內(nèi)部成熟的組件蔫磨，通過模塊化運維中日志信息的采集推送，監(jiān)控數(shù)據(jù)采集推送已經(jīng)兼容原有方式推送到監(jiān)控平臺圃伶。而物理機監(jiān)控已經(jīng)通過運維物理機部署Agent來采集堤如，不需要重新引入別的工具去完成。整體的監(jiān)控總共有如下的幾個部分：
1.?物理機信息監(jiān)控：物理機CPU窒朋、內(nèi)存搀罢、IOPS、帶寬侥猩、負載榔至、網(wǎng)絡(luò)等基礎(chǔ)監(jiān)控信息
2.?業(yè)務(wù)容器的業(yè)務(wù)監(jiān)控：包括接口QPS、耗時欺劳、返回狀態(tài)碼占比唧取、err／warn日志記數(shù)、鏈接資源耗時等（見圖十）
圖十
3.?容器使用物理資源監(jiān)控：CPU划提、內(nèi)存枫弟、IOPS、帶寬腔剂、負載媒区、網(wǎng)絡(luò)等基礎(chǔ)監(jiān)控信息，由于已有一套監(jiān)控體系，修改了的實現(xiàn)把原先需要集中處理的部分落在了計算節(jié)點本地袜漩，然后通過已有的物理機監(jiān)控數(shù)據(jù)推送到遠端監(jiān)控上绪爸。一來避免了之前Heapster結(jié)構(gòu)中的單點問題，二來可以復(fù)用現(xiàn)有的日志推送架構(gòu)宙攻。（見圖十一）
圖十一
4.?Kubernetes 組件監(jiān)控：包括單機的kubelet接口耗時奠货、成功率監(jiān)控、日志中err座掘、warn監(jiān)控递惋，同樣包括master節(jié)點的同類數(shù)據(jù)監(jiān)控
基礎(chǔ)平臺的建設(shè)不限于上述的部分，還做了鑒權(quán)溢陪，DNS優(yōu)化等相關(guān)服務(wù)萍虽。限于篇幅不便展開，于此同時微博平臺Kubernetes也在積極的與社區(qū)保持迭代形真，爭取做到能回饋社區(qū)杉编。
四、業(yè)務(wù)落地
2019年春晚期間咆霜，后端服務(wù)支持紅包飛業(yè)務(wù)邓馒，如果按照傳統(tǒng)方式需要近百臺的公有云設(shè)備按需成本。我們通過把垂直業(yè)務(wù)從大容器中抽離形成微服務(wù)蛾坯，利用Kubernetes PaaS整合能力光酣，在未增加資源成本的情況下完成春晚紅包飛保障。
目前有6大服務(wù)池接入Kubernetes PaaS脉课，共管理數(shù)千核CPU救军，數(shù)TB內(nèi)存的計算資源。通過Kubernetes整合閑散資源與合理的混合部署倘零，可提供近整體的30%的彈性伸縮能力缤言。
綜上，是微博平臺在探索Kubernetes與業(yè)務(wù)更好結(jié)合道路上的一些體會视事，實際業(yè)務(wù)接入過程中依然會有很多的挑戰(zhàn)。但是在團隊成員的努力下庆揩，最終實現(xiàn)了方案的落地并保障了春晚的線上業(yè)務(wù)的穩(wěn)定俐东。通過這次的平臺建設(shè)充分體會到只有和業(yè)務(wù)結(jié)合，并且服務(wù)好業(yè)務(wù)才能更好的促進自身架構(gòu)的成長订晌，很多時候看似很完美的方案虏辫，面對真實的業(yè)務(wù)需求還是會出現(xiàn)紕漏。我們會吸取歷史的教訓(xùn)锈拨，總結(jié)經(jīng)驗砌庄。爭取利用先進的技術(shù)來為公司創(chuàng)造更大的價值。
五、展望未來
未來我們將長期運行混合部署的微服務(wù)架構(gòu)娄昆，優(yōu)化調(diào)度系統(tǒng)佩微，對接更多的IAAS層提供商。更進一步提高接口可用性和資源利用率萌焰，也會對服務(wù)的穩(wěn)定性和資源的利用率做進一步探索哺眯，利用技術(shù)提升研發(fā)效率也是我們后續(xù)的方向。在探索的同時我們也會對ServiceMesh扒俯、Serverless持續(xù)關(guān)注奶卓，結(jié)合著業(yè)務(wù)需求，更進一步優(yōu)化容器基礎(chǔ)平臺撼玄。
相關(guān)閱讀：
Kubernetes大集群怎么管?基于監(jiān)控的彈性伸縮方法
從美圖容器優(yōu)化實踐談Kubernetes網(wǎng)絡(luò)方案設(shè)計
管理數(shù)萬個實例夺姑，服務(wù)上百個業(yè)務(wù)：kubernetes在騰訊游戲的使用及演進歷程
轉(zhuǎn)載本文請注明出處盏浙，技術(shù)原創(chuàng)及架構(gòu)實踐文章，歡迎通過公眾號菜單「聯(lián)系我們」進行投稿留潦。
高可用架構(gòu)
改變互聯(lián)網(wǎng)的構(gòu)建方式
長按二維碼 關(guān)注「高可用架構(gòu)」公眾號
