GitHub遷移到K8S的最佳實踐是怎樣的

GitHub遷移到K8S的最佳實踐是怎樣的，相信很多沒有經驗的人對此束手無策，為此本文總結了問題出現(xiàn)的原因和解決方法，通過這篇文章希望你能解決這個問題。

為什么嘗試改變——釋放SRE工程師

在此之前，主要的Ruby On Rails應用（github/github）還類似于8年前：“Unicorn processes”由Ruby進程管理器調用運行在 Puppet-managed的“God”。同樣的，部署ChatOps如同第一次引入時所作：Capistrano在每個前端服務器上建立SSH連接，然后更新代碼，重新啟動應用，當峰值請求負載超過可用的前端CPU容量時，GitHub站點的SRE會釋放額外的容量，并將其添加到活動前端服務器池當中。

在近幾年中，雖然基本生產方法沒有太大的變化，不過GitHub本身有了很多改變如：新的功能、更大的社區(qū)、更多的員工、以及更多的需求。所以這也就產生了很多新的問題，許多團隊想將其負責的功能從某個大的應用中提取出來，形成一個可以獨立運行和部署的小型服務。伴隨著運行服務數(shù)量的增加，SRE團隊開始為數(shù)十個其他應用提供類似的配置，從而增加了在服務器維護、配置和其他工作上花費的時間，但這些工作又和改進整個GitHub的工作流程沒有直接關聯(lián)。

新服務因為它們的復雜性和SRE團隊的時間問題，需要幾天、幾周或者幾個月的時間來進行部署，隨著時間的推移，一些問題逐漸顯現(xiàn)：這種方法并沒有為工程師提供他們需要的靈活性，以繼續(xù)構建世界級的服務。

工程師們需要一個自助平臺，可以在上面試驗、部署和擴展新的服務，還需要同樣的平臺來滿足Ruby On Rails應用的需求，這樣工程師或機器人就能以秒、天或更長的時間來分配額外的計算機資源去響應需求的變化。

為了滿足這些需求，SRE、平臺和開發(fā)者體驗團隊開始了一個聯(lián)合項目：每天數(shù)十次地將github.com和api.github.com的代碼部署到Kubernetes集群。

為什么是Kubernetes？

為了評估“平臺即服務”的工具，GitHub仔細研究了Kubernetes，它是Google的一個項目，用于自動化部署、擴展和管理容器化應用的開源系統(tǒng)，通過以下幾點為Kubernetes特性做了評估：該項目獲得了火熱的開源社區(qū)支持，首次運行實踐（允許部署小型集群和應用在最初的幾個小時），大量關于設計的經驗。

因此迅速地擴大了實驗力度和范圍：立了一個小的項目去構建Kubernetes集群和部署工具，用來支持即將到來的Hack Week從而獲得一些實際場景中的經驗，GitHub內部對這個項目反映非常積極。

為什么從github/github開始？

在項目最初階段，GitHub做了一個深思熟慮的決定：關鍵性工作負載的：github/github遷移，許多因素促成了這一決定，比較重要的幾點是：

• 需要自助擴展工具來處理持續(xù)的增長

• 希望確保開發(fā)習慣和模式適用于大型應用和較小的服務

• 可以更好地將應用與開發(fā)、Staging、生產、Enterprise、和其他環(huán)境隔離

• 遷移一個關鍵的、高知名度的工作負載可以激發(fā)信心，讓更多的Kubernetes在GitHub上采用。

Rapid iteration and confidence building with a review lab

作為遷移的一部分，進行了一些設計以及原型，并驗證了前端服務器使用Kubernetes的基礎服務如：Pod、部署和服務。通過在容器中運行gitub/github現(xiàn)有的測試套件，可以對這種新設計進行一些驗證，但仍需觀察這個容器是如何成為更大的Kubernetes資源一部分的，很快就清楚地認識到，在驗證階段，對Kubernetes和打算運行的服務進行探索性測試環(huán)境是必備的。

與此同時，項目成員觀察到，現(xiàn)有的github/github抓取請求的模式已經開始顯示出增長十分困難的跡象，部署速度和工程師的數(shù)量成正比，使用幾個額外的部署環(huán)境作為驗證拉取請求到github/github的部分過程也是如此，在工作高峰時，功能齊全的部署環(huán)境數(shù)量往往是固定的，這就降低了部署拉取請求的過程，工程師門經常要求在“Branch Lab”中測試更多的子系統(tǒng)，同時允許多名工程師同時進行部署，但每個工程師只能啟動一個“Unicorn Process”，所以只在測試API和UI變更時有用，因為這些需求重疊很多，所以可以將這些項目結合起來，并開始在github/github上開發(fā)一個新的基于Kubernet/github的部署環(huán)境，被稱之為：Review Lab。

• 在構建Review Lab的過程中，還發(fā)布了幾個子項目：

• 在AWS VPC上運行的Kubernetes集群管理使用了Terraform & Kops

• 一組Bash集成測試使用短暫的Kubernetes集群，后來在項目開始時大量使用，增強對Kuberbetes的信心。

• 一個github Dockerfile/github

• 對內部CI平臺的增強，用來支持構建和將容器發(fā)布到容器注冊中心

• YAML表示50+Kubernetes資源，簽入github/github

• 對內部部署應用的增強，支持將Kubernetes的資源從一個存儲庫部署到Kubernetes的命名空間，以及從內部存儲庫中創(chuàng)建Kubernetes

• 該服務結合了Haproxy和Consul-Template，將Unicorn Pods路由到現(xiàn)有的服務，發(fā)布服務信息。

• 一種讀取Kubernetes事件的服務，并將異常事件發(fā)送給內部服務跟蹤系統(tǒng)

• 一種名為kube-me且與Rpc兼容的服務，通過聊天向用戶公開一組有限的kubectl命令。

• 最終的結果是一個基于聊天的界面，用于為任何拉取請求創(chuàng)建GitHub的獨立部署，一旦請求通過了所有需要的CI任務，用戶即可部署他們的請求：

如同之前的“Branch Lab”一樣，實驗室在最后一次部署后就被清理掉，由于每個實驗室都是在其Kubernetes名稱空間中創(chuàng)建的，清理工作就像刪除名稱空間一樣簡單，部署系統(tǒng)會在需要時自動執(zhí)行。

Review Lab是一個成功的項目積累了許多經驗和成果，在為工程師提供這種環(huán)境之前，還為Kubernetes集群設計提供了必要的驗證基礎和原型環(huán)境，以及Kubernetes資源的設計和配置，這些資源現(xiàn)在用以描述github/github的工作負載，在發(fā)布后，它幫助工程師建立了信心，GitHub非常滿意這個環(huán)境賦予工程師實驗和通過自助的方式去解決問題。

Metal Cloud上的Kubernetes

• 隨著Review Lab的發(fā)布后，注意力就轉移到了github.com上，為了滿足關鍵服務的性能的可靠性需求（依賴于低延遲訪問其他數(shù)據(jù)服務），需要構建Kubernetes的基礎設施，去支持在物理數(shù)據(jù)中心和POP中運行的云計算，同樣，有12個子項目：

• 關于容器網(wǎng)絡，因為一個及時且詳盡的帖子，GitHub選擇了Calico，其提供了需要在IPIP模式下快速發(fā)送一個集群的功能，與此同時也提供了可以在以后的網(wǎng)絡基礎設施中進行探索的靈活性。

• 通過十幾次閱讀Kelesyhightower寫的《Kubernetes the hard way 》，GitHub將一些手動操作的服務器組裝到了一個臨時的Kubernetes集群中，此集群通過了相關測試。

• 還構建了一些小工具，為每個集群生成所需的CA和配置，格式可以由Puppet和Secret Systems 使用。

• 對兩個實例配置進行了處理：Kubernetes節(jié)點和Kubernetes Apiservers，這種方式允許用戶提供已經配置的集群名稱，以便在規(guī)定的時間內引入。

• 構建了一個小型的Go服務，用于消耗容器日志，將Key/Value格式的元數(shù)據(jù)附加到每一行，并將它們發(fā)送到主機的本地Syslog端點。

• 加強內部負載均衡服務，用來支持Kubernetes Node Port。

這些工作并沒有白費，都通過了內部驗收測試的集群，因此，GitHub的信心十足，同樣的一組Inputs（由Review Lab使用的Kubernetes資源），相同的數(shù)據(jù)集（網(wǎng)絡服務Review Lab連接到VPN上），同樣的工具都會產生類似的結果，不到一周，雖然大部分的時間都花費在了內部通信和排序上，但對遷移產生了非常重大的影響：可以將整個工作負載從運行在AWS上的Kubernetes集群遷移到一個運行在GitHub數(shù)據(jù)中的集群。

Raising the confidence bar

Kubernetes集群在Github Metal Cloud上的成功和可復制性，所以是時候對“Unicorn”進行部署來替代當前前端服務器池了，在GitHub，工程師及其團隊通過創(chuàng)建一個Flipper特性去驗證新功能是很常見的做法，若可行即選擇它，然后加強部署系統(tǒng)再去部署一套新的Kubernetes資源，github-produciton名稱空間和現(xiàn)有的生產服務器，提高GLB支持員工請求路由到不同的后端：基于Flipper-infuenced的cookie，允許員工在任務控制欄的一個按鈕上選擇實驗Kubernetes后端。

來自內部用戶的負載可以幫助發(fā)現(xiàn)問題、修復BUG，并開始適應Kubernetes的生產，在此期間，通過模擬未來想要執(zhí)行的應用、編寫運行手冊和執(zhí)行Failure Tests來增強信心，還將少量的生產流量路由到這個集群，去確認對于負載下性能和可靠性的設定，從每秒100個請求開始，然后擴展到github.com和api.github.com請求的10%，在幾個模擬試驗中曾短暫地停止用來重新評估完全遷移的風險。

Cluster Groups

因為一些Failure Tests導致了意料之外的結果，特別是模擬單個Apiserver節(jié)點故障的測試破壞了集群，這種方式對運行工作負載的可用性造成了負面影響，根據(jù)調查顯示，這些測試沒有取得決定性的效果，但幫助識別出相關的破壞可能是一個相互作用的各種客戶連接到Kubernetes Apiserver（像Calico-Agent Kubelet Kube-Proxy，Kube-Controller-Manager）和內部負載均衡器的行為在一個Apiserver節(jié)點中的失敗，因為檢測到Kuberntes集群降級可能會破壞服務，所以開始關注了每個站點上運行的關鍵應用，并自動化地將請求從一個不健康的集群遷移到其他健康的集群。

類似的工作已經放在GitHub的流程圖中，支持此應用部署到多個獨立運營的網(wǎng)站，和其他積極的方式進行取舍。最終選定的設計是：使用部署系統(tǒng)支持多個“分區(qū)”增強它通過一個定制的支持提供集群乏味內配置Kubernetes資源注釋，放棄現(xiàn)有的聯(lián)合解決方案，允許使用業(yè)務邏輯已經出現(xiàn)在GitHub的部署系統(tǒng)。

從10%到100%

有了集群組，GitHub逐漸將前端服務器轉換為Kubernetes節(jié)點，并增加了路由到Kubernetes的流量，與其他一些工程師團隊一起，在一個多月的時間內完成了前端的轉換，同時，在這此期間保持了預計的性能和可接受的錯誤率。

在遷移過程中，遇到了一直持續(xù)至今的問題：在高負載/或高利用率的容器中，一些Kubernetes節(jié)點會出現(xiàn)內核錯誤并會重啟，雖然GitHub對這種情況不是很滿意，而且進行了最高優(yōu)先級的排查，但還是很高興地看到Kubernetes能夠自動地繞過這些故障，并繼續(xù)在錯誤范圍內服務流量。

GitHub進行了一些Failure Tests，模擬了與echo c/proc/sysrq觸發(fā)相似的內核錯誤，這是一個很有用的補充。

看完上述內容，你們掌握GitHub遷移到K8S的最佳實踐是怎樣的的方法了嗎？如果還想學到更多技能或想了解更多相關內容，歡迎關注億速云行業(yè)資訊頻道，感謝各位的閱讀！