Categories
程式開發

Brandwatch如何管理多雲生產環境Kubernetes集群


Brandwatch的工程團隊介紹了他們在跨EKS、GKE和自管理集群管理多集群Kubernetes方面的經驗。 Brandwatch在6個獨立的Kubernetes集群,其中運行著約150項生產服務,這些集群運行在AWS EKSGKE和倫敦自主管理的數據中心裡。 2016年初,他們開始在GKE上運行這些服務,並且發現這對他們的許多服務都非常適合。他們使用ConcourseCI和一些定制工具進行自動化部署,並使用nginx ingress控制器對HTTP請求/響應進行更多控制。

為了解更多信息,InfoQ聯繫了Brandwatch應用基礎設施工程總監Andy Hume

雖然GKE和EKS解決了管理Kubernetes控制平面的難題,但Brandwatch仍需管理和升級其自主管理的Kubernetes集群。 Hume談到了他們使用的工具:

我們在自己的數據中心裡使用Rancher管理Kubernetes集群。在2015/2016年,使用Kubernetes之前,我們已經有了運營Rancher 1的經驗,因此,當Rancher 2遷移到Kubernetes時,對於我們最初的實現來說,這似乎是一個明智的起點。然而,當我們計劃如何在現有的裸金屬基礎設施上擴展Kubernetes時,我們可能會尋找複雜性更低的解決方案,並為集成現有網絡設計提供更大的靈活性。

Brandwatch團隊廣泛使用了K8S。 Hume解釋說,他們並沒有在團隊中強推任何特定的工具:

我們的開發團隊在開發人員工作流方法方面非常的多樣化,並且應用程序平台沒有針對本地開發強推任何特定的工具或工作流。團隊使用了一系列工具來簡化開發,包括Skaffold、Telepresence、Docker Compose。

然而,他們的CI/CD工作流是標準化的,並且“所有團隊都將容器鏡像和元數據發佈到一個用於管理部署和變更控制的中央系統”,Hume如是說。

CI/CD在ConcourseCI上進行管理,而它本身就運行在Kubernetes上,他們使用一些自定義工具實現了部署的自動化。該團隊圍繞kubectl編寫了一個聲明性封裝器(可作為YAML編輯),用於捕獲服務元數據。Helm用於模板(但不用於生產部署),與Kustomize一起管理所有集群級服務。該團隊將所有Kubernetes清單文件保存在一個與應用程序源代碼分離的存儲庫中,這“簡化了滾動推出變更的機制”。要回滾到應用程序的舊版本,團隊只需部署一個舊版本的清單。 Hume解釋說:

當團隊部署源代碼的新版本(鏡像)時,他們通過更新Git中Kubernetes清單中的鏡像引用來實現。這是自動的,讓部署過程盡可能簡單,但這也意味著應用程序源代碼和Kubernetes清單之間實際上沒有單獨的映射。 Git中的清單是唯一的真相來源,因此,恢復到舊版本也會回滾鏡像標籤/版本。

Kubernetes集群需要Ingress來接受來自互聯網的流量——管理Kubernetes的雲供應商將其負載均衡器合併為Ingress實現的一部分。這裡,你也可以使用自己的負載均衡器,或者自己管理Kubernetes集群。 Brandwatch工程團隊在所有集群(包括EKS和GKE上的集群)上運行nginx-ingress-controller,繞過了託管的負載均衡器。這使他們可以操作HTTP響應報頭,添加特定於安全性的報頭並刪除內部報頭。此外,Hume還說:

最好不要依賴於應用程序本身添加這些報頭,而要在一個中心位置進行,以便我們的安全團隊在需要時可以進行審計或調整。我們還發現了雲HTTP LB的一些其他約束。例如,GCP LB限制傳入請求HTTP頭的大小,對於我們希望遷移到Kubernetes的一些舊應用程序,這會導致問題。

Brandwatch在每個集群上都運行Prometheus,使用Prometheus operator進行監控和報警。按照Hume的說法,發出告警的主要目標是“關注我們面向客戶的應用程序的可用性和正確性,通常,由一個開發團隊負責使用prometheus/alertmanager棧在我們的每個集群中創建和響應這些告警” 。除此之外,Kubernetes工作負載的總體健康狀況也會被監控,作為整個集群健康狀況的指示器。 Hume補充道:

一般來說,我們發現GKE和EKS的管理節點是有彈性的,並且在發生故障時很容易管理。如果特定節點上的工作負載出現故障,採取的措施是立即終止該節點,並讓集群自動擴展啟動一個新節點。我們確實在節點級進行了監控,但是我們不會主動觸發任何節點級度量的告警。

儘管Brandwatch會在需要時使用Cluster Autoscaler來啟動節點,但這通常太慢了。他們是使用應用程序邏輯來處理這一問題,在節點(和pod)啟動時進行排隊或重試,對於已知的工作負載峰值,他們還會按預期進行擴展。

原文鏈接:

Managing Multi-Cloud Production Kubernetes Clusters at Brandwatch