Home » Author » Simon » Project Octant – Graphical User Interface for Kubernetes

Project Octant – Graphical User Interface for Kubernetes

Project Octant – Graphical User Interface for Kubernetes

By introducing new layers of abstraction through kubernetes, it is possible that this comes with additional complexity. Project Octant is a useful tool to add to the arsenal when trying to navigate how resources within a kubernetes cluster hang together, to describe kubernetes clusters in a manner that is perhaps more friendly to existing operation teams.

Octant is a tool for developers to understand how applications run on a Kubernetes cluster. It aims to be part of the developer’s toolkit for gaining insight and approaching complexity found in Kubernetes. Octant offers a combination of introspective tooling, cluster navigation, and object management along with a plugin system to further extend its capabilities.

Getting Started with Project Octant

Getting started couldn’t be much more straight forward.  From the github page for the project there is a link to the releases location where you can download the prepackaged binaries for your operating system (you can also use chocolatey, scoop, brew if you desire).  Once downloaded extract to your binary directory or working location.  The environment I’ve got access to for this is running windows, as you can see I’ve got a few other tools in this directory.

Octant needs to be run from a terminal so launch a cmd prompt from your working location.  Authenticate to the cluster you wish to inspect, switch to your desired context and and launch octant.  The process will start listening on localhost:7777, which you can access with your favourite browser.  The vSphere supervisor cluster is not aware of the namespaces running within the Tanzu Kubernetes Clusters, so authenticate against the cluster that you want to see the information for.

The UI is very intuitive and allows you to click between namespaces, contexts and the resources with ease.  Displaying pertinent information at every step.  IN the example below I’ve logged into the supervisor cluster selected the namespace for the vSphere container registry and selected the pods resource.

One of the killer features here is that it allows me as an administrator to view and search through the logs for the pods.  Brilliant, as it saves hours of looking through logs in a terminal with grep.

For providing visibility for troubleshooting this is beyond cool!  The octant session only lives as long as the process is running so to exit is a simple ‘ctrl-c’

If I want to view my Tanzu Kubernetes Clusters, the process is exactly the same.  I use ‘kubectl-vsphere’ to login to my TKG cluster and launch octant.  From there again I can browse through the resources and namespaces associated with the cluster.

NOTE: Interestingly logging into the TKG cluster with an appropriately privileged  SSO account does grant you permissions to inspect the supervisor cluster.  I authenticated as “administrator@vsphere.local” so had permissions at the higher context.  If I login as a user with lower permissions I can see the supervisor cluster context but no resources within it.  Using the vSphere client to add edit permissions to an SSO account in the namespace of the TKG cluster, information available to that user is also limited.  I suspect to see full information in octant the user would need to be bound to a cluster role of ‘cluster-admin’ of ‘psp:vmware-system-privileged’.

If the log feature wasn’t killer enough as I have elevated permissions in TKG vs the supervisor cluster, so I can run a terminal to the pod!

It is a little hard to see from the above image but what I’m demonstrating is logging into the pod terminal, launching a bash shell, changing directory to ‘/var/log/’ and then running ‘cat dpkg.log’ to view the log file.  Not very interesting for a wordpress installation but what about the backend MariaDB?

Again I can connect into the terminal launch bash and authenticate to the DB.  Obviously the tools that are available are limited by what is in the pod image itself (which is why busybox somewhere in the estate is probably a good idea).


Devilishly simple to get working, but something that could and huge value and improve the troubleshooting experience.