Table of Contents
Octant is one of the best-known tools in the Kubernetes dashboard space. It’s a project that Bryan Liles built a lot of back when he was at Heptio. I remember Bryan talking on Twitter about a new tool he was working on that would help folks think about what was running in their Kubernetes clusters, and that was Octant. VMWare acquired Heptio after that, and now Bryan and Octant are both at VMWare.
Previously in this series, I looked at Lens and Headlamp, and I should say that Octant feels pretty different than those other tools. According to the Octant docs, it’s not a Kubernetes dashboard but “a platform that ships with a dashboard view.” I think that’s a fair characterization. Octant is highly extensible, and the docs say that it provides “the ability to easily extend [it] to create custom developer experiences around resources in the Kubernetes cluster.”
Bryan gave a fantastic keynote at KubeCon San Diego in 2019. He talked about complexity in Kubernetes and how we need to be thoughtful about how much of that complexity we expose to users. It’s clear he’s thought a lot about the fact that people of different experience and knowledge levels interact with and operate Kubernetes clusters, and teams have different needs.
Installation
Octant ships as a Go binary. If you run it with no arguments, it opens a window in your default web browser for the Octant web UI. The Octant roadmap doc mentions that the team would like to provide a standalone UI at some point, but I think this setup works fine. The Octant CLI allows some additional arguments to do things like open the UI to a specific namespace. You can see the CLI options by running `octant -h`.
The Octant UI
By default, Octant opens to the namespace view of the kube-system namespace.
If you’ve seen the previous posts about Lens and Headlamp, you’ll probably notice that this looks pretty different. Those other two tools have a cluster overview and sections of resources like workloads, networking, configMaps/secrets, etc. Resources in Octant seem to be grouped more by their functions, not resource types. Like “Discovery and Load Balancing” is not a category I’ve seen in other tools.
One thing I did miss from some other tools is the ability to select multiple namespaces to view simultaneously. There’s a pulldown menu at the top where you can select a namespace, but it looks like you can only select one. I sometimes find it handy to view multiple namespaces that may be related or all namespaces except kube-system.
The Applications category on the left menu shows some metrics about your workloads. The metrics were populated out of the box for me using Google Kubernetes Engine (GKE), which is nice.
Drilling into one of the workloads shows this super cool resource viewer.
The pod is at the top level, and the resources it depends on are stacked below. I love this kind of visualization. It can make it very clear how things relate to each other, and I think this could be especially useful for folks who are newer to Kubernetes and may not understand how all of those objects interact.
The Cluster Overview section is a great way to see what’s happening in the cluster at a high level.
You can just scroll down that page and see the resources in the cluster listed by type.
Editing Objects
As we’ve discussed in previous posts in this series, editing objects in a UI like Octant won’t be a recommended workflow for most teams managing production Kubernetes clusters. Typically teams will be using GitOps or other tools like Terraform or Pulimi, and making changes out-of-band in Octant will be very problematic. But if you’re using Octant to view a development cluster, or to do POCs, or just to learn about Kubernetes, making changes in the UI could be helpful for those kinds of use cases.
In my GKE cluster, I had a pod that wouldn’t start because of a lack of CPUs. When I drilled into the pod resource, I was able to see the resource viewer, which, again, I find very handy.
It’s pretty clear from the resource map that the deployment is the object I need to look at.
When I click into that and go to the YAML tab, I can take several actions.
There’s a Delete button in the upper right corner where I could just delete the deployment completely. I could also edit the YAML to change the number of replicas if I wanted and then hit the Update button. Or, on every screen of Octant, there’s an Apply YAML link near the top of the screen, where I could load in an updated YAML file with the new settings I want. I could see using that during development when I’ve made changes to the YAML file and want to validate that it works correctly before committing it to the Git repository. That’s a place where I think Octant would fit very well in a GitOps workflow, pre-commit.
One thing I really appreciate about the YAML screen is the Reset button in the lower right corner. If you’re making changes to the YAML directly but mess something up before applying it, hitting Reset will pull back in the YAML for the running object in the cluster. I make more than my share of typos, and I could also see situations where someone isn’t sure about their change and wants to go back to the running version. This is such a small thing in the UI, but it shows that the folks designing Ocatant understand operating clusters and are thinking about the users.
Extensibility
As we discussed, one of the main goals of Octant is to be a highly customizable platform. That customization is done through plugins.
Octant plugins are written in Go, and there’s a sample plugin on GitHub that you can look at. The plugin docs seem great too.
Unfortunately, it looks like there are not many shared plugins that folks in the community have written. The page in the docs that’s supposed to list the known plugins is empty, and looking through Google I only found one, a plugin for Starboard from Aqua Security.
But even without a large number of plugins available, it’s still comforting to know that it’s possible to extend it. Many teams run into edge cases where a tool doesn’t meet their needs, and extending tools is super helpful.
Conclusion
As you can probably tell, I like Octant. Calling a tool a platform can feel like a marketing gimmick at times, but I think that’s a pretty legit claim with Octant. It’s a very powerful tool, and I think teams looking at Kubernetes dashboards should have it in their list to evaluate.
When I compare Octant to the other dashboards I’ve written about, Lens and Headlamp, it stacks up very well. I think it had the best performance of all three tools, running on my Macbook Pro against a GKE cluster. It’s fast to start up, and I never felt like it was lagging. The UI is very friendly and I don’t mind that it’s not standalone. I also really like the way they’ve grouped the different types of resources in the UI. It’s different from the other tools I’ve seen in the space and seems very functional.
In terms of the actual design, I think Headlamp probably wins for me. I think it’s a bit more fun visually. But I do like Octant’s design too.
Next up, I’ll be writing about the official Kubernetes Dashboard. Are there other dedicated Kubernetes dashboards you’d like to see in the series? Leave a comment below, or you can at me on Twitter.
