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

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

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

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

社交媒體就是社交媒體: 關(guān)于幾乎所有技術(shù)主題的辯論，包括“Kubernetes 單槍匹馬讓我們的行業(yè)倒退了十年”，正如 Kelsey Hightower所說。或者 37signals退云并避開 Kubernetes 的舉動。

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

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

在我看來，討論Kubernetes的價值和成本不應(yīng)僅僅局限于“服務(wù)器與無服務(wù)器”或“簡單與復(fù)雜”。而應(yīng)該關(guān)注在什么時候(假設(shè)這一點(diǎn)確實(shí)存在)，Kubernetes的好處開始超過其帶來的挑戰(zhàn)。

因此，讓我們關(guān)注Kubernetes現(xiàn)狀，它的優(yōu)勢，并尋找避免其復(fù)雜性的方法。

聲明: 出現(xiàn)一些供應(yīng)商的名稱或標(biāo)志。我不為任何廠商效力，也不應(yīng)將其解釋為建議優(yōu)于可能存在的類似解決方案。

多功能性

Kubernetes無所不在: 它可以促進(jìn)各種工作負(fù)載在各種環(huán)境中運(yùn)行:

圖片

Kubernetes無所不在

如上圖所示，可以在從大型云到小型云，再到內(nèi)部數(shù)據(jù)中心甚至邊緣計(jì)算的各種環(huán)境中運(yùn)行Kubernetes。

關(guān)注工作負(fù)載類型，Kubernetes可以做很多事情。但也存在Kubernetes可能不特別適合的工作負(fù)載類型。在單體方面，可以想象(遺留)的大型機(jī)?；螂y以容器化的基于VM的應(yīng)用程序。

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

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

Kubernetes 可以為其用戶提供標(biāo)準(zhǔn)化的工作方式(大致是:將 YAML 放入集群)，為平臺團(tuán)隊(duì)提供統(tǒng)一的方式來支持工程團(tuán)隊(duì)(大致是:幫助擬定適當(dāng)?shù)?YAML 并幫助將 YAML 放入集群)。它可以通過利用和集成大型云平臺的托管服務(wù)來做到這一點(diǎn)，而不是試圖替換它們?nèi)俊?/p>

關(guān)于這種標(biāo)準(zhǔn)化我將在后面詳細(xì)說明。

為什么以及如何

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

如本博客文章的標(biāo)題所示，明確回答“我們?yōu)槭裁词褂?Kubernetes？”這個問題很重要。但如果“Kubernetes”是組織面臨的各種挑戰(zhàn)的邏輯答案，那么這可能會更好。例如:

• 我們?nèi)绾斡行н\(yùn)行大量容器化的工作負(fù)載？
• 我們?nèi)绾巫屢粋€云專家團(tuán)隊(duì)通過提供黃金路徑和防護(hù)欄來賦能許多工程團(tuán)隊(duì)？
• 我們?nèi)绾我耘c我們已經(jīng)有的軟件交付流程保持一致的方式在邊緣運(yùn)行應(yīng)用程序？
• 我們?nèi)绾卧试S工程團(tuán)隊(duì)在我們內(nèi)部的數(shù)據(jù)中心部署應(yīng)用程序？
• 我們?nèi)绾卧跒槲覀冎匾牡胤教峁╈`活性的同時，標(biāo)準(zhǔn)化我們的工作方式？
• 我們?nèi)绾未_保我們投資的知識和工具盡可能廣泛適用(例如不限于單一云供應(yīng)商)？

是的，最后一點(diǎn)聽起來有“多云”和“供應(yīng)商鎖定”的意思。明確一點(diǎn): 僅僅因?yàn)槠渌胤接?jì)算更便宜就切換云，幾乎從不劃算。僅僅為了“多云”而使用多云的公共部分，也幾乎從不劃算。供應(yīng)商鎖定無處不在，不僅僅是在選擇云時。但是，從多年的時間跨度來看，組織可能會看到專注于跨供應(yīng)商邊界適用的技術(shù)的優(yōu)勢。

建造摩天大樓

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

圖片

建立平臺

在底部，我們找到了基礎(chǔ)。它之所以在那里，是因?yàn)樗枰谀抢?，但沒有人單純?yōu)榱擞袀€基礎(chǔ)而建立基礎(chǔ)。在 Kubernetes 的術(shù)語中，基礎(chǔ)包括網(wǎng)絡(luò)(CNI)、存儲(CSI)、容器運(yùn)行時(CRI)、虛擬機(jī)或裸機(jī)服務(wù)器以及操作系統(tǒng)等組件。

接下來是地下室。與基礎(chǔ)類似，這不是最終目標(biāo)(除非你在建地下停車場且上面是一個公園)。它容納了你通常認(rèn)為理所當(dāng)然的東西。設(shè)備、維護(hù)間、管道等等。在 Kubernetes 中，這對應(yīng)于在上線之前需要的一些基本要求: 可觀測性和安全性。證書管理?？赡苁且粋€策略引擎。

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

現(xiàn)在，對于每個組件，可以爭論它是基礎(chǔ)、地下室還是建筑。也許 ArgoCD 和 KEDA 更像地下室而不是建筑?？赡?CSI 也是地下室，而不是基礎(chǔ)，因?yàn)槟憧梢韵鄬θ菀椎靥砑踊騽h除存儲類。

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

• 變得越來越明顯
• 一般來說隨著時間的推移變得更容易適應(yīng)
• 從只是成本變?yōu)楫a(chǎn)生價值

關(guān)注點(diǎn): 不要無處不在

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

與此同時，你只能在堅(jiān)實(shí)的基礎(chǔ)之上建造。地下室也不應(yīng)該坍塌。

我們需要關(guān)注點(diǎn)。如果在大型云中運(yùn)行，所有基礎(chǔ)組件以預(yù)制的方式存在。我們應(yīng)該首先考慮這些。

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

在邊緣運(yùn)行時，關(guān)注操作系統(tǒng)和網(wǎng)絡(luò)至關(guān)重要:我們需要能夠在不破壞網(wǎng)絡(luò)和鎖定自己的情況下安全地更新遠(yuǎn)程設(shè)備。另一方面，在云中運(yùn)行時，優(yōu)先考慮云供應(yīng)商提供的解決方案，就此打住。

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

復(fù)雜性預(yù)算

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

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

只要我們在資本支出上的花費(fèi)最終減少或者至少穩(wěn)定我們的整體運(yùn)營支出，我們的運(yùn)營就是可持續(xù)的。如果不是，如果運(yùn)營支出占了上風(fēng)，我們就會遇到問題。

圖片

能力

這并不意味著我們永遠(yuǎn)不應(yīng)該向我們的平臺添加任何組件。當(dāng)我們的運(yùn)營范圍擴(kuò)大時，復(fù)雜性也會增加。我們需要應(yīng)對這一點(diǎn)的方法。順便說一句，這不僅僅是Kubernetes所特有的。

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

當(dāng)避開了地表以下的一些復(fù)雜性陷阱時，Kubernetes 提供的統(tǒng)一 API 和工作方式就可以開始產(chǎn)生回報。讓我們舉個例子:

挑戰(zhàn): 我們有一個 Kubernetes 設(shè)置。團(tuán)隊(duì)正在部署應(yīng)用程序。然而，我們注意到工作負(fù)載有時無法承受重新調(diào)度。此外，一致的標(biāo)記也有點(diǎn)問題。

改進(jìn): 我們添加了一個策略引擎。這有助于我們實(shí)施良好的實(shí)踐。

新狀態(tài): 團(tuán)隊(duì)將 YAML 放入集群。集群有時會說不。

挑戰(zhàn): 我們注意到我們開始有很多部署流水線。而且它們都略有不同。我們越來越難以將我們集群中應(yīng)運(yùn)行的內(nèi)容與這些流水線關(guān)聯(lián)起來，而這些流水線主要由各個工程團(tuán)隊(duì)管理。

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

新狀態(tài): 團(tuán)隊(duì)將 YAML 放入 git。GitOps 將 YAML 放入集群。集群機(jī)制使事情發(fā)生。

挑戰(zhàn): 一些團(tuán)隊(duì)注意到他們需要比基于 CPU 的工作負(fù)載縮放更“智能”的東西。

改進(jìn): 平臺團(tuán)隊(duì)設(shè)置 KEDA。由于已經(jīng)有了一個策略引擎，所以很容易為 KEDA 縮放器配置設(shè)置一些防護(hù)欄。

新狀態(tài)，就像以前一樣: 團(tuán)隊(duì)將 YAML 放入 git。GitOps 將 YAML 放入集群。集群機(jī)制使事情發(fā)生。

挑戰(zhàn): 平臺團(tuán)隊(duì)注意到大多數(shù)需要為工程團(tuán)隊(duì)完成的更改歸結(jié)為相同的事情:為新服務(wù)提供命名空間、工件存儲庫、數(shù)據(jù)庫、Redis、流水線、IAM 標(biāo)識或隊(duì)列。

改進(jìn): 在 POC 之后，平臺團(tuán)隊(duì)決定設(shè)置 Crossplane，調(diào)整策略引擎以允許一組受控的 Crossplane 資源，并提供防護(hù)措施?，F(xiàn)在，團(tuán)隊(duì)可以自己設(shè)置資源。與此同時，平臺團(tuán)隊(duì)可以繼續(xù)關(guān)注提供和維護(hù)這種能力，而不會被“大量類似任務(wù)”淹沒。

新狀態(tài)，就像以前一樣: 團(tuán)隊(duì)將 YAML 放入 git。GitOps 將 YAML 放入集群。集群機(jī)制使事情發(fā)生。

挑戰(zhàn): 平臺團(tuán)隊(duì)注意到跟蹤組件更新需要越來越多的努力。

改進(jìn): 在 POC 之后，他們設(shè)置了Renovate。現(xiàn)在，平臺團(tuán)隊(duì)不再需要檢查平臺中運(yùn)行的每個組件的發(fā)布頁面。

新狀態(tài)，與以前非常相似: Renovate 將 YAML 放入 git。GitOps 將 YAML 放入集群。集群機(jī)制使事情發(fā)生。

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

API 思維方式

在采用 Kubernetes 時，根據(jù)組織、經(jīng)驗(yàn)和文化的不同，可能會有不同的視角:

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

前者傾向于避免更改并專注于正常運(yùn)行時間。

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

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

不要: 設(shè)置對服務(wù)器的 shell 訪問以用于管理目的。

而要: 關(guān)注如何避免登錄(生產(chǎn))服務(wù)器的需要。我們需要發(fā)送出什么可觀測性數(shù)據(jù)？我們?nèi)绾卧趯?shí)驗(yàn)室設(shè)置中重現(xiàn)錯誤場景？

不要: 研究如何就地修補(bǔ)節(jié)點(diǎn)，以及伴隨而來的整個編排、檢查和重啟過程。

而要:考慮不可變的基礎(chǔ)設(shè)施。經(jīng)常用打了補(bǔ)丁的節(jié)點(diǎn)簡單替換舊節(jié)點(diǎn)。這是一個易于重現(xiàn)(在非生產(chǎn)環(huán)境中測試)和可逆的過程。額外收益:混沌工程。

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

而要:關(guān)注不可變基礎(chǔ)設(shè)施和cloud-init，執(zhí)行絕對必要的少量安裝步驟。

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

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

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

結(jié)論(也稱 TL;DR)

在一定規(guī)模下，隨著團(tuán)隊(duì)數(shù)量的增加，組織將面臨以下挑戰(zhàn):

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

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

大規(guī)模運(yùn)行時，Kubernetes在2024年也可以成為構(gòu)建這種平臺工程的合適技術(shù)棧。但風(fēng)險很高:可能帶來巨大回報，但在開始回饋之前需要前期投入。這對進(jìn)入構(gòu)成了一定的風(fēng)險和障礙。

圖片

比較技術(shù)棧

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

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

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

• 需要在云中運(yùn)行“一些”應(yīng)用程序的創(chuàng)業(yè)公司?除非您對此有明確目標(biāo)，否則不要首先構(gòu)建 Kubernetes。
• 沒有集中式平臺團(tuán)隊(duì)的自治團(tuán)隊(duì)?您需要_一些東西_來避免每個團(tuán)隊(duì)稍微不同地重造 DevOps 車輪?？梢允?Kubernetes。
• 實(shí)際上并沒有運(yùn)行太多容器，而是使用無服務(wù)器?太棒了，建立您的組織以持續(xù)改進(jìn)_那個_技術(shù)棧。不要因?yàn)椤叭藗冋谑褂?Kubernetes”而考慮 Kubernetes。

明智地花費(fèi)您的復(fù)雜性預(yù)算。選擇 Kubernetes 時，關(guān)注 API，您甚至可能會忘記服務(wù)器。

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

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