Kubernetes Dashboard: Quick Guide and 4 Great Alternatives

What Is the Kubernetes Dashboard?

The Kubernetes Dashboard is a web-based user interface for Kubernetes. You can use it to get an overview of applications running on a cluster, deploy containerized applications to a Kubernetes cluster, and manage cluster resources. It also enables troubleshooting for containerized applications, providing information about the health of Kubernetes resources in your cluster and any errors that have occurred.

The Kubernetes Dashboard makes it possible to create or modify individual Kubernetes resources, such as deployments, jobs, DaemonSets, and StatefulSets. It can also be used to directly manage Kubernetes pods.

Updated May 28, 2024: We added simple instructions on how to deploy the dashboard, access it with admin permissions, and create a read-only role.

Image Source: Kubernetes

This is part of a series of articles about Kubernetes architecture.

Kubernetes Dashboard UI Overview 

Here are the components of the Kubernetes dashboard.

The Cluster View

The cluster view comprises five subviews: namespaces, nodes, persistent volumes, roles, and storage classes. Clicking on a subview will direct you to that subview’s UI. 

Here is a closer look at two of the subviews.

Namespaces

The namespace subview gives an overview of every namespace in a cluster. This part of the Kubernetes dashboard should look like this:

Clicking on a namespace directs you to a dedicated view of that namespace. Currently, this view only displays recent events, but you can access other namespace-specific information in the general overview.

Nodes

You can click on the node subview to go to the nodes overview page, which lists all the nodes in your Kubernetes cluster. This overview page defines each node’s status, labels, limits, and memory/CPU requests.

Clicking on a specific node directs you to a detailed page for that node. This page contains several sections providing extensive information about the node, including machine ID, addresses, allocated resources, pods, conditions, and events.

The Details section provides basic data about the node, including its name, labels, kube-proxy version, kubelet version, operating system, and provider ID.

The Allocated Resources section contains three views—CPU allocation, memory allocation, and pod allocation. The memory and CPU allocation views specify the node’s memory and CPU capacity in addition to the total number of CPU limits and requests for all the pods running on the node. 

These views prodigy the numbers as percentages and in absolute terms. For instance, the CPU requests may be 0.64 CPU, representing 64% of the node’s total capacity of 1 CPU. Likewise, the memory limits may be 690 MiB or 18.62% of the node’s total capacity of 3.619 GiB.

The pod allocation view shows the total number of pods the node can support (i.e., 110) and the number of live pods (i.e., 29 pods, or 26.36% of the node’s total capacity).

The Node Conditions section describes the node’s status. Node conditions must be “true” or “false” and include Ready, OutOfDisk, MemoryPressure, DiskPressure, PIDPressure, and NetworkUnavailable. 

The Pods section aggregates all the pods belonging to the specific node and displays information about its namespace and status. If you click on an individual pod, it redirects you to a “details” page for that pod. 

The Cluster section contains several subviews showing information about specific Kubernetes objects—persistent volumes, roles, and storage class. Other sections include “workload, discovery, and load balancing” and “configuration and storage” on the main dashboard in Kubernetes. You can toggle between specific namespace views across these sections and an overview showing all namespaces. 

The Overview section includes combined information for every section’s most critical Kubernetes objects. It includes deployments, workload status, pods, replica sets, services, config maps, and secrets.

The Workloads View

The workloads view offers an overview of all applications running in the cluster, including deployment, pods, replica sets, and other Kubernetes controllers. Here is a closer look at the “pods” sub-section.

If you click on “pods,” it will take you to an overview of all the pods running in your cluster. This overview page provides all the important information for all individual pods, including the node, namespace, status, and the number of restarts. 

You can click on a specific pod to see a detailed overview of that pod. The pod overview provides details about the pod, including its attached labels, QoS class, and status. It also shows which containers belong to the specific pod, its condition, which controller created the pod, attached persistent volume claims, and events.

The Discovery and Load Balancing Section

This section consists of two Kubernetes objects—services and ingresses. The service section provides the most important data about specific services, including their namespaces, attached labels, and the cluster’s IP.

You can click on any service to see its dedicated overview, where you can view the service type, label selectors, and a list of the service’s endpoints, pods, and events.

The Configuration and Storage Section

This section provides information about secrets, config maps, and persistent volume claims. The persistent volume claims section includes details about all the PVCs in your cluster—volume, status, capacity, storage class, and access mode.

Each persistent volume claim has a detailed PVC section showing additional information about the claim, including its attached annotations and labels, namespace, and capacity.

Related content: Read our guide to Kubernetes Service

Tips from the expert

Itiel Shwartz

Co-Founder & CTO

Itiel is the CTO and co-founder of Komodor. He’s a big believer in dev empowerment and moving fast, has worked at eBay, Forter and Rookout (as the founding engineer). Itiel is a backend and infra developer turned “DevOps”, an avid public speaker that loves talking about things such as cloud infrastructure, Kubernetes, Python, observability, and R&D culture.

In my experience, here are tips that can help you better utilize the Kubernetes Dashboard:

Enable RBAC

Use Role-Based Access Control (RBAC) to manage who can access and interact with the dashboard.

Secure with HTTPS

Always access the dashboard over HTTPS to ensure data security.

Use read-only roles

Create read-only roles for non-admin users to prevent unauthorized changes.

Monitor with Prometheus

Integrate Prometheus for enhanced monitoring and alerting.

Automate access token rotation

Regularly rotate service account tokens to enhance security.

Installing Kubernetes Dashboard 

To install the Kubernetes dashboard:

1. Open an SSH client and connect to the Kubernetes master node.
2. Install kubectl on the master node, if not already installed.
3. Install the Kubernetes dashboard by running the following kubectl command. This command sets up each component of the dashboard by downloading the required .yaml file and following the instructions in it. Update this command to include the latest version of the Kubernetes Dashboard (see the documentation).

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

kubectl creates deployment resources including a dedicated Kubernetes Dashboard namespace, service accounts, configuration maps, pods, cluster roles, services, and RBAC roles, enabling the Kubernetes dashboard to function.

4. Run the following kubectl command to verify that all resources have been installed successfully.

kubectl get all -n kubernetes-dashboard

The output confirms that all dashboard components were created correctly.

Deploying and Accessing the Kubernetes Dashboard

After installing the Kubernetes Dashboard, you need to create a service account to access it. Follow these steps to set up and access the dashboard.

Create the Service Account

 First, create a service account named dashboard-user in the kubernetes-dashboard namespace. Create a file named dashboard-user.yaml with the following content:

yaml
   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: dashboard-user
     namespace: kubernetes-dashboard

Apply the configuration:

kubectl apply -f dashboard-user.yaml

Create the ClusterRoleBinding

Next, create a file named dashboard-clusterrolebinding.yaml to grant the necessary permissions:

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

Apply the configuration:

kubectl apply -f dashboard-clusterrolebinding.yaml

Create a Bearer Token and Retrieve It

Create the bearer token using the following YAML:

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

Save the file as dashboard-user-token.yaml and apply it using the command:

kubectl apply -f dashboard-user-token-yaml

The output should look like this:

Now retrieve the bearer token for the dashboard-user service account and save the output for later use. Assuming the secret name is dashboard-user-token:

kubectl get secret dashboard-user-token -n kubernetes-dashboard -o jsonpath={.data.token}” | base64 --decode

The output will look something like this. Copy the content of the token, you will use it for authentication later.

Warning: Make sure not to store the token in an unsecure location.

Start the Dashboard

Start the Kubernetes proxy to access the dashboard locally:

kubectl proxy

To enable access over the internet (not recommended for production environments) use the following command:

kubectl proxy --address='0.0.0.0' --port=8001 --accept-hosts='^.*$'

Access the Dashboard

Assuming you enabled internet access, open the following URL in a web browser: 

http://<YOUR-IP-ADDRESS>:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/#/login

You will be prompted to choose an authentication method. Select Token and copy the bearer token retrieved earlier:

Stop the Dashboard

To stop the dashboard, delete the deployment created earlier:

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

The output should look like this:

Optional: Creating a Read-Only User

It is more secure to grant read-only access to developers instead of full admin privileges. Follow these steps:

Step 1: Create a Read-Only Role

Create a file named dashboard-read-only-role.yaml with the following content:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: kubernetes-dashboard
  name: dashboard-user-role
rules:
- apiGroups: [""]
  resources: ["pods", "services", "configmaps", "secrets", "deployments", "replicasets", "pods/log"]
  verbs: ["get", "list", "watch"]

Apply the configuration:

kubectl apply -f dashboard-user-role.yaml

Step 2: Create the Read-Only Service Account

Create a file named dashboard-read-only-sa.yaml:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: dashboard-read-only-sa
  namespace: kubernetes-dashboard

Apply the configuration:

kubectl apply -f dashboard-read-only-sa.yaml

Step 3: Bind the Role to the Service Account

Create a file named dashboard-read-only-role-binding.yaml:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: dashboard-read-only-role-binding
  namespace: kubernetes-dashboard
subjects:
- kind: ServiceAccount
  name: dashboard-read-only-sa
  apiGroup: ""
roleRef:
  kind: Role
  name: dashboard-read-only-role
  apiGroup: ""

Apply the configuration:

kubectl apply -f dashboard-read-only-role-binding.yaml

Step 4: Retrieve the Read-Only Bearer Token

Create the token using the following YAML:

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

Now retrieve the bearer token for the dashboard-user service account and save the output for later use. Assuming the secret name is dashboard-user-token:

kubectl get secret dashboard-user-token -n kubernetes-dashboard -o jsonpath={.data.token}” | base64 --decode

The output will look something like this. Copy the content of the token, you will use it for authentication later.

4 Kubernetes Dashboard Alternatives 

The Kubernetes Dashboard solution shipped with the open source Kubernetes distribution is useful, but many do not consider it a full-featured observability solution. Several commercial and open source alternatives have emerged that can help you gain comprehensive visibility over your Kubernetes clusters.

Komodor

Learn more about Komodor
Get Started With Komodor Now!

Komodor is the solution for managing Kubernetes at scale. The platform continuously monitors, analyzes, and visualizes your Kubernetes environment, providing clear, actionable insights that simplify reliability maintenance, real-time troubleshooting, and cost optimization across complex, multi-cluster, and hybrid setups.

By bridging the Kubernetes knowledge gap, Komodor empowers infrastructure and application teams to move beyond firefighting and focus on operational efficiency, reducing MTTR, and accelerating development. With robust RBAC, SSO, and auditing capabilities, Komodor is the trusted platform for innovative enterprises throughout their Kubernetes journey, from migration to Day-2 operations.

Key features: 

• K8s Reliability management – continuously identify risks, optimize performance, and address issues like node pressure or service degradation before they negatively impact the business
• K8s Troubleshooting – guided troubleshooting experience which enables any engineer, regardless of expertise level, to independently detect, investigate, and remediate any K8s issue
• K8s Cost Optimization – view resource consumption trends over time and get suggestions for right-sizing workloads, eliminating idle resources, and applying the optimal strategy for each service with a single click
• K8s User Management – Leverage Komodor’s RBAC mechanism to provide teams of varying expertise with proper permissions and restrictions for accessing Kubernetes, while maintaining an audit trail of every change across the system

Lens

GitHub: https://github.com/lensapp/lens
License: Paid version only

Lens provides many of the same features provided by the official Kubernetes Dashboard, including the ability to view and edit namespaces, ReplicaSets, services, and other Kubernetes resources. It offers granular access control for dashboard users via role-based access control (RBAC).

In addition, Lens is integrated with Prometheus out of the box to provide multi-user visibility. As soon as it is deployed in a cluster, it automatically discovers Prometheus and starts displaying cluster metrics and visualizations in its dashboard, including resource utilization graphs and CPU, memory, network, and request metrics. These graphs and metrics are displayed in the context of a specific cluster.

K9s

GitHub: https://github.com/derailed/k9s 

License: Apache License 2.0

K9s is a terminal-based UI designed to facilitate the navigation, observation, and management of your Kubernetes clusters. This project aims to simplify interactions with deployed applications, offering a streamlined and efficient CLI tool for Kubernetes administrators. Key features includ:

• Real-time resource tracking: K9s continuously monitors Kubernetes resources, reflecting real-time changes and activities for pods, containers, and nodes.
• Resource handling: Supports both standard Kubernetes resources and custom resource definitions (CRDs), ensuring compatibility with various configurations.
• Cluster metrics monitoring: Displays real-time metrics for resources, helping users track the performance and health of their clusters.
• Advanced user commands: Offers standard cluster management commands like logs, scaling, port-forwards, and restarts.
• Filtering and error handling: Provides robust filtering capabilities to drill down into specific workload-related resources, with detailed error zoom features.
• Customizable interface: Allows users to define and apply custom skins, custom views and custom CLI commands.
• Resource views: Offers both minimal and full resource definitions views. Pulses and XRay views provide an overview of cluster resources.
• RBAC Support: Enables viewing of RBAC rules, cluster roles, and associated bindings. It also includes reverse lookup features to determine the permissions of a user, group, or service account.
• Built-in Benchmarking: Users can benchmark HTTP services and pods directly from K9s, allowing them to assess and optimize resource requests and limits.

Rancher Dashboard

GitHub: https://github.com/rancher/dashboard

License: Apache License 2.0

Rancher is an open source Kubernetes management tool that can be used to manage multiple Kubernetes clusters. Part of the Rancher platform is the Rancher Dashboard, a stateless client written in Vue.js and NextJS. The dashboard is bundled by default with the Rancher distribution. 

In Rancher-managed Kubernetes, the index.html file of the dashboard is returned as a “fallback” for any request that does not match an API URL.

The Rancher Dashboard shows Kubernetes types, namespaces, and operations that the current user has access to. By default, it shows a Details view with raw YAML obtained from the Kubernetes API,  and a Table view with the data provided by the command kubectl get <type> -o.

If this basic view is insufficient, the Rancher Dashboard lets you customize your view to enable graphical editing of resource information.