Shulou(Shulou.com)05/31 Report--

This article will explain in detail how Kustomize can easily solve the management of multi-environment and yaml orchestration files. The content of the article is of high quality, so the editor will share it for you as a reference. I hope you will have a certain understanding of the relevant knowledge after reading this article.

Preface

In 18 years, I learned docker, which uses the idea of containers to package dependencies and running environments into self-contained, lightweight, portable containers. The real benefit it brings to developers is to build and run everywhere, eliminating development, test, and production environment inconsistencies. After reading it, I don't think so. can we really completely eliminate the inconsistencies in each environment? Today, Kubernetes has been put into production, but the inconsistency of various environments has not been solved. The general problem is that it is not realistic for all services to be containerized, such as MySql, Redis and so on. These services themselves already have existing and stable deployment methods, and these services are not very changeable. Of course, you can use Kubernetes to mirror the database and orchestrate through stateful service resource objects. It is incorporated into the Kubernetes cluster management to achieve dynamic expansion and reduction. But for small and medium-sized enterprises, the most urgent thing is their own business, for database services or the use of the original server deployment, to minimize the cost of research and development. This brings about the following problems:

First, the database address of the connection between the development environment and the test environment is not the same, and the online environment is even different. Each time you go online, you need to maintain three copies, or even more configurations, namely Kubernetes ConfigMap.

Second, the packaging problem of each environment is solved by mirroring, but it is followed by a large number of yaml orchestration files, how to manage orchestration files? Although each environment is mirrored the same, but the configuration parameters may be different, for example: develop a copy, but production may need three, and so on.

Third, yaml configuration is more, either one by one execution, or separate maintenance script batch execution yaml.

In order to solve the complex problem of different applications using different configuration parameters in different environments, helm appears in the container ecosystem, which greatly simplifies the difficulty of application management. to put it simply, helm is similar to Kubernetes package manager, which is used for application configuration, distribution, version control, search and other operations. Its core function is to package Kubernetes resource objects (Deployment, ConfigMap, Service) into a Charts, and save each Charts to Chart repository for storage and forwarding. Although helm can solve the life cycle management of Kubernetes resource objects and version control through templates, helm is complex to use. It only wants to manage several different environment yaml configurations. Helm has many concepts such as template rendering, and does not support multi-tenancy. Now that helm v3 abandons tiller and introduces lua, it is intended to simply solve the problem of yaml orchestration files, but introduces higher complexity.

But the cloud native community never disappoints us. Then comes Kustomize. There is only one cli tool that can package configurations for different environments. After Kubernetes version 1.14, it can be directly integrated into kubectl commands, and applications in different environments can be packaged by executing kubectl apply-k command, which can be said to be quite simple. Here is an introduction to Kustomize.

Kustomize design concept

Kustomize allows users to Base YAML based on an application description file (YAML file), and then generate the description file needed for the final deployment of the application through the way of Overlay. Both are represented by kustomization files. Base declares shared content (resources and common resource configurations), while Overlay declares differences. It is designed to provide kubernetes users with a declarative application management that can re-use the same set of configuration, so that users only need to manage and maintain kubernetes API objects in configuration work, without learning or installing other configuration management tools, nor do they need to copy and paste to get the configuration of the new environment.

Introduction to the concept of Kustomize

The declaration and specification of the tools in kustomize are defined by a file called kustomization.yaml, ensuring that the three files are in the same directory as kustomization.yaml. Examples are as follows:

CommonLabels: app: hello resources:-deployment.yaml-configMap.yaml-service.yaml

Kustomize will read the declaration file and the Kubernetes API resource file, combine them, and standardize the output of the complete resource. The output text can be further processed by other tools (kustomize build), or directly through kubectl (kubectl apply-k.) It can be applied to clusters in both ways, but kubectl requires a version above kubernetes 1.14. If you need to install the cli command line to use kustomize, you can simply install https://github.com/kubernetes-sigs/kustomize/releases and download binary commands on your own.

Examples of development, testing, and production yaml configuration

The specific directory is as follows:

Example of configuration modification

Among them, the deployment and service stored in base are our common Kubernetes resource objects, and this part is usually unchanged. In addition to these two, plus kustomization, its purpose is to specify which files need to be merged together, as follows:

Run to the dev directory, as follows: there is an extra configuration file yaml in the dev directory. This configuration is suitable for the development environment. Execute [root@k8s-master dev] # kubectl apply-k. It can complete the configuration and execution of each environment. The content of kustomization.yaml is as follows:

NamePrefix applies to the resource name prefix, and you can choose whether to add it or not according to the situation. By the same token, testing and online environments can also perform configuration through this process.

Example of number of copies modified

Deployment runs a copy of nginx.

Modify the number of copies by increasing the number of patch yaml, as follows:

Add a patch policy as follows:

Execute the following command to change from one copy to three copies, as follows:

Kustomize can basically meet the common configuration functions. The specific features are as follows:

This article focuses on how you can manage any number of Kubernetes custom configurations by using kustomize. Each product of kustomize is pure YAML, and these files can be stored in SVN or github, or even managed in combination with helm, and finally automatically pull the configuration through the automated workflow to complete the execution of this process.

On Kustomize how to easily solve multi-environment and yaml choreography file management is shared here, I hope the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.