This website uses cookies. By continuing to browse, you agree to our Privacy Policy.

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.

Image Source: Kubernetes

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

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.

  1. 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.

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

How to Fix Kubernetes Dashboard Forbidden 403 Error 

This is a common error most Kubernetes operators encounter when setting up the dashboard for their clusters. The error occurs because the relevant user certificate is not present. Hence, Kubernetes fails to trust the user, leading to the 403 Forbidden error in question.

The solution is to create a new user using Kubernetes’ service account process and grant this new user admin privileges. Then, the user needs to log into the Kubernetes dashboard with the token associated with the user account.

Setting up a Service Account

To create a service account for the user:

Use the following YAML specification in the namespace titled kubernetes-dashboard:

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

Generating a Custom Role for the Service Account

To generate and grant a role to the user service account:

The service account created above needs a role called ClusterRoleBinding. If it is not already present, use the following command to create such a specific role and grant the required permissions:

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

Locating the Kubernetes Dashboard Token

To login with the Kubernetes Dashboard token:

  1. Use the following command to get the token for the newly created user account:
kubectl -n kubernetes-dashboard create token admin-user
  1. In the Kubernetes Dashboard window as shown below, enter the token obtained with the above command in the text field under the Token option:

Image Source: Kubernetes

Then, click the Sign in button.

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

Product Info: https://vague-comma.flywheelstaging.com/
Sign Up: https://app.vague-comma.flywheelstaging.com/#mode=signUp

Komodor is an end-to-end Kubernetes operations solution for Dev and Ops teams that is designed to bring back control over your Kubernetes environment. 

Komodor provides automated playbooks for every K8s resource, and static-prevention monitors that enrich live & historical data with contextual insights to help enforce best practices and stop incidents in their tracks. By baking K8s expertise directly into the product, Komodor is accelerating response times, reducing MTTR and empowering dev teams to resolve issues efficiently and independently.

Key features: 

  • Single dashboard to access multiple clusters, and namespaces with easy access to resources related information
  • Cross clusters events screen to correlate multiple changes and how they affect each other
  • Comparison between resources on multiple clusters / namespace
  • Pro-active monitors detecting availability/ cluster health issues
  • Show the error, explanation, and suggestion with the context to let developers solve the issues by themselves


Lens

GitHub: https://github.com/lensapp/lens
License: MIT license

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.


Skooner

GitHub: https://github.com/skooner-k8s/skooner

License: Apache License 2.0

Skooner is a Kubernetes dashboard solution that provides views of configurations and workloads, and enables managing resources and editing YAML editing directly in the UI. Key features include:

  • Full cluster management—namespaces, nodes, pods, replica sets, deployments, storage, RBAC, and more.
  • Live metric updates—shows the latest cluster metrics without requiring a refresh.
  • Cluster health view—enable quick tracing of underperforming resources.
  • Easy API integration—simple to perform create, read, update, and delete (CRUD) commands via the API, with comprehensive API documentation.
  • Mobile support—responsive UI supporting desktop, tablets, and smartphones.
  • OpenID Connect (OIDC) integration—out of the box with no agents required.
  • Quick installation—provides YAML resources you can deploy to your cluster and immediately deploy the solution.


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 NuxtJS. 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.

How useful was this post?

Click on a star to rate it!

Average rating 0 / 5. Vote count: 0

No votes so far! Be the first to rate this post.