過去一年中，GitHub將其運行Ruby on Rails應用程序的內部基礎設施遷移到了Kubernetes上，Ruby on Rails是github.com和api.github.com的載體。遷移過程始于在Unicorn進程上運行Web和API應用程序，上述Uncorn進程部署于由Puppet管理的裸機（metal cloud）服務器之上。最后，整個遷移過程在容器處理完所有Web和API請求時結束，這些容器由部署在metal cloud上的Kubernetes集群運行。

根據(jù)GitHub Engineering博文，部署和運行GitHub的基本方法在過去八年中沒有顯著變化。然而，GitHub本身卻發(fā)生了巨大變化，包括新的功能、更大的軟件社區(qū)、更多的GitHub開發(fā)人員及員工以及每秒鐘更多的請求。隨著GitHub組織的發(fā)展，現(xiàn)有的運營方式開始出現(xiàn)新問題。許多團隊希望將功能提取到可以獨立運行和部署的較小服務中。隨著服務數(shù)量的增加，網站可靠性工程師（SRE）團隊發(fā)現(xiàn)他們越來越頻繁地進行維護，這意味著他們沒有時間來增強底層平臺。GitHub工程師需要一個可以用來實驗、部署和擴展新服務的自助服務平臺。

Kubernetes的這幾個品質使其從最初被評估過的幾個平臺中脫穎而出，包括：支持該項目的活躍的開源社區(qū); 第一次運行（第一個吃螃蟹）的體驗，因此我們可以在初始實驗的最初幾個小時內部署小型集群和應用程序; 以及“可用于激發(fā)其設計的大量經驗”，其中值得一提的當屬acmqueue雜志上的"Borg, Omega和Kubernetes"這篇文章。

在本項目的最初階段，GitHub團隊作出了慎重的決定，只關注于關鍵Web流量負載的遷移。做出這一決定源于許多因素，例如：

鑒于被遷移的工作量非常關鍵，在處理任何生產流量之前必須需要極高的運營信心。因此，我們構建了一系列Kubernetes “審查實驗室”集群作為原型。最終我們得到了一個基于聊天的接口，它被用于為所有pull請求創(chuàng)建GitHub的獨立部署。審查實驗室會在最后一次部署后的一天內被清理，由于每個實驗室創(chuàng)建于自己的Kubernetes命名空間中，清理與刪除命名空間一樣簡單，而且部署系統(tǒng)會在必要時自動執(zhí)行清理。

為滿足旗艦GitHub Web服務（該服務依賴于對其他數(shù)據(jù)服務低延遲的訪問）的性能和可靠性要求，我們在GitHub的物理數(shù)據(jù)中心和POPs中運行的metal cloud之上實施了Kubernetes基礎設施。這項工作還涉及許多子項目，包括：通過Project Calico網絡提供商使用容器網絡、借鑒Kelsey Hightower的Kubernetes the Hard Way教程、將Kubernetes節(jié)點和Kubernetes apiserver的配置變得Puppet化、 以及增強GitHub的內部負載均衡服務（GLB）以支持Kubernetes NodePort服務等。

在增強GitHub部署系統(tǒng)后，我們將一套新的Kubernetes資源部署到與現(xiàn)有生產服務器平行的一個github-production命名空間上，并增強了Github負載均衡服務，可基于受Flipper影響的功能切換的 cookie ，將員工的網絡請求路由到另外的后端服務器。然后，員工就能在任務控制欄中用按鈕選擇用于實驗的Kubernetes后端服務器。來自內部用戶的負載幫助我們發(fā)現(xiàn)問題、修復錯誤，并習慣在生產中采用Kubernetes。

幾次初始故障測試產生了出乎意料的結果。特別是，模擬單個apiserver節(jié)點的故障測試中斷了集群并且對運行工作負載的可用性產生了負面影響?？紤]到Kubernetes集群降級可能會中斷服務，現(xiàn)在我們將Web應用程序在每個物理站點上的多個集群上運行，并且把將請求從不正常集群轉移到其他正常集群的過程完全自動化。

前端轉型在一個多月內就完成了，而且性能和錯誤率被控制在目標之內。在遷移過程中，我們遇到了一個始終存在的問題：在高負載和/或高容器流失率的時候，部分Kubernetes節(jié)點會出現(xiàn)內核錯誤并重啟。SRE團隊對此情況不太滿意，并且一直高度重視這個問題，但讓他們很高興的是，Kubernetes能夠自動繞過這些故障，并繼續(xù)提供流量，將錯誤控制在目標范圍內。

GitHub工程團隊“受到了我們將應用程序遷移到Kubernetes的啟發(fā)”。雖然我們將首次遷移的范圍有意限定為無狀態(tài)工作負載，但對于在Kubernetes上試驗運行有狀態(tài)服務，例如使用StatefulSets，我們仍然感到非常期待。

有關GitHub采用Kubernetes的更多信息您可在GitHub Engineering博文中找到。

英文原文：Migrating GitHub's Web and API to Kubernetes Running on Bare Metal