In addition to the command-line utility, there is a dashboard that aggregates almost all the information we just discussed and displays the data in a decent web UI:

This is actually a general purpose graphical user interface of a Kubernetes cluster as it also allows us to create, edit, and delete resources. Deploying it is quite easy; all we need to do is apply a template:

$ kubectl create -f  https://raw.githubusercontent.com/kubernetes/dashboard/v1.10.0/src/deploy/recommended/kubernetes-dashboard.yaml

Many managed Kubernetes services, such as Google Kubernetes Engine (GKE), provide an option to pre-deploy a dashboard in the cluster so that we don't need to install it ourselves. To determine whether the dashboard exists in our cluster or not, use kubectl cluster-info. If it's installed, we'll see the message kubernetes-dashboard is running at ... as shown in the following:

$ kubectl cluster-info
Kubernetes master is running at https://192.168.64.32:8443
CoreDNS is running at https://192.168.64.32:8443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
kubernetes-dashboard is running at https://192.168.64.32:8443/api/v1/namespaces/kube-system/services/kubernetes-dashboard/proxy


To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.

The service for the dashboard deployed with the preceding default template or provisioned by cloud providers is usually ClusterIP. We've learned a bunch of ways to access a service inside a cluster, but here let's just use the simplest built-in proxy, kubectl proxy, to establish the connection between our Terminal and our Kubernetes API server. Once the proxy is up, we are then able to access the dashboard at http://localhost:8001/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy/. Port 8001 is the default port of the kubectl proxy command.

The methods to authenticate to the dashboard vary between cluster setups. For example, the token that allows kubectl to access a GKE cluster can also be used to log in to the dashboard. It can either be found in kubeconfig, or obtained via the one-liner shown in the following (supposing the current context is the one in use):

$ kubectl config view --minify -o 
 jsonpath={.users[].user.auth-provider.config.access-token}

If we skip the sign in, the service account for the dashboard would be used instead. For other access options, check the wiki page of the dashboard's project to choose one that suits your cluster setup: https://github.com/kubernetes/dashboard/wiki/Access-control#authentication.

As with kubectl top, to display the CPU and memory stats, you'll need a metric server deployed in your cluster.