Kubernetes Dashboard 已归档，Headlamp 接棒——迁移思路与上手实战

Kubernetes Dashboard 正式归档了。对很多人来说，它是第一个让集群"看得见、摸得着"的工具，帮无数开发者和运维从 kubectl get pods 的纯命令世界迈出了第一步。Dashboard 的贡献值得尊重，但单集群、功能固定、扩展性有限的架构，已经跟不上今天多集群、多团队的实际用法。Headlamp 不是简单换了个名字的替代品——它在保留 Dashboard 熟悉体验的同时，补上了多集群管理、应用视角聚合、插件扩展和灵活部署这几块短板。这篇文章帮你理清迁移思路，并给出可以直接跑的部署示例。

熟悉的工作流，不用重新学

如果你用过 Dashboard，Headlamp 的上手成本几乎为零。核心操作逻辑没有变，只是做得更顺畅。

浏览资源——Pod、Deployment、Service、Namespace，入口和层级与 Dashboard 一致，但跨 Namespace、跨集群的切换更直接，不再需要反复切换上下文。

编辑与交互——查看和修改 YAML、删除资源、扩缩 Deployment，这些操作 Headlamp 都支持，且完全遵循现有 RBAC 权限。你之前能做的操作，现在照样能做，权限边界不变。

资源关系可视化——这是 Headlamp 开始拉开差距的地方。Dashboard 只有列表视图，Headlamp 增加了资源关系图，让你一眼看到 Workload、Service、ConfigMap 之间的关联，排查问题时不用逐个资源拼拼图。

一句话总结：你之前的操作习惯全部保留，Headlamp 只是在同样的地基上加了更多房间。

Headlamp 超越 Dashboard 的四个方向

多集群：一个界面管所有环境

Dashboard 只能连一个集群。对只有一套环境的团队来说够用，但一旦有了 dev / staging / production 多套集群，你就得开多个浏览器标签、反复切换 kubeconfig，容易出错也容易迷失上下文。

Headlamp 在一个界面内接入多个集群，切换时保留当前操作上下文。这对管理多环境的团队来说，摩擦大幅减少。

Projects：从"资源列表"升级到"应用视角"

Dashboard 的视角是资源维度——你要看一个应用的状态，得在 Deployment 列表找 Workload，再去 Service 列表找入口，再去 ConfigMap 找配置，拼凑出全貌。

Headlamp 的 Projects 功能把相关资源按应用维度聚合：同一个业务的 Workload、Service、ConfigMap、Secret 形成一个视图，变更追踪和故障排查都在同一个上下文里完成。底层仍然是原生 Namespace + Label + RBAC，Projects 只是加了一层可视化聚合，不改变任何 Kubernetes 原生概念。而且 Projects 是可选的——你完全可以继续按资源维度逐个查看，只在需要全局视角时才切换到 Projects。

插件：把工作流收进同一个界面

Headlamp 的插件机制让常见工作流不用跳出 UI：

• Flux 插件——把 GitOps 状态和 Kubernetes 资源放在同一屏，Git 里的变更和集群里的运行状态一目了然。
• AI Assistant 插件——在当前资源页面内提供对话式辅助，解释你看到的内容、建议排查方向，不用另开终端或搜索引擎。

更重要的是，插件不限于社区提供的。平台团队可以自己写插件，把内部工具链、审批流程、自定义仪表盘收进 Headlamp，保持用户体验一致。

部署方式：集群内 + 桌面端，按场景选

Dashboard 只能跑在集群内。Headlamp 给了两种选择：

• In-cluster 部署——适合共享环境，集中管理访问权限，走集群内认证和 RBAC，和 Dashboard 的部署模式一致。
• 桌面应用——适合本地开发和多集群日常管理，直接读本地 kubeconfig，不需要在集群里部署任何东西。

两种方式不互斥。很多团队的日常做法是：桌面端做日常操作，集群内部署给生产环境做共享访问。

上手实战：三种方式部署 Headlamp

下面给出三种可以直接复制运行的部署方式，按你的场景选择。

方式一：桌面端快速体验（零部署成本）

最简单的起步方式——下载桌面应用，直接用现有 kubeconfig 连集群。

# macOS (Homebrew)
brew install --cask headlamp

# Linux (Flatpak)
flatpak install flathub io.kinvolk.Headlamp

# Windows — 从官网下载安装包
# https://headlamp.dev/docs/latest/installation/

安装后启动应用，它会自动读取 ~/.kube/config 中已配置的集群。如果你本地 kubeconfig 已经能连集群，Headlamp 打开就能用，不需要任何额外配置。

方式二：In-cluster 部署（Helm）

适合团队共享访问，替代原来 Dashboard 的集群内部署。

# 添加 Helm repo
helm repo add headlamp https://headlamp-k8s.github.io/headlamp-helm
helm repo update

# 基础安装（默认命名空间 headlamp）
helm install headlamp headlamp/headlamp \
  --namespace headlamp \
  --create-namespace

# 如果需要指定自定义证书或 ingress，可以覆盖 values
helm install headlamp headlamp/headlamp \
  --namespace headlamp \
  --set ingress.enabled=true \
  --set ingress.host=headlamp.example.com \
  --set ingress.tls=true

安装完成后获取访问入口：

# 查看 Service
kubectl get svc -n headlamp

# 如果没有 Ingress，可以用 port-forward 快速验证
kubectl port-forward -n headlamp svc/headlamp 8080:80

浏览器打开 http://localhost:8080，用 ServiceAccount token 或集群认证方式登录。

方式三：为 Headlamp 创建专用 ServiceAccount（RBAC 示例）

如果你在集群内部署 Headlamp 并需要受控访问，可以创建专用 ServiceAccount：

apiVersion: v1
kind: ServiceAccount
metadata:
  name: headlamp-admin
  namespace: headlamp
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: headlamp-admin-binding
subjects:
  - kind: ServiceAccount
    name: headlamp-admin
    namespace: headlamp
roleRef:
  kind: ClusterRole
  name: cluster-admin   # 生产环境请替换为更细粒度的自定义 ClusterRole
  apiGroup: rbac.authorization.k8s.io

# 应用 RBAC 配置
kubectl apply -f headlamp-rbac.yaml

# 获取 token（Kubernetes 1.24+ 需要手动创建 Secret）
kubectl create token headlamp-admin -n headlamp --duration=24h

拿到的 token 在 Headlamp 登录页输入即可。生产环境务必把 cluster-admin 替换为按 Namespace 和资源类型限权的自定义 Role。

迁移前的自查清单

在动手迁移之前，花 10 分钟确认这几项，能让过渡更顺畅：

写在最后

Dashboard 归档不是终点，而是 Kubernetes UI 工具演化的一个自然节点。Headlamp 没有推翻你已有的操作习惯，而是在同样的地基上加了多集群、应用视角、插件扩展和灵活部署——这些正是今天实际使用 Kubernetes时最常碰到的痛点。

迁移建议：先用桌面端连接现有集群试一周，确认高频操作都顺畅，再决定是否用 Helm 在集群内部署共享版本。官方的逐步迁移指南即将发布，但核心操作逻辑的延续性已经足够让你放心起步。

更多信息和插件开发文档，见 headlamp.dev。