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