In this chapter we will learn about Helm, the package manager for Kubernetes.
Every successful software platform has an excellent packaging system, such as apt for Debian, Ubuntu, yum for Redhat, Centos. And Helm is the package manager on Kubernetes.
In this chapter we will discuss why Helm is needed, its architecture and components, and how to use Helm.
Why Helm
What problem does Helm solve? Why does Kubernetes need Helm?
The answer is: Kubernetes is great for organizing and orchestrating containers, but it lacks a higher-level application packaging tool, which Helm is for.
Let's look at an example first.
For example, for a MySQL service, Kubernetes needs to deploy the following objects:
Service, so that the outside world can access MySQL.
Secret, defines the MySQL password.
PersistentVolumeClaim, apply for persistent storage space for MySQL.
Deployment, deploys MySQL Pods, and uses these support objects above.
We can save the above configurations to their respective files, or centrally write them into a configuration file, and then kubectl apply -f deploy them.
So far, Kubernetes supports the deployment of services very well. If the application consists of only one or a few such services, the above deployment method is completely sufficient.
However, if we develop an application with a microservice architecture, there may be as many as ten or even dozens or hundreds of services composing the application. This way of organizing and managing applications is not easy to use:
It is difficult to manage, edit and maintain so many services. Each service has several configurations, and a higher-level tool is lacking to organize these configurations.
It is not easy to release these services uniformly as a whole. Deployers need to first understand which services are included in the application, and then execute them in a logical order
kubectl apply. That is, there is a lack of a tool to define applications and services, and the dependencies between services and services.不能高效地共享和重用服务。比如两个应用都要用到 MySQL 服务，但配置的参数不一样，这两个应用只能分别拷贝一套标准的 MySQL 配置文件，修改后通过
kubectl apply部署。也就是说不支持参数化配置和多环境部署。不支持应用级别的版本管理。虽然可以通过
kubectl rollout undo进行回滚，但这只能针对单个 Deployment，不支持整个应用的回滚。不支持对部署的应用状态进行验证。比如是否能通过预定义的账号访问 MySQL。虽然 Kubernetes 有健康检查，但那是针对单个容器，我们需要应用（服务）级别的健康检查。
Helm 能够解决上面这些问题，Helm 帮助 Kubernetes 成为微服务架构应用理想的部署平台。
下一节我们讨论 Helm 的架构。
书籍：
1.《每天5分钟玩转Kubernetes》
https://item.jd.com/26225745440.html
2.《每天5分钟玩转Docker容器技术》
https://item.jd.com/16936307278.html
3.《每天5分钟玩转OpenStack》
https://item.jd.com/12086376.html
