从 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 保持这个相同的起点。工作负载易于查找和检查，在命名空间和集群之间切换更加简单。 资源仍然以熟悉的方式组织，导航感觉更流畅，尤其是在跨多个环境工作时。
编辑和与资源交互
与 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 概念之上。 Namespaces、labels 和 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 可能会有所帮助。 提前进行一些思考可以大大有助于使过渡感觉顺畅和熟悉。
首先记录你访问的集群和命名空间以及认证如何工作。 Headlamp 依赖标准的 Kubernetes 认证和 RBAC。 在大多数情况下，现有的访问模型无需更改即可延续。 如果用户已经使用 kubeconfig 文件或服务账户连接，他们将能够在 Headlamp 中访问相同的资源。
思考对你的团队最重要的工作流程也很有用。 一些用户依赖 Dashboard 进行快速检查或故障排除，而另一些用户则用它进行轻量级编辑或验证。 Headlamp 支持这些相同的工作流程，并在此基础上添加可选功能。 了解你今天依赖什么有助于使过渡感觉可预测并建立信心。
如果你想在迁移前探索 Headlamp 或试用它，可以在 headlamp.dev 了解更多信息。
这篇博客重点介绍了理解过渡和预期内容。分步迁移指南即将推出，将详细介绍安装和迁移过程。