So, What is Helm?
Simply put, Helm is a package manager for Kubernetes. The main concept of Helm is to coordinate and simplify the installation, deployment, and maintenance of applications. It is mostly achieved through the use of one of the basics of Helm – Helm charts.
A Helm chart encapsulates the structure of the Kubernetes application, which is a great alternative to creating multiple config files on the Kubernetes cluster. As we’ve mentioned, Helm charts apply the templated approach to the structure definition, but the templates are adaptable enough to fit any application in the Kubernetes environment.
If you want to make Helm charts even simpler and easier to use, take a look at Helmbay. This Kubernetes Helm repository was created by developers and for developers. With an intuitive web interface and automatically generated instructions, building Helm charts will be as easy as it can be, and it will minimize issues connected with team communication. Give Helmbay a try and deploy quality applications now!
Looking for a Helm Repository?
Helmbay provides an enterprise-ready helm repository for free. Add you,r teammates, upload unlimited version of the charts, connect to any modern GitOps or CI/CD tool.
Helm Chart Creation Tutorial
To help you get started, here’s a step-by-step Helm chart tutorial for beginners:
#1 Use the helm create command
If you have your Kubernetes cluster running and the latest version of Helm set up, the best way to start a new Helm chart is to use the helm create command:
$ helm create newchart
This will create a new directory in your project, named newchart.
#2 Define the chart structure
Inside the newchart directory, you will see the next structure:
charts
templates
|- NOTES.txt
|- _helpers.tpl
|- Deployment.yaml
|- Ingress.yaml
|- Service.yaml
Chart.yaml
values.yaml
The files in the main directory (Chart.yaml and values.yaml) are the defining features of your chart – they will contain the information on what the Helm chart is (the metadata on it and which values it will contain at the time of deployment.
The files in the templates directory are the YAML definitions of the Kubernetes objects of your application (Deployment, Service, etc.). You can extend and adjust these files to fit your particular application before the deployment.
#3 Recognize and edit the values
The important deployment information is collected from the values.yaml file. That’s why the next step in the Helm charts for Kubernetes tutorial is to learn how to edit this file. The values file generated from the helm create command should look something like this:
replicaCount: 1
image:
repository: nginx
pullPolicy: IfNotPresent
imagePullSecrets: []
nameOverride: ""
fullnameOverride: ""
serviceAccount:
create: true
annotations: {}
name:
podSecurityContext: {}
securityContext: {}
service:
type: ClusterIP
port: 80
ingress:
enabled: false
annotations: {}
hosts:
- host: chart-example.local
paths: []
tls: []
resources: {}
nodeSelector: {}
tolerations: []
affinity: {}
replicaCount is a value that determines the number of pods launched. By default, the value is set to 1, but it is easy to change if you need more than one instance of the application for increased scalability or reliability. Be wary that it will consume more Kubernetes resources.
In the image section, you can see two values – repository, which determines the location of the image, and pullPolicy. If the pullPolicy is set to IfNotPresent, like in the example, it means that the image will be downloaded if it does not exist in the Kubernetes node yet.
imagePullSecret, allows you to pull the generated password or API key (secrets), used for the registry.
The next section is dedicated to overrides: nameOverride and fullnameOverride can be used to change the name of your Helm chart.
serviceaccount ensures that you can use a user identity inside the cluster. If the name value is not filled out, it will be automatically generated.
The next few values are dedicated to pod security. By filling them out, you can limit the access to the pod for certain users or filesystem groups.
service values refer to networking options available for the application. One is ClusterIP – cluster-internal service. The other is NodePort – for the application to be reachable from the Kubernetes node. Finally, there is the Loadbalancer value – for the cases when you use cloud services with an external load balancer support.
resources value allows you to allocate hardware resources for your application manually. You can set up limits to not overload the hardware, or you can set maximum amounts of resources available to ensure that apps run as fast as possible. Setting both requests and limits ensures the highest Guaranteed QoS and dedicated resources for your pods.
The next set of values is used to manipulate the application in relation to Kubernetes clusters. For example, nodeSelector can be used to assign certain aspects of your application to certain nodes in your Kubernetes cluster.
#4 Check out the documentation
The Helm documentation is extensive and has various, more detailed Kubernetes Helm charts tutorials on how to properly develop and customize your chart. If this Helm chart creation tutorial is not enough for you, try searching for a part you need more information on there.
How to Install Helm Chart
Now that you know how to create a Helm chart, you also need to learn how to install Helm charts. You can do that with a simple helm install command:
helm install chartname ./newchart
One of the biggest benefits of Helm is that you don’t need to take down the whole application to implement specific changes that you want to make. Instead, you can make changes in the chart and use the upgrade command to implement them:
helm upgrade chartname ./newchart
In case the changes you’ve made weren’t successful, or you’ve made a mistake upgrading the application, you can always roll back to the previous state:
helm rollback chartname ./newchart
How to Manage and Host Helm Charts
The next step in the tutorial on how to make a Helm chart is how to manage it after the installation. The question you need to answer is where to host the chart? The answer is simple.
Chart repositories are HTTP servers that store their index.yaml file, in addition to any other Helm-related package. By default, the chart is set up to run on an NGINX server exposed via a Kubernetes Service. This means that basically any HTTP server can be used to host the Helm chart. You can use such services as:
- Google Cloud Storage;
- Amazon S3;
- GitHub.
Consider Helmbay Your Trusted Partner
Besides making Helm charts easier and more intuitive to work with, we at Helmbay provide our users with a private Helm repository. Create and deploy your application with Helmbay to make sure you’re using Helm charts to their fullest potential.
Final Thoughts
Helm charts are an essential tool for effective Kubernetes application deployment. They are highly customizable and can be used to ensure the constant uptime of your application. However, they can be rather complex for beginners. Hopefully, this tutorial will help you get your footing in the area and successfully deploy your applications in no time.
FAQ
Why use Helm Charts?
Helm is a package management tool for Kubernetes. By using Helm charts, you can deploy and manage your applications more effectively.
What are the steps to install Helm Charts?
You need to use the Helm creation command, edit any values you might need, and deploy the chart with the helm install command.
How to host Helm Charts
You can host them using any HTTP server of your liking: Google Cloud Storage, Amazon S3, GitHub, etc.
