Kubernetes Dashboard 深度指南：从入门到精通的视觉管理利器

引言：驾驭 Kubernetes 的视觉之窗
- 1.1 Kubernetes 挑战与 Dashboard 的诞生
- 1.2 什么是 Kubernetes Dashboard？
- 1.3 为什么需要 Kubernetes Dashboard？
Kubernetes Dashboard 核心概念与工作原理
- 2.1 架构概述
- 2.2 与 API Server 的交互
- 2.3 权限管理（RBAC）的重要性
- 2.4 Metrics Server：Dashboard 数据的源泉
前置条件与准备工作
- 3.1 一个可用的 Kubernetes 集群
- 3.2 kubectl 命令行工具
- 3.3 基础 Kubernetes 知识
Kubernetes Dashboard 部署与安装
- 4.1 部署 Dashboard Pods 和 Service
- 4.2 验证 Dashboard 部署状态
- 4.3 安装 Metrics Server (可选但强烈推荐)
  - 4.3.1 什么是 Metrics Server？
  - 4.3.2 部署 Metrics Server
  - 4.3.3 验证 Metrics Server 状态
访问 Kubernetes Dashboard
- 5.1 方法一：使用 kubectl proxy (开发/测试环境推荐)
  - 5.1.1 启动代理
  - 5.1.2 访问 URL
  - 5.1.3 优点与局限性
- 5.2 方法二：通过 NodePort 暴露 (慎用，适用于特定场景)
  - 5.2.1 修改 Dashboard Service 类型
  - 5.2.2 访问 URL
  - 5.2.3 安全考量
- 5.3 方法三：通过 Ingress 暴露 (生产环境推荐)
  - 5.3.1 前提：Ingress Controller
  - 5.3.2 创建 Ingress 资源
  - 5.3.3 配置 TLS (HTTPS)
  - 5.3.4 优点
Kubernetes Dashboard 认证与授权 (RBAC)
- 6.1 认证方式：Token vs Kubeconfig
- 6.2 创建拥有管理权限的 Service Account (最佳实践)
  - 6.2.1 创建 Service Account
  - 6.2.2 创建 ClusterRoleBinding
  - 6.2.3 获取 Service Account Token
- 6.3 安全警告：避免使用 cluster-admin 权限直接暴露
Kubernetes Dashboard 使用指南：功能详解
- 7.1 登录界面
- 7.2 概览 (Overview)
  - 集群资源概览
  - CPU/内存使用率 (需 Metrics Server)
  - 最新事件
- 7.3 工作负载 (Workloads)
  - 部署 (Deployments)：扩展、回滚、暂停/恢复、编辑
  - Pods：查看日志、执行命令、进入容器、删除
  - 副本集 (ReplicaSets)、有状态副本集 (StatefulSets)、守护进程集 (DaemonSets)
  - 作业 (Jobs)、定时作业 (CronJobs)
- 7.4 服务与网络 (Services & Networking)
  - 服务 (Services)：查看类型、端口、Endpoints
  - Ingress：管理流量入口
- 7.5 存储 (Storage)
  - 持久卷 (Persistent Volumes)
  - 持久卷声明 (Persistent Volume Claims)
  - 存储类 (Storage Classes)
- 7.6 配置与密钥 (Config & Storage)
  - 配置字典 (ConfigMaps)：查看、创建、编辑
  - 密文 (Secrets)：查看 (注意安全)、创建、编辑
- 7.7 RBAC (Role-Based Access Control)
  - 服务账户 (Service Accounts)
  - 角色 (Roles)、集群角色 (ClusterRoles)
  - 角色绑定 (RoleBindings)、集群角色绑定 (ClusterRoleBindings)
- 7.8 命名空间 (Namespaces)
- 7.9 节点 (Nodes)
- 7.10 事件 (Events)
- 7.11 资源创建与编辑
  - 通过 YAML 文件创建/更新资源
  - 通过表单创建资源
高级用法与最佳实践
- 8.1 安全最佳实践：最小权限原则
- 8.2 多集群管理 (不直接支持，但可结合 Kubeconfig)
- 8.3 定期更新 Dashboard
- 8.4 结合监控与告警系统
常见问题与故障排除
- 9.1 无法访问 Dashboard
- 9.2 Dashboard 中看不到 CPU/内存利用率
- 9.3 权限不足
- 9.4 Dashboard 页面报错
Kubernetes Dashboard 的优缺点
- 10.1 优点
- 10.2 缺点
- 10.3 替代方案 (Lens, K9s 等)
总结与展望

1. 引言：驾驭 Kubernetes 的视觉之窗

1.1 Kubernetes 挑战与 Dashboard 的诞生

Kubernetes (K8s) 已成为容器编排领域的领导者，它提供了强大的自动化部署、扩展和管理容器化应用的能力。然而，对于初学者乃至经验丰富的 DevOps 工程师来说，直接通过命令行接口（CLI）工具 kubectl 来管理复杂的 Kubernetes 集群可能是一项挑战。kubectl 强大而灵活，但它的输出通常是纯文本，对于集群的整体健康状况、资源间的相互关系以及实时指标的观察，往往需要执行一系列命令并进行人工解读，效率较低。

为了解决这一痛点，提供一个直观、易用的图形用户界面（GUI）变得尤为重要。这便是 Kubernetes Dashboard 诞生的初衷。

1.2 什么是 Kubernetes Dashboard？

Kubernetes Dashboard 是 Kubernetes 官方提供的一款基于 Web 的用户界面。它允许用户通过一个统一的、可视化的界面来部署容器化应用、管理集群资源、排查故障，以及查看集群和应用的运行状态。你可以使用 Dashboard 来：

部署应用程序到 Kubernetes 集群。
监控集群中应用程序的整体健康状况。
管理各种 Kubernetes 资源，如 Deployment、Pod、Service、Ingress、ConfigMap、Secret 等。
查看 Pod 的日志、执行命令、进入容器内部进行调试。
检查节点（Nodes）和命名空间（Namespaces）的资源使用情况和状态。
监控集群事件和资源利用率。

简而言之，Kubernetes Dashboard 是一个将复杂的 kubectl 命令和集群信息可视化、简化操作流程的工具。

1.3 为什么需要 Kubernetes Dashboard？

直观的可视化界面： 将命令行输出的文本信息转化为图表和表格，更易于理解集群的整体健康状况和资源使用情况。
简化操作： 对于创建、更新、删除各种 Kubernetes 资源，Dashboard 提供了友好的表单和 YAML 编辑器，减少了手动编写 YAML 的错误几率。
快速故障排查： 集中查看 Pod 日志、事件、资源状态，有助于快速定位问题。
学习曲线平缓： 对于 Kubernetes 新手，Dashboard 提供了一个更平易近人的入口，帮助他们理解 Kubernetes 概念和资源之间的关系。
概览和监控： 提供集群资源的实时概览和性能指标（CPU、内存），方便管理员监控集群健康。

2. Kubernetes Dashboard 核心概念与工作原理

2.1 架构概述

Kubernetes Dashboard 本身也是一个运行在 Kubernetes 集群中的标准应用程序。它通常由以下 Kubernetes 资源组成：

Deployment： 运行 Dashboard 应用程序的 Pods。
Service： 暴露 Dashboard Pods，使其可以在集群内部被访问。
Service Account： 为 Dashboard Pods 提供与 Kubernetes API Server 交互所需的身份认证。
Role/ClusterRole & RoleBinding/ClusterRoleBinding： 定义 Dashboard Service Account 拥有哪些权限（例如，读取 Pods、Deployments，或完全管理集群）。

2.2 与 API Server 的交互

Dashboard 的核心工作原理是：它作为客户端，通过其 Service Account 的权限与 Kubernetes API Server 进行通信。所有你在 Dashboard 界面上看到的数据（例如 Pod 列表、日志、资源状态）以及执行的操作（例如部署应用、扩展副本）都通过 API Server 来完成。Dashboard 不直接与 Kubelet 或其他组件交互。

2.3 权限管理（RBAC）的重要性

由于 Dashboard 具有与 API Server 交互的能力，其安全性至关重要。Kubernetes 的 Role-Based Access Control (RBAC) 机制用于授权 Dashboard 的 Service Account。这意味着你可以精确控制 Dashboard 能够访问和操作哪些资源。给予 Dashboard 过高的权限（如 cluster-admin）可能会带来严重的安全风险，尤其当 Dashboard 被公开暴露时。因此，理解并正确配置 RBAC 是安全使用 Dashboard 的关键。

2.4 Metrics Server：Dashboard 数据的源泉

Kubernetes Dashboard 默认只显示资源的状态信息，例如 Pod 运行中、Deployment 已就绪等。如果你希望在 Dashboard 中看到 实时的 CPU 和内存使用率图表，那么你的集群还需要部署 Metrics Server。

Metrics Server 是一个集群范围的聚合器，它从每个节点上的 Kubelet 收集资源使用指标（CPU、内存），并将这些指标通过标准的 Kubernetes API 暴露出来。Dashboard 会查询 Metrics Server 的 API 来获取并显示这些数据。如果你的集群没有安装 Metrics Server，Dashboard 的 CPU/内存图表部分将无法显示数据。

3. 前置条件与准备工作

在部署和使用 Kubernetes Dashboard 之前，请确保满足以下条件：

3.1 一个可用的 Kubernetes 集群

无论是 Minikube、Kubeadm 搭建的裸机集群、云服务商（如 AWS EKS, Google GKE, Azure AKS）提供的托管集群，还是其他任何形式的 Kubernetes 集群，都必须是正常运行且可访问的。

3.2 `kubectl` 命令行工具

你的本地机器上需要安装并配置好 kubectl，并且它能够正常连接到你的 Kubernetes 集群。你可以通过运行 kubectl get nodes 来验证 kubectl 是否工作正常。

3.3 基础 Kubernetes 知识

理解 Pod、Deployment、Service、Namespace、RBAC 等基本概念将有助于更好地理解和使用 Dashboard。

4. Kubernetes Dashboard 部署与安装

4.1 部署 Dashboard Pods 和 Service

Kubernetes Dashboard 的部署非常简单，通常只需要应用官方提供的 YAML 文件。

“`bash

1. 部署 Kubernetes Dashboard

使用官方推荐的部署文件，这个文件包含了 Dashboard 的 Deployment 和 Service 等资源。

注意：这个推荐文件通常将 Dashboard 部署在 `kubernetes-dashboard` 命名空间下。

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

如果你想使用特定版本，可以修改 v2.7.0 为你需要的版本号。

也可以下载到本地后编辑，例如：

curl -o recommended.yaml https://raw.githubusercontent.com/kubernetes/dashboard/v2.7.0/aio/deploy/recommended.yaml

kubectl apply -f recommended.yaml

`` **注意：** 上述 URL 中的v2.7.0` 是 Dashboard 的版本号，请根据实际情况或官方文档更新到最新稳定版本。

4.2 验证 Dashboard 部署状态

部署完成后，你可以检查 kubernetes-dashboard 命名空间下的 Pod 和 Service 状态：

“`bash

检查 Pod 状态

kubectl get pods -n kubernetes-dashboard

预期输出：

NAME READY STATUS RESTARTS AGE

kubernetes-dashboard-xxxxxxxxx-xxxxx 1/1 Running 0 Xm

检查 Service 状态

kubectl get service -n kubernetes-dashboard

预期输出：

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE

kubernetes-dashboard ClusterIP 10.xx.xx.xx 443/TCP Xm

`` 如果STATUS显示Running，则表示 Dashboard Pod 已成功启动。kubernetes-dashboardService 默认为ClusterIP` 类型，这意味着它只能在集群内部访问。

4.3 安装 Metrics Server (可选但强烈推荐)

为了在 Dashboard 中显示 CPU 和内存利用率图表，你需要安装 Metrics Server。

4.3.1 什么是 Metrics Server？

Metrics Server 是一个通用的、可扩展的容器资源使用量数据聚合器。它从 Kubelet 暴露的 /metrics/resource API 中收集指标，然后通过 Kubernetes API 的 metrics.k8s.io 接口提供这些数据。Dashboard 以及 kubectl top 命令都依赖于它。

4.3.2 部署 Metrics Server

“`bash

1. 部署 Metrics Server

使用官方推荐的部署文件

kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/metrics-server/master/deploy/1.8%2B/high-availability.yaml

注意：某些环境中，Metrics Server 部署可能需要跳过 TLS 验证。

如果遇到 “x509: cannot validate certificate” 错误，

你可能需要在 metrics-server 的 deployment 中添加 `--kubelet-insecure-tls` 参数。

例如：编辑 high-availability.yaml 文件，找到 metrics-server 容器的 args 字段，

添加 – –kubelet-insecure-tls。

“`

4.3.3 验证 Metrics Server 状态

“`bash

检查 Pod 状态 (通常在 kube-system 命名空间下)

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

预期输出：

NAME READY STATUS RESTARTS AGE

metrics-server-xxxxxxxxx-xxxxx 1/1 Running 0 Xm

检查 Metrics API 是否可用

kubectl get apiservice v1beta1.metrics.k8s.io

预期输出：

NAME SERVICE AVAILABLE AGE

v1beta1.metrics.k8s.io kube-system/metrics-server True Xm

验证数据是否能正常获取 (可能需要等待一两分钟 Pod 启动并收集数据)

kubectl top nodes
kubectl top pods -A
`` 如果kubectl top` 命令能正常输出节点和 Pod 的 CPU/内存数据，则说明 Metrics Server 运行正常。

5. 访问 Kubernetes Dashboard

由于 Dashboard Service 默认是 ClusterIP 类型，它不会自动暴露到集群外部。你需要选择一种方式来访问它。

5.1 方法一：使用 `kubectl proxy` (开发/测试环境推荐)

这是最简单、最安全的访问方式，尤其适用于本地开发和测试。它通过你的 kubectl 配置，在本地机器上建立一个代理，将对 Dashboard 的请求转发到集群内部。

5.1.1 启动代理

打开一个新的终端窗口，并执行以下命令：

bash kubectl proxy
该命令会监听本地的 8001 端口。

5.1.2 访问 URL

在你的 Web 浏览器中输入以下 URL：

http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/
注意： URL 后面有一个斜杠 /，不能省略。

5.1.3 优点与局限性

优点： 简单、安全，无需修改集群配置，基于你当前的 kubectl 认证。
局限性： 代理只在执行 kubectl proxy 命令的终端窗口保持活动。关闭终端或终止命令将断开连接。不适合多用户或持续访问。

5.2 方法二：通过 NodePort 暴露 (慎用，适用于特定场景)

将 Dashboard Service 从 ClusterIP 类型更改为 NodePort 类型，可以在每个节点上打开一个随机端口，通过节点的 IP 地址和该端口来访问 Dashboard。出于安全考虑，除非你知道自己在做什么，否则不建议在生产环境使用此方法。

5.2.1 修改 Dashboard Service 类型

“`bash

编辑 kubernetes-dashboard Service

kubectl edit service kubernetes-dashboard -n kubernetes-dashboard
`` 在打开的编辑器中，找到type: ClusterIP这一行，将其改为type: NodePort`，然后保存并退出。

修改后 Service 信息可能如下：

yaml apiVersion: v1 kind: Service metadata: labels: k8s-app: kubernetes-dashboard name: kubernetes-dashboard namespace: kubernetes-dashboard spec: ports: - port: 443 targetPort: 8443 nodePort: 30000 # 这是一个示例，实际值可能是随机分配的或你指定的 protocol: TCP name: https selector: k8s-app: kubernetes-dashboard type: NodePort # 更改为 NodePort

获取 NodePort：

“`bash
kubectl get service -n kubernetes-dashboard

查找 kubernetes-dashboard Service 的 PORT(S) 字段，会显示类似 443:30XXX/TCP 的信息，其中 30XXX 就是分配的 NodePort。

“`

5.2.2 访问 URL

使用集群中 任意一个节点 的 IP 地址和分配的 NodePort 来访问：

https://<NodeIP>:<NodePort>
例如：https://192.168.1.100:30000

5.2.3 安全考量

暴露风险： Dashboard 会在所有节点上暴露，增加了攻击面。
无额外认证： NodePort 本身不提供额外的认证或加密，仅依赖 Dashboard 自身的登录机制。

5.3 方法三：通过 Ingress 暴露 (生产环境推荐)

在生产环境中，最推荐的方式是使用 Ingress。Ingress 提供了外部 URL、负载均衡、SSL/TLS 终止、基于名称的虚拟主机等功能，能够更安全、灵活地暴露 Dashboard。

5.3.1 前提：Ingress Controller

你的集群必须已经部署了一个 Ingress Controller（如 Nginx Ingress Controller、Traefik 等）。

5.3.2 创建 Ingress 资源

创建一个 Ingress 资源来路由到 kubernetes-dashboard Service：

“`yaml

dashboard-ingress.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: kubernetes-dashboard-ingress
namespace: kubernetes-dashboard
annotations:
# 如果使用 Nginx Ingress Controller，这是为了启用 SSL 重定向和路径重写
nginx.ingress.kubernetes.io/backend-protocol: “HTTPS”
nginx.ingress.kubernetes.io/rewrite-target: /
nginx.ingress.kubernetes.io/force-ssl-redirect: “true”
spec:
rules:
– host: dashboard.yourdomain.com # 替换为你的域名
http:
paths:
– path: /
pathType: Prefix
backend:
service:
name: kubernetes-dashboard
port:
number: 443 # Dashboard Service 的端口
`` 应用此 Ingress：kubectl apply -f dashboard-ingress.yaml`

5.3.3 配置 TLS (HTTPS)

强烈建议为 Ingress 配置 TLS，以加密 Dashboard 的访问流量。这通常需要一个 TLS 密钥和证书。你可以手动创建 Secret，或者使用 Cert-Manager 这样的工具自动管理证书。

“`yaml

带有 TLS 配置的 Ingress 示例

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: kubernetes-dashboard-ingress
namespace: kubernetes-dashboard
annotations:
# … 其他 Ingress Controller 相关的注解 …
spec:
tls:
– hosts:
– dashboard.yourdomain.com
secretName: dashboard-tls-secret # 存储 TLS 证书和私钥的 Secret
rules:
– host: dashboard.yourdomain.com
http:
paths:
– path: /
pathType: Prefix
backend:
service:
name: kubernetes-dashboard
port:
number: 443
创建 `dashboard-tls-secret`：bash
kubectl create secret tls dashboard-tls-secret –key /path/to/your/tls.key –cert /path/to/your/tls.crt -n kubernetes-dashboard
“`

5.3.4 优点

安全性： 通过 Ingress Controller 提供 TLS 终止，可以更好地保护流量。
灵活性： 支持自定义域名、路径路由、负载均衡等高级功能。
生产就绪： 是在生产环境中暴露 Web 服务的标准方法。

6. Kubernetes Dashboard 认证与授权 (RBAC)

部署并访问 Dashboard 后，你会看到一个登录界面。Dashboard 不会存储用户凭据，它依赖 Kubernetes 的认证机制。

6.1 认证方式：Token vs Kubeconfig

Token (令牌)： 最常见的登录方式。你需要提供一个 Service Account 的 Token。这个 Service Account 必须拥有访问 Dashboard 所需的 RBAC 权限。
Kubeconfig： 你也可以上传你的 Kubeconfig 文件进行登录。这会使用你 Kubeconfig 中配置的凭据。通常用于本地开发环境，但将 Kubeconfig 文件上传到 Web 界面存在一定的安全风险，不如使用 Token。

6.2 创建拥有管理权限的 Service Account (最佳实践)

为了安全起见，我们不应该使用默认的 Service Account，而是创建一个专用的 Service Account 并为其绑定适当的权限。

6.2.1 创建 Service Account

创建一个名为 admin-user 的 Service Account：

“`yaml

dashboard-adminuser.yaml

apiVersion: v1
kind: ServiceAccount
metadata:
name: admin-user
namespace: kubernetes-dashboard # 确保在 Dashboard 所在的命名空间
“`

bash kubectl apply -f dashboard-adminuser.yaml

6.2.2 创建 ClusterRoleBinding

接下来，将 admin-user Service Account 绑定到 cluster-admin ClusterRole，赋予其集群的完全管理权限。

安全警告：将 cluster-admin 权限授予任何 Service Account 都意味着巨大的安全风险。在生产环境中，应根据实际需求创建具有最小权限的自定义 ClusterRole 或 Role。这里为了演示方便，先使用 cluster-admin。

“`yaml

dashboard-admin-binding.yaml

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 # 确保 Service Account 所在的命名空间
“`

bash kubectl apply -f dashboard-admin-binding.yaml

6.2.3 获取 Service Account Token

现在，我们需要获取 admin-user Service Account 的 Token。

对于 Kubernetes 1.24 及更高版本： Service Account 的 Token 不再自动作为 Secret 创建。你需要手动创建一个 Token Secret。

“`yaml

admin-user-token.yaml

apiVersion: v1
kind: Secret
metadata:
name: admin-user-token
namespace: kubernetes-dashboard
annotations:
kubernetes.io/serviceaccount.name: admin-user
type: kubernetes.io/service-account-token
“`

“`bash
kubectl apply -f admin-user-token.yaml

等待 Secret 创建并填充 Token

kubectl get secret admin-user-token -n kubernetes-dashboard -o jsonpath='{.data.token}’ | base64 –decode
“`

对于 Kubernetes 1.23 及更早版本： Token 会自动创建一个 Secret。

“`bash

获取 Service Account 关联的 Secret 名称

SECRET_NAME=$(kubectl get sa admin-user -n kubernetes-dashboard -o jsonpath=”{.secrets[0].name}”)

从 Secret 中提取 Token

kubectl get secret $SECRET_NAME -n kubernetes-dashboard -o jsonpath=”{.data.token}” | base64 –decode
“`
复制输出的 Token。这就是你登录 Dashboard 所需的凭证。

6.3 安全警告：避免使用 `cluster-admin` 权限直接暴露

再次强调，将 cluster-admin 权限授予 Dashboard 是非常危险的。如果 Dashboard 意外暴露或被攻击，攻击者将获得整个集群的最高权限。

更好的实践是：

为不同用户或团队创建独立的 Service Account。
根据最小权限原则，创建自定义的 Role 或 ClusterRole，只包含用户或团队所需的最小权限集。
将这些 Role 或 ClusterRole 绑定到相应的 Service Account。
建议在生产环境中将 Dashboard 的访问权限限制在内部网络或通过 VPN 访问。

7. Kubernetes Dashboard 使用指南：功能详解

登录到 Kubernetes Dashboard 后，你将看到一个功能丰富的界面。

7.1 登录界面

输入你获取的 Token 或上传 Kubeconfig 文件进行登录。选择 “Token” 方式，粘贴 Token，点击 “Sign in”。

7.2 概览 (Overview)

登录后的第一个页面通常是概览页，提供集群的高级视图：
* 集群资源概览： 显示集群中各种资源的数量，如 Pods、Deployments、Services、Nodes 等。
* CPU/内存使用率： 如果 Metrics Server 已部署并正常工作，这里会显示集群整体的 CPU 和内存使用率图表。
* 最新事件： 列出集群中最近发生的事件，有助于快速了解集群动态。

7.3 工作负载 (Workloads)

这是管理容器化应用的核心区域。
* 部署 (Deployments)：
* 显示所有 Deployment 列表及其状态（运行中、就绪、更新中等）。
* 点击某个 Deployment 可以查看其详细信息：Pod 列表、ReplicaSet、事件、环境变量、卷等。
* 操作： 扩展（Scale）、回滚（Rollback）、暂停/恢复（Pause/Resume）、编辑 YAML、删除。
* Pods：
* 显示集群中所有 Pods 列表。
* 点击 Pod 可以查看详细信息：容器状态、IP 地址、事件、卷等。
* 操作：
* 查看日志 (Logs)： 实时查看容器日志，支持选择容器。
* 执行命令 (Exec)： 在容器内部执行 shell 命令，如 bash 或 sh。
* 进入容器 (Shell)： 直接打开一个交互式 shell 到容器内部。
* 删除 Pod。
* 副本集 (ReplicaSets)、有状态副本集 (StatefulSets)、守护进程集 (DaemonSets)、作业 (Jobs)、定时作业 (CronJobs)：
* 类似 Deployment 和 Pods，Dashboard 提供了对这些工作负载的详细查看和管理功能，包括创建、编辑、删除以及查看关联 Pods。

7.4 服务与网络 (Services & Networking)

服务 (Services)：
- 列出所有 Service，显示其类型（ClusterIP, NodePort, LoadBalancer, ExternalName）、集群 IP、端口、选择器等。
- 查看 Service 的 Endpoints（后端 Pods）。
Ingress：
- 管理 Ingress 资源，显示其规则、后端服务和主机名。

7.5 存储 (Storage)

持久卷 (Persistent Volumes – PVs)： 查看集群中所有 PVs 的状态、容量、访问模式、回收策略等。
持久卷声明 (Persistent Volume Claims – PVCs)： 查看用户对存储的声明，以及它们与 PV 的绑定情况。
存储类 (Storage Classes)： 管理存储类，定义动态创建存储的方式。

7.6 配置与密钥 (Config & Storage)

配置字典 (ConfigMaps)：
- 列出所有 ConfigMaps。
- 点击可以查看 ConfigMap 中的键值对数据。
- 支持创建、编辑和删除。
密文 (Secrets)：
- 列出所有 Secrets。
- 注意： 出于安全考虑，Dashboard 在默认情况下不会直接显示 Secret 的值。你可以通过编辑 YAML 来查看，但请务必小心。
- 支持创建、编辑和删除。

7.7 RBAC (Role-Based Access Control)

这个区域允许你查看和管理 Kubernetes 的 RBAC 资源：
* 服务账户 (Service Accounts)
* 角色 (Roles)、集群角色 (ClusterRoles)
* 角色绑定 (RoleBindings)、集群角色绑定 (ClusterRoleBindings)
通过查看这些资源，你可以更好地理解集群中的权限配置。

7.8 命名空间 (Namespaces)

在顶部导航栏，你可以轻松切换不同的命名空间，查看特定命名空间下的资源。你也可以创建新的命名空间。

7.9 节点 (Nodes)

显示集群中所有节点的详细信息：
* 节点名称、状态、角色。
* CPU、内存、存储的资源使用情况和容量。
* 系统信息（OS、内核版本、Docker 版本）。
* 节点上的 Pods 列表和事件。

7.10 事件 (Events)

集中展示集群中所有资源的事件流，是故障排查的重要工具。可以根据资源类型、命名空间进行过滤。

7.11 资源创建与编辑

Dashboard 允许你通过两种主要方式创建或修改 Kubernetes 资源：
* 通过 YAML 文件创建/更新资源： 你可以直接在 Dashboard 中粘贴 YAML 内容来部署新的应用或更新现有资源。
* 通过表单创建资源： 对于 Deployment 等常见资源，Dashboard 提供了向导式的表单填写，简化了创建过程。

8. 高级用法与最佳实践

8.1 安全最佳实践：最小权限原则

专用 Service Account： 始终为 Dashboard 访问创建一个专用的 Service Account。
限制权限： 不要随意授予 cluster-admin 权限。根据实际需要，创建自定义的 Role 或 ClusterRole，并只包含必要的 verbs (如 get, list, watch, create, update, delete) 和 resources (如 deployments, pods, services)。
网络隔离： 使用 Ingress 和网络策略（Network Policies）限制 Dashboard 的网络访问。
TLS 加密： 确保 Dashboard 始终通过 HTTPS 访问，使用有效的 TLS 证书。

8.2 多集群管理 (不直接支持，但可结合 Kubeconfig)

Kubernetes Dashboard 本身设计为管理单个集群。如果你需要管理多个集群，每次都需要切换 Kubeconfig 文件或使用不同的 Token 登录。一些第三方工具（如 Lens）在多集群管理方面表现更优。

8.3 定期更新 Dashboard

Kubernetes Dashboard 社区会持续发布新版本，修复 Bug、增强功能和提升安全性。定期关注并更新 Dashboard 到最新稳定版本是良好的实践。

8.4 结合监控与告警系统

虽然 Dashboard 提供了一些基本的资源利用率展示，但它并非专业的监控告警系统。在生产环境中，应将 Dashboard 与 Prometheus、Grafana 等专业的监控告警方案结合使用，以获得更全面的集群健康状况和性能洞察。

9. 常见问题与故障排除

9.1 无法访问 Dashboard

kubectl proxy 未运行？ 确保你在一个独立的终端中启动了 kubectl proxy。
URL 错误？ 检查 kubectl proxy 提供的 URL 是否正确，特别是末尾的 /。
防火墙？ 检查本地或集群防火墙是否阻止了访问。
Service 类型？ 如果使用 NodePort 或 Ingress，检查 Service 或 Ingress 配置是否正确，以及对应的端口或域名是否可访问。

9.2 Dashboard 中看不到 CPU/内存利用率

Metrics Server 未安装或未运行？ 检查 kubectl top nodes 或 kubectl top pods 是否能正常获取数据。如果不能，重新部署或排查 Metrics Server 的问题（如 kubelet-insecure-tls 参数）。
Pod 状态异常？ 检查 Metrics Server 的 Pod 是否处于 Running 状态。

9.3 权限不足

登录失败？ 检查你使用的 Token 是否属于一个具有足够权限的 Service Account。
某些资源无法显示或操作？ 这通常是 RBAC 权限不足导致的。检查你用于登录的 Service Account 绑定了哪些 RoleBinding 或 ClusterRoleBinding，以及这些绑定指向的 Role 或 ClusterRole 是否包含了所需的 verbs 和 resources。例如，如果你只能看到 Pods 而无法删除它们，可能是缺少 delete 权限。

9.4 Dashboard 页面报错

查看 Dashboard Pod 日志： kubectl logs -n kubernetes-dashboard <dashboard-pod-name>。日志通常会提供有用的错误信息。
检查 API Server 状态： 确保 Kubernetes API Server 正常运行。

10. Kubernetes Dashboard 的优缺点

10.1 优点

官方支持： 作为 Kubernetes 官方项目，与 K8s 版本兼容性良好。
开箱即用： 部署简单，上手迅速。
直观易用： 图形化界面对 K8s 新手友好，降低学习门槛。
核心功能全面： 覆盖了集群资源管理、应用部署、日志查看、事件监控等日常操作。
免费开源： 无成本使用，社区活跃。

10.2 缺点

安全性挑战： 权限管理不当容易成为安全漏洞，需要仔细配置 RBAC。
功能相对基础： 相比一些商业或更专业的 K8s UI 工具，Dashboard 的高级功能（如自定义监控图表、复杂故障排除工具、多集群管理）相对较少。
性能瓶颈： 在非常庞大或繁忙的集群中，Dashboard 可能会响应缓慢。
不适合高级运维： 对于经验丰富的 K8s 专家，kubectl 结合脚本和自动化工具效率更高。Dashboard 更多是作为辅助和快速查看工具。
Metrics Server 依赖： 完整的监控功能需要额外部署 Metrics Server。

10.3 替代方案 (Lens, K9s 等)

市场上有许多优秀的 Kubernetes UI 工具，它们在某些方面可能比官方 Dashboard 更强大：

Lens (KubeLens)： 一个功能非常强大的桌面应用，支持多集群管理、更丰富的监控、资源编辑、日志聚合等。是目前非常受欢迎的 Kubernetes IDE。
K9s： 一个基于终端的 UI (TUI) 工具，通过键盘操作，提供类似 CLI 的速度和 GUI 的可视化，非常适合喜欢命令行但又需要可视化辅助的工程师。
Rancher UI： 如果你使用 Rancher 管理 Kubernetes 集群，Rancher 本身就提供了一个功能非常强大的 Web UI，支持多集群管理、应用商店、CI/CD 集成等。
OpenShift Console： 红帽 OpenShift 平台提供的 Web 控制台，功能非常全面且企业级。

11. 总结与展望

Kubernetes Dashboard 是一个非常有用的工具，它为 Kubernetes 集群提供了一个直观、可视化的管理界面，极大地简化了日常的运维和开发任务。无论是对于刚接触 Kubernetes 的新手，还是需要快速查看集群状态的资深工程师，Dashboard 都是一个不可或缺的辅助工具。

然而，我们也要清醒地认识到其局限性，特别是在安全性、高级功能和性能方面的考量。在生产环境中，务必遵循最小权限原则配置 RBAC，并结合 Ingress 进行安全访问。同时，Dashboard 并不是 kubectl 的完全替代品，两者结合使用才能发挥 Kubernetes 管理的最大效能。对于更复杂的场景，探索如 Lens、K9s 等替代方案，可以帮助你更高效、更安全地驾驭 Kubernetes 的强大力量。

随着 Kubernetes 生态的不断发展，我们可以期待 Dashboard 在未来会变得更加智能、安全和功能强大，持续为用户提供更优质的集群管理体验。

Kubernetes Dashboard 深度指南：从入门到精通的视觉管理利器

目录

1. 引言：驾驭 Kubernetes 的视觉之窗

1.1 Kubernetes 挑战与 Dashboard 的诞生

1.2 什么是 Kubernetes Dashboard？

1.3 为什么需要 Kubernetes Dashboard？

2. Kubernetes Dashboard 核心概念与工作原理

2.1 架构概述

2.2 与 API Server 的交互

2.3 权限管理（RBAC）的重要性

2.4 Metrics Server：Dashboard 数据的源泉

3. 前置条件与准备工作

3.1 一个可用的 Kubernetes 集群

3.2 kubectl 命令行工具

3.3 基础 Kubernetes 知识

4. Kubernetes Dashboard 部署与安装

4.1 部署 Dashboard Pods 和 Service

1. 部署 Kubernetes Dashboard

使用官方推荐的部署文件，这个文件包含了 Dashboard 的 Deployment 和 Service 等资源。

注意：这个推荐文件通常将 Dashboard 部署在 kubernetes-dashboard 命名空间下。

如果你想使用特定版本，可以修改 v2.7.0 为你需要的版本号。

也可以下载到本地后编辑，例如：

curl -o recommended.yaml https://raw.githubusercontent.com/kubernetes/dashboard/v2.7.0/aio/deploy/recommended.yaml

kubectl apply -f recommended.yaml

4.2 验证 Dashboard 部署状态

检查 Pod 状态

预期输出：

NAME READY STATUS RESTARTS AGE

kubernetes-dashboard-xxxxxxxxx-xxxxx 1/1 Running 0 Xm

检查 Service 状态

预期输出：

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE

kubernetes-dashboard ClusterIP 10.xx.xx.xx 443/TCP Xm

4.3 安装 Metrics Server (可选但强烈推荐)

4.3.1 什么是 Metrics Server？

4.3.2 部署 Metrics Server

1. 部署 Metrics Server

使用官方推荐的部署文件

注意：某些环境中，Metrics Server 部署可能需要跳过 TLS 验证。

如果遇到 “x509: cannot validate certificate” 错误，

你可能需要在 metrics-server 的 deployment 中添加 --kubelet-insecure-tls 参数。

例如：编辑 high-availability.yaml 文件，找到 metrics-server 容器的 args 字段，

添加 – –kubelet-insecure-tls。

4.3.3 验证 Metrics Server 状态

检查 Pod 状态 (通常在 kube-system 命名空间下)

预期输出：

NAME READY STATUS RESTARTS AGE

metrics-server-xxxxxxxxx-xxxxx 1/1 Running 0 Xm

检查 Metrics API 是否可用

预期输出：

NAME SERVICE AVAILABLE AGE

v1beta1.metrics.k8s.io kube-system/metrics-server True Xm

验证数据是否能正常获取 (可能需要等待一两分钟 Pod 启动并收集数据)

5. 访问 Kubernetes Dashboard

5.1 方法一：使用 kubectl proxy (开发/测试环境推荐)

5.1.1 启动代理

5.1.2 访问 URL

5.1.3 优点与局限性

5.2 方法二：通过 NodePort 暴露 (慎用，适用于特定场景)

5.2.1 修改 Dashboard Service 类型

编辑 kubernetes-dashboard Service

查找 kubernetes-dashboard Service 的 PORT(S) 字段，会显示类似 443:30XXX/TCP 的信息，其中 30XXX 就是分配的 NodePort。

5.2.2 访问 URL

5.2.3 安全考量

5.3 方法三：通过 Ingress 暴露 (生产环境推荐)

5.3.1 前提：Ingress Controller

5.3.2 创建 Ingress 资源

dashboard-ingress.yaml

5.3.3 配置 TLS (HTTPS)

带有 TLS 配置的 Ingress 示例

5.3.4 优点

6. Kubernetes Dashboard 认证与授权 (RBAC)

6.1 认证方式：Token vs Kubeconfig

6.2 创建拥有管理权限的 Service Account (最佳实践)

6.2.1 创建 Service Account

dashboard-adminuser.yaml

6.2.2 创建 ClusterRoleBinding

dashboard-admin-binding.yaml

6.2.3 获取 Service Account Token

admin-user-token.yaml

3.2 `kubectl` 命令行工具

注意：这个推荐文件通常将 Dashboard 部署在 `kubernetes-dashboard` 命名空间下。

你可能需要在 metrics-server 的 deployment 中添加 `--kubelet-insecure-tls` 参数。

5.1 方法一：使用 `kubectl proxy` (开发/测试环境推荐)

6.3 安全警告：避免使用 `cluster-admin` 权限直接暴露

发表评论取消回复