在這篇博客中，我將討論如何通過專注于 Kubernetes 的 API 來釋放其潛力，同時盡量避免可能遇到的復雜性。了解如何以及是否可以讓 Kubernetes 為您發揮作用。

譯自Why Kubernetes? Focus on the API， not the servers。作者 Tibo Beijen 。

隨著我們從 2023 年進入 2024 年，現在是進行反思的好時機。無可爭議，去年最大的話題之一是 AI 的興起。但是離我的日常工作更近一些，有一些事件特別引人注目:

亞馬遜Prime 從無服務器微服務轉向“單體”的博文。隨后有大量的溫吞吞的點擊誘導文和“我的技術棧比你的好”類型的討論。從Jeremy Daly 的這篇文章開始，挑選關于這個主題的一些必讀和避免的文章。

社交媒體就是社交媒體: 關于幾乎所有技術主題的辯論，包括“Kubernetes 單槍匹馬讓我們的行業倒退了十年”，正如 Kelsey Hightower所說?；蛘?37signals退云并避開 Kubernetes 的舉動。

Datadog 的宕機。由多種因素共同導致，可以用關鍵詞概括: Kubernetes、Cilium、eBPF、Systemd、OS 更新。Gergely Orosz(The Pragmatic Engineer)對此進行了很好的解釋。

使用并喜歡Kubernetes，閱讀所有上述內容，很容易會反思這個問題“我卷入了什么？”?；蛘咴诟鼜V泛的意義上: “我們這個行業卷入了什么？”。

在我看來，討論Kubernetes的價值和成本不應僅僅局限于“服務器與無服務器”或“簡單與復雜”。而應該關注在什么時候(假設這一點確實存在)，Kubernetes的好處開始超過其帶來的挑戰。

因此，讓我們關注Kubernetes現狀，它的優勢，并尋找避免其復雜性的方法。

聲明: 出現一些供應商的名稱或標志。我不為任何廠商效力，也不應將其解釋為建議優于可能存在的類似解決方案。

多功能性

Kubernetes無所不在: 它可以促進各種工作負載在各種環境中運行:

圖片

Kubernetes無所不在

如上圖所示，可以在從大型云到小型云，再到內部數據中心甚至邊緣計算的各種環境中運行Kubernetes。

關注工作負載類型，Kubernetes可以做很多事情。但也存在Kubernetes可能不特別適合的工作負載類型。在單體方面，可以想象(遺留)的大型機。或難以容器化的基于VM的應用程序。

大型云平臺提供大量托管服務，包括數據庫、內存存儲、消息組件以及專注于AI/ML和大數據的服務。對于這些服務，你_可以_在Kubernetes內運行與云和平臺無關的原生云替代方案。但這需要更多前期工作，潛在收益因情況而異。

然后在微的另一端，大型云平臺提供“無服務器”: 函數即服務，通常與 API 網關等組件緊密集成，并具有用于事件驅動架構的構建塊。例如，可以決定在 Kubernetes 中運行這些函數，使用Knative。但這需要先設置和支持這些組件，而在這方面，云更容易上手。另外，無服務器以快速擴展和縮放到零作為區別特征。

Kubernetes 可以為其用戶提供標準化的工作方式(大致是:將 YAML 放入集群)，為平臺團隊提供統一的方式來支持工程團隊(大致是:幫助擬定適當的 YAML 并幫助將 YAML 放入集群)。它可以通過利用和集成大型云平臺的托管服務來做到這一點，而不是試圖替換它們全部。

關于這種標準化我將在后面詳細說明。

為什么以及如何

作為一個組織，重要的是要很好地理解為什么選擇一個(技術)策略以及期望是什么。

如本博客文章的標題所示，明確回答“我們為什么使用 Kubernetes？”這個問題很重要。但如果“Kubernetes”是組織面臨的各種挑戰的邏輯答案，那么這可能會更好。例如:

• 我們如何有效運行大量容器化的工作負載？
• 我們如何讓一個云專家團隊通過提供黃金路徑和防護欄來賦能許多工程團隊？
• 我們如何以與我們已經有的軟件交付流程保持一致的方式在邊緣運行應用程序？
• 我們如何允許工程團隊在我們內部的數據中心部署應用程序？
• 我們如何在為我們重要的地方提供靈活性的同時，標準化我們的工作方式？
• 我們如何確保我們投資的知識和工具盡可能廣泛適用(例如不限于單一云供應商)？

是的，最后一點聽起來有“多云”和“供應商鎖定”的意思。明確一點: 僅僅因為其他地方計算更便宜就切換云，幾乎從不劃算。僅僅為了“多云”而使用多云的公共部分，也幾乎從不劃算。供應商鎖定無處不在，不僅僅是在選擇云時。但是，從多年的時間跨度來看，組織可能會看到專注于跨供應商邊界適用的技術的優勢。

建造摩天大樓

采用 Kubernetes 的過程中，在 Kubernetes 開始產生價值之前，需要設置很多東西。我們正在建造一個平臺。讓我們用物理世界建筑的類比來說明:

圖片

建立平臺

在底部，我們找到了基礎。它之所以在那里，是因為它需要在那里，但沒有人單純為了有個基礎而建立基礎。在 Kubernetes 的術語中，基礎包括網絡(CNI)、存儲(CSI)、容器運行時(CRI)、虛擬機或裸機服務器以及操作系統等組件。

接下來是地下室。與基礎類似，這不是最終目標(除非你在建地下停車場且上面是一個公園)。它容納了你通常認為理所當然的東西。設備、維護間、管道等等。在 Kubernetes 中，這對應于在上線之前需要的一些基本要求: 可觀測性和安全性。證書管理。可能是一個策略引擎。

最后，我們進入地面以上。這就是我們要建造的: 有目的的建筑！在 Kubernetes 的術語中，這些顯然是被部署的應用程序。但也包括增強我們平臺能力的組件。例如 ArgoCD/Flux(使用 GitOps 進行高效部署)、Argo Workflows(工作流引擎)和 KEDA(更智能的擴展)。

現在，對于每個組件，可以爭論它是基礎、地下室還是建筑。也許 ArgoCD 和 KEDA 更像地下室而不是建筑。可能 CSI 也是地下室，而不是基礎，因為你可以相對容易地添加或刪除存儲類。

重要的是，從地下向地面以上，我們可以觀察到組件:

• 變得越來越明顯
• 一般來說隨著時間的推移變得更容易適應
• 從只是成本變為產生價值

關注點: 不要無處不在

組織需要小心，不要花費大量時間在基礎和地下室上，同時缺乏資源在地面以上建造好東西。

與此同時，你只能在堅實的基礎之上建造。地下室也不應該坍塌。

我們需要關注點。如果在大型云中運行，所有基礎組件以預制的方式存在。我們應該首先考慮這些。

同樣，在地下室層面，我們可以花很多時間建立一個可觀測性平臺。但存在各種 SaaS 解決方案或云提供商提供的解決方案。安全性也是如此。如果預制組件不滿足要求，仔細檢查這些要求。我們確定擬議的更簡單的解決方案是否“足夠好”嗎？我們能否現在滿足于一些簡單的東西，以后再改進？

在邊緣運行時，關注操作系統和網絡至關重要:我們需要能夠在不破壞網絡和鎖定自己的情況下安全地更新遠程設備。另一方面，在云中運行時，優先考慮云供應商提供的解決方案，就此打住。

在私有環境運行時，我們可能需要高性能的存儲解決方案和有狀態工作負載的備份解決方案。但是在云中運行時，我們不需要在Kubernetes中自己搭建數據庫?？紤]使用托管數據庫，提供您需要的所有大小調整選項和點時恢復。使用與S3兼容的對象存儲來存儲文件。使用SaaS進行可觀測性，避免存儲所有日志，指標和追蹤。這樣可以使存儲需求最小化，使我們的設置保持簡單。

復雜性預算

向集群添加的任何自定義或組件都會增加復雜性。它需要第1天的設置和第2天的維護，并且通過這種方式，它需要資源。這意味著我們可以承受的復雜性數量是有限的。

盡管根據您詢問的人，定義的邊界可能會有所不同，但我們可以將我們平臺上的每項自定義或添加視為資本支出: 這是我們希望從中獲得投資回報的前期費用。

只要我們在資本支出上的花費最終減少或者至少穩定我們的整體運營支出，我們的運營就是可持續的。如果不是，如果運營支出占了上風，我們就會遇到問題。

圖片

能力

這并不意味著我們永遠不應該向我們的平臺添加任何組件。當我們的運營范圍擴大時，復雜性也會增加。我們需要應對這一點的方法。順便說一句，這不僅僅是Kubernetes所特有的。

這確實意味著我們應該考慮什么時候添加組件以及它們對未來的整體工作量有何影響。

當避開了地表以下的一些復雜性陷阱時，Kubernetes 提供的統一 API 和工作方式就可以開始產生回報。讓我們舉個例子:

挑戰: 我們有一個 Kubernetes 設置。團隊正在部署應用程序。然而，我們注意到工作負載有時無法承受重新調度。此外，一致的標記也有點問題。

改進: 我們添加了一個策略引擎。這有助于我們實施良好的實踐。

新狀態: 團隊將 YAML 放入集群。集群有時會說不。

挑戰: 我們注意到我們開始有很多部署流水線。而且它們都略有不同。我們越來越難以將我們集群中應運行的內容與這些流水線關聯起來，而這些流水線主要由各個工程團隊管理。

改進: 我們添加了 GitOps。我們現在有一個單一的窗口，基于拉取請求的工作流程來部署更新。我們已經有基于 PR 的工作流程，所以這很合適。當然，我們可以自動化某些更新，以避免不必要的拉取請求。同樣值得注意的是，通過分離 CI 和 CD 流水線，我們的流水線可以變得非常簡單。

新狀態: 團隊將 YAML 放入 git。GitOps 將 YAML 放入集群。集群機制使事情發生。

挑戰: 一些團隊注意到他們需要比基于 CPU 的工作負載縮放更“智能”的東西。

改進: 平臺團隊設置 KEDA。由于已經有了一個策略引擎，所以很容易為 KEDA 縮放器配置設置一些防護欄。

新狀態，就像以前一樣: 團隊將 YAML 放入 git。GitOps 將 YAML 放入集群。集群機制使事情發生。

挑戰: 平臺團隊注意到大多數需要為工程團隊完成的更改歸結為相同的事情:為新服務提供命名空間、工件存儲庫、數據庫、Redis、流水線、IAM 標識或隊列。

改進: 在 POC 之后，平臺團隊決定設置 Crossplane，調整策略引擎以允許一組受控的 Crossplane 資源，并提供防護措施。現在，團隊可以自己設置資源。與此同時，平臺團隊可以繼續關注提供和維護這種能力，而不會被“大量類似任務”淹沒。

新狀態，就像以前一樣: 團隊將 YAML 放入 git。GitOps 將 YAML 放入集群。集群機制使事情發生。

挑戰: 平臺團隊注意到跟蹤組件更新需要越來越多的努力。

改進: 在 POC 之后，他們設置了Renovate?，F在，平臺團隊不再需要檢查平臺中運行的每個組件的發布頁面。

新狀態，與以前非常相似: Renovate 將 YAML 放入 git。GitOps 將 YAML 放入集群。集群機制使事情發生。

上述更改不是一夜之間就能實現的。此外，它們有時涉及改變一個組織中的工作方式，這通常比技術部分更難。然而，它們確實展示了，在一個地方謹慎地承擔額外的復雜性，可以減少組織內的整體運營工作量。

API 思維方式

在采用 Kubernetes 時，根據組織、經驗和文化的不同，可能會有不同的視角:

• 自下而上: “我們運行服務器，并在其上面部署 Kubernetes”
• 自上而下: “我們運行 Kubernetes，碰巧需要服務器”

前者傾向于避免更改并專注于正常運行時間。

后者將頻繁的受控更改視為滿足各種需求的一種手段。

這是一個細微的區別，但你可能已經猜到了，在使用 Kubernetes 時，自上而下的思維方式更合適。長期來看，它將帶來一個更易于維護的平臺。一些例子:

不要: 設置對服務器的 shell 訪問以用于管理目的。

而要: 關注如何避免登錄(生產)服務器的需要。我們需要發送出什么可觀測性數據？我們如何在實驗室設置中重現錯誤場景？

不要: 研究如何就地修補節點，以及伴隨而來的整個編排、檢查和重啟過程。

而要:考慮不可變的基礎設施。經常用打了補丁的節點簡單替換舊節點。這是一個易于重現(在非生產環境中測試)和可逆的過程。額外收益:混沌工程。

不要:使用Ansible在服務器上“做事情”

而要:關注不可變基礎設施和cloud-init，執行絕對必要的少量安裝步驟。

不要:使用可觀測性代理、EDR代理等擴展VM鏡像

而要:更青睞daemonsets，根據需要具有安全上下文，來運行這些進程。記住飛輪效應:我們已經有方法可以輕松地將工作負載放入集群，并具備監控組件的所有可觀測性。此外，Renovate 將幫助我們保持組件的更新。

上述的重點是，我們需要避免最終落入十年前的狀況(管理大量VM)，另外，還要管理大量Kubernetes的移動部件。我們需要利用Kubernetes使VM管理部分變得更容易，或完全消除。這將留出空間來關注平臺和開發人員體驗。

結論(也稱 TL;DR)

在一定規模下，隨著團隊數量的增加，組織將面臨以下挑戰:

如何提供防護欄而不會最終造就門檻?

合規、安全、成本效益、性能和災難恢復等主題都需要解決。將這些問題委托給每個團隊處理既沒有效率，對團隊也是一個干擾，而且要求每個團隊對這些主題有足夠的知識。因此，組織需要一種方法來整合這些知識，并將其應用于所有團隊。簡而言之，這就是為什么“DevOps”這個流行詞語現在被“平臺工程”所取代的原因。

大規模運行時，Kubernetes在2024年也可以成為構建這種平臺工程的合適技術棧。但風險很高:可能帶來巨大回報，但在開始回饋之前需要前期投入。這對進入構成了一定的風險和障礙。

圖片

比較技術棧

如上圖所示，在技術棧之間，存在收支平衡點。請注意，這是概括性的: 是否存在以及收支平衡點在哪里取決于組織是否成功控制總體工作量在限定范圍內。我們可以了解到的是，由于其本質，Kubernetes非常適合縮放初始工作量到許多團隊。

如果不主要關注規模: 在邊緣運行時，Kubernetes可能會成為一個有趣的選擇，它自然地集成到您運行集中式應用程序的方式中。

然而，Kubernetes可能根本不適合您的組織:

• 需要在云中運行“一些”應用程序的創業公司?除非您對此有明確目標，否則不要首先構建 Kubernetes。
• 沒有集中式平臺團隊的自治團隊?您需要_一些東西_來避免每個團隊稍微不同地重造 DevOps 車輪。可以是 Kubernetes。
• 實際上并沒有運行太多容器，而是使用無服務器?太棒了，建立您的組織以持續改進_那個_技術棧。不要因為“人們正在使用 Kubernetes”而考慮 Kubernetes。

明智地花費您的復雜性預算。選擇 Kubernetes 時，關注 API，您甚至可能會忘記服務器。

只要避免陷入表面以下而忘記享受陽光即可。

1. 避免過濾泡沫，過濾無意義的噪音和僅為了引發互動的隨機事物列表，社交媒體上仍有許多洞見和觀點可以獲取。
2. 幸運的是，現在有足夠的工具可以滿足任何人對純 YAML、模板化 YAML、編程 YAML 或轉換為 YAML 的 JSON 的偏好。
3. 查看團隊拓撲，當我提到“平臺團隊”或簡單的“團隊”時，它們分別指“平臺團隊”和“流一致型團隊”。
4. 罪過，去過那里。與管理 daemonset 相比，擴展 AWS AMI 非常麻煩。