In this chapter we will study the package manager for Helm, Kubernetes.

Every successful software platform has a good packaging system, such as Debian, Ubuntu apt, Redhat, Centos yum. Helm is the package manager on Kubernetes.

In this chapter we discuss why Helm is needed, its architecture and components, and how to use it.

Why Helm

What problem does Helm solve? Why does Kubernetes need Helm?

The answer is: Kubernetes does a good job of organizing and orchestrating containers, but it lacks a higher-level application packaging facility, which Helm does.

Let’s start with an example. For example, for a MySQL service, Kubernetes needs to deploy the following objects:

  1. Service, which allows the outside world to access MySQL.



  2. Secret, which defines the password of MySQL.



  3. PersistentVolumeClaim, which applies for persistent storage for MySQL.



  4. Deployment, deploy MySQL Pod, and use the support objects above.



We can save these configurations to individual files of the objects, or write them into a single configuration file and deploy them through Kubectl apply-f.

So far, Kubernetes has supported the deployment of services quite well, and if the application consists of only one or a few such services, the above deployment method is sufficient.

However, if we are developing an application with a microservice architecture, there may be ten or even dozens or hundreds of services that make up the application, which is not a good way to organize and manage the application:

  1. It’s hard to manage, edit, and maintain so many services. Each service has several configurations and lacks a higher-level tool to organize these configurations.

  2. It is not easy to publish these services as a whole. The deployer needs to first understand what services the application contains and then execute Kubectl Apply in logical order. The lack of a tool to define applications and services and the dependencies between services.

  3. Services cannot be shared and reused efficiently. For example, if two applications use MySQL services, but the parameters configured are different, the two applications can only copy a set of standard MySQL configuration files, modify them, and deploy them using Kubectl Apply. That is, parameterized configuration and multi-environment deployment are not supported.

  4. Application level versioning is not supported. Although it is possible to roll back through Kubectl rollout undo, this is only for a single Deployment and does not support rollback for the entire application.

  5. The status verification of deployed applications is not supported. For example, whether you can access MySQL through a predefined account. Kubernetes has health checks, but that’s for a single container, and we need application (service) level health checks.

Helm addresses these issues by helping Kubernetes become the ideal deployment platform for microservices architecture applications.

In the next section we discuss the architecture of the Helm.

Books:

1. Kubernetes in 5 Minutes every day item.jd.com/26225745440…

2. Docker Container Technology in 5 minutes a day item.jd.com/16936307278…

3. Play OpenStack in 5 Minutes every day item.jd.com/12086376.ht…