【編者的話】網(wǎng)絡(luò)上鮮有文章介紹如何將Kubernetes部署在物理云環(huán)境中。本文作者Newland來自于GitHub的SRE團隊，他從實際項目實施角度，介紹了如何將Kubernetes部署在GitHub的物理服務(wù)器上，并最終實現(xiàn)將GitHub全部運在Kubernetes上。

自GitHub在2008年上線以來，其網(wǎng)站就運行在Ruby on Rails之上。然而，8年過去了， GitHub作為全世界最重要的版本控制倉庫，整個組織架構(gòu)的負載已經(jīng)日趨緊張。GitHub在很多方面都有了很大的發(fā)展，不僅在用戶數(shù)量和對github.com和api.github.com的訪問請求等各方面都有巨大的增長。公司的員工數(shù)量在遞增，同時對站點可靠性工程師(Site Reliability Engineering，SRE )團隊服務(wù)的需求也在遞增。

SRE團隊越來越多地從項目中撤出，旨在直接改善GitHub.com網(wǎng)站的用戶體檢，以支持各種各樣的內(nèi)部需求。隨著GitHub 服務(wù)數(shù)量的增多，團隊的數(shù)量也在不斷增加，隨之站點可靠性團隊花費在服務(wù)的維護、部署和其他無關(guān)任務(wù)上的時間也越多。

受限于SRE團隊的可用性，GitHub的其他工程師也受到限制，甚至變得更慢。“新的服務(wù)可能需要幾天、幾周甚至幾個月才能完成部署，這取決于它們的復(fù)雜性和我們團隊的可用性。”GitHub的首席站點可靠性工程師 Jesse Newland 說。“我們迫切地需要給其他的工程師提供一個自助的平臺，他們可以用來自己實驗創(chuàng)建和部署新的服務(wù)，并按需擴容。”

因此，在2016年8月的前一年，啟動了Newland團隊和平臺開發(fā)實驗團隊的一個合作項目，將整個平臺作為服務(wù)解決方案進行評估。Kubernetes是由Google開發(fā)并由云原生計算基金會( Cloud Native Computing Foundation )維護的開源容器編排引擎，它迅速地成為行業(yè)的領(lǐng)先競爭者。

“ Kubernetes 項目是我見過的維護和監(jiān)管最好的開源項目之一，和它相關(guān)的社區(qū)也都非常精彩，該項目的每個領(lǐng)域展現(xiàn)著出色的工程師。”Newland說。“我相信該技術(shù)能夠幫助團隊以更加穩(wěn)健地方式來遠行項目，不僅限于GitHub團隊，也包括任何使用它的團隊。”

開始使用容器

這不是GitHub首次涉足容器。“我們已經(jīng)在很多方面使用了他們，比如CI、測試和一些隔離的項目上。不過，他們沒有提供大量的生產(chǎn)工作負載。”他解釋道。因此，我們已經(jīng)擁有了一些經(jīng)驗，但是并不深入。我們確實對Dockerfile格式的優(yōu)點和缺點都很熟悉，這也是有所幫助的。

在項目的最初階段，團隊就決定要致力于遷移公司的一個最核心的負載：github.com和GitHub API。“ 這是一個深思熟慮的決定，它受很多因素的影響。” Newland說。這其中包括對自助服務(wù)容量擴容工具的需求，隨時間的推移增加指定工作負載的可遷移性的需求，以及對新的平臺能持續(xù)運行多年的需求。

“根據(jù)我們選擇要遷移負載的關(guān)鍵性能，我們需要在把它服務(wù)于實際生產(chǎn)負載前，獲得高水平的運維信心。”Newland說。

Kubernetes風(fēng)格的黑客周（Hack Week）

為了支持即將到來的黑客周，一個小型的實驗項目已經(jīng)構(gòu)建，并創(chuàng)建了Kubernetes集群和部署工具，此舉也獲得一些該平臺的實踐經(jīng)驗。這是一個合適的場景，讓不同的團隊同時嘗試集群和部署，這也是一個小規(guī)模版本GitHub對平臺的全面組織的需求。

Newland說，黑客周正如其名，是一個非常適合的測評場地。這是一個低風(fēng)險的實驗環(huán)境，來驗證Github在Kubernetes的運行狀況，并且成為我們第一次調(diào)研的良好的質(zhì)量標準，因為黑客周就是圍繞軟件的最多可用性來進行的。“然而，更重要的是公司的開發(fā)人員喜歡擁有一個可重復(fù)的環(huán)境，去測試他們的修改對所有依賴的子系統(tǒng)的運行情況。

簡而言之，Github的第一次深入嘗試Kubernetes取得了真正成功。“我們對該項目的經(jīng)驗以及來自黑客周的工程們的反饋都是非常積極正面的，并支持擴大該實驗。”Newland總結(jié)到。“有了這些正面的體驗，我們開始計劃更大的推廣。”

（此外，Newland說，黑客周已經(jīng)成為了一種模式，用來運行和檢驗其他的GitHub的應(yīng)用，這些應(yīng)用可以從獨立的運行環(huán)境中獲得好處，并可按需創(chuàng)建而不必運行在固定數(shù)量的準生產(chǎn)服務(wù)器上。“以我的經(jīng)驗來看，非生產(chǎn)或者準生產(chǎn)環(huán)境隨著時間推移而逐漸會變得陳舊，因為在你真正需要它們的那一刻之前，它們并沒有被真正地維護和受關(guān)注，這樣會引起各種各樣的問題。”Newland說。“所以，我們非常興奮地應(yīng)用該模式到所有的GitHub及它的應(yīng)用上，正如我們需要一套預(yù)備生產(chǎn)測試環(huán)境一樣。”）

構(gòu)建之路

該團隊沒有為整個Kubernetes的遷移工作設(shè)立一個固定時間表，而采用了一種以成就為導(dǎo)向的方式 。目標是根據(jù)現(xiàn)有產(chǎn)品的性能以及錯誤率為導(dǎo)向遷移，而不會設(shè)定一個固定的截止期限來完成。

“我們大致知道我們要達到的目標，會通過選定一個接近的目標和設(shè)定一個大概的日期，讓團隊感到緊迫性。”Newland說。這是一個階段性的推進方案，他解釋道：“我們對這個新的平臺進行小流量的測試，并在我們嘗試更大的步驟前，來檢驗它是否能夠滿足我們的預(yù)期目標。”

下一個關(guān)鍵的成就是：建立一個“評審實驗室”（review lab）。

“我們知道，我們需要設(shè)計、原型和驗證使用Kubernetes原生的Pods、Deployments和Services來替代由前端服務(wù)器提供的服務(wù)。”Newland說。“一些驗證可以通過在一個容器中運行現(xiàn)有的測試套件來進行，而不是運行在一個配置為模擬前端服務(wù)器上。

但是，我們還需要獲得更大的信心在把容器作為一組更大的Kubernetes資源的一部分來運行。”

我們決定建立“評審實驗室”--- 這是一個通過Kubernetes來部署和管理的環(huán)境，它支持對Kubernetes及其服務(wù)組合進行探索性測試，類似與現(xiàn)有GitHub的“分支實驗室”環(huán)境。

團隊們花費了2016余下的時間來創(chuàng)建評審實驗室，并在此程中交付了多個子項目。其中包含把K8s集群運行在AWS 虛擬私有云平臺（ AWS Virtual Private Cloud ），它使用Hashicorp的 Terraform 和 kops 的組合管理；使用Dockerfile文件來部署github.com和api.github.com,使用YAML來描述超過50個的Kubernetes資源；使用一些Bash集成測試腳本來實驗短暫的Kubernetes集群服務(wù)。Newland把它描述為“在項目開始時，通過大量地高負載地使用來獲得對Kubenetes的信心。”

最終的結(jié)果是一個聊天式的用戶界面，可以根據(jù)拉取請求來創(chuàng)建隔離部署GitHub的總量。“我們非常高興的是，這種環(huán)境使工程師能夠以自助服務(wù)的方式來實驗和解決問題，”Newland說。他解釋說，評審實驗室環(huán)境在內(nèi)部發(fā)布后，給大量的工程師提供了一種新的部署方式。從環(huán)境感興趣的工程師們的反饋，以及在持續(xù)使用過程中工程師并未察覺環(huán)境變化并為此提出反饋，這些都幫助可靠性團隊對Kubernetes建立了信心。

在物理服務(wù)器上部署Kubernetes

評審實驗室成功推出后，Newland和他的團隊從2016年底假期結(jié)束后，準備重點關(guān)注在GitHub的物理環(huán)境工作Kubernetes集群上，并開始遷移網(wǎng)絡(luò)流量。

“我覺得特別有趣的一點是，我們實際上是在金屬實體物理機器上運行著Kubernetes集群。Kubernetes生態(tài)系統(tǒng)非常專注于運行在云服務(wù)提供商上，大多數(shù)文檔都是基于這一點的，”Newland說。 “有關(guān)Kubernetes如何工作在我們的物理數(shù)據(jù)中心的設(shè)計上，我們遇到了一些挑戰(zhàn)。我們也看一些零散的文章和先驅(qū)者，但大多數(shù)博客文章和討論都是基于 Kubernetes集群運行在他們的房子來闡述。所以，幾個團隊成員實際上開始在家里實施Kubernetes，并把它作為實驗和學(xué)習(xí)的機會。”

“實際上，我的幾個家庭自動化現(xiàn)在由Kubernetes來提供支持，”Newland補充說。

不容置疑，這需要做一些非常有趣的調(diào)整。為了滿足GitHub的旗艦服務(wù) 的性能和可靠性要求，其中的一部分服務(wù)還要依賴于對其他數(shù)據(jù)服務(wù)的低延遲訪問， GitHub的Kubernetes基礎(chǔ)設(shè)施將需要支持公司的物理數(shù)據(jù)中心和接駁點(POPs)中的“物理云”。

“參照 Kelsey Hightower 的一篇不少于十幾個讀者的文章“ Kubernetes The Hard Way ”, 我們將少量手動配置的服務(wù)器組合到了一個臨時的Kubernetes群集中。這些集群通過了我們的一組集成測試，該測試集之前也同樣用來測試我們的AWS集群，”Newland說。

在遷移工作站旅途上的幾個小的驛站：

• 使用 Calico軟件定義的網(wǎng)絡(luò)提供商 的即時可用功能，在IP-in-IP模式下快速發(fā)布群集，隨后允許使用GitHub的網(wǎng)絡(luò)基礎(chǔ)設(shè)施進行對等探測。
• 構(gòu)建一個小工具，為GitHub的內(nèi)部Puppet和加密系統(tǒng)生成每個集群所需的證書授權(quán)和配置。
• 使用兩種實例角色（Kubernetes節(jié)點和 Kubernetes API服務(wù) ）的配置，允許用戶提供已經(jīng)部署的集群的名稱，以便在部署時加入該集群。
• 構(gòu)建一個小型的基于Go的服務(wù)來使用容器日志，將元數(shù)據(jù)以key / value格式附加到每一行，并將它們發(fā)送到主機本地Syslog終端。
• 加強GitHub的內(nèi)部負載均衡服務(wù)，以支持 Kubernetes NodePort 服務(wù)。

“所有這些努力的工作組合，通過了在單個集群的驗收測試。”Newland說。鑒于此，團隊們有理由相信，在相同的一組投入（指的是評審實驗所使用的Kubernetes資源），同一組數(shù)據(jù)（通過VPN連接的評審實驗室的網(wǎng)絡(luò)服務(wù)）和使用相同的工具能夠得到類似的結(jié)果。

“在不到一個星期的時間里，其中大部分時間用于內(nèi)部溝通和對遷移有重大影響的事物的排序上，我們將整個工作負載從運行在AWS上的Kubernetes集群遷移到我們的一個數(shù)據(jù)之中心。”他總結(jié)道。

最后的倒計時

通過在GitHub的物理云上創(chuàng)建了一個成功和穩(wěn)定的組合Kubernetes集群的模式，現(xiàn)在是時機開始減輕GitHub前端服務(wù)器的部分負載 。

“在GitHub，通常的做法是工程們通過創(chuàng)建一個稱為Flipper的功能來驗證他們正在構(gòu)建的新功能，一旦可行就可以接它。”Newland說。 在增強部署系統(tǒng)后，將新的Kubernetes資源部署到現(xiàn)有前端服務(wù)器并行的Github生產(chǎn)環(huán)境的域名空間中，并增強了Github負載均衡服務(wù)，可基于受影響的Flipper功能模塊的 cookie ，將員工的網(wǎng)絡(luò)請求路由到另外的后臺服務(wù)器，該團隊允許GitHub的員工選擇路由到一個實驗性的Kubernetes后端。

“來自于內(nèi)部用戶的負載，幫助我們發(fā)現(xiàn)問題、修復(fù)錯誤，并讓我們開始建立信心，”Newland說。 “我們還將少量網(wǎng)絡(luò)流量路由到此集群，以確認我們對該負載下的性能和可靠性的假設(shè)。從最初的100個請求每秒開始，并擴大到對整個github.com和api.github.com的10％的訪問量的請求。 ”

問題也卷土而出，其中也包括將集群與GitHub的現(xiàn)有負載平衡基礎(chǔ)設(shè)施集成在一起的問題。 “運行高可用集群的文檔掩蓋了對負載均衡器的必要特性 – 這也不是缺陷，因為這也不是經(jīng)常使用的事情。”他說。 “我們在此開辟先河，并在此過程中更具體地理解問題所在。當(dāng)我們這樣做的時候，我們也愿意和社區(qū)分享一些我們的經(jīng)驗。”

在即將把100%流量路由到Kubernetes時，團隊選擇在每個站點的多個群集上運行GitHub的前端系統(tǒng)，并自動地將請求從不健康的群集轉(zhuǎn)移到其他健康群集。 “所以我們不用把所有的蛋放在一個Kubernetes集群中，而是運行了幾個集群 - 這樣一來，如果出現(xiàn)了錯誤的話，那么我們只會丟失一部分當(dāng)時正在處理服務(wù)請求的服務(wù)器，”Newland解釋說 。 “我們改進了我們的設(shè)計，并讓它在那些測試過程中存在問題的領(lǐng)域提供更加合理的服務(wù)。”

最終，從內(nèi)部到外部的Kubernetes的過渡是在一個月內(nèi)進行的，同時保持在一定的性能和錯誤率之內(nèi)。 “我在這里，因為我喜歡解決問題，”Newland說。 “不過，我同樣感興趣于不再創(chuàng)造出絕無必要的問題。”

個人視角

“作為一名站點的可靠性工程師，我的愿望是能夠創(chuàng)建工具，使得軟件開發(fā)人員比我更有創(chuàng)意 - 構(gòu)建創(chuàng)新的和革新的解決方案，然后幫助其他人在GitHub上使用它們，”Newland總結(jié)說。 “這個項目讓我感到鼓舞 - 我們設(shè)置的審查實驗室環(huán)境，讓我們的工程師能夠嘗試新事物并進行實驗，而在此之前他們需要等待SRE團隊?，F(xiàn)在，他們不再受限于SRE員工的數(shù)量了。我們看到工程師們實驗用不同的方法來替代大塊的軟件棧 ，并且審查實驗室和Kubernetes組合使他們不僅可以自己實踐，而且還做了一些SRE團隊意想不到的事情...”

“我已經(jīng)看到，Kubernetes是如何在GitHub上創(chuàng)造了一個更快速創(chuàng)新的環(huán)境 - 用戶將從這些創(chuàng)新中得到受益，最終使整個行業(yè)受益。”

原文連接：（翻譯：侯巧燕）