Searching for detailed Helm 3 documents on the Internet failed, the official website documents were too messy, and the technical group consulted on the document information and was ridiculed. MD doesn't fight for steamed buns. If there is no good document, I will summarize a document by myself. Part of the content in the document comes from major blogs and official websites, and part of the text content has been rearranged by me. All concept explanations will be accompanied by actual code records and experience. The article is updated from time to time, welcome to follow and subscribe to the column. If you have any questions, please leave a message in the comment area.
Link to the original text of this column: https://blog.csdn.net/xzk9381/category_10895812.html, please indicate the source for reprinting
1. What is Helm
Kubernetes is a distributed container cluster management system. It abstracts all resources in the cluster into API objects, and uses declarative methods to create, modify, and delete these objects. One problem that this brings is that there are many declaration files for these API objects. Whenever you need to create an application, you need to write a bunch of files that declare the creation of resources. In particular, many businesses are currently transforming to microservices. By decomposing huge monolithic applications into multiple services, the complexity of monolithic applications is decomposed, so that each microservice can be independently deployed and expanded, realizing agile development. And rapid iteration and deployment. But everything has two sides. Although microservices have brought us a lot of convenience, the number of services has increased significantly because the application is split into multiple components. For Kubernetest orchestration, each component has its own resource file. And it can be deployed and scaled independently, which brings the following problems:
- Need to manage, update and maintain a large number of yaml files
- You cannot create multiple environments based on a set of yaml files, you need to modify them manually
Helm is a tool used to manage these API objects. It is similar to the YUM package management of CentOS and the APT package management of Ubuntu. You can understand it as a package management tool for Kubernetes. It can combine and package all the Kubernetes API object declaration files needed to create an application. It also provides a warehouse mechanism for easy distribution and sharing. It also supports template variable replacement. At the same time, it also has the concept of version, which enables it to manage the version of an application.
Two, Helm components
Helm has the following components (concepts):
- Chart : It is a package of Helm that contains all the Kubernetes manifest templates of an application, similar to the RPM of YUM or the dpkg file of APT.
- Helm CLI : Helm's client component, responsible for communicating with the Kubernetes API
- Repository : A repository for publishing and storing Chart.
- Release : It can be understood as an example of Chart deployment. Applications deployed in Kubernetes through Chart will generate a unique Release. Even if the same Chart is deployed multiple times, multiple Releases will be generated.
3. The difference between Helm 3 and Helm 2
Only some important changes are listed below. For complete information, please refer to the official website: https://v3.helm.sh/zh/docs/faq/
1. Remove Tiller
Helm 2 is a C/S architecture, which is mainly divided into client helm and server Tiller. However, due to the complete components of permission control systems such as RBAC and the increasing demand for multi-tenancy and security, Tiller has become more and more insecure, and the community has encountered great obstacles in the field of permission control. Therefore, in the Helm 3 version, the core component of Tiller is directly removed, and helm communicates directly with the Kubernetes API. The benefits of this are as follows:
-
Helm's architecture has become simpler and more flexible
-
No longer need to create ServiceAccount, directly use the kubeconfig configuration in the current environment
-
Can directly interact with the Kubernetes API, which is more secure
-
No longer need to use helm init to initialize (previous versions need to use this command to install Tiller into the K8S cluster)
2. Delete the release command change
To completely delete a release in the previous version, you need to use the following command:
helm delete release-name --purge
Now just use the uninstall command, -purge will be used as a default behavior:
helm uninstall release-name
3. View chart information command changes
The previous version used the helm inspect command to view the specific chart information, now it has been changed to the helm show command.
4. Pull chart package command changes
Modify the helm fetch command in the previous version to the helm pull command. This is more like keeping up with docker pull.
5. The release name must be specified
In helm 2, if the release name is not specified during helm install, a random name will be automatically generated. But in helm 3, you must specify the release name, or use the --generate-name option.
Error: must either provide a name or specify --generate-name
6. About release information storage
In helm 2, the release information is all stored in the namespace where Tiller is located, so the name of the release cannot be repeated. In helm 3, release information will only be stored in the namespace of the release installation, so that different namepsaces can have releases with the same name.
So if you consider upgrading helm 2 to helm 3, you need to use the official 2To3 plug-in to complete. The specific operation process can refer to the official website: https://helm.sh/zh/docs/topics/v2_v3_migration/