Komodor is a Kubernetes management platform that empowers everyone from Platform engineers to Developers to stop firefighting, simplify operations and proactively improve the health of their workloads and infrastructure.
Proactively detect & remediate issues in your clusters & workloads.
Easily operate & manage K8s clusters at scale.
Reduce costs without compromising on performance.
Empower developers with self-service K8s troubleshooting.
Simplify and accelerate K8s migration for everyone.
Fix things fast with AI-powered root cause analysis.
Explore our K8s guides, e-books and webinars.
Learn about K8s trends & best practices from our experts.
Listen to K8s adoption stories from seasoned industry veterans.
The missing UI for Helm – a simplified way of working with Helm.
Visualize Crossplane resources and speed up troubleshooting.
Validate, clean & secure your K8s YAMLs.
Navigate the community-driven K8s ecosystem map.
Your single source of truth for everything regarding Komodor’s Platform.
Keep up with all the latest feature releases and product updates.
Leverage Komodor’s public APIs in your internal development workflows.
Get answers to any Komodor-related questions, report bugs, and submit feature requests.
Kubernetes 101: A comprehensive guide
Expert tips for debugging Kubernetes
Tools and best practices
Kubernetes monitoring best practices
Understand Kubernetes & Container exit codes in simple terms
Exploring the building blocks of Kubernetes
Cost factors, challenges and solutions
Kubectl commands at your fingertips
Understanding K8s versions & getting the latest version
Rancher overview, tutorial and alternatives
Kubernetes management tools: Lens vs alternatives
Troubleshooting and fixing 5xx server errors
Solving common Git errors and issues
Who we are, and our promise for the future of K8s.
Have a question for us? Write us.
Come aboard the K8s ship – we’re hiring!
Hear’s what they’re saying about Komodor in the news.
Package management is not a new concept. In Linux, package managers like YUM, RPM, or APT are essential for installing and removing packages. Node.js developers rely heavily on NPM, the Node Package Manager (NPM), which has thousands of packages that can do virtually anything in a Node.js environment.
Helm is a package manager for Kubernetes that enables you to automate YAML manifests for Kubernetes objects, packaging information into charts and deploying to a Kubernetes cluster. It tracks the versioned history of each chart installation and change, allowing you to use simple commands to roll back to a previous version or upgrade to a newer one. It also makes it easy to install popular applications to Kubernetes via community-shared Helm charts.
You can leverage Helm to more easily deploy and test an environment, increasing productivity and reducing the time it takes to transition from testing to production. Additionally, Helm can help you simplify and automate the process of sending applications to end users for installation.This is part of a series of articles about Kubernetes architecture.
Helm operates by defining and managing charts, which are packages of pre-configured Kubernetes resources. When a chart is deployed, Helm communicates with the Kubernetes API to create and manage the defined resources within the cluster. A file called ‘values.yaml’ provides variables needed to correctly deploy specific resources.
[this is a copyrighted image, do not use it as is. We recommend rebuilding with your graphic designer. Change text as follows:
A Helm chart is a collection of files that describe a related set of Kubernetes resources. This includes:
By packaging Kubernetes manifests into a chart, Helm simplifies the deployment and management of applications. Charts can be shared and reused, promoting consistency and reducing duplication of effort.
Related content: Read our guide to Kubernetes helm charts.
A Helm chart repository is a collection of Helm charts that are made available for installation. These repositories can be public or private and are often hosted on platforms like GitHub or dedicated Helm repository services.
Repositories are defined by an index.yaml file, which lists the available charts and their versions. Users can add repositories to their Helm client using the helm repo add command and then install charts from these repositories with helm install. Public repositories, such as the Helm stable and Helm incubator repositories, provide access to a wide range of community-maintained charts for popular applications and services.
Itiel Shwartz
Co-Founder & CTO
In my experience, here are tips that can help you better work with Kubernetes Helm:
Leverage Helm’s conditional logic to create more flexible and dynamic charts. For example, use the if, else, and with statements to conditionally include resources or configuration settings based on the values provided.
if
else
with
Always version your Helm charts properly and use semantic versioning. This makes it easier to manage dependencies and ensure compatibility with different versions of your applications.
Maintain separate values.yaml files for different environments (e.g., development, staging, production). This allows you to tailor configurations for each environment without modifying the base chart.
values.yaml
Implement Helm hooks to manage complex lifecycle events, such as pre-install, post-install, pre-upgrade, and post-upgrade. This enables you to perform custom tasks at specific stages of the Helm chart deployment process.
Use tools like helm unittest or chart-testing to write tests for your Helm charts. Automated testing helps ensure that your charts deploy correctly and behave as expected across different environments.
helm unittest
chart-testing
The Helm client is the primary user interface for Helm. It provides the command-line interface (CLI) used to execute Helm commands, such as installing, upgrading, or rolling back charts. The Helm client interacts with the Helm library to process charts and manage releases. It also communicates with the Kubernetes API server to deploy and manage resources in the cluster.
The Helm library contains the core logic for Helm. It handles the rendering of templates, the management of releases, and the communication with the Kubernetes API. The Helm library is responsible for the following tasks:
At a high level, Helm charts and Kubernetes operators do almost the same thing, but adoption varies based on different criteria such as cluster adoption, team maturity, and application requirements.
How are Helm charts used?
For teams that are just starting to run Kubernetes clusters and want to provide simple applications to their users, packaging these applications with Helm charts has the advantage of simplifying template YAML manifests. Helm charts enable IT operations teams to quickly deliver applications by packaging, versioning, and sharing them, together with their dependencies.
To create Helm charts, you need to be familiar with YAML and use the Go templating engine and the Sprig template library.
Helm charts are often most useful when first setting up a Kubernetes cluster to deploy a simple application. They can handle the full life cycle of installing, updating, and uninstalling applications deployed on a cluster.
How are Operators used?
As your team and your use of Kubernetes clusters mature, you may be facing day-to-day tasks and complex requirements to run your applications. This is where the IT operations team needs to add Kubernetes operators to the mix. Writing Kubernetes operators also means the team needs to maintain this code base over time.
Operators are useful for teams implementing complex custom configurations or deploying specialized applications that require significant operational expertise.
To install Helm on your local machine, you will need to download the Helm binary and add it to your PATH. The easiest way to do this is to use the Helm installer script:
curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3
chmod +x get_helm.sh
./get_helm.sh
This will install Helm and add it to your PATH. You can then use the helm command to interact with your cluster.
helm
To install a chart using Helm, you will first need to add a chart repository. A chart repository is a collection of charts that you can install from. You can add the official Helm chart repository by running:
helm repo add chartmuseum http://localhost:8080
This will add the “stable” chart repository to your list of repositories. You can then search for charts in this repository by running:
helm search repo stable
This will list all the available charts in the stable repository. To install a chart, use the helm install command and specify the name of the chart and the release name (a unique name for this instance of the chart):
helm install
helm install myrelease stable/mysql
This will install the MySQL chart and create an instance of the application called “myrelease”. Helm will take care of creating all the necessary Kubernetes resources and deploying the application on your cluster.
You can also install a chart from a local directory by using the helm install command and specifying the path to the chart directory:
helm install chartmuseum/mychart --generate-name
This will install the chart from the local directory and create an instance of the application called myrelease.
myrelease
Like any new tool, Helm has a learning curve. Creating and deploying your first Helm chart isn’t easy. Charts also create additional code that needs to be managed and handled. This includes the overhead of managing, maintaining, and storing Helm chart repositories. For simple deployments, Helm might be overkill.
It is, of course, possible to use Helm charts maintained by others. But you need to be sure these Helm charts are well tested and contain only safe components, with no security vulnerabilities.
Keep in mind that applications using many Kubernetes resources can be difficult to troubleshoot using Helm, because you have reduced visibility over individual components.
Helm shapes resource files using Go templates. Go provides several built-in functions, but you can add others. For example, you can add the functions from the Sprig library (although you should avoid expandenv and except env for security reasons. Other useful functions are required and include, which lets you import another template and forward the results to another template function.
expandenv
except env
required
include
For instance, the following template snippet uses the include function to bring in the extpl template, convert the result to uppercase, and wrap it in double quotations.
extpl
value: {{ include "extpl" . | upper | quote }}
You can use the required function to declare specific value entries needed to render the template. The template rendering fails if the value is empty.
For example, the following required function provides an entry for the .Values.who element and prints an error message if the required entry is missing:
.Values.who
value: {{ required "A valid .Values.who entry required!" .Values.who }}
YAML has type coercion rules that can be counterintuitive. For instance, there is a difference between foo: false and foo: "false". In some cases, large integers are converted to scientific notations.
foo: false
foo: "false"
The easiest way to prevent type conversion errors is to make strings explicit while other elements remain implicit—i.e., quoting every string.
It is often useful to store integers as strings to avoid integer casting problems—use the {{ int $value }} element in the template to convert strings back to integers. Usually, the system will respect explicit type tags, i.e., foo: !!string 3287 treats 3287 as a string. However, the YAML parser will consume the tag, meaning you lose the type data after a single parse.
{{ int $value }}
foo: !!string 3287
Labels are important for the internal operations of Kubernetes—almost all Kubernetes resources offer labels for specific purposes like grouping, load balancing, resource allocation, and scheduling.
You can use one Helm command to install several resources, but you need to know where each resource originates. Labels allow you to find the resources created by a Helm release quickly.
The most common way to define labels is in the helpers.tpl element:
helpers.tpl
{{/* My labels */}} {{- define "my.labels" -}} app.kubernetes.io/instance: {{ .Release.Name }} app.kubernetes.io/managed-by: {{ .Release.Service }} {{- end -}}
You must then use the include function for labels in each resource template:
apiVersion: apps/v1 kind: Deployment metadata: name: my-queue labels: {{ include "my.labels" . | indent 4 }}
Now, you can list all the resources using label selectors. For instance, you can use the following command to list all the pods in the my-queue deployment:
kubectl get pods -l app.kubernetes.io/instance=[Helm Release]
This step allows you to locate and debug the Helm-managed resources.
Kubernetes stores sensitive data like passwords and keys as secrets. While you can secure secrets on Kubernetes’ side, storing them as text files in Helm templates and values is more common.
The helm-secrets plugin can manage and protect secrets and critical data. Mozilla SOPS will handle the secret encryption, supporting AWS KMS, PGP, Cloud KMS on GCP, and Azure
helm-secrets
The helm-secrets plugin can be installed using the following command:
helm plugin install https://github.com/jkroepke/helm-secrets
Or a specific version
helm plugin install https://github.com/jkroepke/helm-secrets --version v4.1.1
Key Vault.
Suppose you put all sensitive data in a file called secrets.yaml:
secrets.yaml:
postgresql: postgresqlUsername: postgres postgresqlPassword: ZoWpBAlCsg postgresqlDatabase: wp
You can use the plugin to encrypt your file:
$ helm secrets enc secrets.yaml Encrypting secrets.yaml Encrypted secrets.yaml
It will then update and encrypt all the values:
postgresql: postgresqlUsername: ENC\[AES256\_GCM,data:D14/CcA3WjY=,iv...==,type:str\] postgresqlPassword: ENC\[AES256\_GCM,data:Wd7VEKSoqV...,type:str\] postgresqlDatabase: ENC\[AES256\_GCM,data:8ur9pqDxUA==,iv:R...,type:str\] sops: ...
The data in the YAML above wasn’t secure, but the helm-secrets element allows you to store sensitive information in Helm charts.
Helm template files offer many functions and sources of values to create Kubernetes resources. Users must know what resources are deployed to their cluster. Thus, you should learn how to verify Helm charts and debug templates.
You can use these four key commands for debugging:
Helm Dashboard is an open-source project which offers a UI-driven way to view the installed Helm charts, see their revision history and corresponding k8s resources. It also allows users to perform simple actions such as rolling back to a revision or upgrading to a newer version. This project is part of Komodor’s vision to help Kubernetes users to navigate and troubleshoot their clusters. It is important to note that Helm Dashboard is NOT an official project by the helm team.
Key capabilities of the tool:
Together with our content partners, we have authored in-depth guides on several other topics that can also be useful as you explore the world of Kubernetes.
Authored by Komodor
Authored by Granulate
Share:
and start using Komodor in seconds!
