將GitLab.com折騰到Kubernetes的一年中，我們踩到了什麼坑？

跨可用區流量增加了計費
Google將其網路劃分為多個區域，並將各個區域劃分為可用區（AZ）。由於Git託管需要大量頻寬，因此瞭解網路出口非常重要。對於內部網路流量，僅當出口保持在單個可用區中時，它才是免費的。
區域GKE群集提供了跨越多個可用區以實現冗餘的便利。我們正在考慮將區域GKE群集拆分為單個區域群集，以使用大量頻寬的服務來避免網路出口費用，同時在群集級別上保持冗餘。
 

資源限制，請求和擴充套件
我們的遷移故事始於2019年8月，當時我們將GitLab容器登錄檔遷移到Kubernetes，這是第一個遷移的服務。儘管這是一項關鍵且高流量的服務，但它是第一次遷移的不錯選擇，因為它是一個無狀態應用程式，只有很少的外部依賴項。我們遇到的第一個挑戰是由於節點上的記憶體限制而導致大量Pod被驅逐消失。
這要求對請求和限制進行多次更改。我們發現，隨著應用程式隨著時間的推移增加其記憶體利用率，低請求（為每個Pod保留記憶體）和對利用率的慷慨硬性限制是導致節點飽和和驅逐率高的秘訣。
為了對此進行調整，我們最終決定使用更高的請求和更低的限制這樣可以減輕節點的壓力，並在不對節點施加太大壓力的情況下回收豆莢。經歷了一次之後，我們開始以接近相同值的大量請求和限制進行遷移，然後根據需要進行調整。
 

指標和記錄
在過去的一年中，基礎架構部門的主要變化之一是改進了我們監控和管理SLO的方式。SLO使我們能夠為遷移過程中受到密切監視的單個服務設定目標。
 

將流量轉移到新叢集
我們遷移的第一個服務從內部限制流量開始，我們將繼續使用此方法來確保在將所有流量提交給群集之前滿足我們的SLO。對於遷移而言，這意味著將內部專案的請求首先路由到Kubernetes，然後使用HAProxy後端加權將其他流量緩慢移至群集。在從VM遷移到Kubernetes的過程中，我們瞭解到，對我們而言，以一種簡便的方法在新舊基礎架構之間移動流量，並使舊基礎架構在遷移後的頭幾天保持可回滾狀態非常有益。
 

預留的Pod容量和利用率
我們較早發現的一個問題是，雖然我們註冊服務的pod啟動時間很短，但Sidekiq的啟動時間卻長達兩分鐘。當我們開始為需要快速處理工作和快速擴充套件的工作人員將工作負載轉移到Kubernetes時，漫長的Sidekiq啟動時間帶來了挑戰。此處的教訓是，在Kubernetes中，水平pod自動縮放器（HPA）在適應不斷增加的流量方面效果很好，同時評估工作負載特性和設定預留的pod容量（尤其是對於不均衡的需求）也很重要。
在我們的案例中，我們看到作業突然激增，這導致了一個大型擴充套件事件，在我們可以擴充套件節點池之前，該事件使CPU​​飽和。儘管試圖儘可能地將其擠出叢集，但在遇到一些初始效能問題後，我們現在首先從設定大量的pod開始，然後在以後縮小規模，同時密切關注SLO。