[Kubernetes, kubernetes dashboard]

The Ultimate Guide to the Kubernetes Dashboard: How to Install, Access, Authenticate and Add Heapster Metrics

Kubernetes Dashboard is the official web-based UI for Kubernetes. In this deep dive into the Kubernetes Dashboard, we will go through the process of installing, accessing and authenticating the Dashboard as well as adding basic resource metrics via Heapster.

Hasham Haider

Hasham Haider

April 12, 2019

11 minute read

Kubernetes dashboard is the official web-based UI for Kubernetes. The dashboard provides an overview of the Kubernetes cluster as well as the individual resources running in it. As such it is an important piece of the Kubernetes puzzle allowing DevOps and Kubernetes administrators to view and manage the monitoring and operational aspects of their Kubernetes clusters. Following is an exhaustive list of the functionality provided by the dashboard:

  • Overview of the Kubernetes cluster
  • Deploy applications onto your Kubernetes clusters
  • Get an overview of the applications running
  • Troubleshoot those applications
  • Get an overview of the resources running in the cluster
  • Create, modify, update and delete Kubernetes resources
  • Information about the state of the Kubernetes resources running in the cluster
  • Basic resource metrics including resource usage for individual Kubernetes objects

We will take a closer look at each of these functionalities as we review the dashboard. But first, let’s go through the process of installing the Kubernetes dashboard. 

Install Kubernetes Dashboard using Kubectl

We assume that you already have a Kubernetes cluster up and running and have installed Kubectl. Deploy the Kubernetes dashboard using Kubectl:

kubectl create -f https://raw.githubusercontent.com/kubernetes/dashboard/master/aio/deploy/recommended/kubernetes-dashboard.yaml

Alternatively, we can also deploy the dashboard by saving this yaml code into a file locally and using kubectl create: 

kubectl create -f kubernetes-dashboard.yaml

Running the Kubectl command creates both the Kubernetes dashboard service and deployment. It also creates a default service account, role, role binding and secret for the dashboard: 

kubectl-kubernetes-dashboard

Looking to launch Kubernetes in Production? Download the Complete Production-Readiness Checklist with Checks, Recipes and Best Practices for Resource Management, Security, Scalability and Monitoring

Download Checklist

Access Kubernetes Dashboard using Kubectl

Once we create the dashboard we can access it using Kubectl. To do this we will spin up a proxy server between our local machine and the Kubernetes apiserver.

Kubectl proxy

Kubectl proxy is the recommended way of accessing the Kubernetes REST API. It uses http for the connection between localhost and the proxy server and https for the connection between the proxy and apiserver.

We can access the Kubernetes dashboard UI by browsing to the following url: 

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

Opening this url will take us to the account authentication page for the Kubernetes dashboard. To get access to the dashboard, we need to authenticate our account. As mentioned earlier, running the Kubectl command does create a default service account as well as a role and role binding for the dashboard. You can access the dashboard using the token from the default service account. However to cover the authentication process in more detail let's create a service account from scratch and also attach a larger set of permissions to it.

Kubernetes Dashboard Authentication

There are two options to authenticate our Kubernetes dashboard account; using either the token or the kubeconfig method. For the purposes of this tutorial, we will use the token authentication method.

The token authentication method requires us to create a new service account for the Kubernetes dashboard. We will bind this service account to the cluster-admin role, which will give us access to all Kubernetes resources on the dashboard. We can then use the bearer token for the service account to log in to the dashboard.

Create the dashboard service account

kubectl create serviceaccount dashboard-admin-sa

This will create a service account named dashboard-admin-sa in the default namespace

Next bind the dashboard-admin-service-account service account to the cluster-admin role

kubectl create clusterrolebinding dashboard-admin-sa --clusterrole=cluster-admin --serviceaccount=default:dashboard-admin-sa

When we created the dashboard-admin-sa service account Kubernetes also created a secret for it.

List secrets using:

kubectl get secrets

kubectl-get-secrets-kubernetes-dashboard

We can see the dashboard-admin-sa service account secret in the above screenshot above.

Use kubectl describe to get the access token:

kubectl describe secret dashboard-admin-sa-token-kw7vn

kubectl-describe-secret-kubernetes-dashboard

Copy the token and enter it into the token field on the Kubernetes dashboard login page.

We can now access the Kubernetes dashboard and will land on the overview page for the default namespace. 

The Kubernetes dashboard has four main sections;

  • Cluster
  • Workload
  • Discovery and Load Balancing and
  • Config and Storage

Let's go though a quick overview of each of these sections.

Cluster View

The Cluster view has five sub-views including Namespaces, Nodes, Persistent Volumes, Roles and Storage Classes. Clicking on any one of the subviews will take us to the overview UI for that subview. Let’s take a closer look at some of these subviews.

Namespaces:

The Namespace subview shows us an overview of all the Namespaces in the cluster. This is what the Namespace subview on the Kubernetes dashboard looks like:

kubernetes-dashboard-namespace-subview

Clicking on a Namespace will take us to the individual view for that Namespace. As of now this individual view only shows recent events. We can access more Namespace specific information in the Overview, but more on that later.

kubernetes-dashboard-individual-namespace-view

Nodes:

Clicking on the Node subview will take us to the overview page for Nodes listing all Kubernetes nodes in the cluster. The overview page outlines the labels and Status as well as the CPU and memory requests and limits for each individual Node.

kubernetes-dashboard-node-overview

Clicking on an individual node will take us to the detailed information page for that Node. This page is divided into sections and is chock full of information about the Node, from the addresses and Machine ID to allocated resources, conditions, pods and events.

The details section outlines basic information about the node from the Name and labels to the kubelet version, kube-proxy version and the operating system and provider ID.

kubernetes-dashboard-node-details

Next we have the allocated resources section. It has 3 views; CPU allocation, Memory allocation and Pod allocation. The CPU and memory allocation views show us the CPU and Memory capacity of the Node as well as the total CPU requests and limits for all pods running on that node. These numbers are provided both in absolute terms as well as percentages. For example CPU requests are 0.64 cpu or 64% of the total capacity of the node which is 1 cpu. Similarly Memory limits are 690 MiB or 18.62% of the total capacity of the Node i.e 3.619 GiB.

The pod allocation view displays the total number of pods that the Node can accommodate i.e. 110 as well as the number currently running ie. 29 or 26.36% of the total capacity.

kubernetes-dashboard-node-allocated-resources

Next is the Node conditions section. Node conditions describe the status of a Node. Node conditions include OutOfDisk, Ready, MemoryPressure, PIDPressure, DiskPressure and NetworkUnavailable which can be either True or False. 

kubernetes-dashboard-node-conditions

The fourth section is Pods which groups together all the pods that belong to that Node and shows information about the Namespace it is running in and its status. Clicking on the individual pod will take us to the details page for that individual pod. We will take a closer look at this in the Namespace main view. 

We also have the Persistent Volumes, Roles and Storage Class subviews in the cluster section which display information related to each of these Kubernetes objects.

Let’s now move on to the Workload, Discovery and Load Balancing and Config and Storage sections on the main Kubernetes dashboard. We can toggle between individual Namespace views for all these sections as well as an aggregated view for all Namespaces.

The Overview section also aggregates the most important Kubernetes objects from all these sections. These include workload status, deployments, Pods, ReplicaSets, Services, Config Maps and secrets.

Workloads View

The workload section provides an overview of all the applications running in our cluster. These include Deployment, Pods, ReplicaSets as well as other Kubernetes controllers. Let’s take a closer look at the Pods sub-section.

Clicking on the Pods subsection will take us to the overview page for all pods running in the cluster. The overview page outlines all necessary information for each individual pod including the Namespace and Node it is running on as well as the Status and Number of restarts. 

kubernetes-dashboard-pods

Clicking on the the individual Pod will take us to the detailed Pod overview. The Pod overview shows us detailed information about the Pod including the labels attached, status and QoS class. You will also be able to see the containers that belong to the pod, Pod condition, the controller that created that Pod, Pod events and Persistent Volume Claims.

In the same way we can get detailed information about the other Kubernetes objects that are part of the Workloads section. 

Discovery and Load Balancing

Next Up we have the Discovery and Load Balancing section. This section has two Kubernetes objects; Services and Ingresses. The services section outlines the most important information about each service including the Namespace it belongs to, the labels attached and the Cluster IP.

Clicking on any one of the individual services will take us to the individual Service overview, where we can see the type of service, the Label Selectors as well as a list of the pods, endpoints and events for that service.

kubernetes-dashboard-services-view

Config and Storage

The Config and Storage section contains information about Config Maps, Persistent Volume Claims and Secrets.

The persistent volume claims section provides information about all PVCs in the cluster including the status, volume, capacity, access mode and storage class.

kubernetes-dashboard-persistent-volume-view

The detailed PVC section for each individual PVC also shows us more information about the PVC including the labels and annotations attached, the namespace it is provisioned in and the capacity.

kubernetes-dashboard-individual-persistent-volume

Now that we have an overview of the Kubernetes dashboard, let’s see how we can add basic resource metrics like resource usage to the dashboard.

Adding Heapster Metrics to the Kubernetes Dashboard

The Kubernetes dashboard currently supports resource metrics integration via Heapster. A word of caution before we move on though; Heapster is currently being deprecated in favor of metrics server. Support for metrics api is being actively worked on by the Kubernetes community as part of the v2 dashboard launch. You can also consider setting up a resource monitoring pipeline for your Kubernetes cluster using third party tools like Prometheus and Grafana both of which we have covered in previous posts.

Alright, let’s now move on to installing Heapster in our Kubernetes cluster. We will be installing heapster using Helm. We have already covered Helm installation in one of our previous blog posts. Here is quick recap:

Head over here and download the latest version.

Unpack it:

tar -zxvf helm-v2.13.1-darwin-amd64.tar.gz

Move it to your bin directory:

mv darwin-amd64/helm /usr/local/bin/helm

Initialize helm and install tiller:

helm init

Create a service account:

kubectl create serviceaccount --namespace kube-system tiller

Bind the new service account to the cluster-admin role. This will give tiller admin access to the entire cluster:

kubectl create clusterrolebinding tiller-cluster-rule --clusterrole=cluster-admin --serviceaccount=kube-system:tiller

Deploy tiller and add the line serviceAccount: tiller to spec.template.spec:

kubectl patch deploy --namespace kube-system tiller-deploy -p '{"spec":{"template":{"spec":{"serviceAccount":"tiller"}}}}'

Now we are ready to install Heapster:

helm install --name heapster stable/heapster --namespace kube-system

Once the installation is complete, browse back to the Kubernetes dashboard and click on Nodes in the Cluster section.

Kubernetes-dashboard-node-heapster-resource-usage

We can see both the CPU Usage and Memory Usage graphs on the dashboard. These are the aggregated CPU and memory usage metrics for all Pods belonging to the cluster.

Click on anyone of the Nodes to see individual CPU Usage and Memory metrics for that Node. This will show us the aggregated CPU and Memory usage for all the pods running on that Node.

Kubernetes-dashboard-node-heapster-resource-usage-1

Similarly we can see the CPU and Memory usage for other Kubernetes objects too.

CPU and Memory Usage for individual Deployments:

Kubernetes-dashboard-deployments-heapster-resource-usage

CPU and Memory Usage for individual Pods:

Kubernetes-dashboard-services-heapster-resource-usage

Conclusion

In this blog post we took a deep dive into the Kubernetes dashboard. We started by looking at the functionality provided by the dashboard and then covered the topics of installation, deployment and authentication. Finally we outlined the process of integrating resource metrics into the dashboard by installing Heapster.

Heapster is a handy tool for performing cluster monitoring and performance analysis. It also gives us access to basic resource metrics in our Kubernetes cluster. However the fact that it has been deprecated and support for metrics server is still in the works means that it is a good time to start thinking about alternatives.

One alternative to resource monitoring via the Kubernetes dashboard is to setup an alternative resource monitoring pipeline using tools like Prometheus and Grafana. Prometheus and Grafana together give us access to more in-depth resource metrics for clusters as well as individual Kubernetes objects. These are however, still restricted to native Kubernetes objects.

Replex's Kubernetes solution drives visibility into resource usage metrics for both native Kubernetes abstractions as well as custom groupings like teams, clients and applications. It also puts a dollar number on this resource usage by co-relating usage with the costs of the underlying infrastructure. This drives cost transparency and accountability and allows granular cost insights into Kubernetes deployments.

Replex also helps teams optimize resource usage of their Kubernetes deployments by collecting and analyzing historical and real-time usage and utilization metrics. collects and analyzes usage and utilization metrics in real-time and provides actionable intelligence on optimizing them. On average, this translates into cost savings of up-to 30% across clients using a wide range of infrastructure variants from public cloud to multi and hybrid cloud.

Looking to launch Kubernetes in Production? Download the Complete Checklist with Checks, Recipes and Best Practices for Resource Management, Security, Scalability and Monitoring for Production-Ready Kubernetes

Download Checklist

 

Hasham Haider

Author

Hasham Haider

Fan of all things cloud, containers and micro-services!

Want to Dig Deeper and Understand How Different Teams or Applications are Driving Your Costs?

Request a quick 20 minute demo to see how you can seamlessly allocate Kubernetes costs while saving up to 30% on infrastructure costs using Replex.

Schedule a Meeting