2021 年 11 款最佳的開源 K8s 工具

到 2021 年，幾乎所有接觸過雲基礎設施的人都熟悉 Kubernetes 項目。簡單地說，Kubernetes 是一個非常強大的容器編排平臺，並且 Kubernetes 社區一直在共享工具，這有助於改善 Kubernetes 開發人員的體驗。本文列出作者自己最常用的 11 款 Kubernetes 工具，並對它們進行了分類介紹。

Kubernetes 是一個非常強大的容器編排平臺。但在我看來，Kubernetes 最重要的是將最佳實踐整合到了一個系統中，這個系統可以從樹莓派（Raspberry Pi）擴展到財富 500 強中最大的基礎設施。它使得開發和運維人員能夠通過標準化的 API 和有意義的抽象（如 Pod 或 ConfigMap）進行協作。

通過提供一個開源標準，Kubernetes 可以將一個組織從數十年自己摸索的 “容器策略” 中拯救出來，幸運的是，這個標準也是每個主要雲供應商的標準。也就是說，像 Kubernetes 這樣龐大的野獸是很難馴服的，但爲了充分發揮它的潛力，我們需要一套額外的工具。

Kubernetes 社區一直在共享工具，這有助於改善 Kubernetes 開發人員的體驗。以下是我自己最常用的 11 款 Kubernetes 工具，我將它們進行了分類：哪些是可以幫助我運行 Kubernetes 的工具，哪些是測試 Kubernetes 的工具，以及哪些是可以讓我在 IDE 中能夠獲得樂趣的（最後但並非不重要）。

類別 1：運行 Kubernetes 環境

Minikube 仍然是最佳的

幾乎每個 Kubernetes 教程都是從 “下載 Minikube” 開始的，這在今天仍然行得通。如果你想在一個真正低風險的環境中編排容器，那麼打包及維護良好的 Minikube 項目可以讓你在大約 23 秒內即可運行一個集羣。

Helm 仍然是可重複部署的標準

雖然我們都編寫過一兩個一次性腳本來將一些配置部署到 Kubernetes 中，但實際上管理可重複部署的方法是使用 Helm。就像 Ubuntu 上的 apt 或 RHEL 上的 rpm 一樣，Helm 是一個包管理器，它爲 Kubernetes 開發人員做了很多事情。作爲一名開發人員，想在投入不多的情況下用其他項目來測試我的應用程序。我可以簡單地運行 helm install jenkins/jenkins，而不是編寫自己的 Jenkins 設置。想要獲取 Helm 或其他 Kubernetes 軟件包，請查看 Artifact Hub。

Rancher K3s 可隨時隨地運行

向 Kubernetes 服務中推送容器是一回事，但是如果你想在 Raspberry Pi 農場之外也弄一個呢？來自 Rancher 的 K3s 項目可以做到這一點。正如維護人員在 README 中所說的那樣，它對於 Kubernetes“集羣學”（clusterology）的任何邊界或物聯網嘗試都是理想選擇。

K3s 作爲本地和輕量級集羣選擇的一個突出特點是它支持的設備非常廣泛。使用 K3s，你可以在任何地方運行 Kubernetes。事實上，它是以單個二進制文件下載的，這意味着它包含了所有生產 Kubernetes 配置的功能（sqlite3 是默認的，但是你可以通過它的可插拔存儲後端將其擴展到 Etcd3），並且 Rancher 團隊及其 1749 名（到目前爲止）貢獻者仍在非常積極地維護它。

Loft 可擴大團隊規模

任何人都可以通過調用 curl 來啓動上面提到的 Minikube 集羣。但是，如果你想要和別人合作呢？在雲原生開發工具和本地開發集羣的交接處有很多選擇。

傳統的選擇是在公有云上運行一些可公開訪問的資源：AKS、EKS、DigitalOcean Managed Kubernetes 或其他可用資源。但是任何一個在雲服務上運行過 hello world 教程但忘刪除它的人都知道，這會讓你很快就損失很多。

Loft 提供了一組包含 UI 和 CLI 在內的服務，可以進一步抽象 Kubernetes 環境，這些環境最終將在生產環境中運行。這樣做之後，你可以建立一個自助服務體驗，而無需考慮隔離和預算問題。

Loft 對隔離的關注，特別是對 vClusters 及其相應 Spaces 的關注，爲每個開發人員提供了一個真實的環境，而不會影響預算。這對開發人員和部門領導來說都是非常有價值的。

Loft 的價值在於啓動和關閉安全 Kubernetes 環境的速度。它在一個用例中提到只需單擊一次 UI，即可創建本地環境的現場演示。更自私地考慮一下，在不破壞開發集羣命名空間的情況下，可以在自己的獨立測試用例中演示最新的生產功能，這說聽起來確實不錯。

此外，Loft 實驗室最近聘請了了不起的 Rich Burroughs，這對於他們正在建立的這類社區來說是個非常好兆頭。

當與團隊合作時，使用 Loft 是非常有意義的。

類別 2：簡化反饋迴路

Skaffold 可提供自動反饋迴路

假設你是一名開發人員，你想寫一個可以在 Kubernetes 上運行的應用程序。從運行 Node.js 或 Python 應用程序到在 Kubernetes 上運行容器，你需要了解大量的 Kubernetes 概念，數量大到像一堵 YAML 牆。幸運的是，谷歌的好朋友們編寫了 Skaffold，爲我們提供了一些急需的腳手架。

不要誤會我的意思：你仍然需要編寫自己的代碼、Dockerfile、清單文件以及與管道相關的所有服務。Skaffold 提供的是一種乾淨的方法，可以在每次變更代碼後重新運行部署管道。它的主頁上引用了來自世界各地開發人員的語錄，深受用戶喜愛。

你可能會有這種感覺：運行 Skaffold 感覺就像第一次運行 Vagrant，而不是手動管理虛擬機。曾經需要很多步驟才能完成且不可靠的任務，在某種程度上變得簡單且可重複了，從而簡化了我們的工作。Skaffold 將在 Kubernetes 的測試和部署反饋迴路中這樣做。

Podman 可停止管理 Docker 守護進程

雖然 Dockerfiles 可能永遠是我們表示容器的方式，但 Docker 本身是完全可選的。甚至 Kubernetes 本身也在將其運行時從 Dockershim 中移出來。我非常推薦 Podman 作爲本地運行 Docker 的替代品，唯一的原因是你不需要再維護守護進程服務了。不干擾守護進程意味着更少的無效時間浪費和更多的編碼時間。

這種區別對你來說可能很陌生，所以解釋一下：Docker 既是一個與本地容器交互的客戶端，也是一個管理容器運行的用戶態守護進程（aka server）。Nick Janetakis 在這裏完美地解釋了這一點。

像我一樣，當一切都能正常工作時，你可能會忘記 Docker 客戶端和服務端之間的區別。也就是說，我經常會看到這樣的信息：

$ docker ps
$ Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?

現在我只能選擇了。我可以對 Docker 守護進程和工具鏈中的服務進行故障排除，或者我可以使用一些不會遇到相同問題的服務。我更喜歡後者。

Podman 提供了將容器作爲子進程運行的選項，從而無需單獨的守護進程。這意味着我永遠不會再收到那條錯誤消息了，我的容器會一直在做它該做的事情。

你可能會因爲自己的肌肉記憶太根深蒂固而不願改變。在這種情況下，我強烈建議你刪除 dockerCLI 並將 alias docker = podman 添加到你的 shell 配置文件中。

Tilt 真正瞭解你的應用程序

雖然我介紹了幾種不同的管理管道的方法，但我仍然認爲 Tilt 是觀察基於 Kubernetes 應用程序的持續反饋迴路最徹底、最直觀的方法。Tilt UI 具有非常簡潔的錯誤捕捉功能，可以在 YAML 小錯誤變成重大部署錯誤之前就能指認出它們來。它還具有可定製的按鈕，以提供特定於應用程序的獨特功能，如在不同迭代之間刷新架構中的消息隊列。

如果你想觀察細節但又不想被它們淹沒，那就試試 Tilt 吧。

DevSpace 可使開發流程更高效

你是否有過想讓 kubectl 做某件事情，但卻忘記了做這件事情所需要的大量命令呢？很幸運的是，DevSpace 是一個開源的命令行實用程序，它可以將 Kubernetes 開發人員體驗包在一個溫暖的擁抱中。它能管理大量繁瑣的任務，所以你可以像對待運行在本地系統上的 Pod 一樣對待它。

此外，如果你有非常特殊的設置項，可以簡單地將它們添加到 devspace.yaml 聲明配置文件中即可。

雖然它不會一對一地取代 kubectl 提供的 “手術刀”，但運行 DevSpace 會爲你提供大量正常的默認行爲，使與真正的 Kubernetes 環境交互更像是 $HOME。

Lens IDE 可使調試更快速

像 Minikube 這樣的 Kubernetes 項目開箱即用，帶有一個稱爲 Dashboard 的絲滑而直接的 GUI。這是一個非常出色的以閱讀爲中心的環境視圖，但是如果你想通過 UI 執行某些操作，該怎麼辦呢？

開源社區中最強大的選項是 Lens。我真的不應該稱它爲 GUI，因爲它的特性豐富到足以被視爲 IDE。只需單擊按鈕，你就可以在 Lens 中執行 Kubernetes 能夠執行的任何操作。我最喜歡 Lens 的是它那不可思議的思維情境特定選項，它幫助我區分了 Kubernetes 領域許多其他資源的命名空間服務。

類別 3：不可或缺的 IDE 開發工具

VSCode 我們都需要的 Kubernetes 擴展

如果沒有一個能夠區分 Kubernetes 資源和 Helm 圖表的 IDE，就不能說是有 Kubernetes 開發經驗。這就是 Visual Studio Code Kubernetes Tools 的亮點所在。任何生活在 Kubernetes 世界的人都必須從安裝它開始。

該 VSCode 插件使 YAML 更易於管理

Kubernetes 開發人員被描述爲 YAML 牧民，我認爲這非常合適。雖然我也喜歡結構化的特定領域語言，如下一代 Kubernaut，但我不會放棄任何來自管理 YAML 本身的幫忙。幸運的是，紅帽（Red Hat）的 YAML Language Support 擴展可以幫到我。

它提供了大量的自動完成選項，以及許多額外的細微選項，這些選項幫助我解決了問題。話雖如此，右鍵單擊並選擇 “格式化文檔” 的功能本身就很有價值。

Footsteps 通過代碼查找路徑

嚴格來說，它雖然不是 Kubernetes 擴展，但是我發現在 YAML 的農場中導航可能會讓我忘記出發的地方。它在我 2000 行的配置文件的什麼地方呢？那時 Footsteps 聲照亮了我短期失憶的立足點。這個出色的擴展程序，也適用於 VSCode 或其他 IDE，它通過高亮來突出顯示最近編輯的文檔。隨着你的繼續編碼，Footsteps 會逐漸淡化這些顏色，讓你瞭解你的編碼模式。安裝它，可以節省你迷失方向的時間。

總結

有很多不可思議的工具可以幫助 Kubernetes 開發和運維人員來駕馭這種新的容器編排範式。我喜歡從三個方面來考慮它們：它們是能幫助我運行 Kubernetes，是能測試 Kubernetes，還是能以可感知的方式編寫 Kubernetes 代碼呢？所有這三個類別都可以引導你在開源生態系統中獲取維護良好的軟件，這可以幫助你像我們及其他人一樣成爲更好的 YAML 牧民。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/7dZHkxYkXuV_CfezgmUcyQ