Now, let's take a look at the Grafana dashboard. In our case, for the minikube-booted cluster, we should open a proxy to enable accessibility from the localhost to the Kubernetes cluster:
$ kubectl proxy
Starting to serve on 127.0.0.1:8001
You may access Grafana through this URL: http://localhost:8001/api/v1/namespaces/kube-system/services/monitoring-grafana/proxy/. The magic that enables us to see the web page is made by the Kubernetes DNS server and proxy:
Accessing the Grafana dashboard in an anti-minikube Kubernetes
To access Grafana through a browser, it depends on the network configuration of nodes and the Kubernetes service of Grafana. Follow these points for forwarding the web page to your client:
- Upgrade Grafana's service type: The configuration file we applied creates Grafana with a ClusterIP service. You should change it to NodePort or LoadBalancer for exposing Grafana to the outside world.
- Check firewalls: Make sure your clients or load balancer are able to access your node of the cluster.
- Dashboard access through the target port: Instead of using a detailed URL, like we did on the minikube cluster, you can access Grafana with simple ones such as NODE_ENTRYPOINT:3000 (Grafana requests port 3000 in the configuration file by default) or the entry point of the load balancer.
In the default settings of Grafana, we have two dashboards, Cluster and Pods. The Cluster board covers the nodes' resource utilization, such as CPU, memory, network transaction, and storage. The Pods dashboard has similar plots for each Pod and you can check each container in a Pod:
As the preceding screenshot show, for example, we can observe the CPU utilization of individual containers in the Pod kube-dns in the namespace kube-system, which is the cluster of the DNS server. You can find that there are three containers in this Pod, kubedns, dnsmasq, and sidecar, and the lines in the plot express the limit, request, and real usage of CPU for containers respectively.