【51CTO.com原創(chuàng)稿件】2018年5月18-19日，由51CTO主辦的全球軟件與運(yùn)維技術(shù)峰會(huì)在北京召開(kāi)。來(lái)自全球企業(yè)的技術(shù)精英匯聚北京，暢談軟件技術(shù)前沿，共同探索運(yùn)維技術(shù)的新邊界。而在本次大會(huì)上，除了眾星云集的主論壇環(huán)節(jié)，12場(chǎng)分論壇更是各具特色，在19日下午的“開(kāi)源與容器技術(shù)”分論壇上，來(lái)自知乎計(jì)算平臺(tái)負(fù)責(zé)人張阜興發(fā)表了題為“知乎容器平臺(tái)演進(jìn)及與大數(shù)據(jù)融合實(shí)踐”的精彩演講。

知乎計(jì)算平臺(tái)負(fù)責(zé)人張阜興演講

知乎計(jì)算平臺(tái)負(fù)責(zé)人張阜興碩士畢業(yè)于中科院計(jì)算所，在加入知乎之前，先后在搜狐研究院和雅虎北京研發(fā)中心從事分布式存儲(chǔ)以及云平臺(tái)相關(guān)的開(kāi)發(fā)工作，現(xiàn)在在知乎計(jì)算平臺(tái)主要負(fù)責(zé)容器，流量負(fù)載均衡，以及大數(shù)據(jù)基礎(chǔ)組件相關(guān)的工作。在此次的演講中，張阜興主要從三個(gè)方面進(jìn)行講解，包括知乎容器平臺(tái)演進(jìn)、實(shí)踐過(guò)程中在生產(chǎn)環(huán)境里踩過(guò)的坑，以及在容器技術(shù)和大數(shù)據(jù)應(yīng)用所做的一些融合實(shí)踐。

知乎容器平臺(tái)演進(jìn)的歷程

在演講的開(kāi)始，張阜興為大家介紹了知乎容器平臺(tái)演進(jìn)的歷程。知乎容器平臺(tái)的演進(jìn)歷程大致可以分成三個(gè)階段，2015年9月，知乎的容器平臺(tái)正式在生產(chǎn)環(huán)境中上線(xiàn)應(yīng)用；2016年5月，知乎90%的業(yè)務(wù)遷移到容器平臺(tái)；目前，除了業(yè)務(wù)容器外，包括像HBase、Kafka多個(gè)基礎(chǔ)組件也采用容器部署，總的物理節(jié)點(diǎn)數(shù)達(dá)到了兩千多，容器數(shù)達(dá)到了三萬(wàn)多。

演進(jìn)過(guò)程中，張阜興總結(jié)了三個(gè)要點(diǎn)：

***是從Mesos到Kubernetes，這樣一個(gè)技術(shù)選型的變化；

第二是從單集群到多集群混合云的架構(gòu)調(diào)整；

第三是從滾動(dòng)部署到部署發(fā)布分離這樣的一種使用上的優(yōu)化。

張阜興首先分享了從Mesos到Kubernetes技術(shù)選型的思考，知乎是在2015年開(kāi)始在生產(chǎn)環(huán)境中使用容器平臺(tái)，那時(shí)Kubernetes剛剛發(fā)布，還不成熟。所以知乎選用了Mesos技術(shù)方案，Mesos的優(yōu)勢(shì)是非常穩(wěn)定，并且架構(gòu)設(shè)計(jì)中，Master的負(fù)載比較輕，單集群可以容納的容器規(guī)模比較大，據(jù)官方介紹可以單集群容納五萬(wàn)個(gè)節(jié)點(diǎn)。劣勢(shì)是需要單獨(dú)開(kāi)發(fā)一套Framework，會(huì)帶來(lái)較高的使用成本。

 Kubernetes的優(yōu)勢(shì)是社區(qū)強(qiáng)大，功能完善，使用成本較低。但是由于他把所有的狀態(tài)都放在etcd中存取，所以單集群的所能容納節(jié)點(diǎn)規(guī)模沒(méi)有Mesos那么大。官方說(shuō)法是現(xiàn)在etcd升級(jí)到V3版本之后，現(xiàn)在可以到五千個(gè)節(jié)點(diǎn)。

    第二個(gè)架構(gòu)上的變化是從單集群到混合云的架構(gòu)，為什么要做這個(gè)呢，在生產(chǎn)環(huán)境中也是實(shí)際所需。***我們需要做灰度集群，也就是對(duì)于Mesos或者是對(duì)于Kubernetes做任何參數(shù)的變更，一定需要在灰度集群上去先做驗(yàn)證，然后才能在生產(chǎn)環(huán)境中大規(guī)模的實(shí)踐。第二點(diǎn)是對(duì)單機(jī)群容量進(jìn)行擴(kuò)容，第三點(diǎn)是容忍單集群故障，采用混合云的架構(gòu)因?yàn)楣性频募撼乇容^大，這樣可以大大提升彈性資源池的大小，抵抗突發(fā)擴(kuò)容情況。

在混合云架構(gòu)的實(shí)現(xiàn)過(guò)程中，知乎也調(diào)研了像Kubernetes的Federation這些方案，首先是Kubernetes的Federation方案現(xiàn)在官方還不推薦在生產(chǎn)環(huán)境中運(yùn)行。第二，由于在部署和管理上有很多的問(wèn)題，所以我們采用的是自研的管理方案，大致的原理就是我們的每一組業(yè)務(wù)容器會(huì)同時(shí)在多個(gè)集群上去創(chuàng)建Deployment，這些Deployment的配置，比如說(shuō)像容器版本，或者CPU內(nèi)存資源的配置都是完全相同的，唯一的不同只不過(guò)是容器數(shù)量會(huì)根據(jù)不同集群的大小做出調(diào)整。

另一個(gè)變化是從滾動(dòng)部署的模式切換成了部署和發(fā)布分離的模式。這里先給出我們對(duì)部署和發(fā)布的定義，我們可以看一個(gè)典型的服務(wù)上線(xiàn)流程，包括了內(nèi)網(wǎng)，金絲雀，生產(chǎn)環(huán)境三個(gè)發(fā)布階段，在每個(gè)階段都需要觀察驗(yàn)證指標(biāo)是否正常以便決定是繼續(xù)上線(xiàn)還是回滾，如果采用Deployment的滾動(dòng)部署，可以實(shí)現(xiàn)每次升級(jí)部分容器，升級(jí)過(guò)程中服務(wù)不中斷，消耗的瞬時(shí)***資源較小，但是滾動(dòng)部署不能控制進(jìn)度暫停，導(dǎo)致不能和多個(gè)發(fā)布階段對(duì)應(yīng)。如果每個(gè)階段采用獨(dú)立的 k8s Deployment，會(huì)導(dǎo)致部署速度慢，而且由于滾動(dòng)過(guò)程中舊容器即銷(xiāo)毀了，如果要回滾，需要重新部署，回滾速度慢。為此，我們將部署和發(fā)布階段進(jìn)行了分離，服務(wù)上線(xiàn)時(shí)，就后臺(tái)啟動(dòng)一組新版本容器實(shí)例，當(dāng)實(shí)例數(shù)滿(mǎn)足發(fā)布的條件時(shí)，就發(fā)布部分實(shí)例接收外部流量，在外部流量驗(yàn)證過(guò)程中，后臺(tái)還可以并行的繼續(xù)部署新容器實(shí)例，從而使得用戶(hù)感知不到容器實(shí)例部署的時(shí)間，實(shí)現(xiàn)秒級(jí)部署。同時(shí)在發(fā)布過(guò)程中，舊容器實(shí)例只是不再對(duì)外可見(jiàn)，但實(shí)例依然保留一段時(shí)間，這樣如果發(fā)布過(guò)程有問(wèn)題，可以立即切換，秒級(jí)回滾。

在容器的使用模式上，知乎引入了持久化存儲(chǔ)去對(duì)應(yīng)著做一些支持。在容器是使用模式上我們從最初的無(wú)狀態(tài)web應(yīng)用，到在容器中使用持久化存儲(chǔ)，來(lái)實(shí)現(xiàn)一些有狀態(tài)服務(wù)的容器化部署，如可以基于Hostpath，用Daemonset方式在每個(gè)節(jié)點(diǎn)上啟動(dòng)consul agent，因?yàn)镈eamon Set保證每個(gè)節(jié)點(diǎn)上只啟動(dòng)一個(gè)pod，不會(huì)存在 hostpath 沖突的情況?；?local volume 可以進(jìn)行本地磁盤(pán)調(diào)度管理，實(shí)現(xiàn) kafka broker 的部署，這個(gè)在后面介紹 kafka 方案時(shí)再想細(xì)介紹。另外有基于 Fuse 將 分布式文件系統(tǒng)映射到容器中，目前主要應(yīng)用于業(yè)務(wù)數(shù)據(jù)讀取的場(chǎng)景。

另外一個(gè)使用模式是容器網(wǎng)絡(luò)，我們?cè)贙ubernetes的方案上，選用的是Underlay IP網(wǎng)絡(luò)，我們所采用的模式是容器的IP和物理機(jī)的IP是完全對(duì)等的。這樣互聯(lián)簡(jiǎn)單，由于不存在overlay的封包解包處理，性能幾乎無(wú)損耗，另外 IP 模式下，可以方便的定位網(wǎng)絡(luò)連接的來(lái)源，故障定位更容易。在具體的實(shí)踐過(guò)程中，我們給每一臺(tái)機(jī)器一個(gè)固定網(wǎng)絡(luò)IP段，然后通過(guò)CNI插件IPAM去負(fù)責(zé)容器IP的分配和釋放。

維護(hù)容器平臺(tái)過(guò)程中所采過(guò)的那些坑

張阜興在容器平臺(tái)的生產(chǎn)環(huán)境和建立中有著豐富的經(jīng)驗(yàn)，也踩過(guò)不少技術(shù)的“坑”。在此次的WOT峰會(huì)上，他把過(guò)去經(jīng)歷過(guò)的比較典型的技術(shù)故障、技術(shù)陷阱與大家分享，寶貴的“踩坑經(jīng)”讓來(lái)賓受益匪淺。

陷阱之一：K8S events

在一個(gè)月黑風(fēng)高的夜半，我們的K8S etcd 突然間全部不能訪(fǎng)問(wèn)了，通過(guò)調(diào)查，原因就是K8S events 默認(rèn)存儲(chǔ)方式帶來(lái)的性能問(wèn)題。K8S默認(rèn)會(huì)把集群發(fā)生的任何事件變化全部記錄到etcd里。K8S events默認(rèn)配置了一個(gè)過(guò)期策略，每過(guò)一段時(shí)間，這個(gè)events就會(huì)回收，釋放etcd的存儲(chǔ)空間，這樣聽(tīng)起來(lái)是很合理，但是在etcd對(duì)TTL的實(shí)現(xiàn)里面，每次去遍歷查找非常低效，隨著集群規(guī)模變大，集群上面頻繁的去發(fā)布部署變更，導(dǎo)致了events 越來(lái)越多，etcd負(fù)載越來(lái)越大，直至etcd崩掉，整個(gè)K8S集群就崩掉了。

K8S其實(shí)也意識(shí)到這個(gè)問(wèn)題，所以為用戶(hù)提供了一個(gè)配置，可以把events記錄到一個(gè)單獨(dú)的etcd集群里。此外，我們可以在晚低峰的時(shí)候，把整個(gè)event的etcd清空，相當(dāng)于我們自己去實(shí)現(xiàn)過(guò)期清理的策略。

陷阱之二：K8S Eviction

第二個(gè)坑是K8S Eviction，這個(gè)坑是直接把所有生產(chǎn)環(huán)境中的Pods全部給刪掉了。它的產(chǎn)生首先是API server要去配置高可用，但是即使配置了高可用，也會(huì)有很小的概率會(huì)掛掉。如果沒(méi)有及時(shí)去處理，例如API server宕機(jī)超過(guò)五分鐘，這些集群的Node都和它失聯(lián)了，會(huì)觸發(fā)控制節(jié)點(diǎn)將所有 pod 殺掉驅(qū)逐出集群。在1.5版本之后，官方已經(jīng)增加了一個(gè)配置，就是-unhealthy-zone-threshold，例如當(dāng)超過(guò)30%的Node處于一個(gè)失聯(lián)狀態(tài)的時(shí)候，這時(shí)候集群會(huì)禁止Controller Manager的驅(qū)逐策略，當(dāng)遇到大規(guī)模異常時(shí)，防止對(duì)集群容器進(jìn)行誤驅(qū)逐。

    另一個(gè)是容器端口泄露問(wèn)題，在使用端口映射的模式時(shí)，經(jīng)常在發(fā)現(xiàn)有容器啟動(dòng)時(shí)報(bào)port is already allocated，說(shuō)這個(gè)端口已經(jīng)被使用了。我們通過(guò)分析 Docker Daemon代碼，在 Docker Daemon 分配端口到記錄這個(gè)端口到內(nèi)部的持久化存儲(chǔ)這個(gè)過(guò)程不是原子的，在這個(gè)中間如果Docker Daemon重啟了，只會(huì)根據(jù)存儲(chǔ)的端口記錄去恢復(fù)，所以它就遺忘掉了之前分配的端口。找到這個(gè)原因之后，我們向官方提出了對(duì)應(yīng)的解決方案。

陷阱之三 ：Docker NAT

 還有一個(gè)坑是Docker NAT網(wǎng)絡(luò)遇到的。大家如果看了我貼的系統(tǒng)配置，對(duì)于網(wǎng)絡(luò)數(shù)據(jù)包的亂序的處理太過(guò)嚴(yán)格。如果容器中進(jìn)程訪(fǎng)問(wèn)阿里云等公網(wǎng)的一些圖片服務(wù)，在公網(wǎng)這種網(wǎng)絡(luò)比較差的時(shí)候，如果亂序包超過(guò)了TCP的滑動(dòng)窗口，這時(shí)候系統(tǒng)的這個(gè)配置會(huì)把這個(gè)網(wǎng)絡(luò)連接給reset掉。把這個(gè)配置關(guān)掉之后就可以解決這個(gè)問(wèn)題了。

在容器平臺(tái)和大數(shù)據(jù)組建融合上的嘗試

在大數(shù)據(jù)場(chǎng)景下其實(shí)主要有兩條處理路徑，如圖，左邊這一條是實(shí)時(shí)處理的，右邊的是批處理的。因?yàn)槌霭l(fā)點(diǎn)不一樣，所以導(dǎo)致這些組件的設(shè)計(jì)思想有很大的不同，批處理因?yàn)橹饕亲鲞@種ETL任務(wù)，所以說(shuō)他主要是做那種數(shù)據(jù)倉(cāng)庫(kù)的構(gòu)建，追求的是吞吐率，對(duì)于時(shí)延是不敏感的。

    但是實(shí)時(shí)處理是對(duì)時(shí)延是比較敏感的，里面的任何節(jié)點(diǎn)的掛掉，都會(huì)導(dǎo)致數(shù)據(jù)落地的延遲，以及數(shù)據(jù)展示不可用。所以說(shuō)，像實(shí)時(shí)處理，他的組件所運(yùn)行的這些機(jī)器的負(fù)載就不能特別高。

    我們?cè)诖髷?shù)據(jù)生產(chǎn)環(huán)境維護(hù)過(guò)程中，經(jīng)常遇到的一些問(wèn)題，比如說(shuō)某一個(gè)業(yè)務(wù)做了一些變更，他寫(xiě)入Kafka的流量突然大了很多，這時(shí)候把Kafka集訓(xùn)整個(gè)的負(fù)載都給打高了，如果打的太高，可能整個(gè)集群就崩掉了，會(huì)使生產(chǎn)環(huán)境受到影響。

    怎么去做對(duì)應(yīng)的治理呢？基本的思路時(shí)去按業(yè)務(wù)方給他們做集群的劃分，集群的隔離。我們把集群劃分開(kāi)了，帶來(lái)了另外一個(gè)問(wèn)題，我們由原來(lái)的一套集群變成了幾十套集群，這么多集群我們?cè)趺慈ソy(tǒng)一的配置管理和部署。這個(gè)成本是很高的，我們用了K8s的模板，因?yàn)樗梢院芊奖愕囊绘I搭建出多種相同的運(yùn)行環(huán)境。

    另外一個(gè)引發(fā)的問(wèn)題是每一個(gè)業(yè)務(wù)方使用的量是不一樣的，有的業(yè)務(wù)方使用量比較大，有的業(yè)務(wù)方使用量比較小，如果使用量比較小的，比如說(shuō)只有幾十個(gè)kbs，也需要維護(hù)一個(gè)高可用的集群，如果配備三臺(tái)機(jī)器，這樣就帶來(lái)了大量的資源浪費(fèi)，我們的解決方案就是用容器來(lái)實(shí)現(xiàn)更細(xì)粒度的資源分配和配置。

大數(shù)據(jù)平臺(tái)的管理方面，我們踐行了Devops的思想，這意味著我們是平臺(tái)方而非運(yùn)維方，我們定位自己為工具的開(kāi)發(fā)者，日常運(yùn)維操作，包括創(chuàng)建集群、重啟、擴(kuò)容，都通過(guò)PaaS平臺(tái)交由業(yè)務(wù)方自主式的去完成。這樣的好處，首先是減少了溝通的成本，公司越來(lái)越大之后，這種業(yè)務(wù)方之間的溝通特別復(fù)雜。第二方便了業(yè)務(wù)方，比如說(shuō)發(fā)現(xiàn)他需要擴(kuò)容，可以直接在這個(gè)平臺(tái)上自己獨(dú)立的操作完成，減輕了日常工作負(fù)擔(dān)，也讓我們能夠更加專(zhuān)注于技術(shù)本身，專(zhuān)注于更好的如何把這個(gè)平臺(tái)和把底層的技術(shù)做的更好。

    在大數(shù)據(jù)平臺(tái)上，我們還提供了豐富的監(jiān)控指標(biāo)，這個(gè)也是Devops實(shí)踐中我們必須理解的一環(huán)。因?yàn)闃I(yè)務(wù)本身對(duì)于像Kafka或者是對(duì)于HBase這種系統(tǒng)的理解是比較淺的，我們?nèi)绾伟盐覀兎e累的這些集群的理解和經(jīng)驗(yàn)，傳達(dá)給業(yè)務(wù)方，我們通過(guò)監(jiān)控指標(biāo)把這些指標(biāo)完全暴露給業(yè)務(wù)方，希望把Kafka集群變成一個(gè)白盒，而不是一個(gè)黑盒，這樣業(yè)務(wù)方在發(fā)生故障的時(shí)候，直接在指標(biāo)系統(tǒng)上就能看到各種各樣的異常，然后配合，比如說(shuō)我們給他定制的一些報(bào)警閾值，他就能及時(shí)的自己去做一些處理。

    總結(jié)而言，我們?cè)谌萜骱痛髷?shù)據(jù)融合上面的思路，首先我們要按業(yè)務(wù)方去做集群的隔離，第二是我們用K8S去做多集群的管理部署，然后用Docker去做資源的隔離和細(xì)粒度的分配和監(jiān)控，以及在管理運(yùn)維上我們踐行Devops這種理念，然后讓平臺(tái)方更加專(zhuān)注于工具開(kāi)發(fā)本身，而不是限于瑣碎的運(yùn)維操作不能自拔。

    對(duì)于后續(xù)的展望，一方面是希望將更多的基礎(chǔ)設(shè)計(jì)組件，全部挪到K8S上，另外在這些組件之上，提供PaaS平臺(tái)，為業(yè)務(wù)方提供更好更方便更穩(wěn)定的服務(wù)，最終的一個(gè)理想是將我們數(shù)據(jù)中心的資源統(tǒng)一的交給K8S去做調(diào)度管理，實(shí)現(xiàn)DCOS。

本次WOT峰會(huì)講師演講稿件由51CTO采編整理，如欲了解更多，敬請(qǐng)登錄www.scjtxx.cn進(jìn)行查看。

【51CTO原創(chuàng)稿件，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文作者和出處為51CTO.com】