Getting the Most from Kubernetes Dashboards

October 15, 2021

Keeping track of your Kuberetes resources can be a challenge, especially as you scale. The k8s web-based dashboard is a great way to visualize what’s going on in your cluster.

Damaso Sanoja
Engineer

Kubernetes has quickly become the open-source container orchestration platform par excellence around the world. No wonder. Kubernetes offers a level of flexibility and scalability that is hard to beat.

However, the flexibility of K8s to adapt to any use case from Edge nodes to Datacenters comes at a price. Managing the myriad of resources that Kubernetes handles is a daunting task. In this regard, the project has developed a web-based UI popularly known as the Dashboard, which greatly simplifies viewing and understanding what is happening in your cluster.

In this post, you’ll learn how Kubernetes’ built-in Web UI can make your life easier by giving you the ability to check resource usage in real-time, and consequently create, edit, scale, delete, or adjust those resources as needed.

Installing Kubernetes Dashboard Using kubectl

In order to install the Kubernetes Web UI, you’ll need:

  • A Kubernetes distribution is already installed, either locally or on a remote server.
  • Make sure you have Kubernetes Metrics Server installed on your cluster, as some distributions don’t come with it deployed by default.
  • Have the <terminal inline>kubectl<terminal inline> command line tool installed and configured on your local machine.

For the purposes of this guide, I used the lightweight distribution, K3s since it comes ready to use with the Kubernetes Metrics Server configured.

Before starting the dashboard installation, verify that you can connect from your local machine to Kubernetes. To do this, use the following command:

<terminal>kubectl cluster-info<terminal>

You should see an output similar to the following:

K8s cluster information
K8s Cluster iInformation

The Kubernetes Web UI (Dashboard) can be deployed either using the recommended configuration that uses an HTTPS connection or the alternative method that uses an unsecured HTTP connection to communicate with your browser.

To deploy the Dashboard with the recommended configuration, use the following command from your local machine:

<terminal>kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.0/aio/deploy/recommended.yaml<terminal>

The output will confirm that all Dashboard components have been created correctly.

Web UI Deployment

Give your cluster a few minutes to deploy the necessary pods. If you wish, you can check the status of the pods by running the command:

<terminal>kubectl get pods -A<terminal>

The output should be similar to this.

Web UI Pods
Web UI Pods

Securing Access to the Kubernetes Dashboard

For security reasons, the recommended configuration gives the Dashboard ServiceAccount limited access to Kubernetes resources. This can prevent sensitive cluster data such as secrets or certificates from being exposed by accident.

That said, to leverage all Web UI functionality, you’ll need a service account with administrative (superuser) privileges, that is, a service account with the <terminal inline>cluster-admin<terminal inline> cluster role.

Using your preferred text editor, create an <terminal inline>admin-user.yml<terminal inline> file:


---
apiVersion: v1
kind: ServiceAccount
metadata:
 name: admin-user
 namespace: kubernetes-dashboard
---
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

Create the new service account, <terminal inliadmin-user, by applying the changes:

<terminal>kubectl apply -f admin-user.yml<terminal>

The terminal output should confirm the creation of the new service account as well as its role binding.

Admin service account creation
Admin Service Account Creation

Accessing the Kubernetes Dashboard

The recommended way to access the Kubernetes Dashboard is through Bearer Tokens. This allows for great flexibility in managing permissions.

To get the Bearer Token of the ServiceAccount <terminal inline>admin-user<terminal inline> run the following command.


kubectl get secret -n kubernetes-dashboard $(kubectl get serviceaccount admin-user -n kubernetes-dashboard -o jsonpath="{.secrets[0].name}") -o jsonpath="{.data.token}" | base64 --decode


As soon as you execute the instruction, the Bearer Token of the service account will be printed on the console. It’s a long output similar to the one shown below.

Admin Bearer Token
Admin Bearer Token

Copy the Bearer Token to a safe place as you’ll need it shortly. Now, from your local machine, expose the Kubernetes Dashboard running the command:

<terminal>kubectl proxy<terminal>

If you have followed the procedure described in this tutorial, a message will appear in the terminal indicating that the WebUI is available at <terminal inline>127.0.0.1:8001<terminal inline>. For security reasons, the Dashboard will only be accessible from the machine running the <terminal inline>kubectl proxy<terminal inline> command. Keep this in mind, especially if Kubernetes is installed on a remote server.

Once the proxy is active, you can access the Web UI pointing your favorite browser to the following address:

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

You should see a screen similar to the one shown below.

Web UI Login
Web UI Login

Enter the <terminal inline>admin-user<terminal inline> Bearer Token and click the Sign in button to continue. You’ll be presented with the Kubernetes Dashboard “Overview” screen.

Web UI Initial Screen
Web UI Initial Screen

Using the Kubernetes Web UI Dashboard

Out of the box, the Dashboard doesn’t seem to have much to show. This is because there is no pod running in the default namespace at the moment. However, if you go to the drop-down list on the left side menu and select “All namespaces” you will get an idea of the information that the Web UI can make available to you.

Web UI Overview (All namespaces)
Web UI Overview (All namespaces)

In the upper portion, you can see the CPU and memory usage of the cluster in real-time, while just below, you can see the Workload Status of the Daemon Sets, Deployments, Pods, and more.

If you scroll down, you will notice that each workload has its own section with more details. For instance, if you want to check all running pods you can do so by checking the respective section.

Dashboard All Pods
Dashboard All Pods

You could say that this section is the equivalent of the <terminal inline>kubectl get pods -A<terminal inline> command you ran earlier. Furthermore, in addition to the convenience of checking the relevant pod information, this view gives you additional information such as CPU and memory usage per pod.

This is just a small part of the potential of the Kubernetes Dashboard. However, before reviewing in detail the different views, options, and settings offered by this amazing tool, let’s talk a bit more about security.

Hardening Dashboard Authentication

The Dashboard is basically a graphical version of the <terminal inline>kubectl<terminal inline> command-line tool. This leads to serious security implications, so it’s advisable to give the Dashboard the same importance as any <terminal inline>kubectl<terminal inline> users. In other words, you should enforce the same security practices, including proper roles and authentication.

In the previous section, you created the service account <terminal inline>admin-user<terminal inline> and granted it cluster-wide administrative rights. For learning purposes, this type of account provides a convenient solution for accessing all resources. However, if you work in a development team or want to use the Web UI in production, an account with such privileges represents a huge security risk.

Creating a Restricted User Account

To illustrate this point, you’ll create a restricted account that only has privileges to view resources. In that sense, you can repeat the procedure used when creating the <terminal inline>admin-user<terminal inline> from the terminal. However, since you have a fully functional Web UI, why not take advantage of it?

First, select the <terminal inline>kubernetes-dashboard<terminal inline> namespace from the drop-down menu on the left. Then, click on the “+” symbol at the top right to create a new resource.

Selecting Kubernetes Dashboard namespace
Selecting Kubernetes Dashboard namespace

This will give you access to a window where you can paste the content of the resource you want to create.

Create resource panel
Create Resource Panel

In this case, copy and paste the following content.

apiVersion: v1

kind: ServiceAccount

metadata:

name: restricted-user

namespace: kubernetes-dashboard

---

kind: ClusterRole

metadata:

annotations:

rbac.authorization.kubernetes.io/autoupdate: "true"

label:

name: restricted-clusterrole

namespace: default

rules:

- apiGroups:

- ""

resources: ["*"]

verbs:

- get

- list

- watch

- apiGroups:

- extensions

resources: ["*"]

verbs:

- get

- list

- watch

- apiGroups:

- apps

resources: ["*"]

verbs:

- get

- list

- watch

---

apiVersion: rbac.authorization.k8s.io/v1

kind: ClusterRoleBinding

metadata:

name: restricted-binding

roleRef:

kind: ClusterRole

name: view

apiGroup: rbac.authorization.k8s.io

subjects:

- kind: ServiceAccount

name: restricted-user

namespace: kubernetes-dashboard

Once you have pasted it, click on the “Upload” button at the bottom left.

Restricted User creation
Restricted User creation

If there is no syntax error (remember that YAML files are very sensitive to indentations), the window will close without displaying any message. Note that through the Web UI you can also create resources using a file or a form.

Once the <terminal inline>restricted-user<terminal inline> service account is created, you only need its Bearer Token to access the Dashboard. Again, you can get the token from the terminal or you can use the Dashboard.

To obtain the Bearer Token, go to “Secrets” in the Config and Storage section.

Restricted User Token
Restricted User Token

Here you can see that the respective token has been created for the <terminal inline>restricted-user <terminal inline> service account. Click on the secret to view its contents.

Bearer Token
Bearer Token

For security reasons, you must press the button indicated in the image to display the Bearer Token value. Copy this value, as you will need it soon.

Logging in as a Restricted User

In order to use the new ServiceAccount, you must exit the Web UI. To do so, click on the user icon in the upper right corner and then click on "Sign out.”

Log Out
Log Out

This will take you back to the initial login screen. Use the <terminal inline>restricted-user<terminal inline> Bearer Token to log in.

At first glance, you will not notice much difference with respect to the <terminal inline>admin-user<terminal inline>. However, if you select the <terminal inline>kubernetes-dashboard<terminal inline> namespace and try to view the Bearer Tokens, you will notice that you do not have sufficient permissions to view them.

Restricted User View
Restricted User View

Not having access to the secrets is a good thing, but what if instead of checking the secrets you go to the Config Maps section?

CA Certificate
CA Certificate

The “restricted” user has access to the Certificate Authority, thus can take full control of the cluster in the blink of an eye. This has to do with the rights that were granted to the <terminal inline>restricted-user<terminal inline> ServiceAccount.

As you can see, from a security point of view, the Kubernetes Web UI uses the same principles that you are already familiar with. The flexibility offered by the Role-Based Access Control (RBAC) mechanism of the Kubernetes API makes it easy to control the privileges of each user.

You can create as many service accounts as you need and assign each one the permissions you deem appropriate, whether cluster-wide or limited to a particular namespace. The crucial point is to apply the same best practices that you would normally use with <terminal inline>kubectl<terminal inline> users. In other words, grant each user the strictly necessary permissions to carry out their work.

For further reference on how to manage Kubernetes API Access Control, read the k8s RBAC documentation.

Navigating Through the Kubernetes Dashboard

At this point, you already have an idea of the benefits of the Kubernetes Dashboard. However, you may be wondering, what else can I do with it? The goal of this section is to show you what you can do with the Web UI, as well as some of the best practices to get the most out of it.

The Kubernetes Web UI Overview Screen

Login with the <terminal inline>admin-user<terminal inline> service account using the corresponding Bearer Token. This will bring you back to the initial Web UI screen in the default namespace.

On the left-hand side, you have the familiar menu, which is divided into several sections:

  • Cluster
  • Namespace
  • Overview
  • Workloads
  • Discovery and Load Balancing
  • Config and Storage
  • Custom Resource Definitions
  • Settings
  • About

To simplify the Dashboard walkthrough, deploy an Nginx pod. Click on the “+” sign in the upper right corner and paste the following content:

apiVersion: apps/v1

kind: Deployment

metadata:

name: nginx-deployment

spec:

selector:

matchLabels:

app: nginx

replicas: 2 # tells deployment to run 2 pods matching the template

template:

metadata:

labels:

app: nginx

spec:

containers:

- name: nginx

image: nginx:1.14.2

ports:

- containerPort: 80

Nginx Deployment
Nginx Deployment

After pressing the “Upload” button, you will notice that the Overview screen will show you the progress of the pod deployment.

Pod creation
Pod creation

Once the deployment is complete, the screen will update to show additional information, such as CPU and memory usage in the default namespace.

Pod ready
Pod ready

If you scroll down the Overview screen, you will notice that all relevant information is available: the workload, deployments, pods, replica sets, services, config maps, and even secrets. As the name suggests, the Overview screen gives you a bird’ eye view of the selected namespace (or all namespaces if you wish).

You can think of the Overview screen as the sum of all the individual views. From here, you can access all namespace resources, review the contents of each of them, modify them, or delete them.

Cluster View

The Overview screen is an excellent starting point for managing namespace resources. However, when it comes to system-wide resources, the most convenient way to manage them is through the Cluster view.

Unlike the Overview screen, the Cluster view is divided into several sections:

  • Cluster Roles
  • Namespaces
  • Nodes
  • Persistent Volumes
  • Storage Classes

When you click on the Cluster menu, you get a visualization of all these sections together.

Cluster View
Cluster View

However, if you click on Cluster Roles, you will notice that only that section becomes visible.

Cluster Roles View
Cluster Roles View

As you can see, navigating through the Kubernetes Web UI is intuitive and predictable. Each section on the left is divided into subsections that make it easy to visualize active resources. So, for example, if you need an overview of all the resources in the cluster, you can click on the Cluster section, but if you only want to see the namespaces, you can click directly on that view.

Namespaces View
Namespaces View

As you can imagine, in any of the views you can click on the link corresponding to each resource. For instance, click on the default namespace to access its information.


Default Namespace
Default Namespace

At the top right, you will see three icons. The first one will take you to the Overview of this namespace, the second one allows you to edit the resource, and as you can imagine, the trash will delete it.

In principle, all views offer similar options. Some offer graphics and additional information. Others just show links to k8s resources.

Thus we have the view for the cluster nodes:

Cluster Nodes
Cluster Nodes

And the “Persistent Volumes” view, which in this case has nothing relevant to show:

Persistent Volumes
Persistent Volumes

And finally, the Storage Classes view:

Storage Classes
Storage Classes

In each view, you can apply filters, sort rows, or even collapse charts if you wish. Simply put, you have all the cluster information just a click away.

Workloads View

There is no doubt that one of the most useful sections of the Web UI is the Workload view. From there, you can perform most of the administrative operations of your cluster.

Workload View
Workload View

As in the case of the Cluster view, this section is divided into subsections for each type of resource, which aims to achieve more efficient management of them. In the case of the Nginx deployment, there are no cron jobs, daemon sets, jobs, replication controllers, or stateful sets to display. So to show you the functionality of the Dashboard, we are going to focus on the remaining resources.

Let’s start with one of the most important views, Deployments.

Deployments View
Deployments View

In this view, there are two graphs at the top showing the CPU and memory usage in real-time, while below are listed the deployments in the selected namespace.

Note that on the right side of the Nginx deployment is a kebab menu, also known as the three dots menu or three vertical dots menu, which allows you to perform additional actions.

In this case, the Kubernetes Dashboard allows you three specific actions: scale the deployment, edit it, or delete it. Try to scale the deployment by clicking on the corresponding action.

Nginx Replicas Count
Nginx Replicas Count

The pop-up window is quite explicit. You can enter the number of desired replicas in the corresponding box and click “Scale” to proceed. Note that at the bottom, there is a message that will show the equivalent command to run with <terminal inline>kubectl<terminal inline>.

Enter “4” in the Desired replicas field and execute the command. The next screen will show you the course of the action.

Nginx Scaled
Nginx Scaled

Alternatively, you can use the action menu to edit the deployment in the format of your choice, YAML or JSON, and update the resource. Edit the Nginx deployment and change the replicas to “3” as shown in the image below.

Edit Nginx Deployment
Edit Nginx Deployment

As you can see, in a matter of a minute, you have scaled the deployment using two different methods. This same procedure can be used to edit any cluster resource to which you have access.

The action menu can change dynamically depending on the resource you are working on. To check it, go to the Pods section and click on the three-dot menu of one of the pods.

Pods view
Pods view

In this case, the menu allows you to view the logs of each pod, execute a command within the pod (Exec), edit the pod, or delete it. Try the latter by selecting a pod at random and choosing the Delete option. A confirmation message will appear, along with the equivalent command in <terminal inline>kubectl<terminal inline>.

Delete pod
Delete pod

For a moment, you will see the selected pod destroyed while a new one is deployed to replace it. After a few seconds, you will see the new pod running as expected to fulfill the replica set of the deployment.

New Pod
New pod

You can check the recent events by going to the Replica Sets section and clicking on the name of the running resource (Nginx in this case).

Replica Sets
Replica sets

If you scroll down, you will see the Events section where you can see all the operations you have recently performed. Additionally, at the top, you will have four icons. From left to right, the first one allows you to view the logs, the second one allows you to scale the resource, the third one allows you to edit it, and the last one allows you to delete it.

Nginx Replica Set
Nginx Replica Set

Up to this point, you have seen how the Kubernetes Dashboard allows you to perform administrative tasks in a comfortable and fast way. You can edit resources, scale pods, delete resources, view logs, and more. Best of all, the principles you’ve learned in the Workloads section apply to all resources.

Discovery and Load Balancing

Since there is only a single deployment in the default namespace, the Discovery and Load Balancing view only shows the Kubernetes API.

Discovery View
Discovery View

The only possible actions on this resource are to edit or delete it, which would not be a good idea for the cluster.

In this regard, it’s necessary to remember that the service account <terminal inline>admin-user<terminal inline> has the necessary permissions to perform any action. This will be a point to keep in mind in a moment when reviewing the Config and Storage view.

Config and Storage

Of all the sections, this may be the most sensitive of all. Here you can review, edit and even delete secrets and certificates. Needless to say, it is a bad idea to grant a service account rights to manage these resources unless it is strictly necessary.

Config and Storage View
Config and Storage view

If you click on the Certificate Authority link under Config Maps, you can check it for yourself.

CA Certificate
CA Certificate

Any user who has access to this certificate can grant permissions to new users. For this reason, it is a best practice to keep access to this information restricted.

Alternatives to K8s Dashboard

The advantages of having a graphical interface to visualize information and manage the Kubernetes cluster are undeniable. For this reason, teams have been building alternative Kubernetes dashboards for the past few years.

Among the two most popular options are Prometheus, which leverages the power of Grafana, and Portainer, a UI used to manage Docker containers that recently added support for Kubernetes. Each brings advantages and disadvantages depending on your specific needs.

For example, Prometheus is infinitely flexible and powerful for visualizing all kinds of data. It can adapt to many different use cases and functions, but its configuration is more complex than the native Kubernetes Dashboard.

Portainer offers an intuitive interface that, like the Dashboard, allows you to manage cluster resources. It is relatively easy to install (you can deploy it using Helm), and it adds an additional layer of software to guard against possible attacks.

Conclusion

The web-based Kubernetes dashboard is both powerful and easy to install. It’s not perfect, but it provides an alternative to the terminal for common cluster operations and status updates. The unique feature of the Dashboard is its data visualization views, which can’t be replicated in the <terminal inline>kubectl<terminal inline> command-line tool.

While you could monitor the behavior of your Kubernetes cluster using the Web UI, the absence of purpose-built alerting mechanisms means you get little actionable insights regarding your cluster’s health and performance.

This is where state-of-the-art platforms such as ContainIQ come into play. When you need an alerting and monitoring system in place for your Kubernetes cluster, ContainIQ’s pre-built dashboards provide you with the convenience of having all kinds of metrics and events at your fingertips, allowing you to stay one step ahead of potential issues.

Article by

Damaso Sanoja

Engineer

Damaso has been in the automotive/IT world since the age of 14, when his father decided to buy him a Commodore computer. Years later, his passion for electronics, computer science, and automotive mechanics motivated him to graduate in Mechanical Engineering. For years, Damaso specialized in the convergence between electronics, computers, networks, and cars. Today, Damaso is doing what he loves the most: writing engaging content as a freelance writer

Read More