Kubernetes Dashboard: Complete Implementation Guide

Introduction to Kubernetes Dashboard

The Kubernetes Dashboard is a general-purpose, web-based user interface for Kubernetes clusters. It allows administrators and developers to manage and troubleshoot applications running inside a cluster, as well as manage the cluster itself, without resorting to the command line. Originally developed by the Kubernetes community and now maintained as a sub-project under the kubernetes organization, the Dashboard provides a visual overview of nodes, namespaces, workloads, services, configurations, and storage resources.

What Is the Kubernetes Dashboard?

At its core, the Kubernetes Dashboard is a stateless web application that communicates with the Kubernetes API server to fetch, display, and modify cluster resources. It runs as a Deployment inside your cluster and exposes a service that you can access through various methods. The UI is built with modern JavaScript frameworks and renders responsive pages that work on desktops, tablets, and mobile devices.

Key capabilities of the Dashboard include:

• Resource overviews — View nodes, namespaces, pods, deployments, StatefulSets, DaemonSets, Jobs, CronJobs, and more in a sortable, filterable table format.
• Real-time monitoring — Display CPU and memory usage graphs for nodes and pods (requires the Metrics Server).
• Log streaming — View container logs directly in the browser without running kubectl.
• Resource creation and editing — Create, update, and delete resources through a YAML/JSON editor or guided forms.
• Interactive troubleshooting — Execute commands inside running containers via an embedded terminal.
• RBAC-aware views — The Dashboard respects cluster RBAC policies, so users see only the resources their credentials permit.

Why the Kubernetes Dashboard Matters

While kubectl is powerful, it presents a steep learning curve for newcomers and can slow down routine tasks that benefit from visual context. The Dashboard bridges this gap. For platform engineering teams, it serves as a lightweight observability console that doesn't require spinning up Grafana or a full monitoring stack just to check pod status. For developers, it provides self-service access to logs, shell sessions, and deployment status without granting SSH access to nodes or requiring deep Kubernetes expertise.

In production environments, the Dashboard helps on-call engineers quickly triage issues by scanning pod health, restart counts, and resource utilization across namespaces. It also serves as an auditing and validation tool—you can visually confirm that ConfigMaps, Secrets, and Ingress rules are configured correctly before promoting changes.

Prerequisites

• A running Kubernetes cluster (version 1.19+ recommended; the Dashboard follows a version skew policy of one minor version behind the API server).
• kubectl installed and configured to communicate with your cluster.
• The Metrics Server deployed in the cluster if you want CPU and memory graphs (the Dashboard gracefully degrades without it).
• A web browser with JavaScript enabled.

Step 1 — Deploy the Kubernetes Dashboard

The official distribution ships as a single YAML manifest containing all required resources: a Namespace, a ServiceAccount, a Secret for the ServiceAccount token, a ClusterRole and ClusterRoleBinding for default access, a Deployment, and a Service. Deploy it with a single kubectl command:

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

This creates the kubernetes-dashboard namespace and installs all components. Verify the deployment:

kubectl get pods -n kubernetes-dashboard
kubectl get svc -n kubernetes-dashboard

Expected output shows the dashboard pod running and a service named kubernetes-dashboard of type ClusterIP exposed on port 443 (the dashboard serves HTTPS internally using auto-generated certificates).

Step 2 — Choose an Access Method

Because the Dashboard Service is ClusterIP by default, it is only reachable inside the cluster. You need to expose it externally or use a proxied connection. There are several approaches, each with different security implications.

Option A: kubectl proxy (development only)

The simplest method for local development is kubectl proxy, which creates an HTTP proxy on your local machine that authenticates to the API server using your kubeconfig credentials:

kubectl proxy

This listens on http://localhost:8001. Access the dashboard at:

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

Note: This method skips authentication entirely because the proxy passes your kubeconfig credentials. It is suitable for quick exploration but should not be used in production.

Option B: NodePort (testing environments)

Patch the service to NodePort type to expose it on a static port across all nodes:

kubectl patch svc kubernetes-dashboard -n kubernetes-dashboard \
  -p '{"spec":{"type":"NodePort"}}'

Then retrieve the assigned port:

kubectl get svc kubernetes-dashboard -n kubernetes-dashboard \
  -o jsonpath='{.spec.ports[0].nodePort}'

Access via https://<node-ip>:<nodePort>. You'll need to accept the self-signed certificate warning in your browser.

Option C: Ingress with TLS termination (production)

For production, route traffic through an Ingress controller that terminates TLS with a trusted certificate. First create a TLS Secret (or use cert-manager to automate it), then deploy an Ingress resource:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: dashboard-ingress
  namespace: kubernetes-dashboard
  annotations:
    nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"
    nginx.ingress.kubernetes.io/ssl-passthrough: "true"
    # Alternative if you terminate TLS at the ingress:
    # nginx.ingress.kubernetes.io/ssl-redirect: "true"
spec:
  ingressClassName: nginx
  tls:
  - hosts:
    - dashboard.example.com
    secretName: dashboard-tls-secret
  rules:
  - host: dashboard.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: kubernetes-dashboard
            port:
              number: 443

Apply this manifest:

kubectl apply -f dashboard-ingress.yaml

Then configure DNS to point dashboard.example.com at your Ingress controller's external IP.

Step 3 — Configure Authentication and RBAC

The Dashboard supports two authentication mechanisms: a Bearer Token (most common and recommended) and kubeconfig file upload. The default installation creates a kubernetes-dashboard ServiceAccount with cluster-admin privileges, which is dangerously broad. In production you should create scoped RBAC roles.

Creating a dedicated viewer ServiceAccount

First, create a ServiceAccount and a ClusterRole that grants read-only access to most resources but prevents modifications:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: dashboard-viewer
  namespace: kubernetes-dashboard
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: dashboard-viewer-role
rules:
- apiGroups: [""]
  resources: ["pods", "services", "configmaps", "persistentvolumeclaims", "events", "namespaces"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["apps"]
  resources: ["deployments", "statefulsets", "daemonsets", "replicasets"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["batch"]
  resources: ["jobs", "cronjobs"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["networking.k8s.io"]
  resources: ["ingresses"]
  verbs: ["get", "list", "watch"]
- apiGroups: [""]
  resources: ["nodes"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["metrics.k8s.io"]
  resources: ["pods", "nodes"]
  verbs: ["get", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: dashboard-viewer-binding
subjects:
- kind: ServiceAccount
  name: dashboard-viewer
  namespace: kubernetes-dashboard
roleRef:
  kind: ClusterRole
  name: dashboard-viewer-role
  apiGroup: rbac.authorization.k8s.io

Apply it:

kubectl apply -f dashboard-viewer-rbac.yaml

Retrieving the Bearer Token

For Kubernetes 1.24+, the recommended way to obtain a long-lived token is to create a Secret manually bound to the ServiceAccount:

apiVersion: v1
kind: Secret
metadata:
  name: dashboard-viewer-token
  namespace: kubernetes-dashboard
  annotations:
    kubernetes.io/service-account.name: dashboard-viewer
type: kubernetes.io/service-account-token

Apply and extract the token:

kubectl apply -f dashboard-viewer-token-secret.yaml
kubectl get secret dashboard-viewer-token -n kubernetes-dashboard \
  -o jsonpath='{.data.token}' | base64 --decode

On older clusters (pre-1.24), the token is automatically created and can be retrieved directly:

kubectl -n kubernetes-dashboard create token dashboard-viewer

Copy the token value. When you open the Dashboard in your browser, select the "Token" authentication method and paste it. The UI will then show only resources permitted by the dashboard-viewer-role ClusterRole.

Step 4 — Navigating the Dashboard Interface

Once authenticated, the Dashboard presents several sections accessible from the left sidebar:

• Cluster — Global view of nodes, namespaces, persistent volumes, and cluster-level RBAC objects. The node list shows CPU/memory utilization per node when the Metrics Server is present.
• Workloads — Drill down into Deployments, StatefulSets, DaemonSets, Jobs, CronJobs, and individual pods. Each pod detail page includes real-time resource graphs, environment variables, volume mounts, and container logs.
• Service — Lists Services and Ingresses with their endpoints and external IPs.
• Config & Storage — Browse ConfigMaps, Secrets, PersistentVolumeClaims, and StorageClasses.
• Namespaces — The namespace picker at the top controls the scope of all views. Switching namespaces filters every list accordingly.

Creating resources from the UI

Click the + icon in the top-right corner. You can paste YAML or JSON directly into the editor, upload a file, or use guided forms for Deployments, Services, and Ingresses. The editor validates syntax before submission:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-example
  namespace: default
  labels:
    app: nginx
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.25
        ports:
        - containerPort: 80
        resources:
          requests:
            cpu: 100m
            memory: 128Mi
          limits:
            cpu: 500m
            memory: 256Mi

Paste this into the editor, select "Create", and the deployment appears in the Workloads list within seconds.

Viewing logs and executing commands

Navigate to a pod's detail page. You'll see a "Logs" tab that streams stdout/stderr from any container in the pod. Use the container dropdown to switch between init containers, sidecars, and main application containers. The logs view supports searching, filtering by date, and downloading as a text file.

The "Exec" tab opens an interactive terminal inside the container. This is equivalent to kubectl exec -it and is invaluable for debugging environment variables, network connectivity, or file system state without leaving the browser.

Step 5 — Integrating with the Metrics Server

If CPU and memory graphs appear empty or show "metrics not available", deploy the Metrics Server:

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

Verify it is running and producing metrics:

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

Refresh the Dashboard; node and pod resource graphs should now populate. The Dashboard queries the metrics.k8s.io API group, which the Metrics Server registers.

Complete Secure Deployment Example

Below is a consolidated, production-oriented setup script that deploys the Dashboard, creates a scoped ServiceAccount, exposes it via an Ingress, and applies network policies to restrict access:

#!/bin/bash
# Deploy the Kubernetes Dashboard with secure defaults

set -e

DASHBOARD_VERSION="v2.7.0"
NAMESPACE="kubernetes-dashboard"
DOMAIN="dashboard.internal.example.com"

echo "[1/5] Deploying Dashboard ${DASHBOARD_VERSION}..."
kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/${DASHBOARD_VERSION}/aio/deploy/recommended.yaml

echo "[2/5] Creating read-only ServiceAccount..."
cat <

kubectl auth can-i --list --as=system:serviceaccount:kubernetes-dashboard:your-sa -n default

kubectl get deployment metrics-server -n kube-system
kubectl top nodes

kubectl logs -n kubernetes-dashboard deployment/kubernetes-dashboard

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