摘要：基于年底或年初沒(méi)有推廣的現(xiàn)狀，唯品會(huì)部門目前已經(jīng)做了兩年的時(shí)間。唯品會(huì)現(xiàn)狀唯品會(huì)目前線上有一千多個(gè)域，每個(gè)域之間相互的依賴比較復(fù)雜，每次的部署發(fā)布困難。這是唯品會(huì)的架構(gòu)，主要包含持續(xù)集成和持續(xù)部署。

數(shù)人云上海&深圳兩地“容器之Mesos/K8S/Swarm三國(guó)演義”的嘉賓精彩實(shí)錄第三更來(lái)啦。唯品會(huì)是數(shù)人云Meetup的老朋友，去年曾做過(guò)RPC服務(wù)框架和Mesos容器化的分享。本次分享中，嘉賓王成昌分享了唯品會(huì)在Kubernetes上兩年的PaaS實(shí)踐，干貨滿滿誠(chéng)意奉上~

王成昌，唯品會(huì)PaaS平臺(tái)高級(jí)開(kāi)發(fā)工程師
主要工作內(nèi)容包括：平臺(tái)DevOps方案流程優(yōu)化，持續(xù)部署，平臺(tái)日志收集，Docker以及Kubernetes研究。

大家好，我是唯品會(huì)PaaS團(tuán)隊(duì)的王成昌，與大家分享一下PaaS在Kubernetes的實(shí)踐?；?014年底或2015年初PaaS沒(méi)有推廣的現(xiàn)狀，唯品會(huì)PaaS部門目前已經(jīng)做了兩年的時(shí)間。

PaaS 主要工作將分為三個(gè)部分進(jìn)行介紹，首先，PaaS定義的標(biāo)準(zhǔn)構(gòu)建流程，持續(xù)集成和持續(xù)部署的架構(gòu)以及已有組建上的功能定制；第二部分，基于Kubernetes實(shí)現(xiàn)的網(wǎng)絡(luò)方案，以及根據(jù)網(wǎng)絡(luò)方案做的擴(kuò)展定制；第三部分，PaaS如何做日志收集和監(jiān)控方案，最后列一下唯品會(huì)目前為止所遇到的問(wèn)題和總結(jié)。

唯品會(huì)目前線上有一千多個(gè)域，每個(gè)域之間相互的依賴比較復(fù)雜，每次的部署發(fā)布困難。線下有多套的測(cè)試環(huán)境，每套測(cè)試環(huán)境都要去維護(hù)多帶帶的應(yīng)用升級(jí)和管理。公司層面也沒(méi)有統(tǒng)一的持續(xù)集成和部署的流程，大家各自去維護(hù)一個(gè)Jenkins或者一個(gè)Jenkins slave，看工程師的個(gè)人追求是否能夠?qū)懸粋€(gè)完整的從源代碼、到打包、最后到部署的腳本。

唯品會(huì)線上全部用物理機(jī)在跑，之前Openstack方式?jīng)]有在線上，只是在測(cè)試環(huán)境跑，物理機(jī)的使用效率還是比較低的。即使在7周年大促的高峰時(shí)段，60~80%的物理機(jī)利用率也均低于10%。

基于前面提到的現(xiàn)狀，唯品會(huì)的PaaS定義了一個(gè)構(gòu)建流程，整個(gè)流程不是一蹴而就，這是目前為止的定義，首先從源代碼的角度出發(fā)，即Git，所有的7個(gè)Phase全部包括在Jenkins Pipeline里，由于是基于Kubernetes，所以Jenkins Pipeline的執(zhí)行是通過(guò)Jenkins k8s Plugin去調(diào)度后臺(tái)的k8s Cluster，由k8s產(chǎn)生的Pod去運(yùn)行Pipeline。整個(gè)Pipeline的幾個(gè)階段，除了傳統(tǒng)的編譯單元測(cè)試和打包之外，加入了烘焙鏡像、部署以及集成公司的集成測(cè)試（即VTP），打包和鏡像完成后會(huì)正常上傳到公司統(tǒng)一的包管理系統(tǒng)Cider和平臺(tái)維護(hù)的Docker registry。

部署完成后會(huì)觸發(fā)集成測(cè)試，如果通過(guò)測(cè)試的話，會(huì)把這個(gè)包或者是鏡像標(biāo)記為可用的狀態(tài)，一般先從測(cè)試環(huán)境標(biāo)記，然后通過(guò)到staging環(huán)境。目前PaaS 平臺(tái)主要是維護(hù)測(cè)試環(huán)境和staging環(huán)境，線上還沒(méi)有，但是已經(jīng)定義了一個(gè)審批的流程，如果標(biāo)記了這個(gè)包為可用的狀態(tài)，需要一個(gè)審批來(lái)決定它是否可以上線。部署后通過(guò)k8s client，由另外一套k8s的集群來(lái)管理部署里面所有的節(jié)點(diǎn)。

這是唯品會(huì)的PaaS架構(gòu)，主要包含持續(xù)集成和持續(xù)部署。首先由一個(gè)統(tǒng)一UI的入口Dashboard，使用Nginx和Tomcat作為服務(wù)的網(wǎng)關(guān)。其背后有兩套系統(tǒng)——CPMS和API server，CPMS主要管理持續(xù)集成的各個(gè)流程，API server主要管理應(yīng)用部署，在CPMS背后是使用多個(gè)Jenkins server統(tǒng)一連到一個(gè)Kubernetes集群上產(chǎn)生Pod作為Jenkins slave去運(yùn)行，不同的構(gòu)建有多種語(yǔ)言也有不同的模板，這里會(huì)提供各種方案讓不同的Jenkins Pipeline運(yùn)行在不同的Kubernetes node里面。

在部署實(shí)現(xiàn)一個(gè)Cloud Framework，可以接入各種cloud provider，目前使用的是k8s provider，背后的服務(wù)發(fā)現(xiàn)也是k8s推薦使用的Skydns。為了兼容公司基于包發(fā)布的這樣一套模式，鏡像管理這部分會(huì)把包管理系統(tǒng)Cider接入進(jìn)入，平臺(tái)的Docker Registry，以及應(yīng)公司安全方面的要求，通過(guò)Clair對(duì)鏡像的內(nèi)容進(jìn)行檢查。

在日志收集方面，使用fluentd+ELK的組合，采用Prometheus做監(jiān)控。在PaaS架構(gòu)里，安全是通過(guò)接入公司的CAS做認(rèn)證的動(dòng)作，有一個(gè)Oauth組件做鑒權(quán)機(jī)制，通過(guò)Gnats做消息傳輸?shù)南到y(tǒng)。配額的問(wèn)題在構(gòu)建和部署中都會(huì)有所體現(xiàn)，包括用戶對(duì)于Pipeline的個(gè)數(shù)控制或者Pipeline觸發(fā)的個(gè)數(shù)，以及對(duì)應(yīng)用上的物理配額或者邏輯資源配額等。

Docker Registry改造，主要在Middleware做了一些工作，做了一個(gè)接入公司的CAS和Oauth做的驗(yàn)證和授權(quán)。也接入了當(dāng)有新的鏡像Push進(jìn)來(lái)的時(shí)候，會(huì)自動(dòng)觸發(fā)應(yīng)用的部署。Docker Registry本身對(duì)所有的repository不同的tag索引還是比較慢的，所以會(huì)針對(duì)push進(jìn)來(lái)所有的鏡像信息存入數(shù)據(jù)庫(kù)做一個(gè)索引，方便查找鏡像。用戶行為記錄主要針對(duì)pull和push的動(dòng)作，把它記錄下來(lái)。鏡像安全通過(guò)接入Clair做掃描，push鏡像layer完成之后在push鏡像的manifest時(shí)，會(huì)將鏡像layer信息發(fā)送到Clair做鏡像的安全掃描。

原來(lái)的Jenkins Kubernetes Plugin，默認(rèn)把Jenkins slave調(diào)度在所有Kubernetes node上，我們做了一個(gè)node selecter，針對(duì)不同的Pipeline類型，需要跑在不同的節(jié)點(diǎn)上。調(diào)度上加入了node selecter，此外在每個(gè)Pipeline要去run的時(shí)候申請(qǐng)資源，加入了資源的request limit，防止單個(gè)的Pipeline在運(yùn)行的時(shí)候占用過(guò)多的資源，導(dǎo)致其他的應(yīng)用或者是構(gòu)建任務(wù)受影響。在掛載方面，像傳統(tǒng)的maven項(xiàng)目在下載過(guò)一個(gè)包之后，如果是同一個(gè)主機(jī)上會(huì)把.m2文件會(huì)掛載在主機(jī)上，不同的Jenkins Pool在跑的時(shí)候，可以共享已經(jīng)下載過(guò)的資源文件。

最后，實(shí)現(xiàn)了Container slave pool的策略。當(dāng)要run一個(gè)Pipeline的時(shí)候，每次告訴k8s要起一個(gè)Jenkins slave Pod，當(dāng)需要執(zhí)行一個(gè)job的時(shí)候，等待時(shí)間比較長(zhǎng)，這里會(huì)定一個(gè)池的策略，就是一個(gè)預(yù)先準(zhǔn)備的過(guò)程，當(dāng)有一個(gè)新的任務(wù)要run的時(shí)候，立刻就可以拿到一個(gè)可用的containerslave。

這是PaaS的功能點(diǎn)，包含三個(gè)主要的部分，構(gòu)建，部署和測(cè)試集。構(gòu)建是關(guān)于用戶定義Pipeline以及對(duì)Pipeline觸發(fā)的record的管理，以及Pipeline各個(gè)phase的管理。部署主要對(duì)應(yīng)用配置的管理，這個(gè)應(yīng)用包括服務(wù)的配置如何、資源的申請(qǐng)如何，以及應(yīng)用實(shí)例的一些管理。測(cè)試集對(duì)接公司的集成測(cè)試環(huán)境，和平臺(tái)的應(yīng)用進(jìn)行關(guān)聯(lián)。

空間管理和鏡像管理，空間主要提供不同的隔離空間，提供應(yīng)用快速的復(fù)制，比如你有一個(gè)測(cè)試環(huán)境，我也有一個(gè)測(cè)試環(huán)境，為了大家環(huán)境之間相互不干擾可以提供應(yīng)用的快速?gòu)?fù)制。鏡像管理主要分三種，即平臺(tái)提供的基礎(chǔ)鏡像，業(yè)務(wù)部門一些特殊的需求會(huì)基于基礎(chǔ)鏡像做一些定制，以及具體業(yè)務(wù)鏡像。

PaaS采用的網(wǎng)絡(luò)方案，網(wǎng)絡(luò)方案最開(kāi)始直接使用的k8s 1.0的版本加flannel的一套工作模式，后來(lái)由于業(yè)務(wù)需求，用戶需求能夠直接訪問(wèn)到實(shí)例IP，而flannel當(dāng)時(shí)是封閉的子網(wǎng)。目前采用Contiv這套網(wǎng)絡(luò)模式，由公司統(tǒng)一分配Pod的IP網(wǎng)段。這里做了一個(gè)kube-HAProxy，替換了節(jié)點(diǎn)上kube-proxy這個(gè)組件，用kube-HAProxy來(lái)做Service IP到end point的一個(gè)轉(zhuǎn)發(fā)。

在kube2sky，完成域名和服務(wù)IP的注冊(cè)。傳統(tǒng)的模式下，域名是短域名，Service的名字作為短域名，還有Service本身的IP會(huì)注冊(cè)到Skydns上。這里做了一些定制，因?yàn)楣镜膽?yīng)用比如兩個(gè)業(yè)務(wù)域A和B都有本身的域名——a.vip.com和b.vip.com，A如果要訪問(wèn)B，不能讓這個(gè)訪問(wèn)跑到線上或者其他環(huán)境去，于是通過(guò)kube-sky去解析規(guī)則，把b.vip.com加入到里面，再加一個(gè)subdomain作為擴(kuò)展的domain search，最終找到平臺(tái)內(nèi)部部署的B域。

goroute 主要是平臺(tái)內(nèi)部的應(yīng)用，每個(gè)應(yīng)用都會(huì)提供一個(gè)平臺(tái)的域名，這個(gè)域名主要是有一個(gè)組件叫做state aggregator，會(huì)watch k8s apiserver發(fā)出來(lái)的Service和end point的變化，最終通過(guò)Service的名字和end point的地址，把它寫(xiě)到gorouter的route注冊(cè)表信息中，當(dāng)我們?cè)L問(wèn)平臺(tái)域名時(shí)就可以找到真正的end point地址。這里也有定制，采用HAproxy和KeepAlived替換了kube-proxy，之前從Service IP到end point IP的轉(zhuǎn)化，通過(guò)每個(gè)節(jié)點(diǎn)部署的kube-proxy，它會(huì)檢測(cè)到 Service和end point的變化，去寫(xiě)IPtables的規(guī)則，來(lái)找到最終end point的地址的IP。

現(xiàn)在統(tǒng)一使用的HAproxy加上KeepAlived，有一個(gè)kube2HAproxy組件，功能和kube-proxy前面一部分相似，都要watch kube-apiserver的Service和 end point的event來(lái)動(dòng)態(tài)的生成一個(gè)HAproxy最新的配置。KeepAlived主要為了高可用。有一個(gè)值得注意的細(xì)節(jié)，kube2HAproxy所在機(jī)器的IP，要和Service IP的網(wǎng)段在同一個(gè)網(wǎng)段里，用戶在訪問(wèn)真正的應(yīng)用的時(shí)候直接使用Service IP是公共可見(jiàn)的，而不是隨便定義的Service IP。

對(duì)外應(yīng)用訪問(wèn)是由平臺(tái)提供的域名，后綴均為*.PaaS.vip.com，解析到之后會(huì)有公司的DNS統(tǒng)一轉(zhuǎn)發(fā)到gorouter這臺(tái)機(jī)器上，因?yàn)間orouter會(huì)監(jiān)聽(tīng)到Service和end point的變化，route表里面會(huì)存儲(chǔ)每個(gè)域名對(duì)應(yīng)的end point的地址，通過(guò)round robin的方式找到最終的Pod來(lái)完成http訪問(wèn)。

最后一個(gè)定制關(guān)于Pod的IP固定，為什么要做PodIP固定？因?yàn)橹暗臏y(cè)試環(huán)境很多應(yīng)用都是部署在VM甚至在物理機(jī)上，IP都是固定的，有一些應(yīng)用是需要白名單訪問(wèn)的，應(yīng)用在這個(gè)部署機(jī)上，需要將IP提供給相應(yīng)的調(diào)用方或者是公司的某個(gè)部門來(lái)告訴他加入白名單。Docker 默認(rèn)情況下，每次銷毀和重建的過(guò)程中，IP都會(huì)隨機(jī)申請(qǐng)和釋放，所以IP有可能變化。IP固定主要在k8s apiserver做，加了兩個(gè)對(duì)象，即Pod IP Allocator和IP recycler，Pod IP Allocator是一個(gè)大的Pod的網(wǎng)段，可以認(rèn)為它是Pod的IP池， IP recycler主要記錄一些臨時(shí)回收的IP，或者叫臨時(shí)暫存區(qū)，IP不是一直存在，否則是一種IP浪費(fèi)，有一個(gè)TTL時(shí)效性的。

當(dāng)應(yīng)用重新部署的時(shí)候，原本的Pod會(huì)被刪掉，刪掉的過(guò)程中會(huì)先放在IP recycler中，當(dāng)一個(gè)新的Pod啟動(dòng)的時(shí)候，會(huì)通過(guò)namespace+RC name的規(guī)則去找是否有可用的IP，如果找到優(yōu)先用這樣的IP記錄在Pod里，這個(gè)Pod對(duì)象最終會(huì)交由kubelet去啟動(dòng)，kubelet 啟動(dòng)的時(shí)候會(huì)讀取這個(gè)Pod IP，然后告訴Docker 啟動(dòng)的IP是什么。最終有新的Pod啟動(dòng)之后，它的IP是之前已經(jīng)被銷毀的Pod IP，達(dá)到的效果就是Pod IP固定。在kubelet因?yàn)樾薷牧薖od對(duì)象的結(jié)構(gòu)，增加了Pod IP記錄使用IP的情況，根據(jù)Pod的IP告訴Docker run的時(shí)候執(zhí)行剛剛的IP來(lái)啟動(dòng)。kubelet 在刪除Pod的時(shí)候會(huì)告訴k8s去release這個(gè)IP。

日志收集主要分三種類型：首先是平臺(tái)自身的服務(wù)組件的收集，比如像jenkins、Docker 或者Kubernetes 相關(guān)組件的日志收集，另一個(gè)是所有部署在平臺(tái)里面應(yīng)用的收集，最后還有一些域，因?yàn)楣疽恍┮延邢到y(tǒng)（dragonfly）也是做日志收集和監(jiān)控的，有一些特定的規(guī)則對(duì)接公司。

平臺(tái)自身日志收集的規(guī)則，包含系統(tǒng)組件還有平臺(tái)應(yīng)用兩種設(shè)計(jì)。系統(tǒng)組件比較簡(jiǎn)單，無(wú)外乎通過(guò)systemd或者是指定日志文件的路徑做日志的收集，應(yīng)用收集主要在k8snode上，k8s會(huì)把每一個(gè)Pod日志link在一個(gè)特定的文件路徑下，因?yàn)镈ocker會(huì)記錄每一個(gè)容器的日志，可以從這個(gè)地方讀取應(yīng)用的日志，但是只拿到namespace和Pod name這樣的結(jié)構(gòu)，我們會(huì)通過(guò)fluentd里的filter反向去k8s拿Pod所對(duì)應(yīng)的meta data，最終發(fā)送到kafka，通過(guò)logstash達(dá)到elastic search。

Kibana的展現(xiàn)做了一些定制，因?yàn)槠脚_(tái)的展現(xiàn)主要基于namespace和應(yīng)用名稱的概念查看日志的，定制能夠展現(xiàn)特定的namespace下的特定應(yīng)用的日志，同時(shí)把自定義的告警加在了這里，因?yàn)楦婢峭ㄟ^(guò)elastalert來(lái)做的，在Kibana上做一個(gè)自定義告警的UI入口，由用戶來(lái)指定想要監(jiān)聽(tīng)什么樣的日志內(nèi)容的告警，去配置監(jiān)聽(tīng)的間隔或者出現(xiàn)的次數(shù)，以及最終的郵件接收人。

有一個(gè)組件是當(dāng)用戶創(chuàng)建了自定義告警的規(guī)則時(shí)會(huì)發(fā)送到后面的elastalert ruler，ruler解析前臺(tái)UI的信息，生成elastalert能夠識(shí)別的configure文件，動(dòng)態(tài)地讀取configure的加入。
對(duì)接公司的業(yè)務(wù)系統(tǒng)比較簡(jiǎn)單，特定的收集規(guī)則都是特定的，比如具體的目錄規(guī)則，一般來(lái)講都是通過(guò)掛載容器的目錄到主機(jī)目錄上，在主機(jī)上統(tǒng)一部署一個(gè)agent去run，主要體現(xiàn)在k8s node上，所以仍然使用Daemonset的方式去跑agent。

監(jiān)控有兩種，一種是對(duì)單個(gè)Pod的實(shí)例監(jiān)控，在頁(yè)面上是可以直接看這樣的實(shí)例的，單個(gè)Pod是一個(gè)應(yīng)用實(shí)例了，然后通過(guò)node agent去包裝了cAdviser，前端去統(tǒng)一訪問(wèn)，獲取對(duì)應(yīng)的CPU和Memory使用信息。cAdviser對(duì)Network收集到的數(shù)據(jù)是不正確的，通過(guò)node agent 讀取Linux file獲取Network的信息。Websocket Server 是為了提供網(wǎng)頁(yè)上直接對(duì)容器進(jìn)行網(wǎng)頁(yè)控制臺(tái)的登錄。

另一個(gè)是看整個(gè)的應(yīng)用，因?yàn)閼?yīng)用是有多個(gè)實(shí)例的，通過(guò)Graphana去定制，去展現(xiàn)namespace的應(yīng)用，有多個(gè)實(shí)例，就把多個(gè)實(shí)例的監(jiān)控都展現(xiàn)出來(lái)。此處有一個(gè)promethus plugin的定制，之前有一些Swarm的節(jié)點(diǎn)加入，持續(xù)部署提到過(guò)它是一個(gè)多個(gè)cloud framework都可以接入的。唯品會(huì)接入了一些Swarm的信息，針對(duì)Swarm創(chuàng)建的容器的話，也要能夠監(jiān)控到它的容器監(jiān)控信息的數(shù)據(jù)。在Promethus plugin通過(guò)Docker info獲取不同的Swarm node的信息，在每個(gè)Swarm node上部署cAdviser，獲取由Swarm創(chuàng)建的容器的監(jiān)控信息。

遇到的問(wèn)題非常多，到現(xiàn)在為止將近兩年的時(shí)間，有很多都是可以在GitHub找到的問(wèn)題，以及通過(guò)升級(jí)可以解決的問(wèn)題。最開(kāi)始采用的是Docker 1.6以及Kubernetes 1.0，中間經(jīng)歷兩次的升級(jí)，現(xiàn)在主要使用Docker 1.10和Kubernetes 1.2。

production使用direct-lvm做Devicemapper存儲(chǔ)。

目前發(fā)現(xiàn)一些Pod一直處于pending的狀態(tài)，使用kubectl或者Kubernetes API沒(méi)有辦法直接對(duì)Pod做任何操作，目前只能通過(guò)手動(dòng)Docker的方式刪除容器。

k8s僵死容器是以前碰到的問(wèn)題，現(xiàn)在最新版的Kubelet是支持這樣的參數(shù)，允許每一個(gè)節(jié)點(diǎn)上最大僵死容器個(gè)數(shù)，交由Kubelet自己做清理的工作。

因?yàn)橐郧鞍l(fā)現(xiàn)用戶來(lái)告訴配額不足的時(shí)候，調(diào)整配額并不會(huì)立馬的生效，升級(jí)以后就沒(méi)有這種問(wèn)題了。

這個(gè)是應(yīng)用的問(wèn)題，不是傳統(tǒng)理解的跑一次性任務(wù)，k8s batch job要求一定要exit 0。也有一些Job的類型，目前是直接對(duì)應(yīng)的背后k8s的Pod方式。

這是最新遇到的問(wèn)題，上下文的話，稍微有一點(diǎn)復(fù)雜，有兩個(gè)應(yīng)用部署在唯品會(huì)的平臺(tái)上，每個(gè)應(yīng)用都有自己的legacy域名，比如有一個(gè)域名叫user.vip.com，另一個(gè)叫info.user.vip.com，這時(shí)候ping user.vip.com，有可能會(huì)拿到info.user.vip.com的IP，由于kube-sky本身在寫(xiě)Skydns record時(shí)候有問(wèn)題，所以會(huì)添加一個(gè)group做一個(gè)唯一性的識(shí)別，這樣在ping子域名（user.vip.com）的時(shí)候就不會(huì)讀到info.user.vip.com。Skydns本身目錄結(jié)構(gòu)的問(wèn)題，加上group就不會(huì)再去讀到下面的子路徑。

唯品會(huì)一直使用Devicemapper，中間嘗試一些節(jié)點(diǎn)用Overlayfs的存儲(chǔ)，但是在目錄操作時(shí)會(huì)file not found，官方也有一個(gè)issue說(shuō)當(dāng)Overlayfs 在不同的layer的時(shí)候，牽扯到刪除的操作，會(huì)出現(xiàn)這個(gè)問(wèn)題?？梢陨?jí)解決，但是系統(tǒng)是固定的，升級(jí)很麻煩，所以沒(méi)有做升級(jí)而是切回了Devicemapper。

由于容器占用的磁盤空間過(guò)多，導(dǎo)致了整個(gè)k8s node的磁盤空間被占滿的問(wèn)題，唯品會(huì)是在Cadviser做一些改造，可以監(jiān)控到每一個(gè)容器所占用的磁盤空間，對(duì)磁盤空間做一些限制。

在刪除一個(gè)namespace的時(shí)候，namespace是可以動(dòng)態(tài)創(chuàng)建和刪除的，在刪除的時(shí)候會(huì)看到namespace一直處于terminating的狀態(tài)，這個(gè)在GitHub上有一些解決方法，因?yàn)樗旧硎怯捎趎amespace的finalizer會(huì)進(jìn)入一個(gè)死循環(huán)，有一個(gè)work around，可以手動(dòng)的置空f(shuō)inalizer，把這個(gè)namespace update回去，就可以正常刪除了。

以上就是我要分享的主要內(nèi)容，謝謝大家。