Understanding Kubernetes deployments with Helm

I am trying to understand all the YAML code we have in our solution for deploying to Kubernetes. I’ve got three hours today, here’s what I learnt.

What is a Kubernetes object?

A Kubernetes object represents how you would like your cluster to behave in Kubernetes — it describes which applications are running, the resources available to those applications, and any policies that have been set.

There are two main parts to a Kubernetes object — the spec and the status.

• The spec is set when you create the object and describes what you want to happen in your cluster.
• The status is the current state of the object which is continually updated by the Kubernetes system. Kubernetes ensures that the two states match.

This example is taken from the Kubernetes documentation, which I thought was helpful to explain the concept:

For example: in Kubernetes, a Deployment is an object that can represent an application running on your cluster. When you create the Deployment, you might set the Deployment spec to specify that you want three replicas of the application to be running. The Kubernetes system reads the Deployment spec and starts three instances of your desired application--updating the status to match your spec. If any of those instances should fail (a status change), the Kubernetes system responds to the difference between spec and status by making a correction--in this case, starting a replacement instance.

What is Helm?

Without Helm, you would need to create your own YAML files to define the state of a Kubernetes object, which is known as a manifest file. This can be quite complex and result in lots of files and duplicate code.

Helm helps to make the process of doing Kubernetes deployments easier. It is a package manager for Kubernetes and works like the package managers you may be familiar with (e.g. NuGet for .NET). It installs software and dependencies, upgrades it and configures software deployments.