點(diǎn)擊“程序員面試吧”，選擇“星標(biāo)??”

點(diǎn)擊文末“閱讀原文”解鎖資料！

接入 Kubernetes 環(huán)境不僅是我們要做的第一步，而且是在工作中啟用 Kubernetes 的基本要求。盡管如此，接入這樣的環(huán)境時經(jīng)常也會出問題：VMware 的一項(xiàng)研究甚至發(fā)現(xiàn)“訪問基礎(chǔ)架構(gòu)是開發(fā)人員生產(chǎn)力的最大障礙”。為此，對于所有計(jì)劃使用這種技術(shù)的團(tuán)隊(duì)來說，Kubernetes 開發(fā)環(huán)境都應(yīng)該具有較高的優(yōu)先級。

在本文中，我將描述和對比四種不同的 Kubernetes 開發(fā)環(huán)境，并說明何時應(yīng)該使用哪種開發(fā)環(huán)境。

1. 本地 Kubernetes 集群

2. 基于云的獨(dú)立集群

3. 自服務(wù)命名空間

4. 自服務(wù)虛擬集群

為了讓不同的 Kubernetes 開發(fā)環(huán)境具有可比性，我們應(yīng)該首先定義所使用的評估標(biāo)準(zhǔn)。我將使用以下標(biāo)準(zhǔn)對每種環(huán)境打分：

• 開發(fā)體驗(yàn)：開發(fā)人員入門這個環(huán)境有多容易？這包括設(shè)置速度、易用性以及開發(fā)人員所需的知識等因素。

• 管理體驗(yàn)：管理員管理這個環(huán)境和系統(tǒng)有多容易？在這里，我將考慮系統(tǒng)的復(fù)雜性、管理該系統(tǒng)以及添加其他用戶的工作量。

• 靈活性 / 現(xiàn)實(shí)性：與生產(chǎn)環(huán)境相比，開發(fā)環(huán)境的現(xiàn)實(shí)程度如何？對于不同的用例，它的靈活性如何？一個好的開發(fā)環(huán)境應(yīng)該與生產(chǎn)環(huán)境非常相似，以避免出現(xiàn)“它在我的機(jī)器上本來可以運(yùn)行”的問題，并且還應(yīng)該可以自由配置以用于許多不同的用例（例如編碼、測試等）。

• 可擴(kuò)展性：如果有許多用戶正在使用這個系統(tǒng)，環(huán)境本身的可擴(kuò)展性如何？方法的可擴(kuò)展性如何？特別是對于復(fù)雜的、需要大量計(jì)算資源的應(yīng)用程序，開發(fā)環(huán)境應(yīng)該能夠滿足需求。另外，向開發(fā)人員提供這種環(huán)境的通用方法也應(yīng)該適用于大型團(tuán)隊(duì)。

• 隔離度 / 穩(wěn)定性：用戶之間如何隔離，系統(tǒng)有多脆弱？開發(fā)人員應(yīng)該能夠并行工作而不會互相干擾，并且他們使用的系統(tǒng)應(yīng)該穩(wěn)定且安全，以減少低效的中斷事件。

• 成本：這種方法有多昂貴？成本的含義大家都知道，在為團(tuán)隊(duì)選擇正確的開發(fā)環(huán)境時，它仍然是重要的因素。

現(xiàn)在評估標(biāo)準(zhǔn)已經(jīng)明確，我們可以開始對比 Kubernetes 開發(fā)環(huán)境了：

本地 Kubernetes 集群是在開發(fā)人員的單臺計(jì)算機(jī)上運(yùn)行的集群。有許多工具可以提供這樣的環(huán)境，例如 Minikube、microk8s、k3s 或 kind。盡管它們并不完全相同，但它們在開發(fā)環(huán)境中的用法具有相當(dāng)?shù)目杀刃浴?/p>

開發(fā)人員必須在計(jì)算機(jī)上自行設(shè)置本地開發(fā)環(huán)境，因?yàn)檫@些環(huán)境就是在本地計(jì)算機(jī)上運(yùn)行的。這可能非常具有挑戰(zhàn)性，特別是因?yàn)楸镜卦O(shè)置總是有各種區(qū)別（不同的硬件、不同的操作系統(tǒng)、不同的配置等），這樣想要找到一個非常簡單的設(shè)置指南就更難了。設(shè)置完成后，開發(fā)人員還要負(fù)責(zé)自己護(hù)理和管理自己的環(huán)境。如果他們以前沒有 Kubernetes 經(jīng)驗(yàn)，他們通常會感到不習(xí)慣。

因此，對開發(fā)人員來說總體的開發(fā)體驗(yàn)相對較差（至少在沒有 Kubernetes 知識的情況下）。

管理員不參與本地 Kubernetes 集群的設(shè)置和管理。這意味著他們在這里沒有任何要做的事情。但是，他們也不知道開發(fā)人員是否能夠使用自己的集群，并且通常被排除在集群的設(shè)置和管理工作之外。盡管如此，如果出現(xiàn)問題，管理員可能仍需要支持開發(fā)人員。

總體而言，管理體驗(yàn)得分中等，因?yàn)楣芾韱T沒有面對典型的挑戰(zhàn)，而是需要單獨(dú)地教育和支持開發(fā)人員。

一方面，本地集群在云環(huán)境中總是與“真實(shí)”集群有所不同。它們通常是精簡的 Kubernetes 版本，缺少一些無法在本地復(fù)制（并且通常在本地不需要）的特性。比如看名字“k3s”就能看出來，這是對原始 Kubernetes 的“k8s”的簡化。另一方面，工程師可以對本地集群執(zhí)行任何所需的操作，因此他們也可以靈活地對其配置。

總而言之，本地集群在靈活性配置方面得分較高，但在現(xiàn)實(shí)性方面得分較低，因?yàn)樗鼈儾痪哂兴?Kubernetes 特性，因此不能用于所有用例。

由于本地集群只能訪問工程師計(jì)算機(jī)上可用的計(jì)算資源，因此它們相對更容易達(dá)到復(fù)雜應(yīng)用程序的極限。另外，讓工程師自己創(chuàng)建本地集群的方法實(shí)際上并沒有擴(kuò)展性，因?yàn)楸仨殲閹缀趺恳晃粵]有自動化選項(xiàng)的工程師重復(fù)相同的過程。

因此，可擴(kuò)展性是本地 Kubernetes 集群的明顯弱點(diǎn)。

每位開發(fā)人員都有一個單獨(dú)的環(huán)境，該環(huán)境與其他所有環(huán)境完全斷開。從理論上講，它們甚至可以在沒有互聯(lián)網(wǎng)連接的情況下使用。所以本地集群的隔離度是完美的。這種連接斷開還確保了只有單個環(huán)境會被故障波及，故障絕不會同時導(dǎo)致所有環(huán)境失敗，這最大程度地降低了這種方法為開發(fā)人員提供的 Kubernetes 環(huán)境的脆弱性。

隔離和安全性絕對是本地集群的優(yōu)勢。

本地 Kubernetes 集群有時不需要昂貴的云計(jì)算資源，而僅使用本地可用的計(jì)算資源。各種本地 Kubernetes 解決方案都是開源的，可以免費(fèi)使用。

使用本地 Kubernetes 集群進(jìn)行開發(fā)沒有任何直接成本，因此它是最便宜的解決方案。

在云中運(yùn)行的獨(dú)立集群是 Kubernetes 開發(fā)環(huán)境的第二種類型。它們可以由管理員創(chuàng)建，然后管理員可以單獨(dú)授予開發(fā)人員訪問權(quán)限，或者如果開發(fā)人員擁有自己的云提供商帳戶，則可以讓他們自己創(chuàng)建開發(fā)人員。

開發(fā)人員的體驗(yàn)可能會大不相同，并且取決于各個集群的創(chuàng)建方式：如果開發(fā)人員可以直接訪問云，例如借助精心設(shè)計(jì)的身份和訪問管理（IAM）機(jī)制，他們可以按需創(chuàng)建自己的工作環(huán)境，并且設(shè)置過程非常簡單（尤其是在公有云中），因?yàn)樗偸且粯拥?。但是，他們必須自己?zhí)行這一步操作，并且可能需要一些幫助來管理集群。

如果管理員負(fù)責(zé)創(chuàng)建集群并將訪問權(quán)限分發(fā)給各位開發(fā)人員，則開發(fā)人員的體驗(yàn)可能會變得很糟糕。現(xiàn)在，集群的管理有人負(fù)責(zé)了，但管理員卻成為了瓶頸。在這里，你將面臨前面提到的，開發(fā)人員等待中央 IT 提供開發(fā)環(huán)境的問題。

總體而言，在最佳情況下，如果開發(fā)人員具有直接的云訪問權(quán)限，那么開發(fā)體驗(yàn)就足夠優(yōu)秀了。

無論開發(fā)人員以哪種方式獲取集群，管理員的體驗(yàn)總是很糟糕。如果每個開發(fā)人員都有自己的云帳戶，則管理員將很難獲得整個系統(tǒng)的宏觀狀況（哪些資源仍在被使用？誰在使用什么資源？）。在這種情況下，他們還必須支持開發(fā)人員來管理集群。由于集群的數(shù)量與工程師的數(shù)量成比例地增加，因此工作量也隨團(tuán)隊(duì)規(guī)模的增長而增加。

在管理員集中創(chuàng)建和分發(fā)集群的情況下，管理員也需要付出很多努力。他們將必須回應(yīng)開發(fā)人員對集群和配置更改的所有請求，并且必須始終待命，因?yàn)樗麄儗τ陂_發(fā)人員的生產(chǎn)力來說至關(guān)重要。通常，更多的集群會導(dǎo)致管理員付出更多的管理工作。

從管理員的角度來看，基于云的獨(dú)立集群方法是一個不好的解決方案，并且必然導(dǎo)致他們手頭的工作量大增，甚至到他們無法處理的地步。

由于生產(chǎn)系統(tǒng)通常也在云中的 Kubernetes 中運(yùn)行，因此這樣的開發(fā)環(huán)境是完全真實(shí)的。各個環(huán)境也可以自由配置，因此它們完全符合開發(fā)人員的需求，或者與生產(chǎn)系統(tǒng)的設(shè)置相同。

基于云的獨(dú)立集群是獲得高度真實(shí)的開發(fā)環(huán)境的最佳解決方案。

在可擴(kuò)展性方面，集群在云環(huán)境中運(yùn)行時優(yōu)勢很大，幾乎可以無限擴(kuò)展。不過可擴(kuò)展性標(biāo)準(zhǔn)還包括適用于大型團(tuán)隊(duì)的通用方法的可擴(kuò)展性，而在這里，隨著管理工作量隨團(tuán)隊(duì)規(guī)模不斷增長，各個集群可能會達(dá)到極限。

對于云中的獨(dú)立集群而言，計(jì)算資源的可擴(kuò)展性不是問題，但是在大型組織中推廣這樣的系統(tǒng)通常是不可行的。

在集群級別隔離開發(fā)人員是非常安全的。如果你使用的是公有云，則開發(fā)人員的隔離度幾乎與不同公司的隔離度是一個級別，這當(dāng)然是云提供商的高度優(yōu)先事項(xiàng)。

100％的穩(wěn)定性和隔離度可能永遠(yuǎn)不會在云中實(shí)現(xiàn)，但是對于獨(dú)立集群而言，這方面的表現(xiàn)已經(jīng)夠好了。

運(yùn)行許多集群是非常昂貴的。這是由于以下幾個因素：首先，你將具有很多冗余，因?yàn)槊總€集群都有自己的控制平面。其次，采用這種方法幾乎不可避免地會產(chǎn)生超大型或未使用的集群，因?yàn)橐吹糜砷_發(fā)人員負(fù)責(zé)對集群進(jìn)行大小調(diào)整和關(guān)閉操作，要么管理員必須集中管理，但后者沒法監(jiān)控和了解集群中仍在使用哪些資源。

此外，開發(fā)環(huán)境也僅在開發(fā)人員正在工作時使用，因此許多集群可能在晚上、節(jié)假日和周末處于空閑狀態(tài)。最后，公有云提供商會為每個集群（在這種情況下是為每個開發(fā)人員）計(jì)算集群管理費(fèi)。

在云中為每個工程師提供單獨(dú)集群是提供 Kubernetes 開發(fā)環(huán)境的非常昂貴的方法。

除了為每個開發(fā)人員提供整個集群之外，還可以為他們提供 Kubernetes 命名空間。同樣，這些環(huán)境可以由管理員集中創(chuàng)建，或者為開發(fā)人員提供一種工具，讓后者可以按需創(chuàng)建自服務(wù)命名空間。集中提供命名空間的方法也有著前文提到的獨(dú)立集群所具有的許多缺點(diǎn)，因此在這里我將重點(diǎn)介紹自服務(wù)命名空間方法。

由于工程師可以自己創(chuàng)建命名空間，因此它們獨(dú)立于管理員，無需開發(fā)人員等待獲取 Kubernetes 開發(fā)環(huán)境。同時，命名空間在由管理員管理的集群上運(yùn)行，因此開發(fā)人員不必關(guān)心環(huán)境的管理。命名空間作為集群中的構(gòu)造通常足以完成更簡單的開發(fā)工作，因此開發(fā)人員將能夠執(zhí)行大多數(shù)標(biāo)準(zhǔn)任務(wù)，并且僅在某些情況下受到限制，例如當(dāng)他們需要 CRD 或要安裝使用 RBAC 的 Helm 圖表時。

因此，對于“標(biāo)準(zhǔn)”開發(fā)任務(wù)和沒有特殊 Kubernetes 配置要求的開發(fā)人員來說，自服務(wù)命名空間的開發(fā)體驗(yàn)是非常不錯的。

一開始，管理員需要建立一個內(nèi)部自服務(wù) Kubernetes 平臺，如果他們想從頭開始構(gòu)建它的話可能會花費(fèi)一些時間，Spotify 這樣的公司就選擇了這樣做?；蛘?，也可以購買將自服務(wù)命名空間功能添加到任何集群的解決方案（Loft 就是這樣做的）。無論如何，一旦系統(tǒng)正確設(shè)置完畢，管理員就可以專注于其他任務(wù)，例如基礎(chǔ)集群的安全性和穩(wěn)定性等。此外，由于整個系統(tǒng)都在一個集群中運(yùn)行，因此獲得整個系統(tǒng)的概況相對容易。

自服務(wù)命名空間是一種易于管理的解決方案，需要進(jìn)行一些初始設(shè)置。

由于命名空間在共享的 Kubernetes 集群上運(yùn)行，因此開發(fā)人員無法單獨(dú)配置所有內(nèi)容。例如，所有工程師都必須使用相同的 Kubernetes 版本，并且不能修改集群范圍的資源。盡管如此，命名空間仍在類似于生產(chǎn)環(huán)境的云環(huán)境中運(yùn)行，這起碼讓命名空間成為了相對現(xiàn)實(shí)的工作環(huán)境。

總體而言，命名空間在某些情況下可能會限制開發(fā)人員的靈活性，但它通常不會是不切實(shí)際的開發(fā)環(huán)境。

自服務(wù)命名空間系統(tǒng)的可擴(kuò)展性在兩個方面都非常不錯：可以擴(kuò)展命名空間的資源，因?yàn)樗鼈冊谠浦羞\(yùn)行（當(dāng)然也可以限制開發(fā)人員以防止過度使用）。同時，向系統(tǒng)添加其他用戶也沒有問題，特別是如果它提供了“單點(diǎn)登錄”選項(xiàng)就更方便了。

命名空間是為許多開發(fā)人員提供可靈活擴(kuò)展或縮減的 Kubernetes 環(huán)境的有效方法。

命名空間是 Kubernetes 多租戶的原生解決方案，但它的隔離并不是完美的，而是一種軟多租戶的形式。但是，由于承租人（開發(fā)人員）是受信任的，所以這對于開發(fā)環(huán)境而言不一定是問題。此外，多個命名空間共享相同的基礎(chǔ)集群，這意味著如果集群關(guān)閉，所有命名空間都會失敗，因此集群的穩(wěn)定性至關(guān)重要。

命名空間是 Kubernetes 原生的隔離解決方案，但它當(dāng)然不是完美的。但是，如果基礎(chǔ)集群運(yùn)行良好，那么對于組織內(nèi)的受信任工程師而言，命名空間仍然是一個不錯的解決方案。

為了獲得自服務(wù)的體驗(yàn)，你可能需要購買自服務(wù)的命名空間軟件。此外，在云環(huán)境中運(yùn)行的命名空間不是免費(fèi)的，因?yàn)樗鼈冞€需要云計(jì)算資源。但是，許多開發(fā)人員可以共享基礎(chǔ)集群及其資源，從而提高了利用率并避免了不必要的冗余。從控制中心了解哪些資源空閑也是比較容易的，這樣就可以關(guān)閉這些資源節(jié)省費(fèi)用。該過程甚至可以通過睡眠模式自動執(zhí)行。

總體而言，命名空間是一種非常經(jīng)濟(jì)高效的方法，是為開發(fā)人員提供 Kubernetes 接入的好選項(xiàng)。

虛擬集群（vClusters）是一種解決方案，可讓你在 Kubernetes 集群中創(chuàng)建 Kubernetes 集群。像命名空間一樣，虛擬集群在單個物理集群上運(yùn)行，并且如果開發(fā)人員可以訪問 vCluster 平臺，則可以由開發(fā)人員按需創(chuàng)建。

虛擬集群的開發(fā)體驗(yàn)類似于命名空間。開發(fā)人員可以輕松按需創(chuàng)建它們，并且它們獨(dú)立于中央 IT，但開發(fā)人員也不必自己管理基礎(chǔ)集群。同時，對于開發(fā)人員而言 vClusters 感覺像是“真實(shí)的”集群，因此他們通常完全不會遇到什么限制。

因此，vClusters 的開發(fā)體驗(yàn)與命名空間相似，但甚至為開發(fā)人員提供了更多的自由來執(zhí)行和配置他們想要的東西。

考慮到管理員的體驗(yàn)，自服務(wù)命名空間和 vClusters 也是非常相似的。初始設(shè)置后，管理員的管理工作就很少了，因此他們可以專注于其他任務(wù)。但與命名空間相比，vClusters 更好地隔離了用戶，因此開發(fā)人員讓基礎(chǔ)集群崩潰的可能性更小了。此外，大多數(shù) Kubernetes 的配置和安裝都可以在 vCluster 中進(jìn)行，因此基礎(chǔ)集群可以非常簡單，只需提供基本特性即可，從而讓管理員的工作更加輕松。

一旦正確設(shè)置，自服務(wù) vCluster 平臺還可以提供非常流暢的管理員體驗(yàn)。

虛擬集群在云中運(yùn)行，這使它們成為了相當(dāng)逼真的開發(fā)環(huán)境，尤其是考慮到開發(fā)人員可以單獨(dú)配置虛擬集群以滿足他們的需求。但是，vClusters 與真實(shí)集群并不完全相同，因此現(xiàn)實(shí)性指標(biāo)并不像獨(dú)立集群那樣完美。

總體而言，vClusters 可以靈活配置以滿足不同用例的要求。由于它們是虛擬構(gòu)造，因此它們與物理集群之間仍然存在一些細(xì)微差異。

vClusters 的可擴(kuò)展性與命名空間一樣好。vClusters 可以在云中擁有不同的且基本上是無盡的計(jì)算資源。在獨(dú)立集群上運(yùn)行的平臺的自服務(wù)配置還讓 vClusters 可以支持許多工程師同時使用。

自服務(wù) vCluster 解決方案將滿足開發(fā)環(huán)境可擴(kuò)展性方面的所有需求。

虛擬集群的隔離比命名空間級別的隔離要好，但是 vClusters 仍然是 Kubernetes 多租戶的一種形式，因此 vClusters 共享一個公有的物理集群。虛擬集群的一個好處是基礎(chǔ)集群可以是非常基礎(chǔ)的，這使得集群更容易穩(wěn)定下來。

總體而言，vClusters 的隔離度很好，并且整個系統(tǒng)的穩(wěn)定性可以很出色。但是，很多穩(wěn)定性水平取決于基礎(chǔ)集群的穩(wěn)定性。

虛擬集群平臺不是免費(fèi)的，因?yàn)樗枰脚_的云計(jì)算資源和軟件。在這方面，vClusters 又非常接近命名空間：集群共享提高了利用率，并讓管理員更容易獲得系統(tǒng)概況和關(guān)閉未使用的虛擬集群，甚至可以通過睡眠模式將這些操作自動化。

虛擬集群平臺與命名空間平臺一樣具有成本優(yōu)勢，但是所有基于云的解決方案都不一定完全免費(fèi)。

在描述了四種不同類型的 Kubernetes 開發(fā)環(huán)境之后，問題仍然是哪種環(huán)境適合你的情況。

根據(jù)我的經(jīng)驗(yàn)，許多公司和工程師都是從本地開發(fā)環(huán)境開始的。它們是免費(fèi)的并且可以在本地計(jì)算機(jī)上運(yùn)行，這一事實(shí)減少了最初的障礙，因?yàn)楸镜丨h(huán)境不需要復(fù)雜的預(yù)算審批。對于編程愛好者和小型應(yīng)用程序來說，本地環(huán)境也是一個很好的解決方案；而對于知道如何處理和設(shè)置這些環(huán)境的 Kubernetes 專家來說，本地環(huán)境也是一個不錯的選項(xiàng)。

隨著組織在云原生的道路上逐漸前行，他們希望將 Kubernetes 推廣給更多沒有使用 Kubernetes 經(jīng)驗(yàn)的開發(fā)人員。這些組織通常從“顯而易見的”解決方案入手：只需為每個開發(fā)人員提供一個自己的集群。一段時間后，他們通常會意識到這種方法非常昂貴，并且隨著越來越多的開發(fā)人員一起使用 K8s，這種方法變得更加復(fù)雜。為此，除非開發(fā)人員數(shù)量相對較低且成本無關(guān)緊要，否則基于獨(dú)立云的集群解決方案通常只是一個臨時解決方案。

為了避免大型團(tuán)隊(duì)的高昂成本和復(fù)雜管理工作，許多組織希望為開發(fā)人員提供命名空間或虛擬集群（虛擬集群相對較新，因此命名空間仍然很常見）。但是，由于這些公司已經(jīng)意識到該方法的可擴(kuò)展性非常重要，因此他們希望以一種自動化的方式來做到這一點(diǎn)，要么像 Spotify 一樣開始開發(fā)自己的內(nèi)部 Kubernetes 平臺，要么就購買諸如 Loft 之類的現(xiàn)有解決方案。因此，到底命名空間就夠用了，還是說虛擬集群是更好的解決方案，取決于應(yīng)用程序的復(fù)雜性以及開發(fā)人員的專業(yè)知識和需求。

隨著越來越多的公司希望其開發(fā)人員啟用 Kubernetes，也有越來越多的開發(fā)人員需要接入 Kubernetes 環(huán)境。已有的幾種選項(xiàng)都有其優(yōu)點(diǎn)和缺點(diǎn)。

盡管本地開發(fā)集群是一個好而便宜的起點(diǎn)，但對于經(jīng)驗(yàn)不足的開發(fā)人員或大型組織而言，它們通常不是正確的解決方案。

然后，這些組織會轉(zhuǎn)向各個基于云的集群的“顯而易見”的解決方案，這些解決方案在靈活性和現(xiàn)實(shí)性方面無與倫比，但對于管理員而言也難以管理，并且可能變得非常昂貴。

最后，共享集群是自服務(wù)命名空間或虛擬集群的基礎(chǔ)，是一種將成本效益與良好的開發(fā)和管理體驗(yàn)相結(jié)合的解決方案。盡管這些解決方案不是免費(fèi)的，并且需要一些初始設(shè)置工作，但即使對于較大的公司，它們也是一個長期的解決方案選項(xiàng)。

原文鏈接：

https://loft.sh/blog/kubernetes-development-environments-comparison/

作者 | Daniel Thiry

策劃 | 田曉旭

本文最初發(fā)布于 Loft 網(wǎng)站，經(jīng)授權(quán)由 InfoQ 中文站翻譯并分享。

END

阿里云內(nèi)部超全K8s實(shí)戰(zhàn)手冊

《深入淺出Kubernetes項(xiàng)目實(shí)戰(zhàn)手冊》，幫助你一次搞懂 6 個核心原理，吃透基礎(chǔ)理論，一次學(xué)會 6 個典型問題的華麗操作！點(diǎn)擊文末閱讀原文免費(fèi)下載