从 Kubernetes Dashboard 到 Headlamp：理解这一过渡

对许多人来说，Kubernetes Dashboard 是他们了解 Kubernetes 的第一个窗口。它提供了一种简单的可视化方式，用于查看集群中正在运行的内容、检查资源，并在不依赖命令行的情况下建立信心。多年来，它帮助开发者、学生和运维人员理解 Kubernetes，并成为进入该生态系统的重要入口。

Kubernetes Dashboard 项目现已归档。我们非常尊重该团队所做的工作，以及 Dashboard 在让众多用户更容易接触 Kubernetes 方面所发挥的作用。

Headlamp 建立在这一基础之上，并将其延续下去。它保留了可视化界面的清晰性，同时增加了与当今 Kubernetes 使用方式相匹配的能力。这包括多集群可见性、以应用为中心的视图、通过插件实现的可扩展性，以及既适用于集群内又适用于桌面的灵活部署选项。

本指南旨在帮助你有信心地完成这一过渡。在深入迁移机制之前，我们先从熟悉的内容开始，了解常见的 Kubernetes Dashboard 工作流如何映射到 Headlamp。我们还会介绍切换后哪些内容保持不变，哪些方面得到改进。目标不仅是替换一个工具，而是尊重以用户为中心的传承，并帮助你进入一个能够随着 Kubernetes 使用方式演进而共同成长的 UI。

将 Kubernetes Dashboard 工作负载映射到 Headlamp

如果你以前使用过 Kubernetes Dashboard，Headlamp 中的许多工作流都会让你感到熟悉。Headlamp 并不会引入一种新的思维方式。相反，它基于用户已经熟悉的工作负载，并以实用的方式对其进行扩展。重点在于连续性。过去有效的方式仍然有效，并且有了更多成长空间。

查看工作负载和资源

在 Kubernetes Dashboard 中，大多数用户一开始会浏览 Pod、Deployment、Service 和 Namespace 等工作负载。Headlamp 保留了同样的起点。工作负载易于查找和检查，在 Namespace 和集群之间切换也更简单。资源仍以熟悉的方式组织，导航体验更顺畅，尤其是在跨多个环境工作时。

编辑资源并与资源交互

与 Kubernetes Dashboard 一样，Headlamp 允许你根据权限直接在 UI 中查看和编辑清单。你可以从界面中删除资源、扩缩工作负载或更新配置。所有操作都遵循标准的 Kubernetes RBAC。如果你能在 Dashboard 中执行某项操作，那么在 Headlamp 中也能找到相同能力，并同样遵循访问控制。

理解关系

Headlamp 开始扩展体验的地方，在于它呈现资源之间关系的方式。除了列表视图，Headlamp 还提供可视化方式，用于查看工作负载、服务和配置之间如何连接。这有助于提供上下文，而不会改变用户已经依赖的底层工作负载。

从总体上看，你在 Kubernetes Dashboard 中执行的任务仍然存在。Headlamp 保留了熟悉的工作流，同时让集群、团队和应用增长时更容易扩展。

Headlamp 超越 Kubernetes Dashboard 的方面

从单集群扩展到多集群工作流

Kubernetes Dashboard 设计为一次处理一个集群。对于简单配置而言，这种模式运行良好，但随着团队采用多个环境，它开始变得受限。Headlamp 扩展了这一视图，让你可以在单一界面中处理多个集群，而无需切换工具或丢失上下文。这使并排管理开发、预发布和生产环境变得更容易。

对于在多个位置运行 Kubernetes 的团队来说，这种转变减少了摩擦。你可以保持方向感，并有信心地在集群之间切换。

通过 Projects 从资源列表转向应用上下文

Projects 提供了一种以应用为中心的方式来查看 Kubernetes。你不必在列表之间来回跳转，而是可以把相关的工作负载、服务和支撑资源分组到一个地方。这让应用更容易理解。你可以看到哪些内容属于同一整体，在上下文中跟踪变更，并在无需逐段扫描集群的情况下进行故障排查。

Projects 构建在原生 Kubernetes 概念之上。Namespace、Label 和 RBAC 继续以一直以来的方式工作。Headlamp 增加了一个可视化层，将相关资源汇聚在一起。

Projects 是可选的。当任务更适合时，你仍然可以在单个资源层级工作。当你需要更多上下文时，Projects 可帮助你退后一步，看到更大的图景。

通过插件扩展 Headlamp UI

Headlamp 可以通过插件进行扩展，将常见工作流直接带入 UI。你无需切换工具，而是在同一位置、同一上下文中工作。

例如，Flux 插件将 GitOps 工作流带入 Headlamp。它允许团队在查看应用状态的同时查看 Flux 管理的 Kubernetes 资源，从而更容易理解 Git 中的变更与集群中运行内容之间的关系。

AI Assistant 遵循类似模式。它为 UI 添加了一个对话层，帮助用户理解他们所看到的内容、排查问题或采取操作。所有这些都发生在问题出现的同一个屏幕中。

构建你自己的插件

插件是可选的，并且不限于社区构建的扩展。平台团队和项目团队也可以创建自己的插件。这使组织能够添加符合其特定工作流和内部工具的自定义集成，同时保持一致的用户体验。

选择 Headlamp 的运行方式和位置

Headlamp 为团队使用 Kubernetes UI 的方式提供了灵活性。你可以直接在集群中运行它，将其作为桌面应用使用，或根据需求结合两种方式。

在集群内运行 Headlamp 非常适合共享环境。它提供一个集中管理的 UI，具备受控访问，并自然契合 Kubernetes 设置，遵循与其他集群内组件相同的身份验证和 RBAC 规则。

桌面应用通常更适合本地开发和入门上手。当你需要从一个地方管理多个集群时，它也很适用。用户可以使用现有的 kubeconfig 进行连接，而无需在集群中部署任何内容。

这些选项并不互斥。许多团队将桌面应用用于日常工作，同时依赖集群内部署来支持共享环境或生产环境。

为迁移做准备

在从 Kubernetes Dashboard 迁移到 Headlamp 之前，暂停一下并梳理你目前如何使用 Dashboard 可能会有所帮助。前期稍作思考，可以在很大程度上让过渡感觉更顺畅、更熟悉。

首先记录你访问哪些集群和 Namespace，以及身份验证如何运作。Headlamp 依赖标准的 Kubernetes 身份验证和 RBAC。在大多数情况下，现有访问模型可以不做更改地延续。如果用户已经使用 kubeconfig 文件或服务账户连接，他们将能够在 Headlamp 中访问相同资源。

思考对团队最重要的工作流也很有用。一些用户依赖 Dashboard 进行快速检查或故障排查，另一些用户则用它进行轻量级编辑或验证。Headlamp 支持这些相同工作流，并在其上添加可选能力。了解你今天所依赖的内容，有助于让过渡更可预测并增强信心。

如果你想了解 Headlamp 或在迁移前试用，可以在 headlamp.dev 获取更多信息。

本文重点介绍如何理解这一过渡以及可以期待什么。分步迁移指南即将推出，并将详细介绍安装和迁移过程。

• ← 上一篇
• 下一篇 →