Kubernetes Dashboard为何被弃用 — 转向替代方案Headlamp

对于初次接触Kubernetes的人来说，Kubernetes Dashboard是一个熟悉的工具。它允许用户在网页界面上查看Pod和Deployment状态、查看日志或修改YAML，是kubectl不熟悉的用户一个很好的起点。

然而，情况已经发生了变化。Kubernetes官方文档明确指出Dashboard已deprecated and unmaintained，即这是一个计划停止使用且不再维护的项目。项目仓库也于2026年1月21日被归档，变为只读状态。

官方文档推荐作为新安装替代方案的工具是Headlamp。Headlamp不仅仅是重新创建了旧的Dashboard界面，它是一个现代化的Kubernetes UI，支持多集群、插件、桌面运行和集群内部署。

本文将总结Dashboard弃用对生产环境的意义、Headlamp带来了哪些改进，以及在实际迁移过程中如何设计认证和RBAC。

从旧的单集群管理界面过渡到现代多集群UI的景象

Kubernetes Dashboard发生了什么？

Kubernetes官方Dashboard文档目前明确显示以下内容：

Kubernetes Dashboard is deprecated and unmaintained.

这不仅仅意味着新功能会延迟添加。由于仓库已被归档且积极维护已停止，这意味着很难期待与新Kubernetes版本的兼容性、安全漏洞的响应以及依赖项的更新。

类别	当前状态
Kubernetes Dashboard 文档	明确标记为已弃用且不再维护
GitHub 仓库	2026年1月21日归档，只读
新安装建议	考虑Headlamp
现有安装	在了解使用现状后，有计划地迁移，而非立即停止

弃用并不意味着所有现有安装会立即停止工作。现有的Dashboard Pod和Service可以继续运行。然而，随着时间的推移，将一个不受支持的管理界面连接到集群API的负担会越来越大。

特别是，Dashboard可以提供以下敏感功能：

查看集群资源
创建和修改YAML
查看Pod日志
在Pod内部执行命令
访问包括Secret在内的配置资源
调整Deployment规模和重启

将一个已停止维护的UI与高权限的ServiceAccount一起持续暴露，并非一个好的运维选择。

为何Kubernetes Dashboard达到了极限？

Kubernetes Dashboard最初是一个在单个集群内运行的简单Web UI。虽然在小型实验环境中足够，但随着Kubernetes操作方式的变化，其局限性变得明显。

一次只查看一个集群的结构

Dashboard通常为每个集群单独安装。如果存在多个开发、测试和生产集群，您将需要单独管理每个Dashboard的URL和认证令牌。

随着集群数量的增加，会出现以下问题：

每个集群都需要部署和升级Dashboard
管理多个URL和Ingress策略
ServiceAccount和RoleBinding的重复
用户混淆当前正在查看哪个集群
难以比较不同环境间的资源

以Bearer Token为中心的不便登录

Dashboard主要通过输入ServiceAccount的Bearer Token进行登录。虽然简单，但在组织环境中，令牌的颁发、传递、保管和回收都非常繁琐。

为了方便而共享长期有效的令牌或cluster-admin权限账户会增加安全风险。令牌也可能残留在浏览器历史记录、即时通讯工具、文档或终端输出中。

难以扩展的固定UI

现代化的Kubernetes平台仅显示基本资源是不够的。

Argo CD和Flux的部署状态
Prometheus指标
Trivy和Kubescape的安全结果
OpenCost成本信息
KubeVirt虚拟机
组织特有的CRD和操作工作流

Dashboard难以将这些工具扩展到统一的用户体验中。

Headlamp是一个怎样的项目？

Headlamp是一个易于使用且可扩展的Kubernetes Web UI。它目前作为Kubernetes SIG UI下的官方Kubernetes子项目进行开发。

Headlamp可以以两种形式运行：

运行方式	连接方式	适用场景
桌面应用	用户的kubeconfig	个人运维人员、多集群、快速引入
集群内Web UI	ServiceAccount或OIDC	团队共享UI、中央URL、组织认证集成

桌面应用无需在集群内部署UI。它允许用户在一个应用程序中切换其现有kubeconfig中注册的多个集群。

Headlamp中切换多个Kubernetes集群的官方界面

图：从以单集群为中心的Dashboard扩展到多集群Headlamp的流程 · 来源：Kubernetes官方迁移文档 (CC BY 4.0)

集群内方式与Dashboard类似，在Kubernetes中部署Headlamp并通过浏览器访问。这适用于为团队提供公共URL或连接OIDC登录的场景。

Dashboard与Headlamp对比

项目	Kubernetes Dashboard	Headlamp
项目状态	已弃用，仓库已归档	活跃开发的Kubernetes SIG UI项目
部署方式	集群内	桌面或集群内
多集群	每个集群单独访问	基于kubeconfig在桌面端切换
认证	主要为ServiceAccount令牌	kubeconfig、令牌、客户端证书、OIDC
权限控制	Kubernetes RBAC	Kubernetes RBAC
扩展性	有限	支持插件
应用视角	以资源为中心	Projects和Map View等扩展视角
生态系统集成	有限	Flux、Prometheus、Trivy、OpenCost等插件

Headlamp不会创建独立的权限系统。用户可以查看的资源和可以执行的操作都遵循Kubernetes API的RBAC结果。

Headlamp Map View中可视化工作负载和服务关系的官方界面

图：Headlamp Map View可视化工作负载和服务关系的景象 · 来源：Kubernetes官方迁移文档 (CC BY 4.0)

这一点很重要：

安装Headlamp并不意味着权限就安全了，而是连接到Headlamp的认证信息和RBAC权限决定了其安全性。

最简单的迁移：Headlamp桌面应用

对于个人运维人员或平台工程师使用的环境，桌面应用是最简单的选择。

在macOS上，您可以使用Homebrew安装。

brew install --cask headlamp

在Windows上，您可以使用WinGet。

winget install headlamp

在Linux上，提供了Flatpak软件包。

flatpak install flathub io.kinvolk.Headlamp

Headlamp桌面应用默认读取用户的kubeconfig。如果使用多个kubeconfig，可以通过KUBECONFIG环境变量指定。

KUBECONFIG=~/.kube/dev:~/.kube/staging:~/.kube/prod headlamp

桌面方式的优点如下：

无需在集群中部署新的Web UI
不需要Ingress和公共Service
重用现有kubeconfig和用户认证
在一个屏幕上切换多个集群
直接应用每个用户的Kubernetes权限

另一方面，您需要管理用户PC的kubeconfig安全以及应用程序的部署和更新。对于提供公共操作界面的目的，集群内方式可能更合适。

团队共享UI：使用Helm进行集群内安装

添加Headlamp官方Helm仓库。

helm repo add headlamp https://kubernetes-sigs.github.io/headlamp/
helm repo update

创建一个单独的Namespace并安装Headlamp。

kubectl create namespace headlamp

helm upgrade --install headlamp headlamp/headlamp 
  --namespace headlamp

检查Pod和Service状态。

kubectl get pods,svc -n headlamp

首次测试功能时，使用port-forward比对外公开更安全。

kubectl port-forward -n headlamp svc/headlamp 8080:80

在浏览器中访问以下地址：

http://127.0.0.1:8080

在生产环境中，不要直接公开Helm默认值，而应根据组织标准配置Ingress、TLS、认证、NetworkPolicy和资源限制。

创建cluster-admin令牌前的考量

Headlamp官方安装文档展示了如何将cluster-admin连接到ServiceAccount作为快速测试示例。虽然方便功能验证，但不应作为生产环境的默认设计。

以下配置具有强大的权限：

kubectl create serviceaccount headlamp-admin -n headlamp

kubectl create clusterrolebinding headlamp-admin 
  --serviceaccount=headlamp:headlamp-admin 
  --clusterrole=cluster-admin

kubectl create token headlamp-admin -n headlamp

如果此令牌暴露，整个集群都可能被控制。如果只是将Dashboard中使用的cluster-admin令牌改个名字放到Headlamp中，UI虽然替换了，但安全问题依然存在。

在生产环境中，需要遵循以下原则：

每个人使用独立的身份。
如果可能，通过OIDC使用组织账户登录。
定义适合Namespace和职能的Role·ClusterRole。
分离只读用户和具有修改权限的用户。
单独审查Secret查看和Pod exec权限。
最小化共享ServiceAccount令牌的使用。
确保审计日志能够追踪每个用户的操作。

从只读权限开始的示例

如果需要一个可以查看整个集群但不能进行修改的账户，可以利用Kubernetes默认的view ClusterRole。

kubectl create serviceaccount headlamp-viewer -n headlamp

kubectl create clusterrolebinding headlamp-viewer 
  --serviceaccount=headlamp:headlamp-viewer 
  --clusterrole=view

kubectl create token headlamp-viewer -n headlamp

然而，view权限并非适用于所有组织。如果只需要显示特定的Namespace，应使用Namespace级别的RoleBinding而不是ClusterRoleBinding。

kubectl create rolebinding headlamp-team-a-view 
  --namespace team-a 
  --clusterrole view 
  --serviceaccount headlamp:headlamp-viewer

在部署前，使用kubectl auth can-i验证实际权限。

kubectl auth can-i --list 
  --as system:serviceaccount:headlamp:headlamp-viewer

同时单独检查特定的高风险操作。

kubectl auth can-i get secrets 
  --all-namespaces 
  --as system:serviceaccount:headlamp:headlamp-viewer

kubectl auth can-i create pods/exec 
  --all-namespaces 
  --as system:serviceaccount:headlamp:headlamp-viewer

不要只检查UI中是否看不到按钮，必须验证Kubernetes API是否实际拒绝了操作。

集成OIDC有什么好处？

如果团队使用集群内Headlamp，那么集成OIDC非常有价值。

使用OIDC可以创建以下操作模型：

사용자
  → 조직 Identity Provider
  → Headlamp
  → Kubernetes API
  → 사용자·그룹 기반 RBAC

优点显而易见：

无需传递共享令牌
从中央账户处理离职和部门调动
将用户和组映射到Kubernetes RBAC
在审计日志中区分人员身份
可利用MFA和条件访问策略

在OIDC配置中，Redirect URI、Client ID、Client Secret的存储方式以及Kubernetes API Server的OIDC设置必须保持一致。如果Headlamp URL发生变化，Redirect URI也必须更新。

Headlamp插件：优势与新的供应链边界

Headlamp的一大区别在于其插件。它不仅可以将基本的Kubernetes资源，还可以将组织使用的工具集成到UI中。

官方文档和项目资料中介绍了以下生态系统集成：

Flux
Prometheus
Trivy
Kubescape
OpenCost
KubeVirt
Backstage

插件显著改善了操作体验，但也扩大了信任边界。

插件来源和维护状态
请求的Kubernetes权限
前端访问的数据
外部API和网络通信
版本兼容性和更新流程
包完整性和供应链安全

在安装插件之前，应审查其来源、发布签名、权限和网络行为。建议不要随意添加不使用的插件。

从Dashboard迁移到Headlamp的实际步骤

安装新UI后无需立即删除现有Dashboard。并行运行一段时间，比较核心功能和权限会更安全。

第一步：调查当前Dashboard使用情况

谁在使用Dashboard？
访问哪些Namespace和集群？
在日志、exec、YAML修改中使用了哪些功能？
连接了哪些ServiceAccount和RoleBinding？
是否有Ingress和外部访问路径？

第二步：选择Headlamp运行方式

要求	推荐起点
个人运维人员管理多个集群	桌面应用
团队需要公共URL	集群内
组织账户和MFA集成	集群内 + OIDC
不想在集群中添加UI	桌面应用
通过插件集成平台功能	两种方式均可考虑

第三步：以最小权限验证功能

资源列表和详细信息
日志和事件
YAML查看·修改
Pod exec
Namespace切换
多集群切换
自定义资源显示
所需插件

每个功能都应由被授权用户和应被拒绝访问的用户进行测试。

第四步：保护Headlamp访问路径

使用应用TLS的独立主机
应用OIDC或批准的认证方式
最小化公共互联网暴露
NetworkPolicy和防火墙限制
审查CSP和安全头
审计访问和修改操作
固定Helm Chart和镜像版本

第五步：移除Dashboard

使用Headlamp完成主要任务和权限验证后，移除现有的Dashboard。

如果通过Helm安装，可以按如下方式删除：

helm uninstall kubernetes-dashboard 
  -n kubernetes-dashboard

检查剩余资源。

kubectl get all,sa,role,rolebinding 
  -n kubernetes-dashboard

同时检查Dashboard专用的ClusterRoleBinding。

kubectl get clusterrolebinding 
  -o custom-columns='NAME:.metadata.name,SERVICE_ACCOUNTS:.subjects[*].name' 
  | grep -i dashboard

不应自动删除此处发现的所有资源。在确认其他工具是否共享这些权限后，只删除Dashboard专用资源。

Headlamp并非所有情况的答案

Headlamp是Kubernetes官方文档提出的一个自然替代方案，但它并非一个能解决所有运维需求的平台。

在以下情况下，它应与其他工具一起使用：

声明式部署和变更历史：Argo CD, Flux
指标和警报：Prometheus, Grafana
日志搜索：Loki, OpenSearch, Elasticsearch
成本分析：OpenCost
安全态势管理：Trivy, Kubescape等
开发者自助服务门户：Backstage

Headlamp更接近于一个用于探索Kubernetes API和调查问题的UI。如果认为它能替代监控、GitOps、成本和安全工具，那么它的角色就过于庞大了。

迁移清单

领域	检查项
项目状态	在运维文档中反映Dashboard已弃用·归档状态
安装方式	根据目的选择桌面或集群内方式
认证	优先使用个人身份和OIDC而非共享令牌
RBAC	禁止默认使用cluster-admin，验证最小权限
网络	检查TLS、Ingress、NetworkPolicy和外部暴露
功能	测试日志、事件、YAML、exec、CRD和多集群
插件	审查来源、权限、更新和供应链风险
移除	清理Dashboard专用的ServiceAccount和Binding
运维	建立Headlamp版本·镜像·Chart更新流程

结论：这是重新设计访问权限而非仅仅替换UI的机会

Kubernetes Dashboard的弃用不仅仅是UI替换的消息。这是一个运维信号，需要判断是否继续将一个不再维护的管理UI连接到集群API。

Headlamp提供了桌面和集群内运行、多集群、OIDC和插件扩展性，展示了Dashboard之后Kubernetes UI的合适方向。

然而，迁移的核心并非安装Headlamp的命令。

不是简单地将Dashboard中使用的cluster-admin令牌直接迁移到Headlamp，而是必须重新设计用户特定的认证和最小权限RBAC。

个人运维人员可以从桌面应用和现有kubeconfig开始小规模尝试。如果团队需要公共UI，则考虑集群内部署和OIDC。在并行验证主要功能和权限后，通过清理Dashboard专用的ServiceAccount、RoleBinding和外部访问路径，即可完成迁移。