Hello folks，今天我们介绍一下由 Komodor 推出的开源项目 Helm-Dashboard。也是继 ValidKube 之后的第二个开源项目。
在解析 Helm-Dashboard 工具之前，我们先来了解一下 Helm 工具当前的使用现状。从编写 Kubernetes manifests 到每次出现新更改时手动部署以及升级，它会使的我们工作流程变得越来越复杂。因此，大多数团队迟早都会尝试考虑基于工具模型来简化应用程序的部署。Helm 恰好是一款部署应用程序最常用的包管理器，由于降低了在 Kubernetes 平台上部署应用程序的复杂性而被广泛采用至今。然而同时，随着各种技术体系的日渐成熟以及需求的复杂化，Helm 也同时面临着不少挑战：
1、没有使用时间序列数据对 Kubernetes 资源进行主动/实时监控 - 使用 Helm CLI 仅显示应用程序的当前状态，因此，难以进行故障排除
2、资源分组不当
3、访问图表的自述文件不是无缝的
4、缺少用于跨多集群管理 Helm 应用程序的统一界面
5、没有简单的方法来比较跨部署的部署值
除此之外，除了原生 Helm 挑战之外，还有一些其他问题也亟需解决，例如，如下事项：
1、没有对工作负载休眠的开箱即用支持
2、团队成员的复杂访问管理
因此，诚然 Helm 擅长打包 Kubernetes 应用程序，但在使用 Helm CLI 调试、故障排除应用程序方面及 Helm 的应用程序生命周期管理方面仍然需要完善、优化。
Helm Dashboard 背景摘要
在 2020 年 4 月， Helm 成为 CNCF 毕业项目时，已经被 70% 的 Kubernetes 用户使用。有人可能会争辩说，正是 Helm 为 Kubernetes 的全球采用打开了闸门，让模板、打包和部署应用程序变得非常容易，而无需深入了解 K8s。
然而，抽象出底层的复杂性为日常运营创造了一个“黑匣子”。操作和维护应用程序的责任转移给了开发人员，但在没有真正了解底层基础设施的情况下大规模地这样做变得极其困难。
更复杂的是缺少 UI，这迫使 Helm 用户通过 CLI 手动学习和执行许多命令。除了耗时之外，使用 CLI 还很难评估部署或回滚 Helm 图表的影响。比较不同版本的 Helm 图表及其对应的 K8s 资源也是一个非常低效的过程，尤其是在生产中面临故障排除问题的压力时。
对可视化和简化操作的需求产生了一个广泛的“帮助”工具生态系统，例如 Captain、Helm 控制器、Orkestra，它为相关的 Helm 版本及其子图表组添加了一个强大的依赖图，以及Terraform Helm Provider，它启用通过 Terraform 管理 Helm 图表。像 ArgoCD 和 Flux 这样的 GitOps 平台也通过 Helm 钩子或 Helm SDK 支持 Helm 图表。尽管我们热爱所有这些项目，但我们觉得生态系统缺少一个简单而全面的工具，专门用于简化变更智能和故障排除。
Helm Dashboard 概念
Helm-Dashboard 提供了一种基于 UI 驱动的方式来管理已部署的 Helm 图表信息，为所构建的 Kubernetes 和 Helm 平台提供了一个直观的仪表板，并使团队能够轻松协作并在 Kubernetes 之上更快地交付应用程序。以方便维护着能够实时查看其修订历史和相应的 Kubernetes 资源。此外，基于 Helm-Dashboard 还可以执行简单的操作，例如，回滚到修订版或升级到新版本等。
总而言之，通过构建有助于理解分布式云原生系统引入的复杂性的工具，让每个人都可以轻松访问 Kubernetes 操作和故障排除。
Helm Dashboard 基础功能
1、主动监控
通常我们使用 Helm CLI 工具进行操作时，则无法实时监控工作负载情况。使用部署/安装图表 helm install repo/chart 后，即使某些 Kubernetes 资源丢失或未成功部署，Helm status 也会始终显示为已部署。基于 Helm Dashboard，可以轻松地主动监控使用 Helm 图表部署的所有 Kubernetes 资源。它显示通过仪表板或终端部署的应用程序的实时状态。
假设，我们部署了一个 helm 图表，其中有一些配置错误。与 helm CLI 不同，Helm Dashboard 将显示状态为非“DEPLOYED”，因为图表配置不正确。如果一切正常并成功部署，状态将显示为“健康”。同样，如果图表已部署，并且有人删除了与之关联的任何 k8s 工作负载，Helm Dashboard 将立即将状态进行更新。
2、跨集群管理
使用 Helm CLI 或 Kubectl 的一大痛点是没有任何统一的平台/仪表板来管理混合云中跨多集群的部署。如上图所示，Helm Dashboard 做得非常直观。使用 Helm Dashboard 的 Clusters 选项卡，可以轻松地观察和管理跨多个环境和集群的部署，而无需考虑云提供商。
3、资源信息查看
通常，技术人员在进行故障排除时提出的主要问题之一是：自上次应用程序稳定以来“发生了什么变化”？在 Helm 的上下文中，比较 value.yaml 或其他可提供的文件是所有团队最常见的工作流程之一。 Helm Dashboard 提供了一种在处理事件或故障排除时比较 Helm 配置的便捷方式
4、资源分组
基于 Helm Dashboard 对所有应用程序的资源进行分组并将它们分类到不同的存储桶中，这样可以在调试时轻松找到正确的资源。
5、Chart 语法参考
如果想尝试一个新的 Helm 图表，我们将使用它的 README 来检查公开的不同参数、要传递的值等等。如果使用 Helm CLI，查阅 README 会变得很麻烦，一次又一次地导航到浏览器中的不同选项卡，在此过程中出现拼写错误或参数和值不匹配，所有这些都会导致花费更多时间来完成工作。基于 Helm Dashboard，我们可以在值旁边查看图表的 README，并在同一位置查看参数、它们的描述和要传递的值。
6、升级维护
通常情况下，基于不同的业务场景需要，我们可能在环境中部署不同的插件、配置不同的变量，基于环境的诉求，我们可能需要升级我们的资源。
当然，除上述的基础功能外，还有其他功能，例如，与其他主流的插件集成、部署值对比等，在实际的项目开发中也是非常重要的一环。
Helm Dashboard 部署安装
Helm-Dashboard 使用本地 Helm 和 Kubectl 配置运行，无需额外设置。 接下来，我们简要介绍一下。
[leonli@Leon ~ ] % helm version version.BuildInfo{Version:"v3.8.1", GitCommit:"5cb9af4b1b271d11d7a97a71df3ac337dd94ad37", GitTreeState:"clean", GoVersion:"go1.17.8"}
此时，安装 Helm-Dashboard，只需运行以下 Helm 命令：
[leonli@Leon ~ ] % helm plugin install https://github.com/komodorio/helm-dashboard.git
安装后，运行以下命令启动 UI：
[leonli@Leon ~ ] % helm dashboard INFO[0000] Helm Dashboard by Komodor, version 0.2.6 (15ce9170f3f3f61e72c376c3ecabc49b8b225a07 @ 2022-11-06T16:41:29Z) INFO[0000] User analytics is collected to improve the quality, disable it with --no-analytics INFO[0000] Opening web UI: http://localhost:8080 [GIN] 2022/11/12 - 15:03:22 | 200 | 5.824667ms | 127.0.0.1 | GET "/" [GIN] 2022/11/12 - 15:03:22 | 200 | 81.917µs | 127.0.0.1 | GET "/static/analytics.js" [GIN] 2022/11/12 - 15:03:22 | 200 | 108.958µs | 127.0.0.1 | GET "/static/styles-base.css" [GIN] 2022/11/12 - 15:03:22 | 200 | 49.292µs | 127.0.0.1 | GET "/static/actions.js" [GIN] 2022/11/12 - 15:03:22 | 200 | 162.75µs | 127.0.0.1 | GET "/static/styles.css" [GIN] 2022/11/12 - 15:03:22 | 200 | 20.875µs | 127.0.0.1 | GET "/static/scripts.js" [GIN] 2022/11/12 - 15:03:22 | 200 | 23.916µs | 127.0.0.1 | GET "/static/repo.js" [GIN] 2022/11/12 - 15:03:22 | 200 | 9.625µs | 127.0.0.1 | GET "/static/list-view.js" [GIN] 2022/11/12 - 15:03:22 | 200 | 23.125µs | 127.0.0.1 | GET "/static/revisions-view.js" [GIN] 2022/11/12 - 15:03:22 | 200 | 33µs | 127.0.0.1 | GET "/static/details-view.js" [GIN] 2022/11/12 - 15:03:22 | 200 | 126.708µs | 127.0.0.1 | GET "/status" [GIN] 2022/11/12 - 15:03:22 | 200 | 19.625µs | 127.0.0.1 | GET "/static/logo-header.svg" [GIN] 2022/11/12 - 15:03:22 | 200 | 7.375µs | 127.0.0.1 | GET "/static/komodor-logo.svg" [GIN] 2022/11/12 - 15:03:22 | 200 | 34.667µs | 127.0.0.1 | GET "/static/helm-gray.svg" [GIN] 2022/11/12 - 15:03:25 | 200 | 177.166µs | 127.0.0.1 | GET "/api/scanners" [GIN] 2022/11/12 - 15:03:25 | 200 | 64.375µs | 127.0.0.1 | GET "/status" [GIN] 2022/11/12 - 15:03:25 | 200 | 47.538459ms | 127.0.0.1 | GET "/api/kube/contexts" [GIN] 2022/11/12 - 15:03:25 | 200 | 123.917µs | 127.0.0.1 | GET "/static/topographic.svg" [GIN] 2022/11/12 - 15:03:25 | 200 | 102.18225ms | 127.0.0.1 | GET "/api/helm/charts" [GIN] 2022/11/12 - 15:03:25 | 200 | 41.25µs | 127.0.0.1 | GET "/static/helm-gray-50.svg" [GIN] 2022/11/12 - 15:03:29 | 200 | 72.583µs | 127.0.0.1 | GET "/static/logo.png" [GIN] 2022/11/12 - 15:03:37 | 200 | 104.25µs | 127.0.0.1 | GET "/" [GIN] 2022/11/12 - 15:03:37 | 200 | 58.875µs | 127.0.0.1 | GET "/static/analytics.js" [GIN] 2022/11/12 - 15:03:37 | 200 | 92.875µs | 127.0.0.1 | GET "/static/styles.css" [GIN] 2022/11/12 - 15:03:37 | 200 | 14.417µs | 127.0.0.1 | GET "/static/list-view.js" [GIN] 2022/11/12 - 15:03:37 | 200 | 11.833µs | 127.0.0.1 | GET "/static/revisions-view.js" [GIN] 2022/11/12 - 15:03:37 | 200 | 267.333µs | 127.0.0.1 | GET "/static/repo.js" ...
默认情况下，Web 服务器仅在本地可用。您可以通过将 HD_BIND 环境变量指定为所需的值来更改它。例如，0.0.0.0 将绑定到所有 IPv4 地址或 [::0] 将是所有 IPv6 地址。
如果端口 8080 被占用，可以通过 --port <number> 命令行标志指定要使用的不同端口。
此时浏览器会默认自动打开，可以访问仪表板：
从目前的行业趋势来看，Kubernetes 的使用量正在增加，无论大小公司，Helm 的使用也在增加。为了确保业务敏捷性，在部署具有更好管理和调试能力的 Kubernetes 时错误最小化，用户可以采用 Helm Dashboard 来维护团队所部署的资源情况。
如上为 Helm Dashboard 的相关内容解析，希望对大家有用。关于 Helm Dashboard 更多需要了解的信息，欢迎大家交流、关注！
Adiós !
