What is HELM, why do you need it & what problem does it solve for Kubernetes?

• Helm is a tool which helps to manage Kubernetes applications.
  
• Deploying applications to Kubernetes is not a simple task and some of the concepts and techniques for deploying and managing applications and services has a steep learning curve.
  
• To deploy a simple spring boot application with PostgreSQL backend, explained in blog we had to write 7 kubernetes resources namely deployment, service, persistent volume , persistent volume claims, postgres deployment, confifg map and services for database.
  
• Helm aims to solve these challenges and simplifies deploying and managing kubernetes application
  
• To deploy an application without Helm , we use the kubectl command which communicates with Kubernetes API
  
• The kubectl commands follow a common format: kubectl <verb> <noun><arguments>
  
• The verb refers to one of the kubectl subcommands and the noun refers to a particular Kubernetes resource.
  
• For example, the following command can be run to create a PostgreSQL Deployment: kubectl apply -f postgresql-deployment.yaml
  
• You can use kubectl edit, delete to edit and delete the deployment once resource is deployed
  
• There are many different resources in Kubernetes : Deployment, StafefulSet, Service, Ingress, ConfigMap, Secret, StorageClass, PersistentVolume, ServiceAccount etc.
  
• Deploying an application in Kubernetes environment , requires a solid understanding of these resources and steps to create it with right configuration parameters.
  
• This is not the only challenge and complexity . One of the other problem that we often encounter is the difference between local and live state of these resources .
  
• These resource files should be ideally stored in a repository. This state is referred as the local state of the resources.
  
• When these resources are deployed and if a developer wants to change something then he/she can directly modify it by issuing a kubectl edit and apply command. Since the resource was modified directly without updating the version in the repository you have a different state between local and live file.
  
• Another problem with this approach is rollback. Suppose you want to rollback to a state which was there 5 days back. You cannot easily rollback and will have to identify manually what parameters , configurations etc was deployed 5 days back and recreate the resource files with those values and re-apply changes.
  
• Kubernetes resource files are static and they are not natively designed to be parameterized.

apiVersion: v1
kind: Service
metadata:
  name: postgresql
  labels:
    app: postgresql
    tier: database
spec:
  ports:
    - port: 5432
      targetPort: 5432
  selector:
    app: postgresql
    tier: database

• Managing such similar files for same kind of applications for different environments is a cumbersome task.
  

Helm tries to solve all of these problems. It is an open source tool used for packaging and deploying applications on Kubernetes.

• It is mostly referred as package manager because of the similarities it has with other package manager tools that we use to install softwares
  
• For example in mac OS , to install redis i can use the brew package manager tool by issuing a command like brew install redis
  
• The above command will install redis and all its dependencies. Similarly the goal of helm is to simplify deployment and management of applications on Kubernetes by eliminating the need for creating multiple resource files and applying each of them by issuing kubectl apply command.

• When we use package managers to deploy applications, it downloads all the required libraries , jar file etc and installs in the right path. Helm uses charts. It contains all the required resource files required to deploy an application.
  
• Chart developers create yaml files for resources, package them into charts and publish them to chart repositories.
  
• For example, chart developers will create all required resource files to deploy postgreSQL and upload it to chart repository.
  
• Developers can search for charts in the repository and then provide values for the fields that you want to customize and issue one command to install it in Kubernetes.
  
• helm install my-redis redis/redis --version 0.1.1 --namespace=redis
  
• This would install the redis with name my-redis from the redis repository to a Kubernetes namespace called redis. This installation would be referred to as the initial revision, or the initial deployment of a Helm chart.
  
• Similar to install, Helm provides command to upgrade, rollback and delete the deployment.
  
• Helm abstracts the complexity of deploying applications to Kubernetes. Charts are already been written by chart developers in the community and contains the declarative configuration required to deploy applications.
  
• A developer just needs to look for the applicable chart in the repository , provide right values and install it
  
• When a Helm chart is installed for the first time, Helm adds that initial revision to the history. The history is further modified as revisions increase via upgrades, keeping various snapshots of how the application was configured at varying revisions.
  
• The process of tracking each revision provides opportunities for rollback. Rollbacks in Helm are very simple. Users simply point Helm to a previous revision and Helm reverts the live state to that of the selected revision.
  
• Helm allows users to roll back their applications as far back as they desire, even back to the very first installation
  
• To solve the issues of static declarative templates. Helm has the concept of values and templates.
  
• Values are simply what Helm calls parameters for charts. Templates are dynamically generated files based on a given set of values.
  
• These two constructs provide chart developers the ability to write Kubernetes resources that are automatically generated based on values that end users provide.
  
• The ability to dynamically generate declarative resource files makes it simpler to create YAML-based resources while still ensuring that applications are created in an easily reproducible fashion.
  
• Users that want to modify their applications can do so by providing new values to a Helm chart or by upgrading their application to a more recent version of the associated chart.
  
• This allows the local state (represented by the Helm chart configuration) and the live state to remain consistent across modifications, giving users the ability to provide a source of truth for their Kubernetes resource configurations.
  
• Helm simplifies application deployments by determining the order that Kubernetes resources need to be created. Helm analyzes each of a chart’s resources and orders them based on their types.
  
  

Hope this was useful. Please do share your comments and feedback.

Thank You !!