必看：Kubernetes 開(kāi)發(fā)環(huán)境對(duì)比
曾幾何時(shí)，Kubernetes 還被主流視為一種運(yùn)維技術(shù)，但今天的情況已經(jīng)不同了，現(xiàn)在 Kubernetes 對(duì)很多開(kāi)發(fā)人員來(lái)說(shuō)都是很重要的。正如我在有關(guān) Kubernetes 工作流的 博客文章 中所寫(xiě)的那樣，對(duì)于開(kāi)始直接接觸 Kubernetes 的開(kāi)發(fā)人員來(lái)說(shuō)，第一步工作就是設(shè)置 / 接入一個(gè) Kubernetes 開(kāi)發(fā)環(huán)境。
接入 Kubernetes 環(huán)境不僅是我們要做的第一步，而且是在工作中啟用 Kubernetes 的基本要求。盡管如此，接入這樣的環(huán)境時(shí)經(jīng)常也會(huì)出問(wèn)題：VMware 的一項(xiàng)研究甚至發(fā)現(xiàn)“訪問(wèn)基礎(chǔ)架構(gòu)是開(kāi)發(fā)人員生產(chǎn)力的最大障礙”。為此，對(duì)于所有計(jì)劃使用這種技術(shù)的團(tuán)隊(duì)來(lái)說(shuō)，Kubernetes 開(kāi)發(fā)環(huán)境都應(yīng)該具有較高的優(yōu)先級(jí)。
在本文中，我將描述和對(duì)比四種不同的 Kubernetes 開(kāi)發(fā)環(huán)境，并說(shuō)明何時(shí)應(yīng)該使用哪種開(kāi)發(fā)環(huán)境。
-
- 本地 Kubernetes 集群
- 基于云的獨(dú)立集群
- 自服務(wù)命名空間
- 自服務(wù)虛擬集群
1、開(kāi)發(fā)環(huán)境的 6 個(gè)評(píng)估標(biāo)準(zhǔn)
為了讓不同的 Kubernetes 開(kāi)發(fā)環(huán)境具有可比性，我們應(yīng)該首先定義所使用的評(píng)估標(biāo)準(zhǔn)。我將使用以下標(biāo)準(zhǔn)對(duì)每種環(huán)境打分：
- 開(kāi)發(fā)體驗(yàn)：開(kāi)發(fā)人員入門(mén)這個(gè)環(huán)境有多容易？這包括設(shè)置速度、易用性以及開(kāi)發(fā)人員所需的知識(shí)等因素。
- 管理體驗(yàn)：管理員管理這個(gè)環(huán)境和系統(tǒng)有多容易？在這里，我將考慮系統(tǒng)的復(fù)雜性、管理該系統(tǒng)以及添加其他用戶(hù)的工作量。
- 靈活性 / 現(xiàn)實(shí)性：與生產(chǎn)環(huán)境相比，開(kāi)發(fā)環(huán)境的現(xiàn)實(shí)程度如何？對(duì)于不同的用例，它的靈活性如何？一個(gè)好的開(kāi)發(fā)環(huán)境應(yīng)該與生產(chǎn)環(huán)境非常相似，以避免出現(xiàn)“它在我的機(jī)器上本來(lái)可以運(yùn)行”的問(wèn)題，并且還應(yīng)該可以自由配置以用于許多不同的用例（例如編碼、測(cè)試等）。
- 可擴(kuò)展性：如果有許多用戶(hù)正在使用這個(gè)系統(tǒng)，環(huán)境本身的可擴(kuò)展性如何？方法的可擴(kuò)展性如何？特別是對(duì)于復(fù)雜的、需要大量計(jì)算資源的應(yīng)用程序，開(kāi)發(fā)環(huán)境應(yīng)該能夠滿足需求。另外，向開(kāi)發(fā)人員提供這種環(huán)境的通用方法也應(yīng)該適用于大型團(tuán)隊(duì)。
- 隔離度 / 穩(wěn)定性：用戶(hù)之間如何隔離，系統(tǒng)有多脆弱？開(kāi)發(fā)人員應(yīng)該能夠并行工作而不會(huì)互相干擾，并且他們使用的系統(tǒng)應(yīng)該穩(wěn)定且安全，以減少低效的中斷事件。
- 成本：這種方法有多昂貴？成本的含義大家都知道，在為團(tuán)隊(duì)選擇正確的開(kāi)發(fā)環(huán)境時(shí)，它仍然是重要的因素。
現(xiàn)在評(píng)估標(biāo)準(zhǔn)已經(jīng)明確，我們可以開(kāi)始對(duì)比 Kubernetes 開(kāi)發(fā)環(huán)境了：
本地 Kubernetes 集群是在開(kāi)發(fā)人員的單臺(tái)計(jì)算機(jī)上運(yùn)行的集群。有許多工具可以提供這樣的環(huán)境，例如 Minikube、microk8s、k3s 或 kind。盡管它們并不完全相同，但它們?cè)陂_(kāi)發(fā)環(huán)境中的用法具有相當(dāng)?shù)目杀刃浴?/p>
開(kāi)發(fā)人員必須在計(jì)算機(jī)上自行設(shè)置本地開(kāi)發(fā)環(huán)境，因?yàn)檫@些環(huán)境就是在本地計(jì)算機(jī)上運(yùn)行的。這可能非常具有挑戰(zhàn)性，特別是因?yàn)楸镜卦O(shè)置總是有各種區(qū)別（不同的硬件、不同的操作系統(tǒng)、不同的配置等），這樣想要找到一個(gè)非常簡(jiǎn)單的設(shè)置指南就更難了。設(shè)置完成后，開(kāi)發(fā)人員還要負(fù)責(zé)自己護(hù)理和管理自己的環(huán)境。如果他們以前沒(méi)有 Kubernetes 經(jīng)驗(yàn)，他們通常會(huì)感到不習(xí)慣。
因此，對(duì)開(kāi)發(fā)人員來(lái)說(shuō)總體的開(kāi)發(fā)體驗(yàn)相對(duì)較差（至少在沒(méi)有 Kubernetes 知識(shí)的情況下）。
管理員不參與本地 Kubernetes 集群的設(shè)置和管理。這意味著他們?cè)谶@里沒(méi)有任何要做的事情。但是，他們也不知道開(kāi)發(fā)人員是否能夠使用自己的集群，并且通常被排除在集群的設(shè)置和管理工作之外。盡管如此，如果出現(xiàn)問(wèn)題，管理員可能仍需要支持開(kāi)發(fā)人員。
總體而言，管理體驗(yàn)得分中等，因?yàn)楣芾韱T沒(méi)有面對(duì)典型的挑戰(zhàn)，而是需要單獨(dú)地教育和支持開(kāi)發(fā)人員。
一方面，本地集群在云環(huán)境中總是與“真實(shí)”集群有所不同。它們通常是精簡(jiǎn)的 Kubernetes 版本，缺少一些無(wú)法在本地復(fù)制（并且通常在本地不需要）的特性。比如看名字“k3s”就能看出來(lái)，這是對(duì)原始 Kubernetes 的“k8s”的簡(jiǎn)化。另一方面，工程師可以對(duì)本地集群執(zhí)行任何所需的操作，因此他們也可以靈活地對(duì)其配置。
總而言之，本地集群在靈活性配置方面得分較高，但在現(xiàn)實(shí)性方面得分較低，因?yàn)樗鼈儾痪哂兴?Kubernetes 特性，因此不能用于所有用例。
由于本地集群只能訪問(wèn)工程師計(jì)算機(jī)上可用的計(jì)算資源，因此它們相對(duì)更容易達(dá)到復(fù)雜應(yīng)用程序的極限。另外，讓工程師自己創(chuàng)建本地集群的方法實(shí)際上并沒(méi)有擴(kuò)展性，因?yàn)楸仨殲閹缀趺恳晃粵](méi)有自動(dòng)化選項(xiàng)的工程師重復(fù)相同的過(guò)程。
因此，可擴(kuò)展性是本地 Kubernetes 集群的明顯弱點(diǎn)。
每位開(kāi)發(fā)人員都有一個(gè)單獨(dú)的環(huán)境，該環(huán)境與其他所有環(huán)境完全斷開(kāi)。從理論上講，它們甚至可以在沒(méi)有互聯(lián)網(wǎng)連接的情況下使用。所以本地集群的隔離度是完美的。這種連接斷開(kāi)還確保了只有單個(gè)環(huán)境會(huì)被故障波及，故障絕不會(huì)同時(shí)導(dǎo)致所有環(huán)境失敗，這最大程度地降低了這種方法為開(kāi)發(fā)人員提供的 Kubernetes 環(huán)境的脆弱性。
隔離和安全性絕對(duì)是本地集群的優(yōu)勢(shì)。
本地 Kubernetes 集群有時(shí)不需要昂貴的云計(jì)算資源，而僅使用本地可用的計(jì)算資源。各種本地 Kubernetes 解決方案都是開(kāi)源的，可以免費(fèi)使用。
使用本地 Kubernetes 集群進(jìn)行開(kāi)發(fā)沒(méi)有任何直接成本，因此它是最便宜的解決方案。
在云中運(yùn)行的獨(dú)立集群是 Kubernetes 開(kāi)發(fā)環(huán)境的第二種類(lèi)型。它們可以由管理員創(chuàng)建，然后管理員可以單獨(dú)授予開(kāi)發(fā)人員訪問(wèn)權(quán)限，或者如果開(kāi)發(fā)人員擁有自己的云提供商帳戶(hù)，則可以讓他們自己創(chuàng)建開(kāi)發(fā)人員。
開(kāi)發(fā)人員的體驗(yàn)可能會(huì)大不相同，并且取決于各個(gè)集群的創(chuàng)建方式：如果開(kāi)發(fā)人員可以直接訪問(wèn)云，例如借助精心設(shè)計(jì)的身份和訪問(wèn)管理（IAM）機(jī)制，他們可以按需創(chuàng)建自己的工作環(huán)境，并且設(shè)置過(guò)程非常簡(jiǎn)單（尤其是在公有云中），因?yàn)樗偸且粯拥?。但是，他們必須自己?zhí)行這一步操作，并且可能需要一些幫助來(lái)管理集群。
如果管理員負(fù)責(zé)創(chuàng)建集群并將訪問(wèn)權(quán)限分發(fā)給各位開(kāi)發(fā)人員，則開(kāi)發(fā)人員的體驗(yàn)可能會(huì)變得很糟糕?，F(xiàn)在，集群的管理有人負(fù)責(zé)了，但管理員卻成為了瓶頸。在這里，你將面臨前面提到的，開(kāi)發(fā)人員等待中央 IT 提供開(kāi)發(fā)環(huán)境的問(wèn)題。
總體而言，在最佳情況下，如果開(kāi)發(fā)人員具有直接的云訪問(wèn)權(quán)限，那么開(kāi)發(fā)體驗(yàn)就足夠優(yōu)秀了。
無(wú)論開(kāi)發(fā)人員以哪種方式獲取集群，管理員的體驗(yàn)總是很糟糕。如果每個(gè)開(kāi)發(fā)人員都有自己的云帳戶(hù)，則管理員將很難獲得整個(gè)系統(tǒng)的宏觀狀況（哪些資源仍在被使用？誰(shuí)在使用什么資源？）。在這種情況下，他們還必須支持開(kāi)發(fā)人員來(lái)管理集群。由于集群的數(shù)量與工程師的數(shù)量成比例地增加，因此工作量也隨團(tuán)隊(duì)規(guī)模的增長(zhǎng)而增加。
在管理員集中創(chuàng)建和分發(fā)集群的情況下，管理員也需要付出很多努力。他們將必須回應(yīng)開(kāi)發(fā)人員對(duì)集群和配置更改的所有請(qǐng)求，并且必須始終待命，因?yàn)樗麄儗?duì)于開(kāi)發(fā)人員的生產(chǎn)力來(lái)說(shuō)至關(guān)重要。通常，更多的集群會(huì)導(dǎo)致管理員付出更多的管理工作。
從管理員的角度來(lái)看，基于云的獨(dú)立集群方法是一個(gè)不好的解決方案，并且必然導(dǎo)致他們手頭的工作量大增，甚至到他們無(wú)法處理的地步。
由于生產(chǎn)系統(tǒng)通常也在云中的 Kubernetes 中運(yùn)行，因此這樣的開(kāi)發(fā)環(huán)境是完全真實(shí)的。各個(gè)環(huán)境也可以自由配置，因此它們完全符合開(kāi)發(fā)人員的需求，或者與生產(chǎn)系統(tǒng)的設(shè)置相同。
基于云的獨(dú)立集群是獲得高度真實(shí)的開(kāi)發(fā)環(huán)境的最佳解決方案。
在可擴(kuò)展性方面，集群在云環(huán)境中運(yùn)行時(shí)優(yōu)勢(shì)很大，幾乎可以無(wú)限擴(kuò)展。不過(guò)可擴(kuò)展性標(biāo)準(zhǔn)還包括適用于大型團(tuán)隊(duì)的通用方法的可擴(kuò)展性，而在這里，隨著管理工作量隨團(tuán)隊(duì)規(guī)模不斷增長(zhǎng)，各個(gè)集群可能會(huì)達(dá)到極限。
對(duì)于云中的獨(dú)立集群而言，計(jì)算資源的可擴(kuò)展性不是問(wèn)題，但是在大型組織中推廣這樣的系統(tǒng)通常是不可行的。
在集群級(jí)別隔離開(kāi)發(fā)人員是非常安全的。如果你使用的是公有云，則開(kāi)發(fā)人員的隔離度幾乎與不同公司的隔離度是一個(gè)級(jí)別，這當(dāng)然是云提供商的高度優(yōu)先事項(xiàng)。
100％的穩(wěn)定性和隔離度可能永遠(yuǎn)不會(huì)在云中實(shí)現(xiàn)，但是對(duì)于獨(dú)立集群而言，這方面的表現(xiàn)已經(jīng)夠好了。
運(yùn)行許多集群是非常昂貴的。這是由于以下幾個(gè)因素：首先，你將具有很多冗余，因?yàn)槊總€(gè)集群都有自己的控制平面。其次，采用這種方法幾乎不可避免地會(huì)產(chǎn)生超大型或未使用的集群，因?yàn)橐吹糜砷_(kāi)發(fā)人員負(fù)責(zé)對(duì)集群進(jìn)行大小調(diào)整和關(guān)閉操作，要么管理員必須集中管理，但后者沒(méi)法監(jiān)控和了解集群中仍在使用哪些資源。
此外，開(kāi)發(fā)環(huán)境也僅在開(kāi)發(fā)人員正在工作時(shí)使用，因此許多集群可能在晚上、節(jié)假日和周末處于空閑狀態(tài)。最后，公有云提供商會(huì)為每個(gè)集群（在這種情況下是為每個(gè)開(kāi)發(fā)人員）計(jì)算集群管理費(fèi)。
在云中為每個(gè)工程師提供單獨(dú)集群是提供 Kubernetes 開(kāi)發(fā)環(huán)境的非常昂貴的方法。
除了為每個(gè)開(kāi)發(fā)人員提供整個(gè)集群之外，還可以為他們提供 Kubernetes 命名空間。同樣，這些環(huán)境可以由管理員集中創(chuàng)建，或者為開(kāi)發(fā)人員提供一種工具，讓后者可以按需創(chuàng)建自服務(wù)命名空間。集中提供命名空間的方法也有著前文提到的獨(dú)立集群所具有的許多缺點(diǎn)，因此在這里我將重點(diǎn)介紹自服務(wù)命名空間方法。
由于工程師可以自己創(chuàng)建命名空間，因此它們獨(dú)立于管理員，無(wú)需開(kāi)發(fā)人員等待獲取 Kubernetes 開(kāi)發(fā)環(huán)境。同時(shí)，命名空間在由管理員管理的集群上運(yùn)行，因此開(kāi)發(fā)人員不必關(guān)心環(huán)境的管理。命名空間作為集群中的構(gòu)造通常足以完成更簡(jiǎn)單的開(kāi)發(fā)工作，因此開(kāi)發(fā)人員將能夠執(zhí)行大多數(shù)標(biāo)準(zhǔn)任務(wù)，并且僅在某些情況下受到限制，例如當(dāng)他們需要 CRD 或要安裝使用 RBAC 的 Helm 圖表時(shí)。
因此，對(duì)于“標(biāo)準(zhǔn)”開(kāi)發(fā)任務(wù)和沒(méi)有特殊 Kubernetes 配置要求的開(kāi)發(fā)人員來(lái)說(shuō)，自服務(wù)命名空間的開(kāi)發(fā)體驗(yàn)是非常不錯(cuò)的。
一開(kāi)始，管理員需要建立一個(gè)內(nèi)部自服務(wù) Kubernetes 平臺(tái)，如果他們想從頭開(kāi)始構(gòu)建它的話可能會(huì)花費(fèi)一些時(shí)間，Spotify 這樣的公司就選擇了這樣做?；蛘?，也可以購(gòu)買(mǎi)將自服務(wù)命名空間功能添加到任何集群的解決方案（Loft 就是這樣做的）。無(wú)論如何，一旦系統(tǒng)正確設(shè)置完畢，管理員就可以專(zhuān)注于其他任務(wù)，例如基礎(chǔ)集群的安全性和穩(wěn)定性等。此外，由于整個(gè)系統(tǒng)都在一個(gè)集群中運(yùn)行，因此獲得整個(gè)系統(tǒng)的概況相對(duì)容易。
自服務(wù)命名空間是一種易于管理的解決方案，需要進(jìn)行一些初始設(shè)置。
由于命名空間在共享的 Kubernetes 集群上運(yùn)行，因此開(kāi)發(fā)人員無(wú)法單獨(dú)配置所有內(nèi)容。例如，所有工程師都必須使用相同的 Kubernetes 版本，并且不能修改集群范圍的資源。盡管如此，命名空間仍在類(lèi)似于生產(chǎn)環(huán)境的云環(huán)境中運(yùn)行，這起碼讓命名空間成為了相對(duì)現(xiàn)實(shí)的工作環(huán)境。
總體而言，命名空間在某些情況下可能會(huì)限制開(kāi)發(fā)人員的靈活性，但它通常不會(huì)是不切實(shí)際的開(kāi)發(fā)環(huán)境。
自服務(wù)命名空間系統(tǒng)的可擴(kuò)展性在兩個(gè)方面都非常不錯(cuò)：可以擴(kuò)展命名空間的資源，因?yàn)樗鼈冊(cè)谠浦羞\(yùn)行（當(dāng)然也可以限制開(kāi)發(fā)人員以防止過(guò)度使用）。同時(shí)，向系統(tǒng)添加其他用戶(hù)也沒(méi)有問(wèn)題，特別是如果它提供了“單點(diǎn)登錄”選項(xiàng)就更方便了。
命名空間是為許多開(kāi)發(fā)人員提供可靈活擴(kuò)展或縮減的 Kubernetes 環(huán)境的有效方法。
命名空間是 Kubernetes 多租戶(hù)的原生解決方案，但它的隔離并不是完美的，而是一種軟多租戶(hù)的形式。但是，由于承租人（開(kāi)發(fā)人員）是受信任的，所以這對(duì)于開(kāi)發(fā)環(huán)境而言不一定是問(wèn)題。此外，多個(gè)命名空間共享相同的基礎(chǔ)集群，這意味著如果集群關(guān)閉，所有命名空間都會(huì)失敗，因此集群的穩(wěn)定性至關(guān)重要。
命名空間是 Kubernetes 原生的隔離解決方案，但它當(dāng)然不是完美的。但是，如果基礎(chǔ)集群運(yùn)行良好，那么對(duì)于組織內(nèi)的受信任工程師而言，命名空間仍然是一個(gè)不錯(cuò)的解決方案。
為了獲得自服務(wù)的體驗(yàn)，你可能需要購(gòu)買(mǎi)自服務(wù)的命名空間軟件。此外，在云環(huán)境中運(yùn)行的命名空間不是免費(fèi)的，因?yàn)樗鼈冞€需要云計(jì)算資源。但是，許多開(kāi)發(fā)人員可以共享基礎(chǔ)集群及其資源，從而提高了利用率并避免了不必要的冗余。從控制中心了解哪些資源空閑也是比較容易的，這樣就可以關(guān)閉這些資源節(jié)省費(fèi)用。該過(guò)程甚至可以通過(guò)睡眠模式自動(dòng)執(zhí)行。
總體而言，命名空間是一種非常經(jīng)濟(jì)高效的方法，是為開(kāi)發(fā)人員提供 Kubernetes 接入的好選項(xiàng)。
虛擬集群（vClusters）是一種解決方案，可讓你在 Kubernetes 集群中創(chuàng)建 Kubernetes 集群。像命名空間一樣，虛擬集群在單個(gè)物理集群上運(yùn)行，并且如果開(kāi)發(fā)人員可以訪問(wèn) vCluster 平臺(tái)，則可以由開(kāi)發(fā)人員按需創(chuàng)建。
虛擬集群的開(kāi)發(fā)體驗(yàn)類(lèi)似于命名空間。開(kāi)發(fā)人員可以輕松按需創(chuàng)建它們，并且它們獨(dú)立于中央 IT，但開(kāi)發(fā)人員也不必自己管理基礎(chǔ)集群。同時(shí)，對(duì)于開(kāi)發(fā)人員而言 vClusters 感覺(jué)像是“真實(shí)的”集群，因此他們通常完全不會(huì)遇到什么限制。
因此，vClusters 的開(kāi)發(fā)體驗(yàn)與命名空間相似，但甚至為開(kāi)發(fā)人員提供了更多的自由來(lái)執(zhí)行和配置他們想要的東西。
考慮到管理員的體驗(yàn)，自服務(wù)命名空間和 vClusters 也是非常相似的。初始設(shè)置后，管理員的管理工作就很少了，因此他們可以專(zhuān)注于其他任務(wù)。但與命名空間相比，vClusters 更好地隔離了用戶(hù)，因此開(kāi)發(fā)人員讓基礎(chǔ)集群崩潰的可能性更小了。此外，大多數(shù) Kubernetes 的配置和安裝都可以在 vCluster 中進(jìn)行，因此基礎(chǔ)集群可以非常簡(jiǎn)單，只需提供基本特性即可，從而讓管理員的工作更加輕松。
一旦正確設(shè)置，自服務(wù) vCluster 平臺(tái)還可以提供非常流暢的管理員體驗(yàn)。
虛擬集群在云中運(yùn)行，這使它們成為了相當(dāng)逼真的開(kāi)發(fā)環(huán)境，尤其是考慮到開(kāi)發(fā)人員可以單獨(dú)配置虛擬集群以滿足他們的需求。但是，vClusters 與真實(shí)集群并不完全相同，因此現(xiàn)實(shí)性指標(biāo)并不像獨(dú)立集群那樣完美。
總體而言，vClusters 可以靈活配置以滿足不同用例的要求。由于它們是虛擬構(gòu)造，因此它們與物理集群之間仍然存在一些細(xì)微差異。
vClusters 的可擴(kuò)展性與命名空間一樣好。vClusters 可以在云中擁有不同的且基本上是無(wú)盡的計(jì)算資源。在獨(dú)立集群上運(yùn)行的平臺(tái)的自服務(wù)配置還讓 vClusters 可以支持許多工程師同時(shí)使用。
自服務(wù) vCluster 解決方案將滿足開(kāi)發(fā)環(huán)境可擴(kuò)展性方面的所有需求。
虛擬集群的隔離比命名空間級(jí)別的隔離要好，但是 vClusters 仍然是 Kubernetes 多租戶(hù)的一種形式，因此 vClusters 共享一個(gè)公有的物理集群。虛擬集群的一個(gè)好處是基礎(chǔ)集群可以是非?；A(chǔ)的，這使得集群更容易穩(wěn)定下來(lái)。
總體而言，vClusters 的隔離度很好，并且整個(gè)系統(tǒng)的穩(wěn)定性可以很出色。但是，很多穩(wěn)定性水平取決于基礎(chǔ)集群的穩(wěn)定性。
虛擬集群平臺(tái)不是免費(fèi)的，因?yàn)樗枰脚_(tái)的云計(jì)算資源和軟件。在這方面，vClusters 又非常接近命名空間：集群共享提高了利用率，并讓管理員更容易獲得系統(tǒng)概況和關(guān)閉未使用的虛擬集群，甚至可以通過(guò)睡眠模式將這些操作自動(dòng)化。
虛擬集群平臺(tái)與命名空間平臺(tái)一樣具有成本優(yōu)勢(shì)，但是所有基于云的解決方案都不一定完全免費(fèi)。
在描述了四種不同類(lèi)型的 Kubernetes 開(kāi)發(fā)環(huán)境之后，問(wèn)題仍然是哪種環(huán)境適合你的情況。
根據(jù)我的經(jīng)驗(yàn)，許多公司和工程師都是從本地開(kāi)發(fā)環(huán)境開(kāi)始的。它們是免費(fèi)的并且可以在本地計(jì)算機(jī)上運(yùn)行，這一事實(shí)減少了最初的障礙，因?yàn)楸镜丨h(huán)境不需要復(fù)雜的預(yù)算審批。對(duì)于編程愛(ài)好者和小型應(yīng)用程序來(lái)說(shuō)，本地環(huán)境也是一個(gè)很好的解決方案；而對(duì)于知道如何處理和設(shè)置這些環(huán)境的 Kubernetes 專(zhuān)家來(lái)說(shuō)，本地環(huán)境也是一個(gè)不錯(cuò)的選項(xiàng)。
隨著組織在云原生的道路上逐漸前行，他們希望將 Kubernetes 推廣給更多沒(méi)有使用 Kubernetes 經(jīng)驗(yàn)的開(kāi)發(fā)人員。這些組織通常從“顯而易見(jiàn)的”解決方案入手：只需為每個(gè)開(kāi)發(fā)人員提供一個(gè)自己的集群。一段時(shí)間后，他們通常會(huì)意識(shí)到這種方法非常昂貴，并且隨著越來(lái)越多的開(kāi)發(fā)人員一起使用 K8s，這種方法變得更加復(fù)雜。為此，除非開(kāi)發(fā)人員數(shù)量相對(duì)較低且成本無(wú)關(guān)緊要，否則基于獨(dú)立云的集群解決方案通常只是一個(gè)臨時(shí)解決方案。
為了避免大型團(tuán)隊(duì)的高昂成本和復(fù)雜管理工作，許多組織希望為開(kāi)發(fā)人員提供命名空間或虛擬集群（虛擬集群相對(duì)較新，因此命名空間仍然很常見(jiàn)）。但是，由于這些公司已經(jīng)意識(shí)到該方法的可擴(kuò)展性非常重要，因此他們希望以一種自動(dòng)化的方式來(lái)做到這一點(diǎn)，要么像 Spotify 一樣開(kāi)始開(kāi)發(fā)自己的內(nèi)部 Kubernetes 平臺(tái)，要么就購(gòu)買(mǎi)諸如 Loft 之類(lèi)的現(xiàn)有解決方案。因此，到底命名空間就夠用了，還是說(shuō)虛擬集群是更好的解決方案，取決于應(yīng)用程序的復(fù)雜性以及開(kāi)發(fā)人員的專(zhuān)業(yè)知識(shí)和需求。
隨著越來(lái)越多的公司希望其開(kāi)發(fā)人員啟用 Kubernetes，也有越來(lái)越多的開(kāi)發(fā)人員需要接入 Kubernetes 環(huán)境。已有的幾種選項(xiàng)都有其優(yōu)點(diǎn)和缺點(diǎn)。
盡管本地開(kāi)發(fā)集群是一個(gè)好而便宜的起點(diǎn)，但對(duì)于經(jīng)驗(yàn)不足的開(kāi)發(fā)人員或大型組織而言，它們通常不是正確的解決方案。
然后，這些組織會(huì)轉(zhuǎn)向各個(gè)基于云的集群的“顯而易見(jiàn)”的解決方案，這些解決方案在靈活性和現(xiàn)實(shí)性方面無(wú)與倫比，但對(duì)于管理員而言也難以管理，并且可能變得非常昂貴。
最后，共享集群是自服務(wù)命名空間或虛擬集群的基礎(chǔ)，是一種將成本效益與良好的開(kāi)發(fā)和管理體驗(yàn)相結(jié)合的解決方案。盡管這些解決方案不是免費(fèi)的，并且需要一些初始設(shè)置工作，但即使對(duì)于較大的公司，它們也是一個(gè)長(zhǎng)期的解決方案選項(xiàng)。
原文鏈接： https://loft.sh/blog/kubernetes-development-environments-comparison/
作者 | Daniel Thiry 策劃 | 田曉旭 本文最初發(fā)布于 Loft 網(wǎng)站，經(jīng)授權(quán)由 InfoQ 中文站翻譯并分享。