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

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

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

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

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

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

開始使用容器

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

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

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

Kubernetes風格的黑客周（Hack Week）

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

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

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

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

構建之路

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

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

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

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

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

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

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

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

在物理服務器上部署Kubernetes

評審實驗室成功推出后，Newland和他的團隊從2016年底假期結束后，準備重點關注在GitHub的物理環境工作Kubernetes集群上，并開始遷移網絡流量。

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

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

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

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

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

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

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

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

最后的倒計時

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

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

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

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

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

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

個人視角

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

“我已經看到，Kubernetes是如何在GitHub上創造了一個更快速創新的環境 - 用戶將從這些創新中得到受益，最終使整個行業受益。”

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