Kubernetes在GitHub

責(zé)任編輯:editor004

作者:Jesse Newland

2017-08-22 11:08:53

摘自:INFOQ

在本項目的初期,我們做了一個慎重的決定,那就是將遷移的目標(biāo)設(shè)定為某個關(guān)鍵的負(fù)載:即github github。在構(gòu)建審查實驗室的過程中,我們交付了不少子項目,每個子項目都可以在各自單獨的博客文章中進(jìn)行介紹。

為增加本文的代入感,本譯文將以原作者第一稱視角闡述Jesse Newland的經(jīng)歷,請讀者知悉。

去年,GitHub已經(jīng)改進(jìn)了Ruby on Rails應(yīng)用的基礎(chǔ)設(shè)施,該應(yīng)用負(fù)責(zé)運行g(shù)ithub.com和api.github.com。最近我們實現(xiàn)了一個重要里程碑,即:所有Web和API請求都由Kubernetes集群中運行的容器來處理,這些集群都部署在了我們的metal云上。將一個重要的應(yīng)用遷移到Kubernetes是一個非常有趣的挑戰(zhàn),所以我們非常激動可以向你分享我們學(xué)到的東西。

為什么要改變?

在做出這次遷移之前,我們主要的Ruby on Rails應(yīng)用(我們稱之為github/github)的配置和它8年前沒什么兩樣:即由一個名叫God的Ruby進(jìn)程管理器管理著Unicorn(獨角獸)進(jìn)程,而該Ruby進(jìn)程管理器則運行在受Puppet管理的許多服務(wù)器上。類似地,chatops部署的工作方式和它剛被引入時差不多:即Capistrano與每個前端服務(wù)器建立SSH連接,然后更新代碼并重啟應(yīng)用進(jìn)程。當(dāng)峰值請求負(fù)載超過可用的前端CPU能力時,GitHub網(wǎng)站可靠性工程師會分配額外的能力并添加到有效的前端服務(wù)器池中。

雖然我們基本的生產(chǎn)方式這些年并未改變多少,但GitHub本身卻發(fā)生了巨大的變化,包括:新特性、更大的軟件社區(qū)、更多的GitHub用戶以及更高的每秒請求數(shù)。隨著我們不斷地發(fā)展,這一方式開始出現(xiàn)問題。許多團(tuán)隊希望將其負(fù)責(zé)的功能從這個龐大的應(yīng)用中提取到一個更小的服務(wù)中,以便該服務(wù)可以單獨運行或部署。隨著運行的服務(wù)量增大,網(wǎng)站可靠性工程師團(tuán)隊開始讓幾十個其它的應(yīng)用支持與前面提到的配置相類似的配置。這增加了我們在服務(wù)器維護(hù)、分配和其它工作上花費的時間,而這些工作與改善GitHub整體的體驗并無直接關(guān)系。新服務(wù)往往需要幾天、幾周甚至幾個月的時間來部署,這取決于其復(fù)雜程度和網(wǎng)站可靠性工程師團(tuán)隊是不是有空。隨著時間的推移,我們發(fā)現(xiàn),這一方式不能給工程師帶來足夠的靈活性,以使他們繼續(xù)打造世界級的服務(wù)。工程師們需要一個可以讓他們實驗、部署和擴(kuò)展新服務(wù)的自助服務(wù)平臺。同時我們也需要這樣的平臺來滿足核心Ruby on Rails應(yīng)用的需求,從而使工程師或機(jī)器人能在幾秒鐘之內(nèi)(而不是幾小時、幾周甚至更長時間)分配額外的計算資源,從而應(yīng)對需求上的變化。

為了應(yīng)對這些需求,網(wǎng)站可靠性工程師、平臺和開發(fā)者體驗團(tuán)隊啟動了一個共同的項目,在這個項目中,我們最開始只是對容器編排平臺進(jìn)行評估,而到今天,我們已取得這樣的成就,即:每天能將支撐github.com和api.github.com運行的代碼往Kubernetes集群部署幾十次。本文旨在概述一下這個過程中涉及的工作。

為什么是Kubernetes?

作為對“平臺即服務(wù)”工具當(dāng)前局勢評估的一部分,我們對Kubernetes做了近距離考查。Kubernetes是一個谷歌的項目,它自稱是一個開源的系統(tǒng),用來自動部署、擴(kuò)展和管理容器化的應(yīng)用。Kubernetes一些優(yōu)點使它從眾多平臺中脫穎而出,例如:支撐該項目的活躍的開源社區(qū)、首次運行的體驗(這使我們能夠在最初實驗的最初幾個小時內(nèi)部署小型的集群和應(yīng)用)、以及大量與刺激其設(shè)計的體驗有關(guān)的信息。

這些實驗的范圍迅速擴(kuò)大:我們組建了一個小項目,來構(gòu)建Kubernetes集群和部署工具,以便在接下來的黑客(hack)周獲得一些有關(guān)該平臺實際的體驗。我們在這個項目的體驗以及使用過它的工程師的反饋都極其正面。是時候?qū)嶒灁U(kuò)大了,所以我們開始計劃一個更大的上線活動。

為什么要從github/github開始?

在本項目的初期,我們做了一個慎重的決定,那就是將遷移的目標(biāo)設(shè)定為某個關(guān)鍵的負(fù)載:即github/github。許多因素促使我們做出這個決定,但其中尤為突出的是:

我們知道,貫穿GitHub深入了解這個應(yīng)用會對整個遷移過程有幫助。 我們需要自助服務(wù)容量擴(kuò)展工具來應(yīng)對持續(xù)性的增長。我們需要確保我們養(yǎng)成的習(xí)慣和模式不僅適合大型應(yīng)用,還同樣適合小規(guī)模服務(wù)。我們希望更好地讓應(yīng)用不受開發(fā)、過渡、生產(chǎn)、企業(yè)和其它環(huán)境的差異所影響。我們知道,成功遷移一個關(guān)鍵且高度引人注目的負(fù)載可以鼓勵在GitHub更大范圍地采用Kubernetes。

考慮到選擇遷移的負(fù)載的關(guān)鍵性,我們需要在引入任何生產(chǎn)流量之前,樹立高度的運營信心。

通過審查實驗室快速迭代和樹立信心

作為此次遷移的一部分,我們使用了如Pods、Deployments和Services之類的Kubernetes基本單元設(shè)計了目前前端服務(wù)器所提供的服務(wù)的替代品,制作了其原型并進(jìn)行了驗證。這個新設(shè)計的某些驗證可以通過在容器內(nèi)運行g(shù)ithub/github現(xiàn)有的測試套件完成,而不是在同前端服務(wù)器配置相似的服務(wù)器上完成。然而,我們?nèi)匀恍枰^察這個容器作為大量Kubernetes資源的一部分有怎樣的表現(xiàn)。很快我們就清楚發(fā)現(xiàn),我們必須得有一個環(huán)境,能夠支持對Kubernetes和我們要運行的服務(wù)進(jìn)行探索性測試。

大約在同一時間,我們發(fā)現(xiàn),現(xiàn)有的github/github pull request的探索性測試模式已經(jīng)開始出現(xiàn)痛點增長的跡象。隨著部署速度以及項目工作的工程師的數(shù)量的增加,使用幾個額外的部署環(huán)境來驗證向github/github發(fā)出pull request的頻率也在增加。通常,在峰值工作時間內(nèi),少量功能完備的部署環(huán)境已經(jīng)被預(yù)定了,這就減緩了部署pull request的過程。工程師經(jīng)常要求能夠在“分支實驗室”上測試更多的生產(chǎn)子系統(tǒng)。雖然分支實驗室允許許多工程師進(jìn)行并發(fā)部署,但它只給每個部署單獨啟動了一個Unicorn進(jìn)程,這意味著“分支實驗室”僅在測試API和UI變化時才有用。這些需求重疊的很多,所以我們將這些項目結(jié)合起來,并采用了一個由Kubernetes專為github/github開發(fā)的新部署環(huán)境,名為“審查實驗室”。

在構(gòu)建審查實驗室的過程中,我們交付了不少子項目,每個子項目都可以在各自單獨的博客文章中進(jìn)行介紹。前前后后,我們共交付了:

一個在AWS VPC中運行的Kubernetes集群,該VPC由Terraform和kops共同管理。一系列短暫運行Kubernetes集群的Bash集成測試。在項目初期我們大量使用這些測試,以樹立對Kubernetes的信心。github/github的Dockerfile文件。增強(qiáng)內(nèi)部CI平臺,以支持將容器構(gòu)建和發(fā)布到容器注冊表。50個Kubernetes資源的YAML陳述,它們檢查后被加入到github/github。增強(qiáng)內(nèi)部部署應(yīng)用,以支持將Kubernetes資源從存儲庫部署到Kubernetes命名空間,以及從內(nèi)部secret存儲庫創(chuàng)建Kubernetes secrets。一個將haproxy和consul-template組合在一起的服務(wù),以便將Unicorn pod的流量路由到現(xiàn)有服務(wù),并在那里發(fā)布服務(wù)信息。一個讀取Kubernetes事件并將異常事件發(fā)送到內(nèi)部錯誤跟蹤系統(tǒng)的服務(wù)。一個名為kube-me的兼容chatops-rpc的服務(wù),它會通過聊天向用戶公開一組有限的kubectl命令。

最終成果是一個基于聊天的界面,它可以為任何pull request創(chuàng)建GitHub的單獨部署。一旦pull request通過了所有必需的CI作業(yè),用戶就可以將該pull request部署到審查實驗室,如下所示:

jnewland

.deploy https://github.com/github/github/pull/4815162342 to review-lab

用戶說:部署https://github.com/github/github/pull/4815162342 到審查實驗室

Hubot

@jnewland's review-lab deployment of github/add-pre-stop-hook (00cafefe) is done! (12 ConfigMaps, 17 Deployments, 1 Ingress, 1 Namespace, 6 Secrets, and 23 Services)(77.62s) your lab is available at https://jnewland.review-lab.github.com

答復(fù)用戶:@ jnewland的審查實驗室部署github/add-pre-stop-hook(00cafefe)已經(jīng)完成! (共12個ConfigMap、17個Deployment、1個Ingress、1個Namespace、6個Secrets和23個Service)(用時77.62秒),點擊https://jnewland.review-lab.github.com 即可使用。

像分支實驗室一樣,實驗室在上次部署之后的一天內(nèi)即被清理干凈。由于每個實驗室都是在自己的Kubernetes命名空間中創(chuàng)建的,因此清理命名空間與刪除命名空間一樣簡單,部署系統(tǒng)在必要時會自動執(zhí)行這些動作。

審查實驗室是一個成功的項目,產(chǎn)生了一些積極的結(jié)果。在將該環(huán)境普遍開放給工程師之前,它充當(dāng)Kubernetes集群設(shè)計的基本試驗場和原型環(huán)境,以及Kubernetes資源設(shè)計和配置的基本試驗場和原型環(huán)境,現(xiàn)在github/github Unicorn工作負(fù)載由Kubernetes資源來描述。發(fā)布后,大量工程師被迫適應(yīng)新的部署風(fēng)格,一些感興趣的工程師提供了反饋,而一些沒有注意到任何變化的工程師仍在正常使用,這使我們逐步建立了信心。就在最近,我們觀察了高可用性團(tuán)隊中一些工程師使用審查實驗室的情況,他們使用審查實驗室來實驗與Unicorn的互動,并通過將某個新實驗子系統(tǒng)部署到共享實驗室來實驗該子系統(tǒng)的表現(xiàn)。這種環(huán)境能使工程師以自助服務(wù)的方式實驗和解決問題,我們對此感到非常高興。

  每周向分支實驗室和審查實驗室的部署量

Metal上的Kubernetes

隨著審查實驗室的交付,我們的注意力轉(zhuǎn)移到了github.com。為了滿足旗艦服務(wù)的性能和可靠性要求(旗艦服務(wù)依賴于低延遲來訪問其它數(shù)據(jù)服務(wù)),我們需要構(gòu)建Kubernetes基礎(chǔ)設(shè)施來支持在物理數(shù)據(jù)中心和POP中運行的metal云。這次的工作又有近十幾個子項目:

這篇關(guān)于容器聯(lián)網(wǎng)的及時而全面的帖子幫助我們選擇了Calico網(wǎng)絡(luò)提供商,它提供了我們在ipip模式下快速交付集群所需的開箱即用功能,同時讓我們之后能夠靈活地與網(wǎng)絡(luò)基礎(chǔ)設(shè)施進(jìn)行對等互連。經(jīng)過對@kelseyhightower的“艱難但必不可少的Kubernetes”的不少于十幾次的拜讀,我們將一些手動分配的服務(wù)器組裝到了某臨時的Kubernetes集群中,該集群通過了與我們用來鍛煉AWS集群相同的一套集成測試。我們構(gòu)建了一個小工具,來為每個集群生成CA和配置,它們的格式可被內(nèi)部Puppet和secret系統(tǒng)使用。我們Puppet化了兩個實例角色(Kubernetes節(jié)點和Kubernetes apiservers)的配置,并允許用戶提供已配置的集群的名稱于分配時加入。我們構(gòu)建了一個小型Go服務(wù)來使用容器日志,并將元數(shù)據(jù)按鍵/值的格式附加(append)到每一行,并將它們發(fā)送到主機(jī)的本地syslog端點。我們加強(qiáng)了GLB,即內(nèi)部負(fù)載均衡服務(wù),以支持Kubernetes NodePort服務(wù)。

所有這些努力產(chǎn)生了一個集群,并通過了我們的內(nèi)部驗收測試。鑒于此,我們相信,同一套輸入(即由審查實驗室使用的Kubernetes資源)、同一組數(shù)據(jù)(即通過VPN與審查實驗室連接的網(wǎng)絡(luò)服務(wù))以及同樣的工具會產(chǎn)生類似的結(jié)果。在不到一周的時間內(nèi),即便其中大部分時間用于內(nèi)部溝通和對那些對遷移有重大影響的事件進(jìn)行排序,我們?nèi)阅軐⒄麄€工作負(fù)載從運行在AWS上的Kubernetes集群遷移到數(shù)據(jù)中心內(nèi)的Kubernetes集群。

提高信心

憑借在metal云上搭建Kubernetes集群的成功和可重復(fù)的模式,現(xiàn)在我們可以對用Unicorn部署替代當(dāng)前前端服務(wù)器池的能力充滿信心了。在GitHub,工程師及其團(tuán)隊通常會通過創(chuàng)建Flipper特性來驗證新功能,然后在其可行后立即選擇該功能。在加強(qiáng)部署系統(tǒng)后,我們將一套新的Kubernetes資源部署到與現(xiàn)有的生產(chǎn)服務(wù)器并行的github-production命名空間,并加強(qiáng)GLB,以支持通過受Flipper影響的cookie將員工請求路由到不同的后端。因此員工可以通過在任務(wù)控制欄中選擇某按鈕進(jìn)入Kubernetes實驗后端:

內(nèi)部用戶的負(fù)載幫助我們找到問題、修復(fù)錯誤,并在生產(chǎn)中開始習(xí)慣Kubernetes了。在此期間,我們通過模擬將來要執(zhí)行的程序、編寫運行手冊和執(zhí)行故障測試來努力提高信心。我們還將少量生產(chǎn)流量路由到此集群,以確認(rèn)我們對負(fù)載下的性能和可靠性的假設(shè)。我們從每秒100個請求開始,并將其擴(kuò)大到github.com和api.github.com10%的請求。經(jīng)過這些模擬后,我們暫停了一下,重新評估了全面遷移的風(fēng)險。

  集群組

幾個故障測試產(chǎn)生了始料未及的結(jié)果。尤其是,一個模擬單個apiserver節(jié)點的故障的測試對運行的工作負(fù)載的可用性產(chǎn)生了負(fù)面影響,從而中斷了集群。對這些測試結(jié)果的調(diào)查并沒有產(chǎn)生確鑿的結(jié)果,但是幫助我們確定中斷可能與連接到Kubernetes apiserver的各種客戶端之間的交互有關(guān)(如calico-agent,kubelet,kube-proxy和kube-controller-manager)和確定內(nèi)部負(fù)載均衡器在apiserver節(jié)點故障期間的行為。鑒于觀察到Kubernetes集群降級可能會中斷服務(wù),我們開始考慮在每個站點的多個集群上運行旗艦應(yīng)用,并自動將請求從不正常的集群轉(zhuǎn)移到其他正常集群。

我們的路線圖已包含類似的工作,以支持將此應(yīng)用部署到多個獨立運行的站點。同時,這種方法其它積極的折衷 - 包括為低中斷集群升級提供可行的故事、將集群與現(xiàn)有故障域(如共享網(wǎng)絡(luò)和電源設(shè)備)相關(guān)聯(lián) - 支持我們繼續(xù)走這條路線。我們最終決定使用某個設(shè)計,它利用了部署系統(tǒng)支持部署到多個“分區(qū)”的功能,并且通過自定義的Kubernetes資源注釋來增強(qiáng)該設(shè)計,以支持集群特定的配置。所以我們放棄了現(xiàn)有的聯(lián)合解決方案,轉(zhuǎn)而使用另一個方法,因為該方法能夠利用已經(jīng)存在于部署系統(tǒng)中的業(yè)務(wù)邏輯。

從10%到100%

隨著集群組的實施,我們逐漸將前端服務(wù)器轉(zhuǎn)換為Kubernetes節(jié)點,并增加路由到Kubernetes的流量百分比。除了一些其他負(fù)責(zé)的設(shè)計 團(tuán)隊,我們在短短一個多月內(nèi)完成了前端轉(zhuǎn)型,同時將性能和錯誤率保持在目標(biāo)范圍內(nèi)。

  Web請求百分比:Kubernetes/github-fe (%)

在這次遷移期間,有個問題一直延續(xù)到今天:在高負(fù)載和/或高比率容器抖動的時候,一些Kubernetes節(jié)點會引起內(nèi)核崩潰和重啟。雖然我們對此不滿意,并且正在繼續(xù)高度重視和調(diào)查該問題,但讓我們高興的是,Kubernetes能夠自動繞過這些故障,并繼續(xù)在目標(biāo)錯誤率范圍內(nèi)提供流量。我們已經(jīng)通過echo c> / proc / sysrq-trigger執(zhí)行了一些模擬內(nèi)核崩潰的故障測試,而且發(fā)現(xiàn)這可以作為我們故障測試模式的有用補(bǔ)充。

接下來該做什么?

將此應(yīng)用遷移到Kubernetes,我們深受鼓舞,并期待后續(xù)做更多的遷移。雖然我們故意將首次遷移的范圍限定于于無狀態(tài)的工作負(fù)載,但能夠在Kubernetes上嘗試運行有狀態(tài)的服務(wù)仍令人激動不已。

在本項目的最后階段,我們還交付了一個工作流程,用于將新的應(yīng)用和服務(wù)部署到類似的Kubernetes集群組中。在過去幾個月中,工程師已經(jīng)將數(shù)十個應(yīng)用部署到了這個集群。以前,這些應(yīng)用中每一個都需要網(wǎng)站可靠性工程師進(jìn)行配置管理和分配支持。通過自助服務(wù)應(yīng)用分配工作流程,網(wǎng)站可靠性工程師可以將更多的時間投入到為組織其它部門提供基礎(chǔ)設(shè)施產(chǎn)品,以支持我們的最佳實踐,以及為每個人提供更快、更有彈性的GitHub體驗。

鳴謝

我們衷心感謝整個Kubernetes團(tuán)隊提供的軟件、文字和指導(dǎo)。我也要感謝以下GitHub用戶在本項目上所做出杰出貢獻(xiàn):

和我們一起工作!

想幫助GitHub網(wǎng)站可靠性工程師團(tuán)隊解決像這樣有趣的問題嗎? 歡迎你加入我們。請通過這里申請!

查看英文原文https://githubengineering.com/kubernetes-at-github/

鏈接已復(fù)制,快去分享吧

企業(yè)網(wǎng)版權(quán)所有?2010-2024 京ICP備09108050號-6京公網(wǎng)安備 11010502049343號