摘要：月日京東基礎(chǔ)架構(gòu)部技術(shù)總監(jiān)集群技術(shù)部負(fù)責(zé)人鮑永成受邀出席了舉辦的容器技術(shù)大會(huì)，并做了題為京東如何打造全球最大集群支撐萬億電商交易的主題演講，本文根據(jù)演講內(nèi)容整理而成。化繁為簡(jiǎn)重構(gòu)有人問，京東做一個(gè)這么大的集群，是不是特別復(fù)雜特別容易出錯(cuò)。

在過去一年里，Kubernetes以其架構(gòu)簡(jiǎn)潔性和靈活性，流行度持續(xù)快速上升，我們有理由相信在不遠(yuǎn)的未來，Kubernetes將成為通用的基礎(chǔ)設(shè)施標(biāo)準(zhǔn)。而京東早在2016年年底上線了京東新一代容器引擎平臺(tái)JDOS2.0，成功從Openstack切換到JDOS2.0的Kubernetes技術(shù)棧，打造了完整高效的PaaS平臺(tái)。

6月28日京東基礎(chǔ)架構(gòu)部技術(shù)總監(jiān)、集群技術(shù)部負(fù)責(zé)人鮑永成受邀出席了Rancher Labs舉辦的Container Day 2018容器技術(shù)大會(huì)，并做了題為《京東如何打造kubernetes全球最大集群支撐萬億電商交易》的主題演講，本文根據(jù)演講內(nèi)容整理而成。鮑永成，2013年加入京東，負(fù)責(zé)京東容器平臺(tái)JDOS研發(fā)工作，帶領(lǐng)團(tuán)隊(duì)完成京東容器大規(guī)模落地戰(zhàn)略，全量承載京東全部在線系統(tǒng)、中間件、數(shù)據(jù)庫(kù)以及大數(shù)據(jù)離線計(jì)算任務(wù)。目前聚焦在京東JDOS2.0、阿基米德調(diào)度平臺(tái)（特別搶占式智能數(shù)據(jù)中心調(diào)度系統(tǒng)、京東大幅提升數(shù)據(jù)中心資源使用率的利器）、“云+端”線下門店生態(tài)基礎(chǔ)設(shè)施以及新一代數(shù)據(jù)中心研發(fā)工作。

在演講中鮑永成分享了京東在大規(guī)模實(shí)際生產(chǎn)過程對(duì)Kubernetes做深入重構(gòu)的經(jīng)驗(yàn)，以及京東如何圍繞K8s啟動(dòng)一些內(nèi)部新項(xiàng)目，服務(wù)JDOS2.0大規(guī)模生產(chǎn)環(huán)境穩(wěn)定高效運(yùn)行。

感謝Rancher邀請(qǐng)我們來做京東在容器方面的分享。京東的分享可能跟業(yè)內(nèi)的很多做向外輸出的公司有點(diǎn)不一樣，我們的容器主要是自用。京東的數(shù)據(jù)中心現(xiàn)在規(guī)模已經(jīng)比較大，實(shí)際上我們用Kubernetes或者是以前用Openstack的思路完全是克隆谷歌數(shù)據(jù)中心管理的理念。

其實(shí)數(shù)據(jù)中心就是圍繞著幾個(gè)東西來說：服務(wù)器、網(wǎng)絡(luò)以及一些基礎(chǔ)軟件，剩下的就是集群的管理。這里要說明一下，我們認(rèn)為基礎(chǔ)軟件是數(shù)據(jù)中心非常重要的一個(gè)環(huán)節(jié)，比如，域名解析、負(fù)載均衡、時(shí)鐘這些東西，雖然Kubernetes管理了整個(gè)集群，但是這些東西它依然沒有。也就是說，要是想把它用得非常好的話，這些軟件也要進(jìn)行一些適當(dāng)?shù)淖兏铩?/p>

京東在使用Kubernetes管理大數(shù)據(jù)中心的時(shí)候，也圍繞著Kubernetes在我們內(nèi)部的數(shù)據(jù)中心建了很多生態(tài)。首先是適合容器化的DNS，以及適合容器化的負(fù)載均衡，還有適合容器化的文件系統(tǒng)、鏡像中心等等。這里面特別要說明一點(diǎn)，就是DNS跟LB，Kubernetes 1.9合入了高性能的負(fù)載均衡。如果在大規(guī)模生產(chǎn)環(huán)境中，高性能的負(fù)載均衡是必不可少的，但這個(gè)負(fù)載均衡又涉及到另外一些問題。首先，要跟現(xiàn)有的數(shù)據(jù)中心適配，京東自主研發(fā)了一套負(fù)載均衡以及DNS。雖然社區(qū)里有CoreDNS等等，但是這些DNS存在一個(gè)問題，就像昨天某廠的一個(gè)故障那樣，你把所有的東西這個(gè)引導(dǎo)這個(gè)，那個(gè)引導(dǎo)那個(gè)。如果你的DNS不在容器內(nèi)的話，帶來的后果是很難料想的。因?yàn)榫〇|容器已經(jīng)發(fā)展了很多年，數(shù)據(jù)中心也比較大，我們單個(gè)Kubernetes集群能夠做到8000到10000臺(tái)。因?yàn)槲覀兊臋C(jī)器實(shí)在太多，如果不做大集群的話，人力管理的投入上會(huì)非常大。后面我會(huì)解釋怎么做到這么大規(guī)模的集群。
?
京東容器化的數(shù)據(jù)中心建設(shè)已經(jīng)四五年了，已經(jīng)比較穩(wěn)定了，雖然我們的Kubernetes還比較老，是1.6版本，但是我們已經(jīng)有很多改進(jìn)，我們現(xiàn)在的重點(diǎn)就是往阿基米德，也就是往數(shù)據(jù)中心的資源調(diào)度這個(gè)方向發(fā)展。去年雙十一的時(shí)候阿基米德已經(jīng)上線了，Kubernetes使用到后期的時(shí)候，你會(huì)發(fā)現(xiàn)Kubernetes并不能解決數(shù)據(jù)中心資源使用率的問題，它其實(shí)僅僅解決了你的發(fā)布，或者是管理資源的容器這方面的一些東西。

上圖是我們數(shù)據(jù)中心的基礎(chǔ)架構(gòu)，其實(shí)比較傳統(tǒng)，我們會(huì)把負(fù)載均衡、域名，以及我們包的這個(gè)Kubernetes的API統(tǒng)一抽象出來，整個(gè)就是一套。然后在每個(gè)數(shù)據(jù)中心部署若干套Kubernetes集群，每一個(gè)Kubernetes集群，會(huì)管理三個(gè)物理Pod，大概是一萬臺(tái)的規(guī)模。

為了配合這個(gè)規(guī)模，我們做了一些工作。DNS最早的時(shí)候，還沒有CoreDNS來適配，大家知道每個(gè)數(shù)據(jù)中心最老的DNS是bind9，適配起來是非常痛苦的，它缺API，缺很多東西。所以我們就自己研發(fā)了一套基于Etcd的分布式DNS，當(dāng)時(shí)提供了RestfulAPI，直接對(duì)接的Kubernetes的watch，這樣的話我們就能夠做一個(gè)非常好的適配。但是后來我們發(fā)現(xiàn)一個(gè)問題，原來你有可能10萬臺(tái)物理機(jī)，也就假設(shè)就是你的hostname的解析也就10萬個(gè)，現(xiàn)在不一樣了，一臺(tái)物理機(jī)是100多個(gè)容器，即你增長(zhǎng)了100倍。這時(shí)運(yùn)維解析的請(qǐng)求量會(huì)激增，增長(zhǎng)之后會(huì)帶來一個(gè)問題，抖動(dòng)、延遲都非常大，間接的就影響了你的業(yè)務(wù)的TP響應(yīng)。因此我們后來又把我們域名解析的服務(wù)，改成了DBTK的服務(wù)，現(xiàn)在的性能是bind9的19倍，是CoreOS的60多倍，每秒查詢率能沖到800萬QBS。

有人問，京東做一個(gè)這么大的Kubernetes集群，是不是特別復(fù)雜特別容易出錯(cuò)。確實(shí)，如果你的集群非常多，假設(shè)你有50個(gè)集群，那么你誤操作的概率可能就是這50的概率相加。因此京東會(huì)把整個(gè)Kubernetes的集群做減法，并沒有做加法，當(dāng)然這是代表京東的一家之言了，因?yàn)槲覀兪亲杂茫⒉皇峭赓u，所以我們主要是做減法，以適合我們使用。

為了適用上萬臺(tái)Server的這種規(guī)模，最大的問題就是API的負(fù)載容易崩潰。比如你把config-map存到etcd里面去，這個(gè)設(shè)計(jì)本身就是有問題的。如果你的規(guī)模比較大的話，一定要去改，如果不改，你的集群很快就會(huì)崩潰。其實(shí)我們的做法其實(shí)還比較傳統(tǒng)，就是采用一些緩存技術(shù)，就比如說config-map我們壓根是不會(huì)放在etcd里去的。因?yàn)槿绻惆裞onfig-map放到etcd里去的話，首先假設(shè)有一個(gè)用戶，給你傳一百個(gè)20M的配置文件，你就完蛋了。其次，京東對(duì)controller也做了很多重構(gòu)，雖然社區(qū)提供了很多controller，但我可以保證，這些controller絕對(duì)沒有做嚴(yán)格的關(guān)聯(lián)性測(cè)試，也就是說有些controller之間互相是有影響的。建議啟用任何一個(gè)controller前都要做嚴(yán)格的分析跟測(cè)試。想做大集群的Kubernetes，必須得去改，而且是做減法式的改。

還有一點(diǎn)，Kubernetes號(hào)稱有各式各類功能，我可能要潑一下冷水。京東很多東西的確是基于Kubernetes建設(shè)起來的，Kubernetes對(duì)我們的幫助非常大，但是它也不是萬能的。Kubernetes號(hào)稱的deployment、金絲雀發(fā)布等等一切都非常美好，但是我來自京東基礎(chǔ)架構(gòu)部門，基礎(chǔ)部門要服務(wù)業(yè)務(wù)，而業(yè)務(wù)會(huì)給你提很多需求，第一次你聽上去可能覺得這需求非常扯，但是你跟他仔細(xì)溝通之后，你會(huì)發(fā)現(xiàn)人家的需求是非常合理的。比如說，他說你金絲雀發(fā)布的時(shí)候，副本數(shù)隨機(jī)的挑幾個(gè)，升級(jí)了50%，但有的業(yè)務(wù)方會(huì)要求就要升級(jí)某一個(gè)特定IP。他不是對(duì)這個(gè)IP特別有感情，而是因?yàn)樗淞撕芏鄅ost，除了有研發(fā)還有測(cè)試等等，所以你不得不去面臨這個(gè)問題，像IP不變等等這樣的一些需求就會(huì)蹦出來，我們都要滿足他，才能繼續(xù)往下走。?

還有比如說你的節(jié)點(diǎn)被物理故障重啟等等，這個(gè)時(shí)候你要充分的考慮是先拉起新調(diào)度過來的容器，還是先拉起原來老的容器，這些策略都要針對(duì)你自己的業(yè)務(wù)去改變。

還有，比如有人說京東大促的時(shí)候，我們Kubenetes整個(gè)的彈性速度非常快等等。但是我可以向你保證，如果真正是那種流量高峰瞬間來的時(shí)候，這個(gè)彈性是絕對(duì)跟不上的。因?yàn)榈饶氵€沒彈完，老的已經(jīng)被打死了，彈幾個(gè)死幾個(gè)，所以一般來說，你要用更多的實(shí)例，用調(diào)度的方式來做，而不是說通過scale out這種彈來做，來不及的。

剛才也提到這些策略IP不變，還有我們這有一個(gè)很有意思的東西，就是支持容器的rebuild。我們的資源使用率，通過阿基米德調(diào)度之后，我們的資源使用率非常緊張，因?yàn)樯儋I了很多機(jī)器，同時(shí)業(yè)務(wù)又在不斷地增長(zhǎng)，這個(gè)時(shí)候我們資源的限額都會(huì)被耗盡，在某些情況下甚至調(diào)度器也無能為力。這怎么辦？我們采取了一種古老的方法，跳過調(diào)度器，進(jìn)行本地rebuild。因?yàn)槟愕恼{(diào)度有的在排隊(duì)，有的depending，但是有一些業(yè)務(wù)在發(fā)布的時(shí)候，他會(huì)提出一個(gè)問題，我原來有100個(gè)容器，我發(fā)布完之后只剩80了，另外20個(gè)容器的資源被別的業(yè)務(wù)搶走了，這是不能接受的，所以我們也有了這種所謂的優(yōu)先rebuild，就是就地rebuild，這會(huì)帶來很多好處。?
這么做最明顯的一個(gè)好處，就是拉鏡像至少省了一些時(shí)間。還有一個(gè)明顯的好處是，雖然在數(shù)據(jù)中心依然很復(fù)雜，但當(dāng)業(yè)務(wù)部署在某一臺(tái)容器機(jī)器上之后，調(diào)用的依賴、調(diào)用數(shù)據(jù)庫(kù)的鏈路都是經(jīng)過了大量壓測(cè)的，已達(dá)到相對(duì)最優(yōu)的狀態(tài)。如果你今天把這容器從pod1搬到pod2，我說物理pod，從房間1搬到房間2去了，那可能會(huì)帶來抖動(dòng)或者等等情況。當(dāng)然這并不代表你損失了Kubernetes的很多特性。

補(bǔ)充前面的一點(diǎn)，我們的deployment做了大量定制，原生的deployment其實(shí)還是很難滿足這樣的要求。比如說在線上，因?yàn)槭敲嫦蛏a(chǎn)環(huán)境，但是生產(chǎn)環(huán)境不會(huì)那么美好。首先業(yè)務(wù)，可能上100個(gè)容器就有兩個(gè)容器，它的響應(yīng)很差，這個(gè)時(shí)候要去排查或者要去進(jìn)行其他的操作，這個(gè)時(shí)候用deployment做不到，因?yàn)橐簧?jí)就沒了。而我們，讓它可以指定把這兩個(gè)停掉，或者是其他操作，反正就是能夠指定，就相當(dāng)于你要改一些東西，改動(dòng)量不大，只是在它原來基礎(chǔ)之上改。

下面說說我們目前的工作重點(diǎn)。京東整個(gè)數(shù)據(jù)中心規(guī)模很大，有老有新，整體的資源使用率會(huì)有明顯的波峰波谷。比如上圖黑底圖上藍(lán)色的線，1點(diǎn)到6點(diǎn)時(shí)中國(guó)整個(gè)互聯(lián)網(wǎng)的流量都比較低，但是到8點(diǎn)以后流量就開始逐漸攀升。那么1點(diǎn)到6點(diǎn)是一個(gè)非常浪費(fèi)的階段，因?yàn)槲覀冇写罅康挠?jì)算資源，這時(shí)候我們就可以跟大數(shù)據(jù)產(chǎn)生互補(bǔ)，把在線應(yīng)用的波谷算力貢獻(xiàn)給大數(shù)據(jù)做離線計(jì)算，剛好大數(shù)據(jù)也是后半夜，相對(duì)來說離線任務(wù)更多，因?yàn)榈诙煸缟弦鰣?bào)表，于是我們做了一個(gè)融合的混合部署的項(xiàng)目，就叫阿基米德，就是把大數(shù)據(jù)的業(yè)務(wù)給調(diào)到在線業(yè)務(wù)的平臺(tái)上去。這里面就涉及到一個(gè)問題，就是隔離性。大家都覺得Docker的隔離性已經(jīng)很優(yōu)秀了，其實(shí)并非如此，它的隔離性沒有大家想象的那么好，你看到的隔離都是Namespace的隔離，真正的性能隔離其實(shí)并沒有完全做到位。例如內(nèi)存回收，它其實(shí)是操作系統(tǒng)統(tǒng)一進(jìn)行回收的。比如上面10個(gè)容器有5個(gè)容器狂讀小文件，這時(shí)候突然內(nèi)存已經(jīng)到一定閥值了，它就要做一次slab回收。一旦slab回收，它就都被block住了，其他的在線業(yè)務(wù)都會(huì)被卡住，雖然只是毫秒級(jí)的，但是會(huì)有毛刺，業(yè)務(wù)就會(huì)來問你發(fā)生了什么。特別是在線大數(shù)據(jù)進(jìn)來之后，這個(gè)問題就會(huì)被無限放大，因此在這塊你要做適當(dāng)?shù)母膭?dòng)。京東做得比較早，從2013年就開始做容器，在過去幾年我們?cè)谶@塊已經(jīng)做了很多工作。?
還有另外一個(gè)，大家也都感同身受。業(yè)務(wù)說我需要100個(gè)容器，每個(gè)容器八個(gè)核，其實(shí)之后發(fā)現(xiàn)每個(gè)容器只跑了不到10%的CPU，這種情況是有可能的。那怎么辦？你不能粗暴地只給業(yè)務(wù)兩個(gè)核，出問題誰負(fù)責(zé)？那怎么辦？我們就告訴業(yè)務(wù)我們給了他八個(gè)核（其實(shí)沒有），只要不出事就行了，出了事解釋也無用。這會(huì)帶來一個(gè)巨大的收益，就像上圖，綠色的部分是我們給的CPU，紅色是實(shí)際使用的，那我們至少給他砍一半。這樣做了之后你就會(huì)發(fā)現(xiàn)，即使一年不買機(jī)器，機(jī)器也是夠的。

調(diào)度方面的問題，京東整個(gè)數(shù)據(jù)中心都是用Kubenretes來管，我們?nèi)∶麨镴DOS，即JD Datacenter OS，封包了Kubernetes然后做了大量的定制。往上層看，JDOS支持京東的在線業(yè)務(wù)。在線業(yè)務(wù)在2016年6·18之前全部遷完了。然后2017年雙十一的時(shí)候數(shù)據(jù)庫(kù)全部都遷完了，到2018年初的時(shí)候，我們基本上像中間件類的也都大部分遷上來了，也就是說現(xiàn)在我們除了單純的存儲(chǔ)圖片，還在用物理機(jī)那種存儲(chǔ)型的服務(wù)器之外，剩下的全在容器上，現(xiàn)在京東已經(jīng)看不到物理機(jī)了。現(xiàn)在正在做的就是把大數(shù)據(jù)也往上面導(dǎo)。這會(huì)帶來一個(gè)非常好的收益。

但是把大數(shù)據(jù)及很多其他業(yè)務(wù)放上JDOS之后我們發(fā)現(xiàn)，整個(gè)調(diào)度變得非常復(fù)雜，原來的調(diào)度器只是考慮哪一臺(tái)適合放就可以了，用一句話說，它只負(fù)責(zé)殺，不負(fù)責(zé)埋。這會(huì)帶來一個(gè)問題，容器運(yùn)行之后，帶來的影響Kubernetes是無能為力的，除非崩潰了，它給你再重新拉副本等等。這看上去會(huì)很美好，實(shí)際上業(yè)務(wù)會(huì)天天投訴你。為解決這一問題，我們應(yīng)用上線的時(shí)候會(huì)要選優(yōu)先級(jí)，如果你的優(yōu)先級(jí)不高的話，有可能會(huì)被優(yōu)先級(jí)高的驅(qū)逐掉，相當(dāng)于我們多帶帶對(duì)Kubernetes重新做一個(gè)東西，即我們的驅(qū)逐器。驅(qū)逐器會(huì)對(duì)pod打上很多標(biāo)簽，比如優(yōu)先級(jí)、容忍度、副本數(shù)等等（例如只有一個(gè)副本的話，它優(yōu)先級(jí)再低也不能殺）。這很像OM的排序，當(dāng)宿主機(jī)的CPU、內(nèi)存load達(dá)到一定上限的時(shí)候，我們就會(huì)啟動(dòng)這種排序，很快地把它排出來，立馬就驅(qū)逐，而且驅(qū)逐之后，會(huì)告訴調(diào)度器不要再往這臺(tái)上調(diào)了。因?yàn)橛锌赡苜Y源滿了，它又給調(diào)回來了，你又給驅(qū)逐，就形成一個(gè)死循環(huán)了。其實(shí)基本的理念也非常簡(jiǎn)單，就是保障優(yōu)先級(jí)的系統(tǒng)，大數(shù)據(jù)是最先優(yōu)先級(jí)，但是在線業(yè)務(wù)的話，也要往下放，這樣就能在有限資源的情況下發(fā)揮最大的作用，特別是大促的時(shí)候，如果都是靠買機(jī)器來支撐的話，這是非常恐怖的一件事情。因?yàn)槊看未蟠傥覀兌家?0倍來估，這要買多少機(jī)器啊。

最后我想分享一些經(jīng)驗(yàn)與心得體會(huì)。京東最早是Openstack，在2016年切換到了Kubernetes，這兩種系統(tǒng)我一直做下來的，我的感受就是， Kubernetes正在往Openstack這條路上走，越做越龐大，這是一個(gè)非常大的問題。誠(chéng)然，它有很多feature要加，這個(gè)也可以理解，可它還是得拆，拆成非常小的模塊來做。像現(xiàn)在CNI、CRI、CSI這些模塊的拆離應(yīng)該是比較好的一個(gè)開始。Kubernetes在中小規(guī)模集群是沒有問題的，但是它肯定沒有官方號(hào)稱的那樣5000臺(tái)沒問題，如果是非常大的規(guī)模的話，肯定要去改，否則的話會(huì)崩潰。我們?cè)谠缙诘臅r(shí)候，上了一些非重要的系統(tǒng)，經(jīng)歷了非常痛苦的一段時(shí)間，它時(shí)常崩掉了。?

有時(shí)候Etcd跑著跑著就發(fā)現(xiàn)版本差異越來越大，那只能把另外兩個(gè)干掉，把另外一個(gè)副本用來復(fù)制另外兩份，這會(huì)帶來巨大的問題。Etcd的運(yùn)維現(xiàn)在應(yīng)該沒有特別成熟的一些方案，它不像數(shù)據(jù)庫(kù)有很成熟的運(yùn)維方案，畢竟數(shù)據(jù)放在里面，如果它崩了，數(shù)據(jù)就很難找回來，這是非常麻煩的一件事。

還有它的API，因?yàn)樗情L(zhǎng)鏈接，一般的負(fù)載均衡要特別注意起API的時(shí)候不能一個(gè)一個(gè)起，起完了它都來連，搞不好都堆到一臺(tái)上去了，會(huì)導(dǎo)致負(fù)載不均衡，所以正常來說要先把API起好，再去起Kubernetes，這樣負(fù)載均衡才會(huì)起到作用。

另外，大家一定要特別注意Kubernetes對(duì)心跳的判斷，因?yàn)樗l(fā)生not ready的概率太高了。一旦發(fā)生節(jié)點(diǎn)not ready的話，會(huì)產(chǎn)生一系列難以預(yù)料的狀態(tài)，比如網(wǎng)絡(luò)抖動(dòng)，某臺(tái)交換機(jī)壞了，有可能它就會(huì)這樣。所以我們建議心跳檢測(cè)這一塊盡量用另外一套系統(tǒng)來做，把你檢測(cè)的結(jié)果反饋給Kubernetes，這樣可能會(huì)更好一些。

這就是我今天演講，謝謝大家。