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

In this issue, the editor will bring you the analysis of K8S application management based on Helm and Operator. The article is rich in content and analyzed and described from a professional point of view. I hope you can get something after reading this article.

What we share today is K8S application management based on Helm and Operator. We know that Kubernetes provides a variety of resource description types based on service granularity. Describe an application system, especially a micro-service architecture system, which requires the combined use of a large number of Kubernetes resources. For stateful applications, complex operation and maintenance management operations and more domain knowledge are often required.

Tonight we will introduce how to use Helm, a community-led solution for Kubernetes application package management, to simplify application deployment management, how to make application templates and build Kubernetes app stores, and how to take advantage of operator application automation operations.

1. Helm

Let's start from scratch. For example, we have now deployed a K8S cluster. Whether using GKE or EKS, it is not difficult, because deploying K8S is not as troublesome as it used to be. Then we made the containerization of the application. Next, we will try to deploy our application to K8S.

In fact, in K8S, there are many resource objects:

For some microservice architectures, there will be different services running on it, and you may want to manage things such as deployment, service, stateful Statefulset, permission control, and so on. You will find that after deploying the application, there will be a lot of other related things and points you need to consider: for example, your different teams have to manage such an application, from development to testing to production, in different environments, the same set of things may require different configurations. For example, when you develop, you don't need to use PV, you just use some temporary storage; but in a production environment, you have to persist; and you may share it between teams and then archive it.

In addition, you not only have to deploy this application resource, you also have to manage its life cycle, including upgrades, upgrades, subsequent deletions, etc. We know that deployment in K8S is versioned, but from the perspective of the whole application or an application module, there may be other configmap associated with it in addition to deployment. At this point, we wonder, is there such a tool to manage these applications in a higher dimension? At this point we have a package management tool for the community: Helm.

We know that K8S means the helmsman, the person at the helm of the ship. And Helm is actually the rudder. In Helm, one of its applications is called Charts,Charts, which actually means nautical chart. What is it?

It is actually a definition description of an application. It includes some metadata for the application, as well as the template and configuration of the K8S resource definition for the application. Second, Charts can also include documentation descriptions that can be stored in chart's repository.

How to use Helm as a tool? Helm is actually a binary tool. As long as you download it and have configured some relevant configuration information about kubeconfig, you can deploy and manage the application in K8S. What can I do with Helm? In fact, Helm is divided into two parts: the server and the client. After you helm init, it will deploy a server called Tiller in K8S. This server can help you manage a complete life cycle of Helm Chart application packages.

Release = = installation example of Chart:

Let's move on to Helm Chart. It is essentially an application package, and you can think of it as dpkg or a package like rpm. However, it is based on the concept of an application package in the K8S field. You can deploy the same chart package multiple times, and each time you install it, it produces a Release. This Release is equivalent to an installation instance in chart.

Now that we have deployed Tiller, we can manage our application:

$helm install # (stable/mariadb,. / nginx-1.2.3.tgz,. / nginx, https://example.com/charts/nginx-1.2.3.tgz)$ helm upgrade $helm delete

For some common commands, such as installing an application package, you can use install, which actually supports different formats: for example, some local chart packages, or your remote repository path. For updates to the application, use Helm upgrade. If you want to delete it, use Helm Delete.

A Release of Helm generates a corresponding Configmap, which stores the information of the Release and stores it in K8S. It is equivalent to associating an iteration of the application's life cycle directly with K8S, even if the Tiller is dead, as long as your configuration information remains, the release and iteration process of the application will not be lost: for example, you want to roll back to the previous version, or check its upgrade path.

Next, let's look at the structure of a chart.

$helm create demoapp

With Helm create, it will provide a general framework for you to create your own application. For example, this application is called Demoapp, and it will contain the following contents:

The core is templates, that is, the templated K8S manifests file, which will include the definition of resources, such as deployment, service and so on. Now what we create comes out is a default application that is deployed with a nginx deployment.

It is essentially a template template for Go. Helm adds a lot of things to the Go template template. Such as some custom metadata information, extended libraries, and workflows similar to programming forms, such as conditional statements, pipes, and so on. All of these things will make our templates very rich.

With templates, how do we incorporate our configuration? This is the values file that is used. These two parts are actually the core functions of chart.

This deployment is a template for Go template. You can define some default configuration variables. These variables are read from the values file. In this way, we have a template for the application package, which can be deployed in different environments with different configurations. In addition, different value can be used in Helm install/upgrade.

Configuration options:

$helm install-- set image.tag=latest. / demoapp$ helm install-f stagingvalues.yaml. / demoapp

For example, you can set a single variable, you can use the entire File to do a deployment, it will overwrite its default configuration with your current configuration. So we can use different configuration files directly between different teams, and use the same application package for application management. Chart.yaml is the metadata of chart, which describes the information of this chart package.

There are also documentation, such as NOTES.txt, which is usually placed in templates and is automatically listed when you install it or when you view the deployment details (helm status). There is usually some descriptive information such as deployed applications and how to access them.

In addition to templates, another role of Helm chart is to manage dependencies.

For example, if you deploy a Wordpress, it can rely on some database services. You can put the database service in a dependent directory as an chart form. In this way, dependency management between applications can be done very conveniently. If we have now created our own application package and want to have a warehouse to manage the package, what should we do to share it between teams?

Chart's warehouse is actually a HTTP server. As long as you put your chart and its index file on it, you can get it through the above path when you are in Helm install.

The Helm tool itself also provides a simple instruction called Helm serve to help you build a repository for development and debugging.

For example, the warehouse directory structure of https://example.com/charts:

With regard to Helm, the community version already has a lot of application packages, generally placed in some projects under K8S, such as when installing Helm, it has a Stable project by default. There will be all kinds of application packages. Stable and incubator chart Warehouse: https://github.com/kubernetes/charts

In addition, the community version also provides a concept of UI similar to the Rancher Catalog App Store, which you can manage. It is called Monocular, which means monoculars, and the development of these projects is very active and has been updated with the iteration of K8S.

Monocular: chart's UI Management Project: https://github.com/kubernetes-helm/monocular

So how to deploy the K8S version of the app store? It's actually very simple. Because with Helm, you just need to use Helm install as a Monocular, add its warehouse first, and then install it, and you can deploy this application to your K8S cluster. In fact, it also uses Helm Tiller for deployment. We can search for some chart above and manage your warehouse, such as the official stable, or some items in incubator.

You can also manage some deployed applications. For example, if you want to search for an application, click on deployment, and you can deploy it. However, there are still a lot of things that need to be improved, such as the deployment here can not configure a variety of different parameters, it can only enter namespace. Second, some of the management still has limitations, such as not being able to easily update on UI.

We will also have related cooperation with some public cloud vendors around Helm chart. Because the advantage of Helm chart is that an application package can be deployed in multiple places. For example, public cloud services can be based on it to achieve application choreography and management, providing a service to different users conveniently. Rancher will also add support for helm chart in the 2.0 app store, hoping to help users provide a good experience while making it easy to use existing templates.

There is already a lot of chart in stable's warehouse, but it is not very perfect, and there are many applications that can be supplemented and enhanced. In our practical experience, anything can be chart, whether it is a distributed database cluster or a parallel computing framework, can be deployed and managed on K8S in this form.

Another point is that Helm is plug-in, helm plug-ins have Helm-templates, helm-github, and so on.

For example, when you are in Helm install, it can call the plug-in to do the extension. It doesn't have an official warehouse, but it already has some features available. In fact, the Restless/release information as well as your chart information and Tiller connection information to the plug-in to deal with. Helm itself, regardless of the form in which the plug-in is implemented, does its own processing of the passed parameters as long as it is an application package.

There are probably some of the benefits of Helm: using the existing rapid deployment of Chart to experiment with creating custom Chart, easily sharing the lifecycle of applications among teams to facilitate application dependency management and reuse, using K8S cluster as an application release collaboration center.

II. Operator

Let's talk about Operator. Why do you talk about Operator? Operator is not really a tool, but an idea that exists to solve a problem. What's the problem? That is, when we manage applications, we will encounter stateless and stateful applications. Managing stateless applications is relatively simple, but stateful applications are more complex. In Helm chart's stable repository, the chart of many databases is actually single-node, because distributed databases are more troublesome to do.

The idea of Operator is to inject domain knowledge and use software to manage complex applications. For example, for stateful applications, everything is different and may require you to have professional knowledge to deal with. For different database services, there are different ways to expand and reduce capacity and backup. Can you take advantage of the convenient features of K8S to simplify these complex things? That's what Operator wants to do.

In the case of stateless applications, it is relatively simple to make it a Scale UP: just expand its number.

Then in the controller of deployment or ReplicaSet, it will determine its current state and migrate to the target state. For stateful applications, we often need to consider a lot of complex things, including upgrades, configuration updates, backups, disaster recovery, Scale adjustment, and so on, which is sometimes equivalent to brushing the entire configuration or even restarting some services.

For example, Zookeeper315 cannot update the cluster status in real time before, and it is very troublesome to expand the capacity, and you may need to restart the entire node for a round. Some databases may be more convenient, just register with master. So each service has its own characteristics.

Take etcd, for example, it is the main storage in K8S. If you Scale up it, you need to add some connection information of new nodes to the cluster to obtain configuration connections to different Member of the cluster. Then use its cluster information to start a new etcd node.

What happens if you have etcd Operator? Operator is actually something that CoreOS preaches. CoreOS has provided several open source Operator to the community, including etcd, so how to expand an etcd cluster in this case?

First, you can deploy etcd Operator into K8S in the form of deployment. After deploying this Operator, it is actually very convenient to deploy a cluster of etcd. Because you no longer need to manage the configuration information of this cluster, just tell me how many nodes you need and what version of etcd you need, and then create such a custom resource, Operator will listen to your requirements and help you create configuration information.

$kubectl create-f etcd-cluster.yaml

To expand the capacity is also very simple, as long as the number of updates (for example, change from 3 to 5), and then apply, it will also monitor the changes of this custom resource to make corresponding updates.

$kubectl apply-f upgrade-example.yaml

This is equivalent to handing over all the work that previously required operation and maintenance staff to deal with the cluster to Operator. How do you do that? That is, an extensible API--CRD that applies K8S (formerly known as a third-party resource).

After an etcd Operator is deployed, the target application state is managed and maintained through kubernetes API. In essence, it is the mode of Controller in K8S. K8S Controller will manage its resource like this: to monitor or check its expected state, and then compare it with the current state. If there is any difference in it, it will update accordingly.

Kubernetes Controller mode:

Etcd's approach is to create a custom resource called etcd cluster when pulling up an etcd Operator to listen for changes in the application. For example, if you declare your update, it will generate a corresponding event, do the corresponding update, and maintain your etcd cluster in this state.

In addition to etcd, communities such as Prometheus Operator can help you manage stateful applications in this convenient form.

It is worth mentioning that Rancher2.0 widely uses Kubernetes-native 's Controller model to manage application loads and even K8S clusters, jokingly, as a Kubernetes operator.

Third, the comparison between Helm and Operator

After talking about these two things, let's compare the two.

Operator is essentially a tool to do stateful services for specific scenarios, or to simplify its operation and maintenance management for application scenarios with complex applications. Helm, it is actually a more universal tool, the idea is also very simple, is to make your K8S resources template, easy to share, and then reuse in different configurations.

In fact, most of what Operator does can be done by Helm. Use Operator to monitor the cluster status of updated etcd, and you can do the same with custom Chart. It's just that you may need some more complex processing, for example, when the etcd is not set up, you may need some init Container to update the configuration, check the status, and then pull up the node with the corresponding information. When deleting, add some PostHook to do some processing. So Helm is a more universal tool. The two can even be used in combination, such as etcd-operator chart in the stable repository.

As far as I understand it, on top of the behemoth of K8S, both of them are born out of simple but natural ideas, helm is for configuration separation, and operator is for automated management of complex applications.

The above is the analysis of K8S application management based on Helm and Operator shared by Xiaobian. If you happen to have similar doubts, please refer to the above analysis to understand. If you want to know more about it, you are welcome to follow the industry information channel.

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.