Configuring and managing Kubernetes requires a lot of effort and domain expertise. From writing Kubernetes manifests to deploying and upgrading them manually every time a new change comes in, it makes your workflow more and more complex. Sooner or later, most teams end up with tools to simplify their application deployment. Helm happens to be the most adopted package manager for deploying applications on Kubernetes. Though widely adopted because it reduces the complexities of deploying applications on Kubernetes, Helm CLI has posed few challenges that we will talk about in this blog.
If you are new to helm and probably wondering about what exactly it is, have a look at the detailed breakdown on what is helm and how to build your own helm chart.
Challenges with Helm
While Helm is great at packaging Kubernetes applications, it still needs to catch up when it comes to debugging and troubleshooting applications using Helm CLI. The community currently faces some burning challenges:
- No active/real-time monitoring of Kubernetes resources with time series data - using Helm CLI just presents the current state of applications which is rarely enough for troubleshooting
- Improper grouping of resources
- Accessing the chart’s readme documentation is not seamless
- Missing unified interface for managing Helm Apps across multi-clusters
- No easy way to compare deployment values across deployments
Peripheral Challenges
Apart from the native helm challenges, there are some other issues as well which can be solved using Helm Dashboard and can help you to manage the entire team and optimize the infra costs. The other challenges are:
- No out-of-the-box support for hibernation of workloads
- Complex access management for team members
Devtron is aware of the community's difficulty with existing Helm CLI features. Considering these common problems that the community faces today with Helm CLI, we built an intuitive Helm dashboard for managing the lifecycle of Helm apps, abstracting out all the complexities and challenges. Let's take a look into the challenges and how the Devtron dashboard helps to solve those challenges.
Helm Dashboard in Devtron
Before we look out for the solution, let me grab a minute of yours. Devtron is an open-source cloud-native tool integration platform for Kubernetes. It provides an intuitive dashboard for all your Kubernetes and Helm-related challenges and enables teams to easily collaborate and work on faster delivery of applications on the top of Kubernetes.
How Devtron helps to solve all your challenges
Active Monitoring
If you are using helm CLI, there’s no real-time monitoring of your workloads. Once you deploy/install a chart using helm install repo/chart, helm status will always show you as deployed even if some of the k8s resources are missing or not deployed successfully. With Devtron’s Helm Dashboard, it becomes effortless to actively monitor all the Kubernetes Resources deployed using the Helm charts. It shows the real-time status of applications deployed through the dashboard or a terminal.
Let’s assume, you deployed a helm chart and there is some configs error in it. Unlike helm CLI, Devtron will show the status as Degraded since the chart configs were not correct. If everything was good and deployed successfully, the status will be shown as Healthy. Again if the chart is deployed, and someone deletes any k8s workload associated with it, Devtron will immediately change the status to missing.
Resource Grouping
In the official kube-prometheus-stack chart, about 174 Kubernetes resources get deployed when you install the chart. Imagine if there’s an error in any of the config files of the multiple Kubernetes resources. How difficult would it be to debug using helm CLI or just kubectl?
You would have to fire a lot of kubectl/helm commands to figure out which workload is not working. Then check out the logs, describe the pods, etc just to figure out what went wrong and all that from the terminal. But Devtron greatly simplifies that.
Devtron does the grouping of resources of all your applications and categorizes them into different buckets, which makes it easy to find the right resources while debugging. As you can see in the above screenshot, all the networking-related components are categorized under Networking (like Ingress, Service, and Endpoints), ConfigMap, secrets under Config & Storage, etc. Also, if you hover over any workload, you will get an option to check out the k8s manifest and events, check logs in real-time, and even exec into a pod for debugging directly in the Devtron UI.
Here is an additional read on a detailed understanding of debugging and logging capabilities of Devtron for Helm apps.
Referring to Chart’s Documentation In Your Workflow
If you want to try out a new Helm chart, you will use its README to check out the different parameters exposed, the values to be passed, and so forth. If using Helm CLI, it becomes a hassle to refer to README, again and again, navigate to different tabs in the browser, making typo errors or mismatched parameters and values in the process, all leading to spending more time to get the job done. With Devtron’s Helm Dashboard, you can see the chart’s README beside the values and check out the parameters, their descriptions, and values to be passed all at the same place.
Managing Helm Apps Across Multi-Clusters
One of the big pain points of using helm CLI or kubectl is that there isn’t any unified platform/dashboard to manage deployments across multi-cluster in a hybrid cloud. As seen in the above image, Devtron does it very smoothly. With Devtron’s application tab, you can easily observe and manage your deployments across multiple environments and clusters, irrespective of the cloud providers.
Deployment Values Comparison
One of the primary questions that SREs and developers ask while troubleshooting is “what changed” since the last time the application was stable? In the context of Helm, comparing value.yaml files are one of the most common workflows for all teams. Devtron’s Helm Dashboard provides a handy way to compare Helm configurations when you are dealing with an incident or troubleshooting
Hibernation of Workloads
There’s no Out-of-the-Box support for the Hibernation of workloads in Helm or raw Kubernetes. When it comes down to cost optimization, it becomes essential to consume the resources as per requirements, and especially talking about small-scale industries or startups, features like hibernation of workloads can help them save dollars just with a few clicks.
It becomes very effective for environments like non-prod or staging. With a few clicks, as shown in the image above, you can quickly scale down your workloads, not in use, and save the infra costs.
Access Management
When you use raw Kubernetes or Helm CLI, collaborating with other team members becomes a bit complex. For adding any user or upgrading any user's access, you will need to write RBAC rules every time. But Devtron significantly simplifies that. Internally it also uses RBAC, inheriting all its advantages and abstracting out the complexities by providing this intuitive user interface, as seen in the above image. You can add users just in seconds.
Devtron also has its flavor for access management and enables teams to provide access at different levels - for entire projects, environments, and even for a single application. It also comes with Group permissions wherein users can create a group of accesses, for e.g - View only access to maybe staging environment for all new joiners and add the group permissions while adding new users. Please refer to the documentation for more detailed information about fine-grained access management for helm apps.
Conclusion
The adoption of Kubernetes is increasing, and so is the usage of Helm. To ensure business agility with minimal errors in deploying Kubernetes with better management and debugging capabilities, community users can adopt the Helm Dashboard in Devtron.
As part of our commitment to open source, we will strive to improve this dashboard further. We are always looking to learn about what problems we can solve for our community. If you have suggestions or feature requests, submit them on Github.
Top comments (0)