Q1 - What is helm?
A1 - Helm is a Kubernetes deployment tool for automating creation, packaging, configuration, and deployment of applications and services to Kubernetes clusters.
Q1 - Top 5 reason for using helm?
- Without Helm: Teams rely on Kubernetes YAML files to configure Kubernetes workload. These YAML files specify everything needed for deploying containers. Everything from the way each Pod needs to be configured to how load balancing is done by the Kubernetes cluster, has to be mentioned in those YAML files. Thus, to set up a new Kubernetes workload, you need to create a YAML file for that workload. To do it manually means writing multiple YAML files – one for each workload you create.
With Helm:
Instead of having to write separate YAML files for each application manually, you can simply create a Helm chart and let Helm deploy the application to the cluster for you. Helm charts contain templates for various Kubernetes resources that combine to form an application. A Helm chart can be customized when deploying it on different Kubernetes clusters. Helm charts can be created in such a way that environment or deployment-specific configurations can be extracted out to a separate file so that these values can be specified when the Helm chart is deployed. For example, you need not have separate charts for deploying an application in development, staging, and production environments.
Helm Charts provide the ability to leverage Kubernetes packages through the click of a button or single CLI command. You can also include Helm charts within other Helm charts and have various dependencies.
Another distinguishing feature Helm offers is the ability to customize application configurations during deployment. The DevOps team can provide configurations for all the Kubernetes resources included in the application as well as configure all the environment-specific requirements for those resources. This enables teams to reuse one Helm chart across multiple environments.
Boosts Productivity!
Using a Helm allows the software to deploy its test environments at the click of a button. For instance, in order to test a new feature, a developer would need a SQL database. There is no need for the development to go through the process of installing the software and then create all the databases & tables required. Instead, the teams can simply run a single Helm Install command to create and prepare the database ready for testing. This in turn saves the developers time and boosts their productivity.Reduces Complexity!
Once the Helm chart is built, it can be used over and over again by anyone. By using the Helm chart in Kubernetes deployment, product teams can actually reduce complexities. The fact that developers can use the same chart for any environment reduces the intricacies of creating different charts for the dev, test and prod environment. The DevOps teams can simply tune in their Helm chart and make sure it is ready to be applied to any environment, be it in dev, test or prod. This way teams can leverage the benefits of using a production-ready chart in a dev environment.Helm automatically maintains a database of all the versions of your releases. So, whenever something goes wrong during deployment, rolling back to the previous version is just one command away.
Q3 - How helm works? Inlcude some pic
Q4 - Helm Architecture? Inlcude some pic
Q5 - What is chart and what it contains?
A Helm chart is a package that contains all the necessary resources to deploy an application to a Kubernetes cluster. This includes YAML configuration files for deployments, services, secrets, and config maps that define the desired state of your application.
Helm uses a packaging format called charts. A chart is a collection of files that describe a related set of Kubernetes resources. A single chart might be used to deploy something simple, like a memcached pod, or something complex, like a full web app stack with HTTP servers, databases, caches, and so on.
Charts are created as files laid out in a particular directory tree. They can be packaged into versioned archives to be deployed.
If you want to download and look at the files for a published chart, without installing it, you can do so with helm pull chartrepo/chartname.
The Chart.yaml file is required for a chart. It contains the following fields:
`apiVersion: The chart API version (required)
name: The name of the chart (required)
version: A SemVer 2 version (required)
kubeVersion: A SemVer range of compatible Kubernetes versions (optional)
description: A single-sentence description of this project (optional)
type: The type of the chart (optional)
keywords:
- A list of keywords about this project (optional)
home: The URL of this projects home page (optional)
sources:
- A list of URLs to source code for this project (optional)
dependencies: # A list of the chart requirements (optional)
- name: The name of the chart (nginx)
version: The version of the chart ("1.2.3")
repository: (optional) The repository URL ("https://example.com/charts") or alias ("@repo-name")
condition: (optional) A yaml path that resolves to a boolean, used for enabling/disabling charts (e.g. subchart1.enabled )
tags: # (optional)
- Tags can be used to group charts for enabling/disabling together
import-values: # (optional)
- ImportValues holds the mapping of source values to parent key to be imported. Each item can be a string or pair of child/parent sublist items.
alias: (optional) Alias to be used for the chart. Useful when you have to add the same chart multiple times
maintainers: # (optional)
- name: The maintainers name (required for each maintainer)
email: The maintainers email (optional for each maintainer)
url: A URL for the maintainer (optional for each maintainer)
icon: A URL to an SVG or PNG image to be used as an icon (optional).
appVersion: The version of the app that this contains (optional). Needn't be SemVer. Quotes recommended.
deprecated: Whether this chart is deprecated (optional, boolean)
annotations:
example: A list of annotations keyed by name (optional).`
Top comments (0)