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