<code id="ymukc"><xmp id="ymukc">

京東如何打造K8s全球最大集群支撐萬億電商交易

京東 K8s   2018-07-22 22:19:06 發布
您的評價:
     
0.0
收藏     0收藏
文件夾
標簽
(多個標簽用逗號分隔)

在過去一年里,Kubernetes以其架構簡潔性和靈活性,流行度持續快速上升,我們有理由相信在不遠的未來,Kubernetes將成為通用的基礎設施標準。而京東早在2016年年底上線了京東新一代容器引擎平臺JDOS2.0,成功從Openstack切換到JDOS2.0的Kubernetes技術棧,打造了完整高效的PaaS平臺。

6月28日京東基礎架構部技術總監、集群技術部負責人鮑永成受邀出席了Rancher Labs舉辦的Container Day 2018容器技術大會,并做了題為《京東如何打造kubernetes全球最大集群支撐萬億電商交易》的主題演講,本文根據演講內容整理而成。

鮑永成,2013年加入京東,負責京東容器平臺JDOS研發工作,帶領團隊完成京東容器大規模落地戰略,全量承載京東全部在線系統、中間件、數據庫以及大數據離線計算任務。目前聚焦在京東JDOS2.0、阿基米德調度平臺(特別搶占式智能數據中心調度系統、京東大幅提升數據中心資源使用率的利器)、“云+端”線下門店生態基礎設施以及新一代數據中心研發工作。

在演講中鮑永成分享了京東在大規模實際生產過程對Kubernetes做深入重構的經驗,以及京東如何圍繞K8s啟動一些內部新項目,服務JDOS2.0大規模生產環境穩定高效運行。

感謝Rancher邀請我們來做京東在容器方面的分享。京東的分享可能跟業內的很多做向外輸出的公司有點不一樣,我們的容器主要是自用。京東的數據中心現在規模已經比較大,實際上我們用Kubernetes或者是以前用Openstack的思路完全是克隆谷歌數據中心管理的理念。

容器生態建設

其實數據中心就是圍繞著幾個東西來說:服務器、網絡以及一些基礎軟件,剩下的就是集群的管理。這里要說明一下,我們認為基礎軟件是數據中心非常重要的一個環節,比如,域名解析、負載均衡、時鐘這些東西,雖然Kubernetes管理了整個集群,但是這些東西它依然沒有。也就是說,要是想把它用得非常好的話,這些軟件也要進行一些適當的變革。

京東在使用Kubernetes管理大數據中心的時候,也圍繞著Kubernetes在我們內部的數據中心建了很多生態。首先是適合容器化的DNS,以及適合容器化的負載均衡,還有適合容器化的文件系統、鏡像中心等等。這里面特別要說明一點,就是DNS跟LB,Kubernetes 1.9合入了高性能的負載均衡。如果在大規模生產環境中,高性能的負載均衡是必不可少的,但這個負載均衡又涉及到另外一些問題。首先,要跟現有的數據中心適配,京東自主研發了一套負載均衡以及DNS。雖然社區里有CoreDNS等等,但是這些DNS存在一個問題,就像昨天某廠的一個故障那樣,你把所有的東西這個引導這個,那個引導那個。如果你的DNS不在容器內的話,帶來的后果是很難料想的。因為京東容器已經發展了很多年,數據中心也比較大,我們單個Kubernetes集群能夠做到8000到10000臺。因為我們的機器實在太多,如果不做大集群的話,人力管理的投入上會非常大。后面我會解釋怎么做到這么大規模的集群。

京東容器化的數據中心建設已經四五年了,已經比較穩定了,雖然我們的Kubernetes還比較老,是1.6版本,但是我們已經有很多改進,我們現在的重點就是往阿基米德,也就是往數據中心的資源調度這個方向發展。去年雙十一的時候阿基米德已經上線了,Kubernetes使用到后期的時候,你會發現Kubernetes并不能解決數據中心資源使用率的問題,它其實僅僅解決了你的發布,或者是管理資源的容器這方面的一些東西。

上圖是我們數據中心的基礎架構,其實比較傳統,我們會把負載均衡、域名,以及我們包的這個Kubernetes的API統一抽象出來,整個就是一套。然后在每個數據中心部署若干套Kubernetes集群,每一個Kubernetes集群,會管理三個物理Pod,大概是一萬臺的規模。

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

化繁為簡Kubernetes重構

有人問,京東做一個這么大的Kubernetes集群,是不是特別復雜特別容易出錯。確實,如果你的集群非常多,假設你有50個集群,那么你誤操作的概率可能就是這50的概率相加。因此京東會把整個Kubernetes的集群做減法,并沒有做加法,當然這是代表京東的一家之言了,因為我們是自用,并不是往外賣,所以我們主要是做減法,以適合我們使用。

為了適用上萬臺Server的這種規模,最大的問題就是API的負載容易崩潰。比如你把config-map存到etcd里面去,這個設計本身就是有問題的。如果你的規模比較大的話,一定要去改,如果不改,你的集群很快就會崩潰。其實我們的做法其實還比較傳統,就是采用一些緩存技術,就比如說config-map我們壓根是不會放在etcd里去的。因為如果你把config-map放到etcd里去的話,首先假設有一個用戶,給你傳一百個20M的配置文件,你就完蛋了。其次,京東對controller也做了很多重構,雖然社區提供了很多controller,但我可以保證,這些controller絕對沒有做嚴格的關聯性測試,也就是說有些controller之間互相是有影響的。建議啟用任何一個controller前都要做嚴格的分析跟測試。想做大集群的Kubernetes,必須得去改,而且是做減法式的改。

還有一點,Kubernetes號稱有各式各類功能,我可能要潑一下冷水。京東很多東西的確是基于Kubernetes建設起來的,Kubernetes對我們的幫助非常大,但是它也不是萬能的。Kubernetes號稱的deployment、金絲雀發布等等一切都非常美好,但是我來自京東基礎架構部門,基礎部門要服務業務,而業務會給你提很多需求,第一次你聽上去可能覺得這需求非常扯,但是你跟他仔細溝通之后,你會發現人家的需求是非常合理的。比如說,他說你金絲雀發布的時候,副本數隨機的挑幾個,升級了50%,但有的業務方會要求就要升級某一個特定IP。他不是對這個IP特別有感情,而是因為他配了很多host,除了有研發還有測試等等,所以你不得不去面臨這個問題,像IP不變等等這樣的一些需求就會蹦出來,我們都要滿足他,才能繼續往下走。

還有比如說你的節點被物理故障重啟等等,這個時候你要充分的考慮是先拉起新調度過來的容器,還是先拉起原來老的容器,這些策略都要針對你自己的業務去改變。

還有,比如有人說京東大促的時候,我們Kubenetes整個的彈性速度非常快等等。但是我可以向你保證,如果真正是那種流量高峰瞬間來的時候,這個彈性是絕對跟不上的。因為等你還沒彈完,老的已經被打死了,彈幾個死幾個,所以一般來說,你要用更多的實例,用調度的方式來做,而不是說通過scale out這種彈來做,來不及的。

剛才也提到這些策略IP不變,還有我們這有一個很有意思的東西,就是支持容器的rebuild。我們的資源使用率,通過阿基米德調度之后,我們的資源使用率非常緊張,因為少買了很多機器,同時業務又在不斷地增長,這個時候我們資源的限額都會被耗盡,在某些情況下甚至調度器也無能為力。這怎么辦?我們采取了一種古老的方法,跳過調度器,進行本地rebuild。因為你的調度有的在排隊,有的depending,但是有一些業務在發布的時候,他會提出一個問題,我原來有100個容器,我發布完之后只剩80了,另外20個容器的資源被別的業務搶走了,這是不能接受的,所以我們也有了這種所謂的優先rebuild,就是就地rebuild,這會帶來很多好處。

這么做最明顯的一個好處,就是拉鏡像至少省了一些時間。還有一個明顯的好處是,雖然在數據中心依然很復雜,但當業務部署在某一臺容器機器上之后,調用的依賴、調用數據庫的鏈路都是經過了大量壓測的,已達到相對最優的狀態。如果你今天把這容器從pod1搬到pod2,我說物理pod,從房間1搬到房間2去了,那可能會帶來抖動或者等等情況。當然這并不代表你損失了Kubernetes的很多特性。

補充前面的一點,我們的deployment做了大量定制,原生的deployment其實還是很難滿足這樣的要求。比如說在線上,因為是面向生產環境,但是生產環境不會那么美好。首先業務,可能上100個容器就有兩個容器,它的響應很差,這個時候要去排查或者要去進行其他的操作,這個時候用deployment做不到,因為一升級就沒了。而我們,讓它可以指定把這兩個停掉,或者是其他操作,反正就是能夠指定,就相當于你要改一些東西,改動量不大,只是在它原來基礎之上改。

阿基米德調度器

下面說說我們目前的工作重點。京東整個數據中心規模很大,有老有新,整體的資源使用率會有明顯的波峰波谷。比如上圖黑底圖上藍色的線,1點到6點時中國整個互聯網的流量都比較低,但是到8點以后流量就開始逐漸攀升。那么1點到6點是一個非常浪費的階段,因為我們有大量的計算資源,這時候我們就可以跟大數據產生互補,把在線應用的波谷算力貢獻給大數據做離線計算,剛好大數據也是后半夜,相對來說離線任務更多,因為第二天早上要出報表,于是我們做了一個融合的混合部署的項目,就叫阿基米德,就是把大數據的業務給調到在線業務的平臺上去。這里面就涉及到一個問題,就是隔離性。大家都覺得Docker的隔離性已經很優秀了,其實并非如此,它的隔離性沒有大家想象的那么好,你看到的隔離都是Namespace的隔離,真正的性能隔離其實并沒有完全做到位。例如內存回收,它其實是操作系統統一進行回收的。比如上面10個容器有5個容器狂讀小文件,這時候突然內存已經到一定閥值了,它就要做一次slab回收。一旦slab回收,它就都被block住了,其他的在線業務都會被卡住,雖然只是毫秒級的,但是會有毛刺,業務就會來問你發生了什么。特別是在線大數據進來之后,這個問題就會被無限放大,因此在這塊你要做適當的改動。京東做得比較早,從2013年就開始做容器,在過去幾年我們在這塊已經做了很多工作。

還有另外一個,大家也都感同身受。業務說我需要100個容器,每個容器八個核,其實之后發現每個容器只跑了不到10%的CPU,這種情況是有可能的。那怎么辦?你不能粗暴地只給業務兩個核,出問題誰負責?那怎么辦?我們就告訴業務我們給了他八個核(其實沒有),只要不出事就行了,出了事解釋也無用。這會帶來一個巨大的收益,就像上圖,綠色的部分是我們給的CPU,紅色是實際使用的,那我們至少給他砍一半。這樣做了之后你就會發現,即使一年不買機器,機器也是夠的。

京東如何打造K8s全球最大集群支撐萬億電商交易

調度方面的問題,京東整個數據中心都是用Kubenretes來管,我們取名為JDOS,即JD Datacenter OS,封包了Kubernetes然后做了大量的定制。往上層看,JDOS支持京東的在線業務。在線業務在2016年6·18之前全部遷完了。然后2017年雙十一的時候數據庫全部都遷完了,到2018年初的時候,我們基本上像中間件類的也都大部分遷上來了,也就是說現在我們除了單純的存儲圖片,還在用物理機那種存儲型的服務器之外,剩下的全在容器上,現在京東已經看不到物理機了。現在正在做的就是把大數據也往上面導。這會帶來一個非常好的收益。

但是把大數據及很多其他業務放上JDOS之后我們發現,整個調度變得非常復雜,原來的調度器只是考慮哪一臺適合放就可以了,用一句話說,它只負責殺,不負責埋。這會帶來一個問題,容器運行之后,帶來的影響Kubernetes是無能為力的,除非崩潰了,它給你再重新拉副本等等。這看上去會很美好,實際上業務會天天投訴你。為解決這一問題,我們應用上線的時候會要選優先級,如果你的優先級不高的話,有可能會被優先級高的驅逐掉,相當于我們單獨對Kubernetes重新做一個東西,即我們的驅逐器。驅逐器會對pod打上很多標簽,比如優先級、容忍度、副本數等等(例如只有一個副本的話,它優先級再低也不能殺)。這很像OM的排序,當宿主機的CPU、內存load達到一定上限的時候,我們就會啟動這種排序,很快地把它排出來,立馬就驅逐,而且驅逐之后,會告訴調度器不要再往這臺上調了。因為有可能資源滿了,它又給調回來了,你又給驅逐,就形成一個死循環了。其實基本的理念也非常簡單,就是保障優先級的系統,大數據是最先優先級,但是在線業務的話,也要往下放,這樣就能在有限資源的情況下發揮最大的作用,特別是大促的時候,如果都是靠買機器來支撐的話,這是非常恐怖的一件事情。因為每次大促我們都要按20倍來估,這要買多少機器啊。

總 結

最后我想分享一些經驗與心得體會。京東最早是Openstack,在2016年切換到了Kubernetes,這兩種系統我一直做下來的,我的感受就是, Kubernetes正在往Openstack這條路上走,越做越龐大,這是一個非常大的問題。誠然,它有很多feature要加,這個也可以理解,可它還是得拆,拆成非常小的模塊來做。像現在CNI、CRI、CSI這些模塊的拆離應該是比較好的一個開始。Kubernetes在中小規模集群是沒有問題的,但是它肯定沒有官方號稱的那樣5000臺沒問題,如果是非常大的規模的話,肯定要去改,否則的話會崩潰。我們在早期的時候,上了一些非重要的系統,經歷了非常痛苦的一段時間,它時常崩掉了。

有時候Etcd跑著跑著就發現版本差異越來越大,那只能把另外兩個干掉,把另外一個副本用來復制另外兩份,這會帶來巨大的問題。Etcd的運維現在應該沒有特別成熟的一些方案,它不像數據庫有很成熟的運維方案,畢竟數據放在里面,如果它崩了,數據就很難找回來,這是非常麻煩的一件事。

還有它的API,因為它是長鏈接,一般的負載均衡要特別注意起API的時候不能一個一個起,起完了它都來連,搞不好都堆到一臺上去了,會導致負載不均衡,所以正常來說要先把API起好,再去起Kubernetes,這樣負載均衡才會起到作用。

另外,大家一定要特別注意Kubernetes對心跳的判斷,因為它發生not ready的概率太高了。一旦發生節點not ready的話,會產生一系列難以預料的狀態,比如網絡抖動,某臺交換機壞了,有可能它就會這樣。所以我們建議心跳檢測這一塊盡量用另外一套系統來做,把你檢測的結果反饋給Kubernetes,這樣可能會更好一些。

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

 

來自:http://dockone.io/article/7737

 

六合特码资料
<code id="ymukc"><xmp id="ymukc">
<code id="ymukc"><xmp id="ymukc">

擴展閱讀

京東DNN Lab首席科學家:用深度學習搞定80%的客服工作
構建高并發高可用的電商平臺架構大綱
構建高并發高可用的電商平臺架構大綱
構建高并發高可用的電商平臺架構大綱
京東咚咚架構演進

為您推薦

開源大數據處理系統/工具大全
Kubernetes 架構淺析
Docker,云時代的程序交付方式
容器服務如何在企業客戶落地?Rancher解決之道分享。
開源大數據處理工具匯總(下)

更多

京東
K8s
容器系統
相關文檔  — 更多
相關經驗  — 更多
相關討論  — 更多