作者丨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 通常因其具有挑戰性的學習之旅而得到認可。是什麼導致了這種複雜性？為了清楚起見，我根據特定標準策劃了一份主題列表，以幫助衡量提高技能所需的努力。
注意：這些複雜程度將根據個人背景和先前的經驗而有所不同。
對於缺乏必要專業知識或學習時間的團隊，整個開發和部署過程可能會變得不堪重負且緩慢，這對於時間緊迫或團隊較小的項目來說並不健康。
四、成本影響是什麼？
雖然 Kubernetes 本身是開源和免費的，但運行它卻不是。你需要考慮與基礎架構相關的費用，包括伺服器、存儲和網絡的成本以及隱性成本。
第一個隱性成本在於其管理和維護——用於培訓團隊、故障排除、維護系統、維護內部工作流程和自助服務基礎設施的時間和資源。
由於各種原因，在計算成熟的 Kubernetes 環境的成本時，許多人忽略了這項工作所需的高技能員工的薪水。警惕完全託管或無伺服器產品與自我管理的 Kubernetes 之間的許多有缺陷的比較。他們通常無法考慮員工成本以及與 Kubernetes 時間損失相關的機會成本。
第二個隱性成本與 Kubernetes 生態系統有關。擁抱 Kubernetes 的世界通常不僅僅意味著採用容器編排平台。這就像踏上一個廣闊的大陸，擁有豐富的功能以及各種供應商提供的輔助工具、服務和產品的整個宇宙，最終會帶來其他成本。
五、結論
一個好的工具不在於它的炒作或受歡迎程度，而在於它如何解決你的問題並融入你的生態系統。在雲原生應用程式的領域，Kubernetes在對話中占據了相當大的份額，這是可以理解的。但是，我鼓勵團隊考慮通過OpenShift，Docker Swarm或由Nitric等框架編排的無伺服器和託管服務等解決方案實現的不同方法的權衡。
原文連結：https://thenewstack.io/kubernetes-isnt-always-the-right-choice/