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

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

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

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

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

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

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

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

為什么是Kubernetes？

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

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

為什么從github/github開始？

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

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

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

• 可以更好地將應用與開發、Staging、生產、Enterprise、和其他環境隔離

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

Rapid iteration and confidence building with a review lab

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

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

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

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

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

• 一個github Dockerfile/github

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

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

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

• 該服務結合了Haproxy和Consul-Template，將Unicorn Pods路由到現有的服務，發布服務信息。

• 一種讀取Kubernetes事件的服務，并將異常事件發送給內部服務跟蹤系統

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

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

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

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

Metal Cloud上的Kubernetes

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

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

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

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

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

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

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

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

Raising the confidence bar

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

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

Cluster Groups

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

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

從10%到100%

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

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

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

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