引言

我們?nèi)绾问褂?Kubernetes 來管理微服務——概覽與介紹

為什么選擇Kubernetes？

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

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

我們?nèi)绾问褂?Kubernetes 呢？

圖片

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

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

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

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

在生產(chǎn)環(huán)境中逐步發(fā)布基礎設施變更

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

我們選擇的服務網(wǎng)格是 Istio[2]。我們使用多種自研控制器來管理我們的入口和出口網(wǎng)關(guān)，確保從我們的 CDN 到四個集群之間的流量配置和協(xié)調(diào)順暢。這里就不再展開討論了（這個話題本身就足夠?qū)懸黄暾奈恼铝耍。?/p>

配置與管理

Terraform 和一些自研工具是我們管理集群配置的首選工具。在團隊最初構(gòu)思 Kubernetes 配置時，市面上并沒有很多工具能幫助簡化 Terraform 的使用。于是，我們開發(fā)了一個內(nèi)部應用（并且一直在維護），幫助我們?yōu)槊總€集群模板化、渲染并應用配置，無論是我們的生產(chǎn)集群，還是任何內(nèi)部的預發(fā)布集群。

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

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

擴展與收縮的調(diào)優(yōu) — 應對流量激增與請求收縮

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

Cluster Over-Provisioner & Pod Preemption

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

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

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

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

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

? 隨著 Over-Provisioner 的 Pods 被驅(qū)逐，它們?nèi)匀恍枰匦抡{(diào)度。因此，它們會通過 ckuster-autoscaler 觸發(fā)節(jié)點擴展事件。

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

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

圖片

在進行 Over-Provisioner 和資源優(yōu)化之前，所有 4 個集群的總節(jié)點數(shù)經(jīng)常突破 800 到 900 個節(jié)點。

圖片

在進行 Over-Provisioner 和應用程序資源優(yōu)化后，所有生產(chǎn)集群的節(jié)點數(shù)峰值降至接近 400 個節(jié)點，且峰值幾乎不再突破 600 個節(jié)點。

結(jié)語

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

原文：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]即驅(qū)逐:https://kubernetes.io/docs/concepts/scheduling-eviction/pod-priority-preemption/#preemption