Today, I am happy to see the public release of Helm-Dashboard, Komodor’s second open-source project, after ValidKube, and my first since joining the team as Head of Open Source. It’s a compelling challenge to try and solve the pain points of Helm users, but more than anything it’s a labor of love. So it is with love that we’re now sharing this project with the community, and I’m excited to imagine where it will go from here. Komodor has a grand vision of making Kubernetes operations and troubleshooting easy and accessible to everyone, by building tools that help to make sense of the complexity introduced by distributed cloud-native systems. Helm-Dashboard is another step in making that vision a reality. But before I dive into all the different features and use cases, let’s talk a bit about why we need a GUI for Helm in the first place. Some Background By the time Helm became a graduated CNCF project in April 2020, it was already used by 70% of Kubernetes users. Some might argue that it was Helm that opened the floodgates to the global adoption of Kubernetes, by making it remarkably easy to template, package and deploy applications without having deep knowledge of K8s. However, abstracting away the complexities under the hood created a “black box” for daily operations. The responsibility for operating and maintaining apps shifted left to developers, but doing so at scale without really understanding the underlying infra became extremely difficult. Adding to the complexity is the lack of UI, which forces Helm users to learn and execute many commands manually through the CLI. Besides being time-consuming, using the CLI makes it hard to assess the impact of deploying or rolling back Helm charts. Comparing different versions of Helm charts and their corresponding K8s resources is also a pretty inefficient process, especially when under the pressure of troubleshooting issues in production. The need for visualization and streamlined operations generated a wide ecosystem of “helper” tools like Captain, the Helm controller, Orkestra, which adds a robust dependency graph for a related group of Helm releases and their sub-charts, and Terraform Helm Provider, which enables management of Helm chart through Terraform. GitOps platforms like ArgoCD and Flux also support Helm charts via Helm hooks or the Helm SDK. As much as we love all of those projects, we felt like the ecosystem is missing a simple, yet holistic, tool dedicated to simplifying change intelligence and troubleshooting. Enter Helm-Dashboard When we looked at Helm from a product perspective, we noticed an interesting paradox: the concepts of Helm are very simple yet it’s difficult to navigate and manipulate the tool for real-life applications. In real life, apps break all the time, while business demands and SLAs require developers to fix issues on the go. But how can you fix something you don’t see? It’s akin to fixing a radio in a dark room. We figured that having a comprehensive UI would help make the very same information much more accessible and clear. The idea is to visualize the intricacies of installed charts and ease navigation through different revisions. Providing UI that is not attached to a bigger commercial product was also an important consideration, as it’s a known barrier for many users to adapt other Helm visualizers that are available on the market. Displaying a list of installed charts and their status is the obvious first capability we wanted to incorporate in the tool. Then, we allowed for the examination of revision history for the charts to get a sense of their trajectory. This alone can already provide valuable answers to many relevant questions: When was the last upgrade rolled out? How long did a revision exist before being upgraded? Were there any issues in the recent rollouts? Other popular tools like ArgoCD do not retain historical data of Helm charts, so it was a clear blindspot we needed to cover. Another part of the K8s universe relating to Helm is the actual state of Helm-created resources inside the cluster, i.e Deployments, StatefulSets, etc. K8s is stateless in nature, meaning that different pods all across the cluster can work independently with multiple requests coming to them simultaneously. The downside of this is, of course, that it requires even more CLI commands and manual investigations to get a clear understanding of the relations and dependencies between Helm charts and K8s resources. When troubleshooting or even just examining your system, understanding changes and comparing diffs is key. With bare Helm it would take at least five different command invocations to understand what actually changed in the K8s manifests following each Helm revision. We wanted to make it super easy and quick to comprehend using Helm-Dashboard. Or, to paraphrase Michelle Noorali, “zero to dopamine in two clicks”. Viewing diffs is only part of the picture, though. As developers, we want to take immediate action as soon as we uncover the problem. To complete the picture we needed to provide the ability to easily rollback and upgrade charts to any existing version, or to uninstall the chart altogether with a single click of the button. All while comparing the various charts and their corresponding K8s resources to give users a clear expectation of what the results of those actions may be. Probably the most important piece of functionality that the UI provides is the preview of manifest changes during upgrading or reconfiguring the chart. This way you don’t have to guess what will change in your K8s cluster following an upcoming chart upgrade. Instead you can see the exact diff right before pressing the “Confirm Upgrade” button. Getting Started Helm-Dashboard runs using your local Helm and Kubectl configuration. No additional setup is required. To install Helm-Dashboard, simply run this Helm command: helm plugin install https://github.com/komodorio/helm-dashboard.git After installing, start the UI by running: helm dashboard The command above will launch the local Web server and will open the UI in a new browser tab. Conclusion Just to be clear, we still love Helm and don’t plan on replacing it or even having a full feature parity with Helm CLI. We did want to cover the mainstream functionality and most common use-cases, so that only the most severe issues would require using Helm CLI manually, and that would be reserved for the more seasoned DevOps or SRE folks. I feel like this is only the beginning of a wonderful open source journey that will bring along many novice and veteran Helm users. We already have some integrations in place, to provide you with additional capabilities, and hopefully it will inspire community members to integrate more useful tools. For instance, security and vulnerability scans are also valuable assets to improve Helm operations and overall reliability, so we’ve integrated two tools we all know and love; Trivy by Aqua Security and Checkov by Bridgecrew. As I’ve mentioned earlier, we’re releasing Helm-Dashboard to the community with love, and I invite everyone to check it out, contribute, open issues, suggest improvements, or create content around it. You are more than welcome to join our vibrant Slack Kommunity, where you can meet fellow Kubernauts and take a more active part in this and other projects. In the project’s repo you can already find a list of possible issues and a tentative roadmap for the future. [komodor_banner name="helm-banner" layout="horizontal"]
