Kubernetes Dashboard 部署实战：从版本匹配到权限管理全指南-代码聚汇网

Kubernetes Dashboard 部署实战：从版本匹配到权限管理全指南

脑袋被门夹得好痛·2026-09-23·阅读 86 GEO检测（免费）

KubernetesDashboardkubectl

|难度：普通|阅读约 34 分钟

1. 先搞清楚Dashboard到底解决什么问题，再谈部署

1.1 命令行的效率极限和UI的存在意义

Kubernetes（后面统一叫K8s）能跑起来之后，大多数人的第一反应是：我又要背一堆kubectl命令了。确实，kubectl get pods、kubectl describe、kubectl logs 这些命令用久了会形成肌肉记忆，但并不代表命令行能覆盖所有场景。尤其是当你需要同时观察多个命名空间、快速判断某个工作负载的实时状态、或者给不太熟悉kubectl的同事交接任务时，纯命令行的工作效率会急剧下降。

Kubernetes Dashboard就是在这个背景下出现的官方可视化管理项目。它把Pod、Deployment、Service、ConfigMap、PVC、Ingress等资源以Web页面的形式呈现出来，支持查看、创建、编辑、删除操作，还内置了资源监控图表（配合Metrics Server）。说白了，它是给K8s集群装了一个"图形化驾驶舱"，让你不用每次都在终端里敲一长串命令才能定位问题。

1.2 Dashboard能管什么、不能管什么

先说能管的部分。Dashboard覆盖的范围其实挺广的：

工作负载：Deployment、StatefulSet、DaemonSet、Pod、ReplicaSet的查看与编辑
服务发现：Service、Ingress、Endpoint的查看与维护
配置管理：ConfigMap、Secret的查看与编辑
存储：PersistentVolumeClaim、StorageClass的查看
集群信息：Node列表及节点的资源水位
日志：容器标准输出的日志查看
扩容：在线修改副本数，触发滚动更新

不能管或者说管得比较弱的部分也要有数。Dashboard很难完成复杂的RBAC策略调整，Helm Chart的升级回滚也基本不适合在UI里点，CRD（自定义资源）的编辑体验非常有限，还有多集群统一管理这种需求更不是它的强项。你要是想跨集群做联邦管理，得另上Rancher或者KubeSphere这类企业级平台。

所以我的判断是：Dashboard最适合定位为"日常巡检和快速排查的辅助工具"，而不是唯一的运维入口。把kubectl当成主力、Dashboard当成可视化辅助，这个组合最实用。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 部署前的基础决策：版本匹配、镜像来源、暴露方式

2.1 Dashboard版本和Kubernetes版本的对应关系

部署之前最容易被忽略的就是版本匹配。不少人在网上随手找一篇博客，复制粘贴一份老旧的yaml文件，结果Dashboard的Pod一直CrashLoopBackOff，然后就开始怀疑集群有问题。实际上大概率是API版本或者兼容性问题导致的。

我列一下目前主流的对应关系，方便你对照自己的集群版本选择：

Dashboard版本	推荐K8s版本范围	说明
v2.7.0	1.24 ~ 1.27	目前最稳定的选择，老集群首选
v3.x	1.28+	新版UI改动较大，API兼容性覆盖到新版本
v4.x	1.29+	适配最新K8s，要求集群不能太旧

查询集群版本用：

code复制kubectl version --short

或者看服务端版本：

code复制kubectl get node -o wide

我的建议是：如果你的集群是1.24到1.27这个区间，直接用v2.7.0，资料多、踩坑答案也多，社区验证充分。如果是1.28以上的新集群，再考虑v3或v4。强行把新版本Dashboard塞进老集群，经常会出现Unknown resources或者接口请求失败。

2.2 镜像来源：官方yaml里的坑

Dashboard官方提供的recommended.yaml文件，是部署的核心入口。这个文件里包含了一次性创建ServiceAccount、Secret、Deployment、Service、RBAC等所有资源的定义。文件地址在GitHub的kubernetes/dashboard仓库下，路径是 aio/deploy/recommended.yaml。

直接部署的命令是：

code复制kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.7.0/aio/deploy/recommended.yaml

但这里有一个现实问题：repositories里默认使用的镜像是 registry.k8s.io/dashboard/dashboard:v2.7.0。如果你的网络环境无法直接访问这个镜像仓库，或者公司内网有严格的代理策略，Pod就会一直处于ImagePullBackOff状态。

解决办法不是让你改yaml里的所有内容，只需要改Deployment里的image字段。更快的办法是下载文件后做一次批量替换：

code复制wget https://raw.githubusercontent.com/kubernetes/dashboard/v2.7.0/aio/deploy/recommended.yaml
sed -i 's#registry.k8s.io/dashboard#你的镜像仓库地址/dashboard#g' recommended.yaml
kubectl apply -f recommended.yaml

注意只替换镜像仓库前缀，不要动后面的镜像名和tag。替换成什么取决于你实际能访问到的镜像源。如果是离线环境，可以在一台能联网的机器上用docker pull拉下镜像，再导出、导入到内网仓库，然后把Deployment里的image改成内网地址。这个过程本身也是运维基本功。

2.3 访问链路的选择：NodePort、kubectl proxy、Ingress

Dashboard默认创建的Service是ClusterIP类型，这意味着集群外部根本没法直接访问。三种主流的访问方式：

第一种，kubectl proxy隧道方式。 在本地机器上执行 kubectl proxy，然后访问：

code复制http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/

这种方式最安全，鉴权走的是kubeconfig，不需要额外开端口，适合个人在电脑上临时使用。缺点是不能多人共享，每次都要保持终端在运行。

第二种，修改Service为NodePort。 把kubernetes-dashboard这个Service的类型改成NodePort，然后在宿主机上通过 https://节点IP:30000 访问。这种方式适合小团队内网使用。我一般会单独写一个patch yaml，这样不会污染官方原始文件。

第三种，Ingress方式。 适合已经有Ingress Controller的集群，用域名访问，可以做TLS终结。生产环境推荐这种方式，因为可以结合证书管理，访问入口也更规范。

三种方式没有绝对的好坏，取决于你的使用场景。我的建议是初次部署先用kubectl proxy跑通全流程，因为不涉及网络层面的改动，排错成本最低。确认能登录之后再根据实际情况决定是否切到NodePort或Ingress。

3. 从yaml文件到Pod启动：完整部署步骤

3.1 获取官方recommended.yaml并部署

假设你的集群已经正常运行，具备kubectl管理权限。我们以一个干净的部署过程为例，把每一步都走一遍。

首选获取官方清单文件。用v2.7.0版本作为示范：

code复制kubectl create namespace kubernetes-dashboard

其实recommended.yaml里已经定义了命名空间的创建，不需要手动先建，但提前建好也无妨，方便后续资源隔离。然后直接应用整个文件：

code复制kubectl apply -f recommended.yaml

敲完命令之后，会自动创建以下资源（可以数一下，大概十几项）：

Namespace: kubernetes-dashboard
ServiceAccount: kubernetes-dashboard
Secret: kubernetes-dashboard-certs
ConfigMap: kubernetes-dashboard-settings
Deployment: kubernetes-dashboard
Service: kubernetes-dashboard
一堆ClusterRole和ClusterRoleBinding

3.2 检查Pod状态和关键日志

应用完yaml后，先看一下Pod有没有跑起来：

code复制kubectl get pods -n kubernetes-dashboard -o wide

正常情况下，你会看到类似下面的输出：

code复制NAME                                         READY   STATUS    RESTARTS   AGE
kubernetes-dashboard-6b7b8c9d4c-abcde        1/1     Running   0          10s

如果状态不是Running，用 kubectl describe pod -n kubernetes-dashboard <pod名> 看事件。最常见的两种情况：

ImagePullBackOff：镜像拉取失败，回到上一节说的方法处理镜像源
CrashLoopBackOff：容器启动后崩溃，大概率是版本不兼容或者证书初始化失败

日志排查命令：

code复制kubectl logs -n kubernetes-dashboard -l k8s-app=kubernetes-dashboard

在v2.7.0中，Dashboard默认会自动生成自签名证书，不需要你手动挂载证书文件。这个设计比以前版本省事很多。如果日志里出现 TLS: http: Server gave HTTP response to HTTPS client 之类的字样，多半是你用了HTTP去访问HTTPS端口，先检查访问方式再查别的。

3.3 配套部署Metrics Server，补全监控数据

刚部署完Dashboard，你会发现集群和节点的CPU、内存信息全是空的，页面上的曲线也没有数据。这时候需要确认集群里是否已经装了Metrics Server。

检查方法：

code复制kubectl get apiservices | grep metrics

如果没有对应的API Service列表，安装Metrics Server。官方地址是：

code复制kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

Metrics Server默认也有镜像拉取的问题，处理方法跟Dashboard类似，把image字段替换成可访问的镜像源即可。装好之后，再刷新Dashboard页面，节点和命名空间级别的资源使用率就能正常显示了。

这里有个细节要注意：Metrics Server启动参数里，有些环境需要加 --kubelet-insecure-tls，否则kubelet证书校验不过会导致无法采集数据。如果你的集群是自建证书，大概率会遇到这个问题。改Deployment参数时，在args里加上这个参数，然后重启Pod：

code复制kubectl edit deployment metrics-server -n kube-system

找到args段，确保包含 - --kubelet-insecure-tls。

4. 登录认证与账号体系：token用户、只读用户、命名空间隔离

4.1 创建集群管理员账号并获取token

Dashboard部署完成后，最关键的一步是认证。Dashboard v2.7.0支持的登录方式有两种：Kubeconfig和Token。日常使用中Token方式最灵活。

官方默认创建的 kubernetes-dashboard ServiceAccount权限很小，只能看一些基本信息，不满足管理需求。我们需要手动创建一个管理员账号：

yaml复制apiVersion: v1
kind: ServiceAccount
metadata:
  name: admin-user
  namespace: kubernetes-dashboard
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: admin-user
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- kind: ServiceAccount
  name: admin-user
  namespace: kubernetes-dashboard

保存为 dashboard-admin.yaml，执行：

code复制kubectl apply -f dashboard-admin.yaml

然后获取token。不同版本获取方式略有差异。v2.7.0及以上可以用下面这个命令：

code复制kubectl -n kubernetes-dashboard create token admin-user

如果是老版本，用：

code复制kubectl -n kubernetes-dashboard get secret $(kubectl -n kubernetes-dashboard get sa admin-user -o jsonpath="{.secrets[0].name}") -o go-template="{{.data.token | base64decode}}"

复制输出的一长串token内容，打开Dashboard登录页面，选择Token方式，粘贴就能登进去。

很多人一开始会拿 kubectl -n kubernetes-dashboard get secret 去列Secret，结果发现没有admin-user对应的Secret。这是因为从1.24开始，ServiceAccount不再自动创建长期有效的Secret，用 kubectl create token 生成的是短时token。短时token有有效期，默认一小时，过期之后重新执行命令再拿一次就行。

4.2 最小权限原则：只读账号和命名空间级账号

admin-user适合你个人管理集群时用。但如果你要把Dashboard分给团队其他人使用，所有人都用cluster-admin，那等于把集群的生死完全交到每个人手上了。我自己在带团队的时候，吃过这个亏——有人误删了某个命名空间下的所有Deployment，整个服务链直接断掉，最后只能靠备份恢复。

建议按角色拆账号：

只读账号，ClusterRole用view：

yaml复制apiVersion: v1
kind: ServiceAccount
metadata:
  name: readonly-user
  namespace: kubernetes-dashboard
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: readonly-user
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: view
subjects:
- kind: ServiceAccount
  name: readonly-user
  namespace: kubernetes-dashboard

这个账号能查看所有命名空间的资源，但不能创建、修改、删除。适合给测试人员、新入职的同学查看环境状态。

命名空间级开发账号，绑定到具体命名空间的管理角色：

yaml复制apiVersion: v1
kind: ServiceAccount
metadata:
  name: dev-user
  namespace: dev
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: dev-user-binding
  namespace: dev
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: admin
subjects:
- kind: ServiceAccount
  name: dev-user
  namespace: dev

注意这里是RoleBinding，不是ClusterRoleBinding，作用范围只限dev这个命名空间。这样开发同学只能在dev环境里折腾，再怎么误操作也影响不到生产环境。

4.3 登录界面与token过期处理

访问Dashboard登录页后，页面会提供Kubeconfig和Token两种登录选择。选Token，把token粘贴进去，点登录即可。

token过期后的表现是：页面上的接口请求开始返回401。这时候不要慌，回到终端重新执行：

code复制kubectl -n kubernetes-dashboard create token admin-user

拿到新token后重新登录。如果你嫌每次复制太麻烦，可以把这个命令写成一个shell alias，比如：

code复制alias dtoken='kubectl -n kubernetes-dashboard create token admin-user'
alias dtoken-readonly='kubectl -n kubernetes-dashboard create token readonly-user'

其实还有一个进阶做法：在浏览器端自动注入token。Dashboard支持在登录后把token存起来，但对于短时token意义不大，我一般还是手动复制。

5. 实际使用中绕不开的坑

5.1 坑一：镜像拉不下来导致Pod一直ImagePullBackOff

这个前面已经提过，但值得单独列出来，因为它是新手上路第一个拦路虎。现象就是 kubectl get pods -n kubernetes-dashboard 显示ImagePullBackOff。你可以先看看Pod事件确认原因：

code复制kubectl describe pod -n kubernetes-dashboard <pod名>

如果事件里明确写了ImagePullBackOff或者ErrImagePull，基本可以确定是镜像源访问问题。处理方式有两种：

手动把Deployment里的image字段改成你实际能拉到的镜像地址，然后重新apply
用sed命令批量替换整个yaml文件后再apply

改完之后记得观察Pod状态：

code复制kubectl get pods -n kubernetes-dashboard -w

等状态变成Running，再看日志确认有没有其他问题。

5.2 坑二：NodePort暴露后浏览器提示证书不安全

把Service改成NodePort后，通过 https://节点IP:30000 访问时，浏览器会跳出大红警告页，提示证书无效。这是自签名证书导致的，正常的。你可以选择点"高级"继续访问，也可以给集群配置正式的证书。

给Dashboard配置正式证书，需要在创建Dashboard之前提前在命名空间里创建一个包含证书的Secret，并把Deployment的启动参数指向对应的证书文件。配置过程略繁琐，内网环境完全没必要折腾，自签名证书点继续访问即可。

5.3 坑三：token类型选错导致登录一闪而过

登录页面有两种方式：Kubeconfig和Token。如果你选择Kubeconfig方式，需要上传kubeconfig文件，这是另一种鉴权路径，要求kubeconfig里的用户具备集群权限。如果你选Token方式，确认粘贴的是完整的token，不要有多余的空格或者截断。

如果你是用 kubectl get secret 方式拿token，在新版K8s里经常拿不到，因为ServiceAccount的Secret机制变了。用 kubectl create token 最靠谱。

5.4 坑四：登录后看到的是403 Forbidden

这个现象是登录成功了，但执行任何操作都提示没有权限。绝大多数原因是ServiceAccount没有绑定对应角色。你要检查两件事：

当前用的token对应的ServiceAccount是谁
这个ServiceAccount有没有绑定ClusterRole或Role

用管理员token排查：

code复制kubectl get clusterrolebinding | grep admin-user

如果admin-user的ClusterRoleBinding不存在，重新apply一次4.1节里的yaml。如果是只读账号疑似没权限，确认ClusterRoleBinding是用 view 而不是 view-only（没有这个ClusterRole，绑定会失败）。

5.5 坑五：节点监控数据全是空

Dashboard页面能进去，Pod列表也正常，但节点、命名空间页面的CPU和内存曲线全是空的。排查顺序：

先看Metrics Server容器状态：

code复制kubectl get pods -n kube-system -l k8s-app=metrics-server

如果运行正常，再调API确认：

code复制kubectl top nodes

如果 kubectl top 报错，说明Metrics Server和kubelet之间通信有问题。大概率是TLS校验问题，在Deployment里加 --kubelet-insecure-tls 参数后，重启Pod通常能解决。

6. 把Dashboard变成日常生产力工具：我的使用习惯

6.1 常用页面和工作流

Dashboard部署好之后，它不是用来"看个新鲜"的。我自己在项目里已经形成了一套固定的巡检流程，每天第一件事就是打开Dashboard，按这个顺序过一遍：

命名空间总览页：看每个命名空间的资源使用占比，哪个命名空间CPU或内存快打满了，马上能发现
Pod列表页：按状态排序，优先看CrashLoopBackOff和Pending的Pod，这些是影响服务可用性的头号目标
存储页面：确认PVC有没有接近容量上限，防止磁盘写满导致Pod eviction
工作负载页面：检查Deployment的副本数是否和期望值一致，有没有意外的缩容

这套流程用命令行也能做，但Dashboard的图形化展示让信息的采集速度提升了一个量级，尤其是当你负责的集群中有几百个Pod时，用眼睛扫一遍页面比一条一条跑kubectl效率高太多。

6.2 安全加固建议

Dashboard默认完全裸露在集群内部，它本身不提供用户管理和登录注册功能，只有Token和Kubeconfig两种认证。所以安全加固的重点在于控制访问边界：

不要把Dashboard的Service直接暴露到公网，默认的ClusterIP就很好
如果非要用NodePort，建议同时开启防火墙，白名单放行需要访问的IP
用Ingress方案时，加上Basic Auth或者OIDC认证作为前置拦截
定期清理不用的ServiceAccount，避免一个token通吃所有环境

我在实践中发现，很多同行连Dashboard的Service类型都不改，直接保持ClusterIP，然后全程用kubectl proxy隧道访问，安全和便捷性平衡得特别好。

6.3 扩展：日志与监控面板联动

如果你已经部署了Grafana Loki这类日志系统，可以尝试把Dashboard和Loki的查询能力结合在一起。Dashboard本身不做日志采集，它显示的是容器实时日志，不会留存历史数据。要查异常退出之前的日志，还是得靠Loki这类集中式日志平台。

我目前的工作流是：Dashboard负责快速发现异常Pod，Loki负责回溯日志深挖原因，Grafana负责长期趋势监控。三者各司其职，整套链路跑下来很顺。这也提醒你，Dashboard不是万能的，它只是可视化日常巡检的第一站，后面的日志分析、监控告警、链路追踪，需要搭配对应的专业工具才能形成完整的运维闭环。

根据我个人经验，第一次部署Dashboard最好就在测试环境完整走一遍上面的流程，把版本、镜像、认证、权限这几个环节都摸清楚，再去生产环境操作心里就有底了。踩过的坑越多，后面的集群越稳定。