來自Datadog的Laurent Bernaille在柏林舉行的Velocity會議上討論了運維大型自管理Kubernetes集羣所面臨的挑戰。Bernailed聚焦在如何配置彈性和可擴展的控制平面，爲何和如何頻繁地循環更新證書，以及在Kubernetes中使用網絡插件實現高效通信的必要性。
傳統的架構方式會將所有的Kubernetes master組件都放到同一臺服務器上，並且至少有三臺這樣服務器來保持高可用性。但是，這些組件有不同的職責，不能或者不需要以相同的方式進行擴展。舉例來說，調度器（scheduler）和控制器（controller）是無狀態的組件，這使得它們很易於擴展。但是，etcd是有狀態的，需要數據的冗餘備份。同時，像調度器這樣的組件會與一個選舉機制協作，確保只有一個實例是處於激活狀態的。Bernaille認爲擴展調度器並沒有什麼意義。
因此，Datadog決定將Kubernetes組件切分到不同的服務器上，這些服務器有不同的資源並配置自定義的擴展策略。對於像API服務器這樣的組件，他們在該組件之前放置了一個負載均衡器，從而能夠正確地分配請求。而對於etcd服務器，他們也對其進行了拆分，形成了一個專門的etcd集羣，只用來處理Kubernetes事件。
Bernaille指出，Kubernetes在所有的組件通信時會使用加密和x509證書。所以，爲了避免出現證書的問題，比如證書過期，Datadog決定每天都輪流更新證書。但是，輪流更新證書是一項很具挑戰性的任務，因爲Kubernetes需要在不同的組件和服務器上安裝和使用不同的證書。同時，Datadog意識到在每次輪流更新之後，他們必須要重新啓動像API服務器這樣的組件。因此，Datadog決定將每天的證書輪流更新自動化並把該任務交給HaschiCorp Vault來實現。
但是，鑑於kubelet按需生成證書的運行方式，Datadog決定在kubelet的每日輪流更新中採用一種例外規則。儘管存在挑戰和複雜性，但是Bernaille依然建議要頻繁地輪流更新證書。這不是一項簡單的任務，不過用戶能夠避免將來在證書過期時出現問題，更糟糕的是在日誌中可能並沒有證書過期的明顯標誌。
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通信實現了原生路由。
Bernaille最後說，他們在DNS、有狀態應用和應用部署方面還面臨着其他的挑戰，但是他沒有足夠的時間來深入討論這些話題。不過，他推薦觀看Jerome Petazzoni關於Kubernetes內部核心的演講以及更早的關於Datadog使用Kubernetes艱辛之路的演講。
原文鏈接：