Categories
程式開發

Datadog使用大規模Kubernetes集群的艱辛之路


來自Datadog的Laurent Bernaille柏林舉行的Velocity會議上討論了運維大型自管理Kubernetes集群所面臨的挑戰。 Bernailed聚焦在如何配置彈性和可擴展的控制平面,為何和如何頻繁地循環更新證書,以及在Kubernetes中使用網絡插件實現高效通信的必要性。

傳統的架構方式會將所有的Kubernetes master組件都放到同一台服務器上,並且至少有三台這樣服務器來保持高可用性。但是,這些組件有不同的職責,不能或者不需要以相同的方式進行擴展。舉例來說,調度器(scheduler)和控制器(controller)是無狀態的組件,這使得它們很易於擴展。但是,etcd是有狀態的,需要數據的冗餘備份。同時,像調度器這樣的組件會與一個選舉機制協作,確保只有一個實例是處於激活狀態的。 Bernaille認為擴展調度器並沒有什麼意義。

因此,Datadog決定將Kubernetes組件切分到不同的服務器上,這些服務器有不同的資源並配置自定義的擴展策略。對於像API服務器這樣的組件,他們在該組件之前放置了一個負載均衡器,從而能夠正確地分配請求。而對於etcd服務器,他們也對其進行了拆分,形成了一個專門的etcd集群,只用來處理Kubernetes事件。

Datadog使用大規模Kubernetes集群的艱辛之路 1

Bernaille指出,Kubernetes在所有的組件通信時會使用加密和x509證書。所以,為了避免出現證書的問題,比如證書過期,Datadog決定每天都輪流更新證書。但是,輪流更新證書是一項很具挑戰性的任務,因為Kubernetes需要在不同的組件和服務器上安裝和使用不同的證書。同時,Datadog意識到在每次輪流更新之後,他們必須要重新啟動像API服務器這樣的組件。因此,Datadog決定將每天的證書輪流更新自動化並把該任務交給HaschiCorp Vault來實現。

但是,鑑於kubelet按需生成證書的運行方式,Datadog決定在kubelet的每日輪流更新中採用一種例外規則。儘管存在挑戰和復雜性,但是Bernaille依然建議要頻繁地輪流更新證書。這不是一項簡單的任務,不過用戶能夠避免將來在證書過期時出現問題,更糟糕的是在日誌中可能並沒有證書過期的明顯標誌。

Datadog使用大規模Kubernetes集群的艱辛之路 2

Bernaille提到,Datadog還面臨網絡方面的挑戰,因為需要大量的服務器來運行他們的平台。 Bernaille花了一些時間闡述Kubernetes節點會有一個IP地址的範圍,它們被用來給pod分配IP地址。因此,對於小型集群來說,使用靜態路由實現pod之間的通信能夠運行地非常好。但是,對於中等規模的集群來說,一種有效的方式就是使用網絡覆蓋(networking overlays),在這種方式中,節點通過隧道進行通信。在Datadog,有效的方式是在整個網絡中,為pod分配一個可路由的IP。通過這種方式,到pod的通信是直接連接的,不再需要像kube-proxy這樣的中介。GCP以IP別名的方式支持該模型AWS也以彈性網絡接口(elastic network interface,ENI)的形式提供了支持,對於企業的內建集群,用戶可以使用像Calico這樣的工具。

最後,Bernaille討論了跨不同集群的通信。默認情況下,在Kubernetes中,當一個外部請求到達集群時,Kubernetes會通過kube-proxy來路由流量。但是,如果請求到達了一個不正確的節點,目標pod並沒有運行,那麼kube-proxy必須將請求重定向到正確的節點。有種替代方案是創建一個外部流量策略或者使用ingress控制器,但是該方案並不適用於大規模集群。因此,Datadog借助AWS中的ALB ingress控制器針對HTTP通信實現了原生路由。

Datadog使用大規模Kubernetes集群的艱辛之路 3

Bernaille最後說,他們在DNS、有狀態應用和應用部署方面還面臨著其他的挑戰,但是他沒有足夠的時間來深入討論這些話題。不過,他推薦觀看Jerome Petazzoni關於Kubernetes內部核心的演講以及更早的關於Datadog使用Kubernetes艱辛之路的演講

原文鏈接:

Kubernetes the Very Hard Way With Large Clusters at Datadog