引言

我們如何使用 Kubernetes 來管理微服務——概覽與介紹

為什么選擇Kubernetes？

簡單來說，Kubernetes 完美地滿足了我們的需求；它解決了許多復雜且重要的問題，而我們無需自己從頭開始構建解決方案。Kubernetes 提供的顯著優勢包括：擴展性、資源優化（類似于容器的“裝箱”）以及其讓服務具備一定的“自愈”能力。

另一個關鍵考慮因素是部署——尤其是簡化發布和回滾的過程。我們圍繞部署構建了復雜的基礎設施，但關于這方面的細節，我們將在后續的文章中進一步討論。

我們如何使用 Kubernetes 呢？

圖片

我們的生產基礎設施分布在四個可用區，位于四個獨立的 Kubernetes 集群中。從技術角度來看，Kubernetes 現在已經有了在單一集群內管理這種拓撲的機制[1]，但這是一個較新的功能，我們還沒有深入探索過。

隨著時間的推移，我們意識到將基礎設施分布在四個集群中帶來了巨大的好處。這個好處清單不斷增加，但其中一些更為重要的好處包括：

必要時通過一些自研工具在可用區之間切換流量

? 當某個可用區出現問題時（無論是由于云服務提供商的問題，還是其他依賴關系出現故障），這種能力證明是非常有用的。

在生產環境中逐步發布基礎設施變更

? 假設我們想要測試一個新的 Kubernetes 插件或配置更改——我們可以將大部分生產流量轉移到其他三個集群上，同時在底層基礎設施上驗證這些更改（如果我們無法在預發布集群上驗證的話）。

我們選擇的服務網格是 Istio[2]。我們使用多種自研控制器來管理我們的入口和出口網關，確保從我們的 CDN 到四個集群之間的流量配置和協調順暢。這里就不再展開討論了（這個話題本身就足夠寫一篇完整的文章了?。?。

配置與管理

Terraform 和一些自研工具是我們管理集群配置的首選工具。在團隊最初構思 Kubernetes 配置時，市面上并沒有很多工具能幫助簡化 Terraform 的使用。于是，我們開發了一個內部應用（并且一直在維護），幫助我們為每個集群模板化、渲染并應用配置，無論是我們的生產集群，還是任何內部的預發布集群。

擁有一個單一的工具，能夠讓我們使用模板和靜態配置，證明在確保我們始終擁有“配置真相源”和擁有合理的測試與應用變更流程方面是無價的。

我們都知道 Kubernetes 和容器化領域變化發展非常迅速——歡迎在評論中分享你們使用的其他工具，幫助你們更輕松地管理 Kubernetes 配置！

擴展與收縮的調優 — 應對流量激增與請求收縮

我們投入了大量精力，確保我們的應用資源請求是根據真實的資源利用情況進行合理調整的。這在很大程度上幫助了 Medium[3] 達到現在的狀態，使我們能夠更高效地使用節點（實現了更有效的資源優化）。此外，這也使得我們的擴展過程更加平穩，但這也需要額外的調優和工具來幫助我們實現這一目標。

Cluster Over-Provisioner & Pod Preemption

這個工具[4]非常棒。對于它的過度簡化解釋是：你定義副本的數量以及它們所需的資源量。在我們的案例中，我們知道需要根據流量進行最大擴展的服務（我們稱之為 backend-A）也需要大量的資源。一旦我們理解了擴展事件的特征，我們就知道了應該為多少副本做規劃以及如何調整它們的資源配置。

假設我們有頻繁的流量激增，并且這個服務需要大約 200 個額外的 Pod （跨所有四個集群）來開始處理請求。如果這些Pod沒有及時擴展，我們就會看到 5xx 錯誤的急劇增加。

我們在每個集群中設置了 cluster-overprovisioner，要求它請求比 backend-A Pod 略多的 CPU 和內存資源，并將副本數設置為 50（因為這是每個集群獨立配置的）。通過 Priority & preemption[5] 和正確配置的cluster-autoscaler[6]，我們獲得了以下好處：

? Cluster Over-Provisioner 的目標是在任何給定時刻，確保為擴展事件提供 200 個額外 backend-A Pods 所需的資源。

? 當新的 backend-A Pods 需要調度時，Cluster Over-Provisioner 的 Pods 會被搶占（即驅逐[7]），以為它們騰出資源。

? 隨著 Over-Provisioner 的 Pods 被驅逐，它們仍然需要重新調度。因此，它們會通過 ckuster-autoscaler 觸發節點擴展事件。

因此，Cluster Over-Provisioner 本質上吸收了節點擴展事件中的延遲，并為我們提供了足夠的空間，確保生產服務的擴展事件能夠順利進行且不受中斷。

另一個好處是，我們的節點計數圖表看起來比以前更加平滑了。我們不再需要像以前那樣頻繁地擴展節點。

圖片

在進行 Over-Provisioner 和資源優化之前，所有 4 個集群的總節點數經常突破 800 到 900 個節點。

圖片

在進行 Over-Provisioner 和應用程序資源優化后，所有生產集群的節點數峰值降至接近 400 個節點，且峰值幾乎不再突破 600 個節點。

結語

Kubernetes 具有極高的復雜性，并且根據組織的需求，它可以有無限多種可能的配置。在 Medium，我們非常自豪能夠將 Kubernetes 調整到符合我們自身需求的狀態。盡管如此，這并沒有減少我們探索新方法以增強基礎設施的熱情，同時我們也在不斷利用新技術，幫助提升系統的可靠性和可擴展性。

原文：https://medium.com/medium-eng/kubernetes-infrastructure-at-medium-d9e2444932ef

引用鏈接

[1] 拓撲的機制:https://kubernetes.io/docs/concepts/services-networking/

[2]Istio:https://istio.io/

[3]Medium:https://medium.com/

[4]工具:https://github.com/deliveryhero/helm-charts/tree/master/stable/cluster-overprovisioner

[5]Priority & preemption:??https://kubernetes.io/docs/concepts/scheduling-eviction/pod-priority-preemption/

[6]cluster-autoscaler:https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler

[7]即驅逐:https://kubernetes.io/docs/concepts/scheduling-eviction/pod-priority-preemption/#preemption