1. 部署前的版本选型与方案权衡1.1 版本匹配为什么是第一个坑凡是碰过 k8s dashboard 部署安装的，几乎都吃过版本不匹配的亏。Kubernetes 的版本迭代速度快，而 Dashboard 作为官方社区维护的可视化面板，它的兼容列表往往滞后于集群版本。你拿一个新的 Dashboard 版本去对接一个老旧的集群，或者反过来，最常见的结局就是 Pod 一直 CrashLoopBackOff，打开页面之后接口报错，节点和 Pod 列表刷不出来，界面空白一片。所以不管你是给生产环境搭管理界面，还是在自己电脑上用 kind / minikube 跑一套测试集群，第一步先说死：先查清楚你的集群版本，再决定用哪个 Dashboard 版本。Kubernetes API 是带组和版本号的，Dashboard 内部会调用 cluster-info、metrics.k8s.io、apps/v1、batch/v1 这些 API，哪怕只是小版本不匹配，也可能导致部分接口返回 403 或者直接 EOF。我在一个测试环境里踩过典型例子：集群是 Kubernetes 1.29，当时装 Dashboard 2.7.0 完全正常，但某同事先在 1.28 集群上手动改了镜像标签去拉 3.0 的新版，结果 API 兼容层直接罢工，Deployment 的副本数都显示不出来。后来切回匹配版本，一切恢复。一个比较稳妥的做法：在部署菜单还没有变成 Helm 默认之前，先去 GitHub 的 releases 页面看那个版本对应的 Kubernetes 最低版本，按图索骥。如果你不喜欢翻文档，也有个偷懒的办法——用 manifests 子目录里的 recommended.yaml，它所绑定的版本一般经过社区回归测试。但我的建议是，不要把“latest”标签用于任何生产环境，因为你永远不知道下一次 apply 会不会给你推送一个 API 变更的版本。1.2 三种部署方式怎么选k8s dashboard 部署安装的主流方式有三种，我按自己的使用频率排序：第一种，官方 YAML 直接 apply。打开官方 GitHub 仓库，找到 releases，复制对应版本下的recommended.yaml链接，然后kubectl apply -f。这是最省事、最不容易出错的路径，也是本文后面实操部分采用的方式。它适合第一次部署、测试环境快速验证和想快速看效果的人，所有配置项都集中在 YAML 里，方便我们按自己的需求做修改。第二种，用 Helm Chart。Dashboard 官方没有单独的 Helm 仓库，但社区 Chart 挺多，也有维护得不错的。Helm 的优势是通过 values.yaml 暴露配置项，比如证书、副本数、镜像仓库地址，改起来比手动修改官方 YAML 要干净。但社区 Chart 的维护质量和官方 YAML 不同步，偶尔会出现字段名对不上的情况，比如extraArgs的写法变了，导致你改了不生效。如果你对 Helm 本身不熟，我不建议用它作为第一选择。第三种，自己拼 YAML。这种属于“受控环境”的玩法，比如无外网环境下的离线安装，或者公司安全合规要求所有镜像必须走内部镜像仓库。操作上就是把 recommended.yaml 下载下来，批量替换 image 字段为内网地址，然后 apply。依赖的镜像是kubernetesui/dashboard和kubernetesui/metrics-scraper，提前在能联网的机器上docker pull然后docker save，再传到内网docker load，整个流程就闭环了。我个人的建议是，优先官方 YAML，后续需要做证书、Ingress 接入，再在官方 YAML 基础上改。别把问题复杂化。2. 证书、存储与命名空间的关键细节2.1 证书方式决定了浏览器地址栏长什么样很多人在 k8s dashboard 部署安装完成、Pod 也 Running 了，结果访问的时候被浏览器拦截，这是因为 Dashboard 默认用的是自签证书。这个证书在启动时会自动生成，但你换个设备访问又要重新点一次信任，烦得很。如果你只是本机kubectl proxy访问，其实可以完全不关心证书问题。但如果要通过 NodePort 或 Ingress 暴露，建议在部署前就把证书问题想清楚。常见的做法有两种：第一种，使用正式的 CA 签发的证书。就是先去申请一张覆盖你域名的证书，然后把 tls.crt 和 tls.key 存成 Kubernetes Secret，Secret 的名字必须是kubernetes-dashboard-certs，命名空间是kubernetes-dashboard。Dashboard 启动时会自动读取这个 Secret 里的证书，然后你的浏览器就不会报警了。关键点是，你需要在 apply 官方 YAML 之前把 Secret 创建好，或者先 apply 再重建 Deployment，否则 Pod 启动时发现没有证书就会重新生成自签证书。第二种，自建内部 CA。公司内部有很多用户却不想暴露公网，就用 OpenSSL 自建 CA，签发一张给 Dashboard 域名用，然后把 CA 下发到团队所有人的电脑上，导入信任列表。这一步做下来，浏览器会显示证书受信任，也不用每台机器单独点风险提示。我干活时的细节是，用 OpenSSL 签发证书之前先检查 SAN 字段，证书的 Subject Alternative Name 必须包含你的 Dashboard 域名，不能只写在 CommonName 里。这个字段现在浏览器强制执行，漏了就等着每台电脑都报错，然后你到处解释为什么明明证书是“对”的却不被信任。openssl req -x509 -nodes -days 365 -newkey rsa:2048 \ -keyout dashboard.key \ -out dashboard.crt这个只是生成自签证书，生产环境请走公司 CA 系统。把证书转成 Secret：kubectl -n kubernetes-dashboard create secret tls kubernetes-dashboard-certs \ --cert=dashboard.crt --key=dashboard.key2.2 存储与命名空间的设计思路Dashboard 本身是无状态应用，它不需要持久化存储，因为它不做数据落盘。但它依赖 metrics-server 或者 metrics-scraper 来展示集群的 CPU、内存监控数据，metrics-scraper 同样是无状态的。真正的“存储”问题出现在你的浏览器端。Dashboard 把用户偏好、主题设置之类的东西存在了 localStorage 里，所以不存在跨设备同步的问题。不要为了 Dashboard 单独建 PVC，那是白费劲。比较值得关注的是命名空间的选择。官方 YAML 固定把什么东西都放在kubernetes-dashboard这个命名空间里。你可以用这个名字，也可以改成自己的命名空间，但强烈建议保持默认。原因是，官方文档里所有证书、ServiceAccount、ClusterRoleBinding 的例子都默认指向这个命名空间，你一旦改名，后面排查问题的时候看到资料，所有命令都要自己改一遍，烦不烦？而且多个环境统一使用同一个命名空间，也方便脚本化处理。生产环境我见过有人把 Dashboard 的 ServiceAccount 权限放大到 cluster-admin，这确实最省事，但不是最安全的做法。后面我会单独讲权限收紧的问题。3. 实操全过程：从下载到访问3.1 下载 recommended.yaml 并检查内容先把 Dashboard 的 YAML 文件拉下来。wget https://raw.githubusercontent.com/kubernetes/dashboard/v2.7.0/aio/deploy/recommended.yaml如果你的网络访问 GitHub 比较费力，可以用镜像站，或者先下到本地再传上去。我一般在服务器上用 wget，如果失败就用代理下载再传。注意，下载完之后，别急着直接 apply，先把关键内容读一遍。我习惯打开 YAML 之后重点看几个地方：Service 是否定义了 type，默认是 ClusterIP；Deployment 和 metrics-scraper 的镜像版本；ServiceAccount、ClusterRoleBinding 的配置；--namespace=kubernetes-dashboard参数是否存在。这一步是为了确认，这份 YAML 里没有任何让你意外的配置。尤其是当初遇到过某些第三方包，往里面塞了一些额外的网络钩子，所以自己检查一遍最稳。3.2 执行部署并检查 Pod 状态确认无异常后再执行：kubectl apply -f recommended.yaml官方 YAML 的内容比较多，包含 Namespace、ServiceAccount、Secret、ConfigMap、Deployment、Service 等多个资源。执行完以后，官方也会提示你查看kubernetes-dashboard命名空间下的资源状态。kubectl -n kubernetes-dashboard get pods正常情况你会看到两个 Pod，一个是 dashboard，一个是 metrics-scraper，状态都是 Running。如果出现 ImagePullBackOff，通常是镜像拉取失败，先确认集群能不能访问 Docker Hub，不行就按第一节的方法改内网镜像源。如果是 CrashLoopBackOff，优先看日志。kubectl -n kubernetes-dashboard logs -l k8s-app=kubernetes-dashboard最常见的原因，就是证书 Secret 被改了而 Pod 没有重新创建，或者 API 版本不兼容。看日志时留意有没有Failed to start和证书相关的关键字。3.3 创建一个可登录的账号与 TokenDashboard 登录有两种方式：Token 和 Kubeconfig。如果你只是开发环境自己用，用 Token 最简单。官方 YAML 本身不创建专门的登录用户。你在 Postman 调接口一样，得有身份才能访问，Dashboard 默认拿 Kubernetes ServiceAccount 认证。所以先创建一个只读的管理员账号。我这里通常创建一个叫 dev-admin 的 ServiceAccount：apiVersion: v1 kind: ServiceAccount metadata: name: dev-admin namespace: kubernetes-dashboard然后绑定到集群角色。如果你只是日常看资源，用 view 角色就够了，但修改不了资源。如果整个测试集群就你自己在用，也可以给 cluster-admin，生产环境则千万不要。apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: dev-admin roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: cluster-admin subjects: - kind: ServiceAccount name: dev-admin namespace: kubernetes-dashboard保存为 dashboard-account.yaml，然后：kubectl apply -f dashboard-account.yaml接着查询 Token。旧版 Kubernetes 的 ServiceAccount 会对应一个长期有效的 Secret，我们可以直接获取。新版 Kubernetes 从 1.24 开始，ServiceAccount 不再自动创建 Secret，而是创建 TokenRequest，所以我们更推荐用下面这个命令生成一个有有效期的 Token：kubectl -n kubernetes-dashboard create token dev-admin这条命令的输出就是一份访问令牌，把它复制下来，在登录页面选择 Token 方式粘贴即可。需要注意，这种 Token 有过期时间，默认一小时左右。你要做自动化或者给别的同事用，就得用定期刷新机制。临时用就无所谓，过期了再生成一次。3.4 开启访问通道的三条路Pod 跑起来了，账号建好了，接下来就是怎么打开页面。第一条路，kubectl proxy。在本地执行kubectl proxy，然后浏览器访问http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/。这个方式对零暴露最安全，但路径又长又丑，只适合本地快速看一眼。第二条路，NodePort。修改 Dashboard Service：kubectl -n kubernetes-dashboard edit svc kubernetes-dashboard把 type 改成 NodePort，然后kubectl -n kubernetes-dashboard get svc查看被分配的节点端口。浏览器访问https://任何节点IP:端口。测试集群懒人方案，但生产环境不建议，因为直接把端口暴露到局域网，缺少额外的认证保护。第三条路，Ingress。这也是我生产环境用的方式。需要集群里已有 Ingress Controller，然后创建一个 Ingress 对象：apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: kubernetes-dashboard namespace: kubernetes-dashboard annotations: nginx.ingress.kubernetes.io/backend-protocol: "HTTPS" spec: rules: - host: dashboard.example.com http: paths: - path: / pathType: Prefix backend: service: name: kubernetes-dashboard port: number: 443这里最关键的是backend-protocol: HTTPS注解。因为 Dashboard Service 的入口协议是 HTTPS，如果你的 Ingress 不声明这一点，nginx 会用 HTTP 去连后端，结果就是 502。这个坑，我见过不止一个人踩过。如果公司内部没有 DNS，你可以改本机 hosts 文件，把dashboard.example.com指到 Ingress Controller 所在节点。浏览器访问时，如果证书是合法 CA 签的，就不会报警。4. 生产环境加固与日常运维4.1 RBAC 权限怎么给才算合理k8s dashboard 部署安装完成之后，最让人纠结的就是权限管理。默认情况下你手动绑定的 dev-admin 如果是 cluster-admin，那整个集群任何一个 namespace 都能改，包括 kube-system。生产环境这是不可接受的。更合理的做法是，按团队成员的分工分配权限。普通开发人员只需要查看工作负载、Service、ConfigMap，可以给 view。需要发布应用的人，可以在指定 namespace 里授予 edit。而需要管理集群节点的 SRE，才需要 cluster-admin。我在公司内部实践下来，会为不同团队创建不同的 ServiceAccount，每个账号绑定相应的 Role 或 ClusterRole。比如：前端组：只能看前端 ns 下的资源，绑定 view；后端组：负责某几个环境，绑定 edit；运维组：绑定自定义 Role，给到 secrets 的读取权限和 Deployment 的上下线权限。这样 Dashboard 登录接口签发的 Token 是不同的，登录进去能看到的资源范围也是隔离的。你要说这有没有多费劲？确实比甩一个 admin 出去费劲，但一旦出问题，责任边界清晰太多了。4.2 证书轮换与访问安全证书是有有效期的，自签证书到期之后 Dashboard 不会自动续期，你需要重新生成并更新 Secret，然后滚动重启 Deployment。具体步骤：生成新证书和 key，更新 Secret，然后删除当前运行的 Pod，让 Deployment 重新创建一个新的 Pod。kubectl -n kubernetes-dashboard delete secret kubernetes-dashboard-certs kubectl -n kubernetes-dashboard create secret tls kubernetes-dashboard-certs \ --cert=dashboard.crt --key=dashboard.key kubectl -n kubernetes-dashboard rollout restart deployment kubernetes-dashboard为了避免到期时手忙脚乱，建议在证书到期前一个月设一个日历提醒。如果你用 cert-manager 管理证书，还可以把证书存放在 Secret 里，然后通过脚本定期刷新 Secret 并 rollout restart。生产环境我强烈建议在 Ingress 层做 IP 白名单或者 OAuth2 代理，不要直接把 Dashboard 裸奔到公网。可以先通过内部身份系统登录，再转发到 Dashboard 的 Token 登录页。这样即使 Token 泄露，攻击者也得先过你那层身份验证。4.3 多集群如何统一管理总有人问，我有好几套集群，难道每套都部署一遍 Dashboard，然后记好几个地址吗？最简单的方式就是每套集群各部署一套 Dashboard，各看各的。但如果你希望在一个页面里快速切换集群场景，Dashboard 本身是不支持的。这个时候我会推荐在客户端层面做聚合，比如使用支持多集群配置的 kubeconfig。本地kubectl proxy的时候，按 context 切换集群，然后 Dashboard 的地址不变，只是拿到的是不同集群的数据。或者更进一步，可以用开源的统一管理面板，把多个集群的 Dashboard 集成进去。但我一般不在生产环境引入额外的控制平面组件，因为多一个管理入口就多一份攻击面。实际场景中，两三个集群分开管理并不算麻烦，关键是把账号密码和 Token 的管理制度化。5. 常见问题与排查技巧实录5.1 经典报错速查表我整理了一些实际操作中经常出现的错误，直接用表格看比较方便。现象可能原因处理方式Pod 一直 CrashLoopBackOff证书 Secret 格式错误或 API 版本不兼容先看日志，重建 Secret，删除 Pod 让它重新创建打开页面提示 403 ForbiddenToken 权限不足检查 ServiceAccount 的 ClusterRoleBinding 绑定关系登录时提示 Could not get tokencreate token 命令的 namespace 打错了确认 ServiceAccount 在 kubernetes-dashboard 命名空间不存在Ingress 访问 502 Bad Gateway缺少backend-protocol: HTTPS在 Ingress annotations 里加上 HTTPS 后端声明页面白屏、接口一直 loadingDashboard 版本和集群 ApiServer 版本不兼容换成版本兼容的 DashboardNodePort 无法访问防火墙或安全组没放行确认节点端口可达镜像一直 ImagePullBackOff拉不到 docker hub 的镜像改内网镜像源，或手动导入镜像这几类问题占了我排查工作量的八成。别怕报错，只要你先看日志，再按这个速查表对一遍，基本都能快速定位。5.2 排查时一定要先看日志Dashboard 的日志是排查问题最重要的入口。不管 UI 上显示什么，日志里一般都有更明确的错误信息。kubectl -n kubernetes-dashboard logs -f deployment/kubernetes-dashboard如果你在浏览器里登录时每次都看到 403，日志里会有一条类似level=error msg="no user authenticated"之类的信息，这时候就去看你的 Token 是不是过期，或者 RBAC 是不是没有绑定好。还有一个很隐秘的问题，是 Dashboard 和 metrics-scraper 之间的连接问题。很多时候页面能打开，但 CPU、内存图表不显示，大概率 metrics-scraper Pod 没有正常工作。直接看 scraper 的日志，如果有连接失败的错误，检查一下metrics.k8s.io这个 API 是否在集群里可用。没有安装 metrics-server 的集群，Dashboard 的图形部分就是残缺的。5.3 避坑笔记与独家技巧关于 k8s dashboard 部署安装，我还有几个经验要分享。第一，进入生产集群之前先做一次离线演练。演练内容就是，在没有外网的情况下，把 recommended.yaml 和镜像全部搞定。这一步做好，你在任何客户环境都不会被网络问题卡住。第二，千万不要手动改 recommended.yaml 里的 Service 类型为 LoadBalancer 就以为万事大吉。LoadBalancer 会创建云厂商的负载均衡器，一来可能有费用产生，二来直接暴露到了公网。如果真要暴露，配合安全组和访问限制一起做。第三，如果你把 Dashboard 安装在公司内网的 Kubernetes 集群，记得在登录页面选择 Kubeconfig 方式时，使用加密后的 Token，或者说使用短期凭证。长期 Token 一旦泄露，等于把整个集群管理权限都暴露了。每过一段时间重新生成一次凭证，算是个好习惯。第四，Dashboard 页面上可以看到日志，但日志刷新是手动的。你如果习惯在终端里盯日志，直接用 kubectl 更方便，浏览器里的日志功能更适合新手点一点。第五，也是我自己踩过的一个最隐蔽的问题：Dashboard 2.7.0 以上版本，默认开启 CSRF 保护。如果你通过某些脚本或者前端工具直接调用 Dashboard API，可能会遇到 CSRF 校验失败。这种情况不能关保护，而是要在请求头里带上正确 token 去适配。6. 个人经验总结与最后几个建议写到这，我回头想想这些年做过的 k8s dashboard 部署安装，最核心的其实不是“安装”这一步，而是安装完成之后你怎么管理和访问它。安装本身只有一条命令的事，真正花时间的是版本选型、证书、权限和访问策略。我自己碰过太多同事，拿起 recommended.yaml 就直接 apply，然后页面开了，Token 一贴，看到资源全出来了，就以为大功告成。直到某一天发现某台集群的 Dashboard 连上之后很多页面报错，才意识到版本问题。所以最后几个建议，供参考：一是养成记录版本的习惯。集群升级，Dashboard 也要跟着评估，随手记一下当前集群和 Dashboard 的版本组合，方便后面排查。二是把证书和权限策略代码化，写进团队的知识库里，而不是靠某个人脑袋记着。这样即使部署的人休假了，其他同学也能接手。三是务必控制访问入口。Dashboard 是管理工具，不是给全公司人浏览的。让你需要的人用适当的权限去访问，而不是所有人共享一个超管账号。四是不管多忙，先做一遍离线部署演练。网络环境变数太大，你永远不想在上线前一天被镜像仓库连不上卡住。这些经验看起来不起眼，但一次事故的价值往往就值回整个部署流程的十倍苦工。希望这篇 k8s dashboard 部署安装的经验总结能帮你少走弯路，把有限的时间留给真正有价值的问题。
1. 部署前的版本选型与方案权衡1.1 版本匹配为什么是第一个坑凡是碰过 k8s dashboard 部署安装的，几乎都吃过版本不匹配的亏。Kubernetes 的版本迭代速度快，而 Dashboard 作为官方社区维护的可视化面板，它的兼容列表往往滞后于集群版本。你拿一个新的 Dashboard 版本去对接一个老旧的集群，或者反过来，最常见的结局就是 Pod 一直 CrashLoopBackOff，打开页面之后接口报错，节点和 Pod 列表刷不出来，界面空白一片。所以不管你是给生产环境搭管理界面，还是在自己电脑上用 kind / minikube 跑一套测试集群，第一步先说死：先查清楚你的集群版本，再决定用哪个 Dashboard 版本。Kubernetes API 是带组和版本号的，Dashboard 内部会调用 cluster-info、metrics.k8s.io、apps/v1、batch/v1 这些 API，哪怕只是小版本不匹配，也可能导致部分接口返回 403 或者直接 EOF。我在一个测试环境里踩过典型例子：集群是 Kubernetes 1.29，当时装 Dashboard 2.7.0 完全正常，但某同事先在 1.28 集群上手动改了镜像标签去拉 3.0 的新版，结果 API 兼容层直接罢工，Deployment 的副本数都显示不出来。后来切回匹配版本，一切恢复。一个比较稳妥的做法：在部署菜单还没有变成 Helm 默认之前，先去 GitHub 的 releases 页面看那个版本对应的 Kubernetes 最低版本，按图索骥。如果你不喜欢翻文档，也有个偷懒的办法——用 manifests 子目录里的 recommended.yaml，它所绑定的版本一般经过社区回归测试。但我的建议是，不要把“latest”标签用于任何生产环境，因为你永远不知道下一次 apply 会不会给你推送一个 API 变更的版本。1.2 三种部署方式怎么选k8s dashboard 部署安装的主流方式有三种，我按自己的使用频率排序：第一种，官方 YAML 直接 apply。打开官方 GitHub 仓库，找到 releases，复制对应版本下的recommended.yaml链接，然后kubectl apply -f。这是最省事、最不容易出错的路径，也是本文后面实操部分采用的方式。它适合第一次部署、测试环境快速验证和想快速看效果的人，所有配置项都集中在 YAML 里，方便我们按自己的需求做修改。第二种，用 Helm Chart。Dashboard 官方没有单独的 Helm 仓库，但社区 Chart 挺多，也有维护得不错的。Helm 的优势是通过 values.yaml 暴露配置项，比如证书、副本数、镜像仓库地址，改起来比手动修改官方 YAML 要干净。但社区 Chart 的维护质量和官方 YAML 不同步，偶尔会出现字段名对不上的情况，比如extraArgs的写法变了，导致你改了不生效。如果你对 Helm 本身不熟，我不建议用它作为第一选择。第三种，自己拼 YAML。这种属于“受控环境”的玩法，比如无外网环境下的离线安装，或者公司安全合规要求所有镜像必须走内部镜像仓库。操作上就是把 recommended.yaml 下载下来，批量替换 image 字段为内网地址，然后 apply。依赖的镜像是kubernetesui/dashboard和kubernetesui/metrics-scraper，提前在能联网的机器上docker pull然后docker save，再传到内网docker load，整个流程就闭环了。我个人的建议是，优先官方 YAML，后续需要做证书、Ingress 接入，再在官方 YAML 基础上改。别把问题复杂化。2. 证书、存储与命名空间的关键细节2.1 证书方式决定了浏览器地址栏长什么样很多人在 k8s dashboard 部署安装完成、Pod 也 Running 了，结果访问的时候被浏览器拦截，这是因为 Dashboard 默认用的是自签证书。这个证书在启动时会自动生成，但你换个设备访问又要重新点一次信任，烦得很。如果你只是本机kubectl proxy访问，其实可以完全不关心证书问题。但如果要通过 NodePort 或 Ingress 暴露，建议在部署前就把证书问题想清楚。常见的做法有两种：第一种，使用正式的 CA 签发的证书。就是先去申请一张覆盖你域名的证书，然后把 tls.crt 和 tls.key 存成 Kubernetes Secret，Secret 的名字必须是kubernetes-dashboard-certs，命名空间是kubernetes-dashboard。Dashboard 启动时会自动读取这个 Secret 里的证书，然后你的浏览器就不会报警了。关键点是，你需要在 apply 官方 YAML 之前把 Secret 创建好，或者先 apply 再重建 Deployment，否则 Pod 启动时发现没有证书就会重新生成自签证书。第二种，自建内部 CA。公司内部有很多用户却不想暴露公网，就用 OpenSSL 自建 CA，签发一张给 Dashboard 域名用，然后把 CA 下发到团队所有人的电脑上，导入信任列表。这一步做下来，浏览器会显示证书受信任，也不用每台机器单独点风险提示。我干活时的细节是，用 OpenSSL 签发证书之前先检查 SAN 字段，证书的 Subject Alternative Name 必须包含你的 Dashboard 域名，不能只写在 CommonName 里。这个字段现在浏览器强制执行，漏了就等着每台电脑都报错，然后你到处解释为什么明明证书是“对”的却不被信任。openssl req -x509 -nodes -days 365 -newkey rsa:2048 \ -keyout dashboard.key \ -out dashboard.crt这个只是生成自签证书，生产环境请走公司 CA 系统。把证书转成 Secret：kubectl -n kubernetes-dashboard create secret tls kubernetes-dashboard-certs \ --cert=dashboard.crt --key=dashboard.key2.2 存储与命名空间的设计思路Dashboard 本身是无状态应用，它不需要持久化存储，因为它不做数据落盘。但它依赖 metrics-server 或者 metrics-scraper 来展示集群的 CPU、内存监控数据，metrics-scraper 同样是无状态的。真正的“存储”问题出现在你的浏览器端。Dashboard 把用户偏好、主题设置之类的东西存在了 localStorage 里，所以不存在跨设备同步的问题。不要为了 Dashboard 单独建 PVC，那是白费劲。比较值得关注的是命名空间的选择。官方 YAML 固定把什么东西都放在kubernetes-dashboard这个命名空间里。你可以用这个名字，也可以改成自己的命名空间，但强烈建议保持默认。原因是，官方文档里所有证书、ServiceAccount、ClusterRoleBinding 的例子都默认指向这个命名空间，你一旦改名，后面排查问题的时候看到资料，所有命令都要自己改一遍，烦不烦？而且多个环境统一使用同一个命名空间，也方便脚本化处理。生产环境我见过有人把 Dashboard 的 ServiceAccount 权限放大到 cluster-admin，这确实最省事，但不是最安全的做法。后面我会单独讲权限收紧的问题。3. 实操全过程：从下载到访问3.1 下载 recommended.yaml 并检查内容先把 Dashboard 的 YAML 文件拉下来。wget https://raw.githubusercontent.com/kubernetes/dashboard/v2.7.0/aio/deploy/recommended.yaml如果你的网络访问 GitHub 比较费力，可以用镜像站，或者先下到本地再传上去。我一般在服务器上用 wget，如果失败就用代理下载再传。注意，下载完之后，别急着直接 apply，先把关键内容读一遍。我习惯打开 YAML 之后重点看几个地方：Service 是否定义了 type，默认是 ClusterIP；Deployment 和 metrics-scraper 的镜像版本；ServiceAccount、ClusterRoleBinding 的配置；--namespace=kubernetes-dashboard参数是否存在。这一步是为了确认，这份 YAML 里没有任何让你意外的配置。尤其是当初遇到过某些第三方包，往里面塞了一些额外的网络钩子，所以自己检查一遍最稳。3.2 执行部署并检查 Pod 状态确认无异常后再执行：kubectl apply -f recommended.yaml官方 YAML 的内容比较多，包含 Namespace、ServiceAccount、Secret、ConfigMap、Deployment、Service 等多个资源。执行完以后，官方也会提示你查看kubernetes-dashboard命名空间下的资源状态。kubectl -n kubernetes-dashboard get pods正常情况你会看到两个 Pod，一个是 dashboard，一个是 metrics-scraper，状态都是 Running。如果出现 ImagePullBackOff，通常是镜像拉取失败，先确认集群能不能访问 Docker Hub，不行就按第一节的方法改内网镜像源。如果是 CrashLoopBackOff，优先看日志。kubectl -n kubernetes-dashboard logs -l k8s-app=kubernetes-dashboard最常见的原因，就是证书 Secret 被改了而 Pod 没有重新创建，或者 API 版本不兼容。看日志时留意有没有Failed to start和证书相关的关键字。3.3 创建一个可登录的账号与 TokenDashboard 登录有两种方式：Token 和 Kubeconfig。如果你只是开发环境自己用，用 Token 最简单。官方 YAML 本身不创建专门的登录用户。你在 Postman 调接口一样，得有身份才能访问，Dashboard 默认拿 Kubernetes ServiceAccount 认证。所以先创建一个只读的管理员账号。我这里通常创建一个叫 dev-admin 的 ServiceAccount：apiVersion: v1 kind: ServiceAccount metadata: name: dev-admin namespace: kubernetes-dashboard然后绑定到集群角色。如果你只是日常看资源，用 view 角色就够了，但修改不了资源。如果整个测试集群就你自己在用，也可以给 cluster-admin，生产环境则千万不要。apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: dev-admin roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: cluster-admin subjects: - kind: ServiceAccount name: dev-admin namespace: kubernetes-dashboard保存为 dashboard-account.yaml，然后：kubectl apply -f dashboard-account.yaml接着查询 Token。旧版 Kubernetes 的 ServiceAccount 会对应一个长期有效的 Secret，我们可以直接获取。新版 Kubernetes 从 1.24 开始，ServiceAccount 不再自动创建 Secret，而是创建 TokenRequest，所以我们更推荐用下面这个命令生成一个有有效期的 Token：kubectl -n kubernetes-dashboard create token dev-admin这条命令的输出就是一份访问令牌，把它复制下来，在登录页面选择 Token 方式粘贴即可。需要注意，这种 Token 有过期时间，默认一小时左右。你要做自动化或者给别的同事用，就得用定期刷新机制。临时用就无所谓，过期了再生成一次。3.4 开启访问通道的三条路Pod 跑起来了，账号建好了，接下来就是怎么打开页面。第一条路，kubectl proxy。在本地执行kubectl proxy，然后浏览器访问http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/。这个方式对零暴露最安全，但路径又长又丑，只适合本地快速看一眼。第二条路，NodePort。修改 Dashboard Service：kubectl -n kubernetes-dashboard edit svc kubernetes-dashboard把 type 改成 NodePort，然后kubectl -n kubernetes-dashboard get svc查看被分配的节点端口。浏览器访问https://任何节点IP:端口。测试集群懒人方案，但生产环境不建议，因为直接把端口暴露到局域网，缺少额外的认证保护。第三条路，Ingress。这也是我生产环境用的方式。需要集群里已有 Ingress Controller，然后创建一个 Ingress 对象：apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: kubernetes-dashboard namespace: kubernetes-dashboard annotations: nginx.ingress.kubernetes.io/backend-protocol: "HTTPS" spec: rules: - host: dashboard.example.com http: paths: - path: / pathType: Prefix backend: service: name: kubernetes-dashboard port: number: 443这里最关键的是backend-protocol: HTTPS注解。因为 Dashboard Service 的入口协议是 HTTPS，如果你的 Ingress 不声明这一点，nginx 会用 HTTP 去连后端，结果就是 502。这个坑，我见过不止一个人踩过。如果公司内部没有 DNS，你可以改本机 hosts 文件，把dashboard.example.com指到 Ingress Controller 所在节点。浏览器访问时，如果证书是合法 CA 签的，就不会报警。4. 生产环境加固与日常运维4.1 RBAC 权限怎么给才算合理k8s dashboard 部署安装完成之后，最让人纠结的就是权限管理。默认情况下你手动绑定的 dev-admin 如果是 cluster-admin，那整个集群任何一个 namespace 都能改，包括 kube-system。生产环境这是不可接受的。更合理的做法是，按团队成员的分工分配权限。普通开发人员只需要查看工作负载、Service、ConfigMap，可以给 view。需要发布应用的人，可以在指定 namespace 里授予 edit。而需要管理集群节点的 SRE，才需要 cluster-admin。我在公司内部实践下来，会为不同团队创建不同的 ServiceAccount，每个账号绑定相应的 Role 或 ClusterRole。比如：前端组：只能看前端 ns 下的资源，绑定 view；后端组：负责某几个环境，绑定 edit；运维组：绑定自定义 Role，给到 secrets 的读取权限和 Deployment 的上下线权限。这样 Dashboard 登录接口签发的 Token 是不同的，登录进去能看到的资源范围也是隔离的。你要说这有没有多费劲？确实比甩一个 admin 出去费劲，但一旦出问题，责任边界清晰太多了。4.2 证书轮换与访问安全证书是有有效期的，自签证书到期之后 Dashboard 不会自动续期，你需要重新生成并更新 Secret，然后滚动重启 Deployment。具体步骤：生成新证书和 key，更新 Secret，然后删除当前运行的 Pod，让 Deployment 重新创建一个新的 Pod。kubectl -n kubernetes-dashboard delete secret kubernetes-dashboard-certs kubectl -n kubernetes-dashboard create secret tls kubernetes-dashboard-certs \ --cert=dashboard.crt --key=dashboard.key kubectl -n kubernetes-dashboard rollout restart deployment kubernetes-dashboard为了避免到期时手忙脚乱，建议在证书到期前一个月设一个日历提醒。如果你用 cert-manager 管理证书，还可以把证书存放在 Secret 里，然后通过脚本定期刷新 Secret 并 rollout restart。生产环境我强烈建议在 Ingress 层做 IP 白名单或者 OAuth2 代理，不要直接把 Dashboard 裸奔到公网。可以先通过内部身份系统登录，再转发到 Dashboard 的 Token 登录页。这样即使 Token 泄露，攻击者也得先过你那层身份验证。4.3 多集群如何统一管理总有人问，我有好几套集群，难道每套都部署一遍 Dashboard，然后记好几个地址吗？最简单的方式就是每套集群各部署一套 Dashboard，各看各的。但如果你希望在一个页面里快速切换集群场景，Dashboard 本身是不支持的。这个时候我会推荐在客户端层面做聚合，比如使用支持多集群配置的 kubeconfig。本地kubectl proxy的时候，按 context 切换集群，然后 Dashboard 的地址不变，只是拿到的是不同集群的数据。或者更进一步，可以用开源的统一管理面板，把多个集群的 Dashboard 集成进去。但我一般不在生产环境引入额外的控制平面组件，因为多一个管理入口就多一份攻击面。实际场景中，两三个集群分开管理并不算麻烦，关键是把账号密码和 Token 的管理制度化。5. 常见问题与排查技巧实录5.1 经典报错速查表我整理了一些实际操作中经常出现的错误，直接用表格看比较方便。现象可能原因处理方式Pod 一直 CrashLoopBackOff证书 Secret 格式错误或 API 版本不兼容先看日志，重建 Secret，删除 Pod 让它重新创建打开页面提示 403 ForbiddenToken 权限不足检查 ServiceAccount 的 ClusterRoleBinding 绑定关系登录时提示 Could not get tokencreate token 命令的 namespace 打错了确认 ServiceAccount 在 kubernetes-dashboard 命名空间不存在Ingress 访问 502 Bad Gateway缺少backend-protocol: HTTPS在 Ingress annotations 里加上 HTTPS 后端声明页面白屏、接口一直 loadingDashboard 版本和集群 ApiServer 版本不兼容换成版本兼容的 DashboardNodePort 无法访问防火墙或安全组没放行确认节点端口可达镜像一直 ImagePullBackOff拉不到 docker hub 的镜像改内网镜像源，或手动导入镜像这几类问题占了我排查工作量的八成。别怕报错，只要你先看日志，再按这个速查表对一遍，基本都能快速定位。5.2 排查时一定要先看日志Dashboard 的日志是排查问题最重要的入口。不管 UI 上显示什么，日志里一般都有更明确的错误信息。kubectl -n kubernetes-dashboard logs -f deployment/kubernetes-dashboard如果你在浏览器里登录时每次都看到 403，日志里会有一条类似level=error msg="no user authenticated"之类的信息，这时候就去看你的 Token 是不是过期，或者 RBAC 是不是没有绑定好。还有一个很隐秘的问题，是 Dashboard 和 metrics-scraper 之间的连接问题。很多时候页面能打开，但 CPU、内存图表不显示，大概率 metrics-scraper Pod 没有正常工作。直接看 scraper 的日志，如果有连接失败的错误，检查一下metrics.k8s.io这个 API 是否在集群里可用。没有安装 metrics-server 的集群，Dashboard 的图形部分就是残缺的。5.3 避坑笔记与独家技巧关于 k8s dashboard 部署安装，我还有几个经验要分享。第一，进入生产集群之前先做一次离线演练。演练内容就是，在没有外网的情况下，把 recommended.yaml 和镜像全部搞定。这一步做好，你在任何客户环境都不会被网络问题卡住。第二，千万不要手动改 recommended.yaml 里的 Service 类型为 LoadBalancer 就以为万事大吉。LoadBalancer 会创建云厂商的负载均衡器，一来可能有费用产生，二来直接暴露到了公网。如果真要暴露，配合安全组和访问限制一起做。第三，如果你把 Dashboard 安装在公司内网的 Kubernetes 集群，记得在登录页面选择 Kubeconfig 方式时，使用加密后的 Token，或者说使用短期凭证。长期 Token 一旦泄露，等于把整个集群管理权限都暴露了。每过一段时间重新生成一次凭证，算是个好习惯。第四，Dashboard 页面上可以看到日志，但日志刷新是手动的。你如果习惯在终端里盯日志，直接用 kubectl 更方便，浏览器里的日志功能更适合新手点一点。第五，也是我自己踩过的一个最隐蔽的问题：Dashboard 2.7.0 以上版本，默认开启 CSRF 保护。如果你通过某些脚本或者前端工具直接调用 Dashboard API，可能会遇到 CSRF 校验失败。这种情况不能关保护，而是要在请求头里带上正确 token 去适配。6. 个人经验总结与最后几个建议写到这，我回头想想这些年做过的 k8s dashboard 部署安装，最核心的其实不是“安装”这一步，而是安装完成之后你怎么管理和访问它。安装本身只有一条命令的事，真正花时间的是版本选型、证书、权限和访问策略。我自己碰过太多同事，拿起 recommended.yaml 就直接 apply，然后页面开了，Token 一贴，看到资源全出来了，就以为大功告成。直到某一天发现某台集群的 Dashboard 连上之后很多页面报错，才意识到版本问题。所以最后几个建议，供参考：一是养成记录版本的习惯。集群升级，Dashboard 也要跟着评估，随手记一下当前集群和 Dashboard 的版本组合，方便后面排查。二是把证书和权限策略代码化，写进团队的知识库里，而不是靠某个人脑袋记着。这样即使部署的人休假了，其他同学也能接手。三是务必控制访问入口。Dashboard 是管理工具，不是给全公司人浏览的。让你需要的人用适当的权限去访问，而不是所有人共享一个超管账号。四是不管多忙，先做一遍离线部署演练。网络环境变数太大，你永远不想在上线前一天被镜像仓库连不上卡住。这些经验看起来不起眼，但一次事故的价值往往就值回整个部署流程的十倍苦工。希望这篇 k8s dashboard 部署安装的经验总结能帮你少走弯路，把有限的时间留给真正有价值的问题。