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