Kubernetes 必備工具：2021
文檔翻譯自 Kubernetes Essential Tools: 2021[1]，篇幅較長，做了部分增刪。
介紹
在本文中，我將嘗試總結我最喜歡的 Kubernetes[2] 工具，並特別強調最新的和鮮爲人知但我認爲會非常流行的工具。
這只是我根據我的經驗得出的個人清單，但爲了避免偏見，我還將嘗試提及每種工具的替代方案，以便你可以根據自己的需要進行比較和決定。我將盡可能縮短這篇文章並提供鏈接，以便你可以自行探索更多內容。我的目標是回答這個問題：“我如何在 Kubernetes 中做 X？” 通過描述不同軟件開發任務的工具。
K3D
K3D[3] 是我最喜歡的在筆記本電腦上運行 Kubernetes (K8s) 集羣的方式。它非常輕巧且速度非常快。它是使用 Docker 圍繞 K3S[4] 的包裝器。所以，你只需要 Docker 來運行它並且資源使用率非常低。唯一的問題是它不完全符合 K8s 標準，但這不應該是本地開發的問題。對於測試環境，你可以使用其他解決方案。K3D 比 Kind 快，但 Kind 完全兼容。
備選
•K3S[5] 物聯網或者邊緣計算 •Kind[6] 完全兼容 Kubernetes 的備選 •MicroK8s[7]•MiniKube[8]
Krew
Krew[9] 是管理的必備工具 Kubectl 插件，這是一個必須有任何 K8S 用戶。我不會詳細介紹超過 145 個可用插件 [10]，但至少安裝 kubens[11] 和 kubectx[12]。
Lens
Lens[13] 是適用於 SRE、Ops 和開發人員的 K8s IDE。它適用於任何 Kubernetes 發行版：本地或雲端。它快速、易於使用並提供實時可觀察性。使用 Lens 可以非常輕鬆地管理多個集羣。如果你是集羣操作員，這是必須的。
備選
• 對於那些喜歡輕量級終端替代品的人來說，K9s[14] 是一個很好的選擇。K9s 會持續觀察 Kubernetes 的變化，並提供後續命令來與你觀察到的資源進行交互。
Helm
Helm[15] 不需要介紹，它是 Kubernetes 最著名的包管理器。你應該在 K8s 中使用包管理器，就像在編程語言中使用它一樣。Helm 允許你將應用程序打包到 Charts[16] 中，將複雜的應用程序抽象爲易於定義、安裝和更新的可重用簡單組件。
它還提供了強大的模板引擎。Helm 很成熟，有很多預定義的 charts，很好的支持，而且很容易使用。
備選
•Kustomize[17] 是 helm 的一個更新和偉大的替代品，它不使用模板引擎，而是一個覆蓋引擎，在其中你有基本的定義和覆蓋在它們之上。
ArgoCD
我相信 GitOps[18] 是過去十年中最好的想法之一。在軟件開發中，我們應該使用單一的事實來源來跟蹤構建軟件所需的所有移動部分，而 Git 是做到這一點的完美工具。我們的想法是擁有一個 Git 存儲庫，其中包含應用程序代碼以及表示所需生產環境狀態的基礎設施 (IaC[19]) 的聲明性描述；以及使所需環境與存儲庫中描述的狀態相匹配的自動化過程。
GitOps: versioned CI/CD on top of declarative infrastructure. Stop scripting and start shipping.
— Kelsey Hightower
儘管使用 Terraform[20] 或類似工具，你可以實現基礎設施即代碼（IaC[21]），但這還不足以將你在 Git 中的所需狀態與生產同步。我們需要一種方法來持續監控環境並確保沒有配置漂移。使用 Terraform，你將不得不編寫腳本來運行terraform apply並檢查狀態是否與 Terraform 狀態匹配，但這既乏味又難以維護。
Kubernetes 從頭開始構建控制循環的思想，這意味着 Kubernetes 一直在監視集羣的狀態以確保它與所需的狀態匹配，例如，運行的副本數量與所需的數量相匹配複製品。GitOps 的想法是將其擴展到應用程序，因此你可以將你的服務定義爲代碼，例如，通過定義 Helm Charts，並使用利用 K8s 功能的工具來監控你的應用程序的狀態並相應地調整集羣。也就是說，如果更新你的代碼存儲庫或 Helm Chart，生產集羣也會更新。這是真正的持續部署 [22]。核心原則是應用程序部署和生命週期管理應該自動化、可審計且易於理解。
對我來說，這個想法是革命性的，如果做得好，將使組織能夠更多地關注功能，而不是編寫自動化腳本。這個概念可以擴展到軟件開發的其他領域，例如，你可以將文檔存儲在代碼中以跟蹤更改的歷史並確保文檔是最新的；或使用 ADR[23] 跟蹤架構決策。
在我看來，在最好的 GitOps 工具 Kubernetes 是 ArgoCD[24]。你可以在此處 [25] 閱讀更多信息。ArgoCD 是 Argo 生態系統的一部分，其中包括一些其他很棒的工具，其中一些我們將在稍後討論。
使用 ArgoCD，你可以在代碼存儲庫中擁有每個環境，你可以在其中定義該環境的所有配置。Argo CD 在指定的目標環境中自動部署所需的應用程序狀態。
ArgoCD 被實現爲一個 kubernetes 控制器，它持續監控正在運行的應用程序並將當前的實時狀態與所需的目標狀態（如 Git 存儲庫中指定的）進行比較。ArgoCD 報告並可視化差異，並且可以自動或手動將實時狀態同步回所需的目標狀態。
備選
•Flux[26] 剛剛發佈了一個具有許多改進的新版本。它提供了非常相似的功能。
Argo 工作流（Workflows）和 Argo 事件（Events）
在 Kubernetes 中，你可能還需要運行批處理作業或複雜的工作流。這可能是你的數據管道、異步流程甚至 CI/CD 的一部分。最重要的是，你甚至可能需要運行對某些事件做出反應的驅動微服務，例如文件上傳或消息發送到隊列。對於所有這些，我們有 Argo Workflows[27] 和 Argo Events[28]。
儘管它們是獨立的項目，但它們往往會被部署在一起。
Argo Workflows 是一個類似於 Apache Airflow[29] 的編排引擎，但它是 Kubernetes 原生的。它使用自定義 CRD 來定義複雜的工作流程，使用 YAML 的步驟或 DAG，這在 K8s 中感覺更自然。它有一個漂亮的 UI、重試機制、基於 cron 的作業、輸入和輸出跟蹤等等。你可以使用它來編排數據管道、批處理作業等等。
有時，你可能希望將管道與異步服務（如 Kafka 等流引擎、隊列、webhooks 或深度存儲服務）集成。例如，你可能想要對上傳到 S3 的文件等事件做出反應。爲此，你將使用 Argo 事件（Event）[30]。
這兩個工具組合爲你的所有管道需求提供了一個簡單而強大的解決方案，包括 CI/CD 管道，它允許你在 Kubernetes 中本地運行 CI/CD 管道。
備選
• 對於 ML 管道，你可以使用 Kubeflow[31]。• 對於 CI/CD 管道，你可以使用 Tekton[32]。
Kaniko
我們剛剛看到了如何使用 Argo Workflows 運行 Kubernetes 原生 CI/CD 管道。一個常見的任務是構建 Docker 鏡像，這在 Kubernetes 中通常是乏味的，因爲構建過程實際上是在容器本身上運行的，你需要使用變通方法來使用主機的 Docker 引擎。
底線是你不應該使用 Docker 來構建你的鏡像：改用 Kanico[33]。Kaniko 不依賴於 Docker 守護進程，而是完全在用戶空間中執行 Dockerfile 中的每個命令。這使得在無法輕鬆或安全地運行 Docker 守護程序的環境中構建容器鏡像成爲可能，例如標準的 Kubernetes 集羣。這消除了在 K8s 集羣中構建鏡像的所有問題。
Istio
Istio[34] 是市場上最著名的服務網格 [35]，它是開源的並且非常受歡迎。我不會詳細介紹什麼是服務網格，因爲它是一個巨大的話題，但是如果你正在構建微服務 [36]，並且可能應該這樣做，那麼你將需要一個服務網格來管理通信、可觀察性、錯誤處理、安全性。與其用重複的邏輯污染每個微服務的代碼（譯者：SDK 侵入），不如利用服務網格爲你做這件事。
簡而言之，服務網格是一個專用的基礎設施層，你可以將其添加到你的應用程序中。它允許你透明地添加可觀察性、流量管理和安全性等功能，而無需將它們添加到你自己的代碼中。
如果 Istio 用於運行微服務，儘管你可以在任何地方運行 Istio 並使用微服務，但 Kubernetes 已被一次又一次地證明是運行它們的最佳平臺。Istio 還可以將你的 K8s 集羣擴展到其他服務，例如 VM，允許你擁有在遷移到 Kubernetes 時非常有用的混合環境。
備選
•Linkerd[37] 是一種更輕巧且可能更快的服務網格。Linkerd 從頭開始爲安全性而構建，包括默認 mTLS[38]、使用 Rust 構建的數據平面 [39]、內存安全語言 [40] 和定期安全審計 [41] 等功能 •Consul[42] 是爲任何運行時和雲提供商構建的服務網格，因此它非常適合跨 K8s 和雲提供商的混合部署。如果不是所有的工作負載都在 Kubernetes 上運行，這是一個不錯的選擇。
Argo Rollouts
我們已經提到，你可以使用 Kubernetes 使用 Argo Workflows 或使用 Kanico 構建圖像的類似工具來運行 CI/CD 管道。下一個合乎邏輯的步驟是繼續並進行持續部署。由於涉及高風險，這在真實場景中是極具挑戰性的，這就是爲什麼大多數公司只做持續交付，這意味着他們已經實現了自動化，但他們仍然需要手動批准和驗證，這個手動步驟是這是因爲團隊不能完全信任他們的自動化。
那麼，你如何建立這種信任以擺脫所有腳本並完全自動化從源代碼到生產的所有內容？答案是：可觀察性。你需要將資源更多地集中在指標上，並收集準確表示應用程序狀態所需的所有數據。目標是使用一組指標來建立這種信任。如果你在 Prometheus[43] 中擁有所有數據，那麼你可以自動部署，因爲你可以根據這些指標自動逐步推出應用程序。
簡而言之，你需要比 K8s 開箱即用的滾動更新 [44] 更高級的部署技術。我們需要使用金絲雀部署 [45] 進行漸進式交付。目標是逐步將流量路由到應用程序的新版本，等待收集指標，分析它們並將它們與預定義的規則進行匹配。如果一切正常，我們增加流量；如果有任何問題，我們會回滾部署。要在 Kubernetes 中執行此操作，你可以使用提供 Canary 發佈等的 Argo Rollouts 。
Argo Rollouts[46] 是一個 Kubernetes 控制器 [47] 和一組 CRD[48]，可提供高級部署功能，例如藍綠、金絲雀、金絲雀分析、實驗和向 Kubernetes 的漸進式交付功能。
儘管像 Istio[49] 這樣的服務網格提供 Canary 發佈，但 Argo Rollouts 使這個過程變得更加容易並且以開發人員爲中心，因爲它是專門爲此目的而構建的。除此之外，Argo Rollouts 可以與任何服務網格集成。
Argo Rollouts 功能：
• 藍綠更新策略 • 金絲雀更新策略 • 細粒度、加權的流量轉移 • 自動回滾和促銷或人工判斷 • 可定製的指標查詢和業務 KPI 分析 • 入口控制器集成：NGINX、ALB• 服務網格集成：Istio、Linkerd、SMI• 指標提供者集成：Prometheus、Wavefront、Kayenta、Web、Kubernetes Jobs
備選
•Istio[50] 作爲 Canary 版本的服務網格。Istio 不僅僅是一個漸進式交付工具，它還是一個完整的服務網格。Istio 不會自動部署，Argo Rollouts 可以與 Istio 集成來實現這一點。•Flagger[51] 與 Argo Rollouts 非常相似，並且與 Flux[52] 很好地集成在一起，因此如果你使用 Flux，請考慮使用 Flagger。•Spinnaker[53] 是 Kubernetes 的第一個持續交付工具，它具有許多功能，但使用和設置起來有點複雜。
Crossplane
Crossplane[54] 是我最喜歡的 K8s 工具，我對這個項目感到非常興奮，因爲它給 Kubernetes 帶來了一個關鍵的缺失部分：像管理 K8s 資源一樣管理第三方服務。這意味着，你可以使用 YAML 中定義的 K8s 資源來配置雲提供商數據庫，例如 AWS RDS[55] 或 GCP Cloud SQL，就像你在 K8s 中配置數據庫一樣。
使用 Crossplane，無需使用不同的工具和方法分離基礎設施和代碼。你可以使用 K8s 資源定義一切。這樣，你就無需學習 Terraform[56] 等新工具並將它們分開保存。
Crossplane 是一個開源 Kubernetes 附加組件，它使平臺團隊能夠組裝來自多個供應商的基礎設施，並公開更高級別的自助 API 供應用程序團隊使用，而無需編寫任何代碼。
Crossplane 擴展了你的 Kubernetes 集羣，爲你提供適用於任何基礎架構或託管雲服務的 CRD。此外，它允許你完全實現持續部署，因爲與 Terraform 等其他工具相反，Crossplane 使用現有的 K8s 功能（例如控制循環）來持續觀察你的集羣並自動檢測任何對其起作用的配置漂移。例如，如果你定義了一個託管數據庫實例並且有人手動更改它，Crossplane 將自動檢測問題並將其設置回以前的值。這將實施基礎設施即代碼和 GitOps 原則。Crossplane 與 ArgoCD 配合使用效果很好，它可以查看源代碼並確保你的代碼存儲庫是唯一的真實來源，並且代碼中的任何更改都會傳播到集羣以及外部雲服務。如果沒有 Crossplane，你只能在 K8s 服務中實現 GitOps，而不能在不使用單獨進程的情況下在雲服務中實現，現在你可以做到這一點，這太棒了。
備選
•Terraform[57] 是最著名的 IaC 工具，但它不是 K8s 原生的，需要新技能並且不會自動監視配置漂移。•Pulumi[58] 是一種 Terraform 替代品，它使用開發人員可以測試和理解的編程語言工作。
Knative
如果你在雲中開發應用程序，你可能已經使用了一些無服務器技術，例如 AWS Lambda [59]，它是一種稱爲 FaaS[60] 的事件驅動範例。
我過去已經討論過 Serverless[61]，因此請查看我之前的文章 [62] 以瞭解更多信息。Serverless 的問題在於它與雲提供商緊密耦合，因爲提供商可以爲事件驅動的應用程序創建一個很好的生態系統。
對於 Kubernetes，如果你希望將函數作爲代碼運行並使用事件驅動架構，那麼你最好的選擇是 Knative[63]。Knative 旨在在 Kubernetes 上運行函數，在 Pod 之上創建一個抽象。
特點：
• 針對常見應用程序用例的具有更高級別抽象的重點 API。• 在幾秒鐘內建立一個可擴展、安全、無狀態的服務。• 鬆散耦合的功能讓你可以使用所需的部分。• 可插拔組件讓你可以使用自己的日誌記錄和監控、網絡和服務網格。•Knative 是可移植的：在 Kubernetes 運行的任何地方運行它，不用擔心供應商鎖定。• 慣用的開發者體驗，支持 GitOps、DockerOps、ManualOps 等常用模式。•Knative 可以與常見的工具和框架一起使用，例如 Django、Ruby on Rails、Spring 等等。
備選
•Argo Events[64] 爲 Kubernetes 提供了一個事件驅動的工作流引擎，可以與 AWS Lambda 等雲引擎集成。它不是 FaaS，而是爲 Kubernetes 提供了一個事件驅動的架構。•OpenFaas[65]
Kyverno
Kubernetes 提供了極大的靈活性，以賦予敏捷的自治團隊權力，但能力越大，責任越大。必須有一組最佳實踐和規則，以確保以一致且有凝聚力的方式來部署和管理符合公司政策和安全要求的工作負載。
有幾種工具可以實現這一點，但沒有一個是 Kubernetes 原生的…… 直到現在。Kyverno[66] 是爲 Kubernetes 設計的策略引擎，策略作爲 Kubernetes 資源進行管理，並且不需要新的語言來編寫策略。Kyverno 策略可以驗證、改變和生成 Kubernetes 資源。
你可以應用有關最佳實踐、網絡或安全性的任何類型的策略。例如，你可以強制所有服務都有標籤或所有容器都以非 root 身份運行。你可以在此處 [67] 查看一些政策示例。策略可以應用於整個集羣或給定的命名空間。你還可以選擇是隻想審覈策略還是強制執行它們以阻止用戶部署資源。
備選
•Open Policy Agent[68] 是著名的雲原生基於策略的控制引擎。它使用自己的聲明性語言，並且可以在許多環境中運行，而不僅僅是在 Kubernetes 上。它比 Kyverno[69] 更難管理，但更強大。
Kubevela
Kubernetes 的一個問題是開發人員需要非常瞭解和理解平臺和集羣配置。許多人會爭辯說 K8s 的抽象級別太低，這會給只想專注於編寫和交付應用程序的開發人員帶來很多摩擦。
在開放式應用程序模型（OAM[70]）的設立是爲了克服這個問題。這個想法是圍繞應用程序創建更高級別的抽象，它獨立於底層運行時。你可以在此處閱讀規範。
專注於應用程序而不是容器或協調器，開放應用程序模型 [OAM] 帶來了模塊化、可擴展和可移植的設計，用於使用更高級別但一致的 API 對應用程序部署進行建模。
Kubevela[71] 是 OAM 模型的一個實現。KubeVela 與運行時無關，可本地擴展，但最重要的是，以應用程序爲中心 。在 Kubevela 中，應用程序是作爲 Kubernetes 資源實現的一等公民。**集羣運營商（Platform Team）和開發者（Application Team）**是有區別的。集羣操作員通過定義組件（組成應用程序的可部署 / 可配置實體，如 Helm Chart）和特徵來管理集羣和不同的環境。開發人員通過組裝組件和特徵來定義應用程序。
KubeVela 是一個雲原生計算基金會 [72] 沙箱項目，雖然它仍處於起步階段，但它可以在不久的將來改變我們使用 Kubernetes 的方式，讓開發人員無需成爲 Kubernetes 專家即可專注於應用程序。但是，我確實對 OAM 在現實世界中的適用性有一些擔憂，因爲系統應用程序、ML 或大數據過程等一些服務在很大程度上依賴於低級細節，這些細節可能很難融入 OAM 模型中。
備選
•Shipa[73] 遵循類似的方法，使平臺和開發團隊能夠協同工作，輕鬆將應用程序部署到 Kubernetes。
Snyk
任何開發過程中一個非常重要的方面是安全性，這一直是 Kubernetes 的一個問題，因爲想要遷移到 Kubernetes 的公司無法輕鬆實現其當前的安全原則。
Snyk[74] 試圖通過提供一個可以輕鬆與 Kubernetes 集成的安全框架來緩解這種情況。它可以檢測容器映像、你的代碼、開源項目等中的漏洞。
備選
•Falco[75] 是 Kubernetes 的運行時安全線程檢測工具。
Velero
如果你在 Kubernetes 中運行工作負載並使用捲來存儲數據，則需要創建和管理備份。Velero[76] 提供簡單的備份 / 恢復過程、災難恢復機制和數據遷移。
與其他直接訪問 Kubernetes etcd 數據庫執行備份和恢復的工具不同，Velero 使用 Kubernetes API 來捕獲集羣資源的狀態並在必要時恢復它們。此外，Velero 使你能夠在配置的同時備份和恢復你的應用程序持久數據。
Schema Hero
軟件開發中的另一個常見過程是在使用關係數據庫時管理模式演變。
SchemaHero[77] 是一種開源數據庫架構遷移工具，可將架構定義轉換爲可應用於任何環境的遷移腳本。它使用 Kubernetes 聲明性來管理數據庫模式遷移。你只需指定所需的狀態，然後 SchemaHero 管理其餘的。
備選
•LiquidBase[78] 是最著名的替代品。它更難使用，且不是 Kubernetes 原生的，但它具有更多功能。
Bitnami Sealed Secrets
我們已經介紹了許多 GitOps 工具，例如 ArgoCD[79]。我們的目標是將所有內容保留在 Git 中，並使用 Kubernetes 聲明性來保持環境同步。我們剛剛看到我們如何（並且應該）在 Git 中保留真實來源，並讓自動化流程處理配置更改。
在 Git 中通常很難保留的一件事是諸如數據庫密碼或 API 密鑰之類的祕密，這是因爲你永遠不應該在代碼存儲庫中存儲祕密。一種常見的解決方案是使用外部保管庫（例如 AWS Secret Manager[80] 或 HashiCorp Vault[81]）來存儲機密，但這會產生很多摩擦，因爲你需要有一個單獨的流程來處理機密。理想情況下，我們希望有一種方法可以像任何其他資源一樣安全地在 Git 中存儲機密。
Sealed Secrets[82] 旨在克服這個問題，允許你使用強加密將敏感數據存儲在 Git 中。Bitnami Sealed Secrets 本地集成在 Kubernetes 中，允許你僅通過在 Kubernetes 中運行的 Kubernetes 控制器而不是其他任何人來解密密鑰。控制器將解密數據並創建安全存儲的原生 K8s 機密。這使我們能夠將所有內容作爲代碼存儲在我們的 repo 中，從而允許我們安全地執行持續部署，而無需任何外部依賴。
Sealed Secrets 由兩部分組成：
• 集羣端控制器 • 客戶端實用程序：kubeseal
該 kubeseal 實用程序使用非對稱加密來加密只有控制器才能解密的機密。這些加密的祕密被編碼在一個 SealedSecret K8s 資源中，你可以將其存儲在 Git 中。
備選
•AWS Secret Manager[83]•HashiCorp Vault[84]）
Capsule
許多公司使用多租戶來管理不同的客戶。這在軟件開發中很常見，但在 Kubernetes 中很難實現。命名空間是將集羣的邏輯分區創建爲隔離切片的好方法，但這不足以安全地隔離客戶，我們需要強制執行網絡策略、配額等。你可以爲每個名稱空間創建網絡策略和規則，但這是一個難以擴展的乏味過程。此外，租戶將不能使用多個命名空間，這是一個很大的限制。
創建分層命名空間是爲了克服其中一些問題。這個想法是爲每個租戶擁有一個父命名空間，爲租戶提供公共網絡策略和配額，並允許創建子命名空間。這是一個很大的改進，但它在安全和治理方面沒有對租戶的本地支持。此外，它還沒有達到生產狀態，但 1.0 版預計將在未來幾個月內發佈。
當前解決此問題的常用方法是爲每個客戶創建一個集羣，這是安全的並提供租戶所需的一切，但這很難管理且非常昂貴。
Capsule[85] 是一種爲單個集羣中的多個租戶提供原生 Kubernetes 支持的工具。使用 Capsule，你可以爲所有租戶擁有一個集羣。Capsule 將爲租戶提供 “幾乎” 原生體驗（有一些小限制），他們將能夠創建多個命名空間並使用集羣，因爲它們完全可用，隱藏了集羣實際上是共享的事實。
Capsule 架構
在單個集羣中，Capsule Controller 在稱爲 Tenant 的輕量級 Kubernetes 抽象中聚合多個命名空間，這是一組 Kubernetes 命名空間。在每個租戶內，用戶可以自由創建他們的命名空間並共享所有分配的資源，而策略引擎則使不同的租戶彼此隔離。
租戶級別定義的網絡和安全策略、資源配額、限制範圍、RBAC 和其他策略由租戶中的所有命名空間自動繼承，類似於分層命名空間。然後用戶可以自由地自治操作他們的租戶，而無需集羣管理員的干預。Capsule 是 GitOps 就緒的，因爲它是聲明性的，並且所有配置都可以存儲在 Git 中。
vCluster
vCluster[86] 在多租戶方面更進了一步，它在 Kubernetes 集羣內提供了虛擬集羣。每個集羣都在一個常規命名空間上運行，並且是完全隔離的。虛擬集羣有自己的 API 服務器和獨立的數據存儲，所以你在 vCluster 中創建的每個 Kubernetes 對象都只存在於 vcluster 內部。此外，您可以將 kube 上下文與虛擬集羣一起使用，以像使用常規集羣一樣使用它們。
只要您可以在單個命名空間內創建部署，您就可以創建虛擬集羣併成爲該虛擬集羣的管理員，租戶可以創建命名空間、安裝 CRD、配置權限等等。
vCluster 使用 k3s[87] 作爲其 API 服務器，使虛擬集羣超輕量級且經濟高效；由於 k3s 集羣 100% 合規，虛擬集羣也 100% 合規。vClusters 是超輕量級的（1 個 pod），消耗很少的資源並且可以在任何 Kubernetes 集羣上運行，而無需對底層集羣進行特權訪問。與 Capsule 相比，它確實使用了更多的資源，但它提供了更多的靈活性，因爲多租戶只是用例之一。
其他工具
•kube-burner[88] 用於壓力測試。它提供指標和警報。• 混沌工程的 Litmus[89]。•kubewatch[90] 用於監控，但主要關注基於 Kubernetes 事件（如資源創建或刪除）的推送通知。它可以與 Slack 等許多工具集成。•BotKube[91] 是一個消息機器人，用於監控和調試 Kubernetes 集羣。與 kubewatch 類似，但更新並具有更多功能。•Mizu[92] 是一個 API 流量查看器和調試器。•kube-fledged[93] 是一個 Kubernetes 插件，用於直接在 Kubernetes 集羣的工作節點上創建和管理容器鏡像的緩存。因此，應用程序 pod 幾乎立即啓動，因爲不需要從註冊表中提取圖像。
結論
在本文中，我們回顧了我最喜歡的 Kubernetes 工具。我專注於可以合併到任何 Kubernetes 發行版中的開源項目。我沒有涵蓋諸如 OpenShift[94] 或 Cloud Providers Add-Ons 之類的商業解決方案，因爲我想讓它保持通用性，但我鼓勵您探索如果您在雲上運行 Kubernetes 或使用商業工具，您的雲提供商可以爲您提供什麼。
我的目標是向您展示您可以在 Kubernetes 中完成您在本地所做的一切。我還更多地關注鮮爲人知的工具，我認爲這些工具可能具有很大的潛力，例如 Crossplane[95]、Argo Rollouts[96] 或 Kubevela[97]。我更感興趣的工具是 vCluster[98]、Crossplane[99] 和 ArgoCD/Workflows。
引用鏈接
[1] Kubernetes Essential Tools: 2021: https://itnext.io/kubernetes-essential-tools-2021-def12e84c572
[2] Kubernetes: https://kubernetes.io/
[3] K3D: https://k3d.io/
[4] K3S: https://k3s.io/
[5] K3S: https://k3s.io/
[6] Kind: https://kind.sigs.k8s.io/
[7] MicroK8s: https://microk8s.io/
[8] MiniKube: https://minikube.sigs.k8s.io/docs/
[9] Krew: https://krew.sigs.k8s.io/
[10] 插件: https://krew.sigs.k8s.io/plugins/
[11] kubens: https://github.com/ahmetb/kubectx
[12] kubectx: https://github.com/ahmetb/kubectx
[13] Lens: https://k8slens.dev/
[14] K9s: https://k9scli.io/
[15] Helm: https://helm.sh/
[16] Charts: https://artifacthub.io/
[17] Kustomize: https://kustomize.io/
[18] GitOps: https://www.gitops.tech/
[19] IaC: https://en.wikipedia.org/wiki/Infrastructure_as_Code
[20] Terraform: https://www.terraform.io/
[21] IaC: https://en.wikipedia.org/wiki/Infrastructure_as_code
[22] 持續部署: https://en.wikipedia.org/wiki/Continuous_deployment
[23] ADR: https://github.com/jamesmh/architecture_decision_record
[24] ArgoCD: https://argoproj.github.io/argo-cd/
[25] 此處: https://argoproj.github.io/argo-cd/core_concepts/
[26] Flux: https://fluxcd.io/
[27] Argo Workflows: https://argoproj.github.io/argo-workflows/
[28] Argo Events: https://argoproj.github.io/argo-events/
[29] Apache Airflow: https://airflow.apache.org/
[30] Argo 事件（Event）: https://argoproj.github.io/argo-events/
[31] Kubeflow: https://www.kubeflow.org/
[32] Tekton: https://tekton.dev/docs/pipelines/pipelines/
[33] Kanico: https://github.com/GoogleContainerTools/kaniko
[34] Istio: https://istio.io/
[35] 服務網格: https://en.wikipedia.org/wiki/Service_mesh
[36] 微服務: https://microservices.io/
[37] Linkerd: https://linkerd.io/
[38] 默認 mTLS: https://linkerd.io/2.10/features/automatic-mtls/
[39] 使用 Rust 構建的數據平面: https://github.com/linkerd/linkerd2-proxy
[40] 內存安全語言: https://github.com/linkerd/linkerd2-proxy
[41] 定期安全審計: https://github.com/linkerd/linkerd2/blob/main/SECURITY_AUDIT.pdf
[42] Consul: https://www.consul.io/
[43] Prometheus: https://prometheus.io/
[44] 滾動更新: https://www.educative.io/blog/kubernetes-deployments-strategies
[45] 金絲雀部署: https://semaphoreci.com/blog/what-is-canary-deployment
[46] Argo Rollouts: https://kubernetes.io/docs/concepts/architecture/controller/
[47] Kubernetes 控制器: https://kubernetes.io/docs/concepts/architecture/controller/
[48] CRD: https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/
[49] Istio: https://istio.io/
[50] Istio: https://istio.io/
[51] Flagger: https://flagger.app/
[52] Flux: https://fluxcd.io/
[53] Spinnaker: https://spinnaker.io/
[54] Crossplane: https://crossplane.io/
[55] AWS RDS: https://aws.amazon.com/rds/
[56] Terraform: https://www.terraform.io/
[57] Terraform: https://www.terraform.io/
[58] Pulumi: https://www.pulumi.com/
[59] AWS Lambda : https://aws.amazon.com/lambda/
[60] FaaS: https://en.wikipedia.org/wiki/Function_as_a_service
[61] Serverless: https://en.wikipedia.org/wiki/Serverless_computing
[62] 之前的文章: https://itnext.io/scaling-my-app-serverless-vs-kubernetes-cdb8adf446e1
[63] Knative: https://itnext.io/scaling-my-app-serverless-vs-kubernetes-cdb8adf446e1
[64] Argo Events: https://argoproj.github.io/argo-events/
[65] OpenFaas: https://www.openfaas.com/
[66] Kyverno: https://kyverno.io/
[67] 此處: https://github.com/kyverno/policies/
[68] Open Policy Agent: https://www.openpolicyagent.org/
[69] Kyverno: https://kyverno.io/
[70] OAM: https://oam.dev/
[71] Kubevela: https://kubevela.io/
[72] 雲原生計算基金會: https://cncf.io/
[73] Shipa: https://www.shipa.io/getting-started/
[74] Snyk: https://snyk.io/
[75] Falco: https://falco.org/
[76] Velero: https://velero.io/
[77] SchemaHero: https://schemahero.io/
[78] LiquidBase: https://www.liquibase.org/
[79] ArgoCD: https://argoproj.github.io/argo-cd/
[80] AWS Secret Manager: https://aws.amazon.com/secrets-manager/
[81] HashiCorp Vault: https://www.vaultproject.io/
[82] Sealed Secrets: https://github.com/bitnami-labs/sealed-secrets
[83] AWS Secret Manager: https://aws.amazon.com/secrets-manager/
[84] HashiCorp Vault: https://www.vaultproject.io/
[85] Capsule: https://github.com/clastix/capsule
[86] vCluster: https://www.vcluster.com/
[87] k3s: https://k3s.io/
[88] kube-burner: https://github.com/cloud-bulldozer/kube-burner
[89] Litmus: https://github.com/litmuschaos/litmus
[90] kubewatch: https://github.com/bitnami-labs/kubewatch
[91] BotKube: https://www.botkube.io/
[92] Mizu: https://getmizu.io/
[93] kube-fledged: https://github.com/senthilrch/kube-fledged
[94] OpenShift: https://www.openshift.com/
[95] Crossplane: https://crossplane.io/
[96] Argo Rollouts: https://kubevela.io/
[97] Kubevela: https://kubevela.io/
[98] vCluster: https://www.vcluster.com/
[99] Crossplane: https://crossplane.io/
本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/2TqClsjQg1-5M_AZwA2J2g