K8s Dashboard部署实战

很多人觉得K8s有kubectl就够了，但在公司推行AI Agent工作流的时候，我发现团队里很多非运维的开发人员根本没法快速上手。每次让他们查个Pod状态或者看下资源占用，都要在终端敲半天命令，效率低得离谱。为了让这帮人能直观地看到资源跑得怎么样，我给公司集群强行推了K8s Dashboard。

说实话，这玩意儿安装简单，但要真正能给团队人用，权限控制和网络暴露才是最坑的地方。如果直接用端口转发，每次得开个终端挂在那，太业余；如果直接裸露在公网，简直是给黑客送礼。

下面是我在公司环境里跑通的一套完整部署指南，直接上干货。

一、快速部署与基础验证

别去研究那些复杂的YAML文件了，直接用Helm部署是最稳的。

# 添加仓库并更新
helm repo add kubernetes-dashboard https://kubernetes.github.io/dashboard/
helm repo update

# 创建命名空间并安装
helm install kubernetes-dashboard kubernetes-dashboard/kubernetes-dashboard --create-namespace --namespace kubernetes-dashboard

# 检查状态，确保Pod全部处于Running
kubectl get all -n kubernetes-dashboard

二、解决权限死结（RBAC配置）

安装完之后你会发现没法登录。Dashboard默认不给权限，得手动创建ServiceAccount。我给公司分了两种角色：一个是给我的“超级管理员”，一个是给开发看的“只读账户”。

1. 管理员账户（全权限，慎用）：
创建 dashboard-admin-user.yml：

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

2. 只读账户（防止开发误删Pod）：
创建 read-only-user.yml：

apiVersion: v1
kind: ServiceAccount
metadata:
  name: read-only-user
  namespace: kubernetes-dashboard
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: read-only-clusterrole
rules:
- apiGroups: ["", "apps", "extensions"]
  resources: ["*"]
  verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: read-only-binding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: read-only-clusterrole
subjects:
- kind: ServiceAccount
  name: read-only-user
  namespace: kubernetes-dashboard

执行部署并生成登录Token：

kubectl apply -f dashboard-admin-user.yml
kubectl apply -f read-only-user.yml

# 获取管理员Token（复制这个Token用于登录）
kubectl -n kubernetes-dashboard create token dashboard-admin-user

三、从临时访问到正式上线

刚部署完，我先用端口转发快速验证了一下，但这在公司环境里没法长期用。

临时方案（仅限本地调试）：

# 绑定到所有接口，防止远程无法访问
kubectl port-forward service/kubernetes-dashboard-kong-proxy 8443:443 -n kubernetes-dashboard --address='0.0.0.0'

这时候访问 https://localhost:8443 就能进，但得忍受那个讨厌的浏览器证书警告。

正式方案（Nginx Ingress + TLS）：
为了让团队成员直接通过域名访问，我部署了Nginx Ingress。

# 安装 Ingress Controller
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update
helm install ingress-nginx ingress-nginx/ingress-nginx --namespace ingress-nginx --create-namespace

然后配置cert-manager来搞定TLS证书，避免每次登录都弹警告。虽然配置过程有点繁琐，但对于企业级部署来说，这是唯一正确的姿势。

四、真实踩坑总结

在公司推行这套方案时，我发现两个关键点：

• Token有效期问题： kubectl create token 生成的Token是有时效的。如果给开发人员用，建议在内部文档里写清楚如何刷新，或者通过更复杂的OIDC集成，否则每天都有人来问我为什么登录失效了。
• 资源监控误区： 很多人进Dashboard是为了看CPU/内存占用。记住，Dashboard本身不提供指标采集，你必须在集群里预先安装 Metrics Server，否则 Nodes 页面全是空白，别怀疑