作者丨Rak Siva
編譯丨Noe
如今，你幾乎可以將任何應(yīng)用程序封裝在容器中以供執(zhí)行。容器解決了很多問題，但它們帶來了新的編排挑戰(zhàn)。由于大量致力于構(gòu)建云原生應(yīng)用程序的團隊對容器編排的需求不斷增長，Kubernetes 作為解決這一挑戰(zhàn)的強大工具而廣受歡迎。
在管理良好的 Kubernetes 環(huán)境中構(gòu)建提供了許多好處，例如自動縮放、自我修復(fù)、服務(wù)發(fā)現(xiàn)和負(fù)載平衡。然而，擁抱 Kubernetes 的世界通常意味著不僅僅是采用容器編排技術(shù)。團隊需要戰(zhàn)略性地考慮，“Kubernetes 是我的正確選擇嗎？”他們必須通過評估這個更廣泛問題的幾個組成部分來做到這一點。
一、我的團隊組成是否適合 Kubernetes？
不乏贊揚 Kubernetes （K8s） 功能的文章，這不是我們要爭論的。在許多情況下，K8s 是正確的選擇。也就是說，與 K8s 的直接交互和維護并不適合所有團隊和項目。
1、擁有云原生應(yīng)用程序的小型初創(chuàng)公司：這些團隊會發(fā)現(xiàn) Kubernetes 的直接管理是一種復(fù)雜、耗時的分散注意力，無法實現(xiàn)他們發(fā)布和擴展產(chǎn)品的目標(biāo)。鑒于他們的規(guī)模，團隊將沒有足夠的帶寬來管理 Kubernetes 集群，同時也開發(fā)他們的應(yīng)用程序。
2、具有各種應(yīng)用程序類型的企業(yè)團隊：對于具有專業(yè)技能的大型團隊，Kubernetes 是一個很好的選擇。但是，仍應(yīng)考慮完全托管的容器運行時或 Kubernetes 即服務(wù)產(chǎn)品。這些服務(wù)允許有限的 DevOps 資源專注于團隊生產(chǎn)力、開發(fā)人員自助服務(wù)、成本管理和其他關(guān)鍵項目。
3、具有 DevOps 文化的中型公司：雖然這些團隊為遷移到 Kubernetes 做好了更充分的準(zhǔn)備，但這是一個重大項目，將破壞現(xiàn)有的工作流程。同樣，托管產(chǎn)品無需大量投資即可釋放 Kubernetes 的許多好處。
4、軟件咨詢：雖然這些團隊適應(yīng)性強，但依賴 Kubernetes 可能會限制他們?yōu)榫哂胁煌枨蟮目蛻籼峁┓?wù)的能力，因為它會促使咨詢公司推薦它，即使它不是最合適的。
二、我的項目有多復(fù)雜？K8s 矯枉過正嗎？
與其確定 K8s 是否滿足你的某些要求，不如考慮確定與 Kubernetes 功能不太一致或引入不必要的復(fù)雜性的特定特征和要求。
1、最小的可擴展性需求：如果項目具有持續(xù)的低流量或可預(yù)測且穩(wěn)定的資源需求，而沒有顯著的擴展要求，則 Kubernetes 將引入不必要的開銷。在這些情況下，托管容器運行時或虛擬專用服務(wù)器 （VPS） 解決方案通常代表更好的價值。
2、簡單的單片應(yīng)用：如果項目是一個具有有限依賴項的整體應(yīng)用程序，并且不需要獨立可擴展的服務(wù)或極高的實例計數(shù)，那么 Kubernetes 對于其需求來說太復(fù)雜了。
3、靜態(tài)或有限的基礎(chǔ)結(jié)構(gòu)：如果項目具有小型或靜態(tài)基礎(chǔ)設(shè)施，而資源使用沒有太大變化，那么更簡單的部署選項（如托管服務(wù)或 VPS）就足夠了。
4、有限的開發(fā)運營資源：Kubernetes 需要容器編排方面的專業(yè)知識，這對于 DevOps 資源有限的項目或團隊不愿意投資學(xué)習(xí) Kubernetes 來說是不可行的。無需這種額外投資，仍然可以實現(xiàn)容器的好處。
5、原型設(shè)計和短期項目：對于開發(fā)生命周期較短或生產(chǎn)持續(xù)時間有限的項目，Kubernetes 開銷是合理的。
6、項目成本限制：如果項目有嚴(yán)格的預(yù)算限制，那么設(shè)置和維護 Kubernetes 集群的額外成本將不可行。在考慮完成這項工作所需的高技能團隊成員的成本時尤其如此。
7、基礎(chǔ)設(shè)施要求：Kubernetes 可能是資源密集型的，需要強大的基礎(chǔ)設(shè)施才能有效運行。如果你的項目是資源需求適中的中小型項目，則使用托管服務(wù)或無服務(wù)器更為合適。
僅憑需求的復(fù)雜性并不能決定 Kubernetes 對你的團隊來說是完美的還是過度的;但是，它可以幫助你以一種或另一種方式傾斜。如果你直接使用 Kubernetes，它本質(zhì)上不會提升你的產(chǎn)品。相反，它的優(yōu)勢在于打造一個彈性平臺，讓你的產(chǎn)品可以在此平臺上蓬勃發(fā)展。
圖片
其結(jié)果是，隨著你承諾將自己的工作置于它之下，對產(chǎn)品的開發(fā)工作將進一步遠(yuǎn)離成為業(yè)務(wù)的基礎(chǔ)。
這揭示了一個真正的問題：我們是在構(gòu)建一個平臺，還是在努力加快上市時間，為我們的核心業(yè)務(wù)目標(biāo)提供更直接的投資回報？
三、我們有必要的技能嗎？
Kubernetes 通常因其具有挑戰(zhàn)性的學(xué)習(xí)之旅而得到認(rèn)可。是什么導(dǎo)致了這種復(fù)雜性？為了清楚起見，我根據(jù)特定標(biāo)準(zhǔn)策劃了一份主題列表，以幫助衡量提高技能所需的努力。
復(fù)雜性 | 描述 |
基本 | 基本、更簡單的概念 |
中間 | 需要一些預(yù)先存在的知識的概念 |
高深 | 需要廣泛知識的復(fù)雜概念 |
注意：這些復(fù)雜程度將根據(jù)個人背景和先前的經(jīng)驗而有所不同。
學(xué)習(xí)區(qū) | 描述 | 復(fù)雜性 |
集裝箱 | 了解容器和工具，如 Docker。 | 基本 |
Kubernetes 架構(gòu) | 了解有關(guān) Pod、服務(wù)、部署、副本集、節(jié)點和集群的知識。 | 中間 |
Kubernetes API 和對象 | 了解 Kubernetes 的聲明式方法，使用 API 和 YAML。 | 中間 |
聯(lián)網(wǎng) | 了解容器間通信、服務(wù)、入口、網(wǎng)絡(luò)策略和服務(wù)網(wǎng)格。 | 高深 |
存儲 | 了解有關(guān)卷、持久卷 （PV）、持久卷聲明 （PVC） 和存儲類的知識。 | 高深 |
安全 | 了解 Kubernetes 安全性，包括 RBAC、安全上下文、網(wǎng)絡(luò)策略和 Pod 安全策略。 | 高深 |
可觀察性 | 熟悉監(jiān)控，日志記錄和跟蹤工具，如Prometheus，Grafana，F(xiàn)luentd，Jaeger。 | 中間 |
Kubernetes 中的 CI/CD | 將 Kubernetes 與 CI/CD 工具（如 Jenkins、GitLab ）集成，并使用 Helm 圖表進行部署。 | 中間 |
Kubernetes 最佳實踐 | 熟悉使用 Kubernetes 的最佳實踐和常見陷阱。 | 中級到高級 |
對于缺乏必要專業(yè)知識或?qū)W習(xí)時間的團隊，整個開發(fā)和部署過程可能會變得不堪重負(fù)且緩慢，這對于時間緊迫或團隊較小的項目來說并不健康。
四、成本影響是什么？
雖然 Kubernetes 本身是開源和免費的，但運行它卻不是。你需要考慮與基礎(chǔ)架構(gòu)相關(guān)的費用，包括服務(wù)器、存儲和網(wǎng)絡(luò)的成本以及隱性成本。
第一個隱性成本在于其管理和維護——用于培訓(xùn)團隊、故障排除、維護系統(tǒng)、維護內(nèi)部工作流程和自助服務(wù)基礎(chǔ)設(shè)施的時間和資源。
由于各種原因，在計算成熟的 Kubernetes 環(huán)境的成本時，許多人忽略了這項工作所需的高技能員工的薪水。警惕完全托管或無服務(wù)器產(chǎn)品與自我管理的 Kubernetes 之間的許多有缺陷的比較。他們通常無法考慮員工成本以及與 Kubernetes 時間損失相關(guān)的機會成本。
第二個隱性成本與 Kubernetes 生態(tài)系統(tǒng)有關(guān)。擁抱 Kubernetes 的世界通常不僅僅意味著采用容器編排平臺。這就像踏上一個廣闊的大陸，擁有豐富的功能以及各種供應(yīng)商提供的輔助工具、服務(wù)和產(chǎn)品的整個宇宙，最終會帶來其他成本。
五、結(jié)論
一個好的工具不在于它的炒作或受歡迎程度，而在于它如何解決你的問題并融入你的生態(tài)系統(tǒng)。在云原生應(yīng)用程序的領(lǐng)域，Kubernetes在對話中占據(jù)了相當(dāng)大的份額，這是可以理解的。但是，我鼓勵團隊考慮通過OpenShift，Docker Swarm或由Nitric等框架編排的無服務(wù)器和托管服務(wù)等解決方案實現(xiàn)的不同方法的權(quán)衡。
原文鏈接：https://thenewstack.io/kubernetes-isnt-always-the-right-choice/
