在過去一年里隆夯，Kubernetes以其架構簡潔性和靈活性，流行度持續(xù)快速上升炼彪，我們有理由相信在不遠的未來，Kubernetes將成為通用的基礎設施標準正歼。而京東早在2016年年底上線了京東新一代容器引擎平臺JDOS2.0辐马，成功從Openstack切換到JDOS2.0的Kubernetes技術棧，打造了完整高效的PaaS平臺局义。
6月28日京東基礎架構部技術總監(jiān)喜爷、集群技術部負責人鮑永成受邀出席了Rancher Labs舉辦的Container Day 2018容器技術大會，并做了題為《京東如何打造kubernetes全球最大集群支撐萬億電商交易》的主題演講萄唇，本文根據(jù)演講內容整理而成檩帐。
鮑永成，2013年加入京東另萤，負責京東容器平臺JDOS研發(fā)工作湃密，帶領團隊完成京東容器大規(guī)模落地戰(zhàn)略，全量承載京東全部在線系統(tǒng)仲墨、中間件勾缭、數(shù)據(jù)庫以及大數(shù)據(jù)離線計算任務。目前聚焦在京東JDOS2.0目养、阿基米德調度平臺（特別搶占式智能數(shù)據(jù)中心調度系統(tǒng)俩由、京東大幅提升數(shù)據(jù)中心資源使用率的利器）、“云+端”線下門店生態(tài)基礎設施以及新一代數(shù)據(jù)中心研發(fā)工作癌蚁。
在演講中鮑永成分享了京東在大規(guī)模實際生產過程對Kubernetes做深入重構的經驗幻梯，以及京東如何圍繞K8s啟動一些內部新項目，服務JDOS2.0大規(guī)模生產環(huán)境穩(wěn)定高效運行努释。
感謝Rancher邀請我們來做京東在容器方面的分享碘梢。京東的分享可能跟業(yè)內的很多做向外輸出的公司有點不一樣，我們的容器主要是自用伐蒂。京東的數(shù)據(jù)中心現(xiàn)在規(guī)模已經比較大煞躬，實際上我們用Kubernetes或者是以前用Openstack的思路完全是克隆谷歌數(shù)據(jù)中心管理的理念。
容器生態(tài)建設
其實數(shù)據(jù)中心就是圍繞著幾個東西來說：服務器逸邦、網(wǎng)絡以及一些基礎軟件恩沛，剩下的就是集群的管理。這里要說明一下缕减，我們認為基礎軟件是數(shù)據(jù)中心非常重要的一個環(huán)節(jié)雷客，比如，域名解析桥狡、負載均衡搅裙、時鐘這些東西皱卓，雖然Kubernetes管理了整個集群，但是這些東西它依然沒有部逮。也就是說娜汁，要是想把它用得非常好的話，這些軟件也要進行一些適當?shù)淖兏铩?/p>
京東在使用Kubernetes管理大數(shù)據(jù)中心的時候甥啄，也圍繞著Kubernetes在我們內部的數(shù)據(jù)中心建了很多生態(tài)存炮。首先是適合容器化的DNS，以及適合容器化的負載均衡蜈漓，還有適合容器化的文件系統(tǒng)穆桂、鏡像中心等等。這里面特別要說明一點融虽，就是DNS跟LB享完，Kubernetes 1.9合入了高性能的負載均衡。如果在大規(guī)模生產環(huán)境中有额，高性能的負載均衡是必不可少的般又，但這個負載均衡又涉及到另外一些問題。首先巍佑，要跟現(xiàn)有的數(shù)據(jù)中心適配茴迁，京東自主研發(fā)了一套負載均衡以及DNS。雖然社區(qū)里有CoreDNS等等萤衰，但是這些DNS存在一個問題堕义，就像昨天某廠的一個故障那樣，你把所有的東西這個引導這個脆栋，那個引導那個倦卖。如果你的DNS不在容器內的話，帶來的后果是很難料想的椿争。因為京東容器已經發(fā)展了很多年怕膛，數(shù)據(jù)中心也比較大，我們單個Kubernetes集群能夠做到8000到10000臺秦踪。因為我們的機器實在太多褐捻，如果不做大集群的話，人力管理的投入上會非常大椅邓。后面我會解釋怎么做到這么大規(guī)模的集群舍扰。
京東容器化的數(shù)據(jù)中心建設已經四五年了，已經比較穩(wěn)定了希坚，雖然我們的Kubernetes還比較老，是1.6版本陵且，但是我們已經有很多改進，我們現(xiàn)在的重點就是往阿基米德物喷，也就是往數(shù)據(jù)中心的資源調度這個方向發(fā)展靠粪。去年雙十一的時候阿基米德已經上線了，Kubernetes使用到后期的時候茬底，你會發(fā)現(xiàn)Kubernetes并不能解決數(shù)據(jù)中心資源使用率的問題，它其實僅僅解決了你的發(fā)布获洲，或者是管理資源的容器這方面的一些東西阱表。
上圖是我們數(shù)據(jù)中心的基礎架構，其實比較傳統(tǒng)贡珊，我們會把負載均衡最爬、域名，以及我們包的這個Kubernetes的API統(tǒng)一抽象出來门岔，整個就是一套爱致。然后在每個數(shù)據(jù)中心部署若干套Kubernetes集群，每一個Kubernetes集群寒随，會管理三個物理Pod糠悯，大概是一萬臺的規(guī)模。
為了配合這個規(guī)模妻往，我們做了一些工作互艾。DNS最早的時候，還沒有CoreDNS來適配讯泣，大家知道每個數(shù)據(jù)中心最老的DNS是bind9纫普，適配起來是非常痛苦的，它缺API判帮，缺很多東西局嘁。所以我們就自己研發(fā)了一套基于Etcd的分布式DNS，當時提供了RestfulAPI晦墙，直接對接的Kubernetes的watch悦昵，這樣的話我們就能夠做一個非常好的適配。但是后來我們發(fā)現(xiàn)一個問題晌畅，原來你有可能10萬臺物理機但指，也就假設就是你的hostname的解析也就10萬個，現(xiàn)在不一樣了抗楔，一臺物理機是100多個容器棋凳，即你增長了100倍。這時運維解析的請求量會激增连躏，增長之后會帶來一個問題剩岳，抖動、延遲都非常大入热，間接的就影響了你的業(yè)務的TP響應拍棕。因此我們后來又把我們域名解析的服務晓铆，改成了DBTK的服務，現(xiàn)在的性能是bind9的19倍绰播，是CoreOS的60多倍骄噪，每秒查詢率能沖到800萬QBS。
化繁為簡Kubernetes重構
有人問蠢箩，京東做一個這么大的Kubernetes集群链蕊，是不是特別復雜特別容易出錯。確實谬泌，如果你的集群非常多滔韵，假設你有50個集群，那么你誤操作的概率可能就是這50的概率相加呵萨。因此京東會把整個Kubernetes的集群做減法奏属，并沒有做加法，當然這是代表京東的一家之言了潮峦，因為我們是自用囱皿，并不是往外賣，所以我們主要是做減法忱嘹，以適合我們使用嘱腥。
為了適用上萬臺Server的這種規(guī)模，最大的問題就是API的負載容易崩潰拘悦。比如你把config-map存到etcd里面去齿兔，這個設計本身就是有問題的。如果你的規(guī)模比較大的話础米，一定要去改分苇，如果不改，你的集群很快就會崩潰屁桑。其實我們的做法其實還比較傳統(tǒng)医寿，就是采用一些緩存技術，就比如說config-map我們壓根是不會放在etcd里去的蘑斧。因為如果你把config-map放到etcd里去的話靖秩，首先假設有一個用戶，給你傳一百個20M的配置文件竖瘾，你就完蛋了沟突。其次，京東對controller也做了很多重構捕传，雖然社區(qū)提供了很多controller惠拭，但我可以保證，這些controller絕對沒有做嚴格的關聯(lián)性測試庸论，也就是說有些controller之間互相是有影響的求橄。建議啟用任何一個controller前都要做嚴格的分析跟測試今野。想做大集群的Kubernetes，必須得去改罐农，而且是做減法式的改。
還有一點催什，Kubernetes號稱有各式各類功能涵亏，我可能要潑一下冷水。京東很多東西的確是基于Kubernetes建設起來的蒲凶，Kubernetes對我們的幫助非常大气筋，但是它也不是萬能的。Kubernetes號稱的deployment旋圆、金絲雀發(fā)布等等一切都非常美好宠默，但是我來自京東基礎架構部門，基礎部門要服務業(yè)務灵巧，而業(yè)務會給你提很多需求搀矫，第一次你聽上去可能覺得這需求非常扯，但是你跟他仔細溝通之后刻肄，你會發(fā)現(xiàn)人家的需求是非常合理的瓤球。比如說，他說你金絲雀發(fā)布的時候敏弃，副本數(shù)隨機的挑幾個卦羡，升級了50%，但有的業(yè)務方會要求就要升級某一個特定IP麦到。他不是對這個IP特別有感情绿饵，而是因為他配了很多host，除了有研發(fā)還有測試等等瓶颠，所以你不得不去面臨這個問題拟赊，像IP不變等等這樣的一些需求就會蹦出來，我們都要滿足他步清，才能繼續(xù)往下走要门。
還有比如說你的節(jié)點被物理故障重啟等等，這個時候你要充分的考慮是先拉起新調度過來的容器廓啊，還是先拉起原來老的容器欢搜，這些策略都要針對你自己的業(yè)務去改變。
還有谴轮，比如有人說京東大促的時候炒瘟，我們Kubenetes整個的彈性速度非常快等等第步。但是我可以向你保證疮装，如果真正是那種流量高峰瞬間來的時候缘琅，這個彈性是絕對跟不上的。因為等你還沒彈完廓推，老的已經被打死了刷袍，彈幾個死幾個，所以一般來說樊展，你要用更多的實例呻纹，用調度的方式來做，而不是說通過scale out這種彈來做专缠，來不及的雷酪。
剛才也提到這些策略IP不變，還有我們這有一個很有意思的東西涝婉，就是支持容器的rebuild哥力。我們的資源使用率，通過阿基米德調度之后墩弯，我們的資源使用率非常緊張吩跋，因為少買了很多機器，同時業(yè)務又在不斷地增長最住，這個時候我們資源的限額都會被耗盡钞澳，在某些情況下甚至調度器也無能為力。這怎么辦涨缚？我們采取了一種古老的方法轧粟，跳過調度器，進行本地rebuild脓魏。因為你的調度有的在排隊兰吟，有的depending，但是有一些業(yè)務在發(fā)布的時候茂翔，他會提出一個問題混蔼，我原來有100個容器，我發(fā)布完之后只剩80了珊燎，另外20個容器的資源被別的業(yè)務搶走了惭嚣，這是不能接受的，所以我們也有了這種所謂的優(yōu)先rebuild悔政，就是就地rebuild晚吞，這會帶來很多好處。
這么做最明顯的一個好處谋国，就是拉鏡像至少省了一些時間槽地。還有一個明顯的好處是，雖然在數(shù)據(jù)中心依然很復雜，但當業(yè)務部署在某一臺容器機器上之后捌蚊，調用的依賴集畅、調用數(shù)據(jù)庫的鏈路都是經過了大量壓測的，已達到相對最優(yōu)的狀態(tài)缅糟。如果你今天把這容器從pod1搬到pod2挺智，我說物理pod，從房間1搬到房間2去了溺拱，那可能會帶來抖動或者等等情況逃贝。當然這并不代表你損失了Kubernetes的很多特性。
補充前面的一點迫摔，我們的deployment做了大量定制，原生的deployment其實還是很難滿足這樣的要求泥从。比如說在線上句占，因為是面向生產環(huán)境，但是生產環(huán)境不會那么美好躯嫉。首先業(yè)務纱烘，可能上100個容器就有兩個容器，它的響應很差祈餐，這個時候要去排查或者要去進行其他的操作擂啥，這個時候用deployment做不到，因為一升級就沒了帆阳。而我們哺壶，讓它可以指定把這兩個停掉，或者是其他操作蜒谤，反正就是能夠指定山宾，就相當于你要改一些東西，改動量不大鳍徽，只是在它原來基礎之上改资锰。
阿基米德調度器
下面說說我們目前的工作重點。京東整個數(shù)據(jù)中心規(guī)模很大阶祭，有老有新绷杜，整體的資源使用率會有明顯的波峰波谷。比如上圖黑底圖上藍色的線濒募，1點到6點時中國整個互聯(lián)網(wǎng)的流量都比較低鞭盟，但是到8點以后流量就開始逐漸攀升。那么1點到6點是一個非常浪費的階段萨咳，因為我們有大量的計算資源懊缺，這時候我們就可以跟大數(shù)據(jù)產生互補，把在線應用的波谷算力貢獻給大數(shù)據(jù)做離線計算，剛好大數(shù)據(jù)也是后半夜鹃两，相對來說離線任務更多遗座，因為第二天早上要出報表，于是我們做了一個融合的混合部署的項目俊扳，就叫阿基米德途蒋，就是把大數(shù)據(jù)的業(yè)務給調到在線業(yè)務的平臺上去。這里面就涉及到一個問題馋记，就是隔離性号坡。大家都覺得Docker的隔離性已經很優(yōu)秀了，其實并非如此梯醒，它的隔離性沒有大家想象的那么好宽堆，你看到的隔離都是Namespace的隔離，真正的性能隔離其實并沒有完全做到位茸习。例如內存回收畜隶，它其實是操作系統(tǒng)統(tǒng)一進行回收的。比如上面10個容器有5個容器狂讀小文件号胚，這時候突然內存已經到一定閥值了籽慢，它就要做一次slab回收。一旦slab回收猫胁，它就都被block住了箱亿，其他的在線業(yè)務都會被卡住，雖然只是毫秒級的弃秆，但是會有毛刺届惋，業(yè)務就會來問你發(fā)生了什么。特別是在線大數(shù)據(jù)進來之后驾茴，這個問題就會被無限放大盼樟，因此在這塊你要做適當?shù)母膭印＞〇|做得比較早锈至，從2013年就開始做容器晨缴，在過去幾年我們在這塊已經做了很多工作。
還有另外一個峡捡，大家也都感同身受击碗。業(yè)務說我需要100個容器，每個容器八個核们拙，其實之后發(fā)現(xiàn)每個容器只跑了不到10%的CPU稍途，這種情況是有可能的。那怎么辦砚婆？你不能粗暴地只給業(yè)務兩個核械拍，出問題誰負責突勇？那怎么辦？我們就告訴業(yè)務我們給了他八個核（其實沒有）坷虑，只要不出事就行了甲馋，出了事解釋也無用。這會帶來一個巨大的收益迄损，就像上圖定躏，綠色的部分是我們給的CPU，紅色是實際使用的芹敌，那我們至少給他砍一半痊远。這樣做了之后你就會發(fā)現(xiàn)，即使一年不買機器氏捞，機器也是夠的碧聪。
調度方面的問題，京東整個數(shù)據(jù)中心都是用Kubenretes來管液茎，我們取名為JDOS矾削，即JD Datacenter OS，封包了Kubernetes然后做了大量的定制豁护。往上層看，JDOS支持京東的在線業(yè)務欲间。在線業(yè)務在2016年6·18之前全部遷完了楚里。然后2017年雙十一的時候數(shù)據(jù)庫全部都遷完了，到2018年初的時候猎贴，我們基本上像中間件類的也都大部分遷上來了班缎，也就是說現(xiàn)在我們除了單純的存儲圖片，還在用物理機那種存儲型的服務器之外她渴，剩下的全在容器上达址，現(xiàn)在京東已經看不到物理機了。現(xiàn)在正在做的就是把大數(shù)據(jù)也往上面導趁耗。這會帶來一個非常好的收益沉唠。
但是把大數(shù)據(jù)及很多其他業(yè)務放上JDOS之后我們發(fā)現(xiàn)，整個調度變得非常復雜苛败，原來的調度器只是考慮哪一臺適合放就可以了满葛，用一句話說，它只負責殺罢屈，不負責埋嘀韧。這會帶來一個問題，容器運行之后缠捌，帶來的影響Kubernetes是無能為力的锄贷，除非崩潰了，它給你再重新拉副本等等。這看上去會很美好谊却，實際上業(yè)務會天天投訴你柔昼。為解決這一問題，我們應用上線的時候會要選優(yōu)先級因惭，如果你的優(yōu)先級不高的話岳锁，有可能會被優(yōu)先級高的驅逐掉，相當于我們單獨對Kubernetes重新做一個東西蹦魔，即我們的驅逐器激率。驅逐器會對pod打上很多標簽，比如優(yōu)先級勿决、容忍度乒躺、副本數(shù)等等（例如只有一個副本的話，它優(yōu)先級再低也不能殺）低缩。這很像OM的排序嘉冒，當宿主機的CPU、內存load達到一定上限的時候咆繁，我們就會啟動這種排序讳推，很快地把它排出來，立馬就驅逐玩般，而且驅逐之后银觅，會告訴調度器不要再往這臺上調了。因為有可能資源滿了坏为，它又給調回來了究驴，你又給驅逐，就形成一個死循環(huán)了匀伏。其實基本的理念也非常簡單洒忧，就是保障優(yōu)先級的系統(tǒng)，大數(shù)據(jù)是最先優(yōu)先級够颠，但是在線業(yè)務的話熙侍，也要往下放，這樣就能在有限資源的情況下發(fā)揮最大的作用摧找，特別是大促的時候核行，如果都是靠買機器來支撐的話，這是非车旁牛恐怖的一件事情芝雪。因為每次大促我們都要按20倍來估，這要買多少機器啊综苔。
總 結
最后我想分享一些經驗與心得體會惩系。京東最早是Openstack位岔，在2016年切換到了Kubernetes，這兩種系統(tǒng)我一直做下來的堡牡，我的感受就是抒抬， Kubernetes正在往Openstack這條路上走，越做越龐大晤柄，這是一個非常大的問題擦剑。誠然，它有很多feature要加芥颈，這個也可以理解惠勒，可它還是得拆，拆成非常小的模塊來做爬坑。像現(xiàn)在CNI纠屋、CRI、CSI這些模塊的拆離應該是比較好的一個開始盾计。Kubernetes在中小規(guī)模集群是沒有問題的售担，但是它肯定沒有官方號稱的那樣5000臺沒問題，如果是非常大的規(guī)模的話署辉，肯定要去改族铆，否則的話會崩潰。我們在早期的時候哭尝，上了一些非重要的系統(tǒng)骑素，經歷了非常痛苦的一段時間，它時常崩掉了刚夺。
有時候Etcd跑著跑著就發(fā)現(xiàn)版本差異越來越大，那只能把另外兩個干掉末捣，把另外一個副本用來復制另外兩份侠姑，這會帶來巨大的問題。Etcd的運維現(xiàn)在應該沒有特別成熟的一些方案箩做，它不像數(shù)據(jù)庫有很成熟的運維方案莽红，畢竟數(shù)據(jù)放在里面，如果它崩了邦邦，數(shù)據(jù)就很難找回來安吁，這是非常麻煩的一件事。
還有它的API燃辖，因為它是長鏈接鬼店，一般的負載均衡要特別注意起API的時候不能一個一個起，起完了它都來連黔龟，搞不好都堆到一臺上去了妇智，會導致負載不均衡滥玷，所以正常來說要先把API起好，再去起Kubernetes巍棱，這樣負載均衡才會起到作用惑畴。
另外，大家一定要特別注意Kubernetes對心跳的判斷航徙，因為它發(fā)生not ready的概率太高了如贷。一旦發(fā)生節(jié)點not ready的話，會產生一系列難以預料的狀態(tài)到踏，比如網(wǎng)絡抖動杠袱，某臺交換機壞了，有可能它就會這樣夭禽。所以我們建議心跳檢測這一塊盡量用另外一套系統(tǒng)來做霞掺，把你檢測的結果反饋給Kubernetes，這樣可能會更好一些讹躯。
這就是我今天演講菩彬，謝謝大家。
