Shulou(Shulou.com)06/01 Report--

Editor to share with you the example analysis of Kubernetes operator, I believe that most people do not know much about it, so share this article for your reference, I hope you can learn a lot after reading this article, let's go to know it!

Operator was introduced to the community in 2016, and CoreOS launched it to simplify the management of complex stateful applications. Operator is an application state-aware controller that automatically creates, manages, and configures application instances by extending Kubernetes API. Operator extends the resource object based on CRD (Custom Resource Definition) and ensures that the application is in the expected state through the controller.

For example, etcd operator simulates the behavior of managing an etcd cluster through the following three steps:

1. Observe the current status of the cluster through Kubernetes API

2. Analyze the difference between current state and expected state.

3. Call K8s API to eliminate these differences.

Let's talk about Operator from different angles.

1. Operator and docker

Let's talk about docker first. Docker has many advantages, such as isolation, execution efficiency, and so on. But in my opinion, the core value, or subversive result of docker, is the design of mirroring processes that provide standardized delivery methods. In terms of a single application example, the standardized and consistent environment solves the problem of application runtime, and uniformly encapsulates the deployment and dependence of the application. The deployment of applications has moved from manual workshop deployment to a standardized industrial era. Of course, this also brings a certain amount of extra disk loss. But today, with the rapid development of hardware, this disk loss is hardly a problem. And with the help of federated file system and mirror optimization, disk wear and tear is hardly considered.

Today, fewer and fewer projects are deployed using source code. In the past, an open source project was often accompanied by a lengthy installation document that taught you how to install and run. Now, basically active open source projects provide container-based deployment, you only need to pull down the image run to use it. Docker greatly improves the efficiency of delivery, reduces the threshold of use, and effectively avoids the failure of deployment.

Operator is similar to docker, and its main delivery object extends from a single application instance to a multi-instance, distributed system. In the past, deploying a distributed system required multiple containers to be launched and then complex configuration, but now all you have to do is create a CRD. Operator will automatically create and deploy the various resources needed in the distributed system. From this perspective, the goal of operator is to achieve standardized delivery of distributed systems.

2. Operator and Helm

Now our general sense of arrangement, that is, orchestration, there is another kind of translation is arrangement. Wikipedia is defined as the scheduling, coordination, and management of complex computer systems, middleware (middleware), and business automation. According to my personal experience, the typical features of summary choreography mainly include service version management, service life cycle management, multi-resource management, parameterization and templating.

The first contact with the choreography concept was through openstack's heat project. There are many systems in openstack, from computing to storage to the network. If a complete application virtual machine is deployed, the collaborative participation of a variety of resources is required. The heat project is born for this goal. It arranges a variety of resources through templates and parameters to achieve the life cycle management of a complete service, such as creation, deployment, modification, deletion and so on.

There are also many orchestration projects in K8s, and the popular one is the package management tool Helm. If docker is the standardized delivery of single instance, then Helm is the standardized delivery of clustering multi-instance and multi-resources.

The management of operator is not limited to pod, but can also be multiple resources (such as svc domain name, etc.). From this point of view, operator, like Helm, also has the ability to orchestrate. From the perspective of arrangement, in the eyes of beginners, Helm and operator have a lot in common, so it is difficult to distinguish between their roles. Helm can also complete the deployment of distributed systems. So what's the difference between operator and Helm? Helm focuses on multiple resource management, while lifecycle management mainly includes creating updates and deletions. Helm drives the entire lifecycle with commands.

Operator's management of resources is not just about creation and delivery. Because it can obtain the change events of related resources through watch, it can achieve high availability, scalability, fault recovery and other operation and maintenance operations. Therefore, operator's lifecycle management includes not only creation, fault recovery, high availability, upgrade, expansion and reduction, exception handling, and final cleanup, and so on.

Well, do you think these functions can be realized with Helm? in fact, I think some functions should also be possible. But there is a problem involved in this, that is, these functions can not be directly implemented in the orchestration, so they need to be solidified into the image by script or program. A large amount of operation and maintenance code is scripted. This can lead to increased complexity and poor readability in maintaining these scripts. In addition, another potential risk that cannot be solved is that when these container instances are all dead, they cannot be automatically restored, even if there is backup data. At this time, it will eventually rely on manual intervention, and it is still unable to achieve the goal of automation and intelligence.

Operator realizes automation and intelligence at the same time. Its main work flow is based on the current state, intelligent analysis and judgment, and finally create, restore, upgrade and other operations. The script located in the container, because of the lack of a lot of global information, can not achieve all these functions on its own. Operator, which is from a third-party perspective, can solve this problem. Through side observation, he can obtain the status and information of all resources and compare them with the expected / declared state. Through the preset analysis process to judge, so as to carry out the corresponding operation, and finally achieve the purpose of declaring the state. In this way, all the operation and maintenance logic is extracted from the mirror and concentrated in the operator. The hierarchy and logic are clearer, easier to maintain, and easier to deliver and pass on.

If Helm is compared to rpm, then operator is systemd. Rpm is responsible for the installation and deletion of applications, while systemd is responsible for the startup, restart and other operations of applications. Of course, the two are not mutually exclusive. At present, one of the more convenient deployment methods of operator is to deploy through Helm.

3. Operator and controller

Operator can be said to be another controller. The current controller manager collection is mainly a basic and general concept of resources, such as rs/deployment, while for specific applications or services (such as etcdcluster, can be considered as a resource), the authority is delegated to a third party, that is, CRD. Users can access through custom resource descriptions and self-developed controller/operator. So the relationship between controller and operator is somewhat similar to that between standard libraries and third-party libraries.

Generally speaking, different operator is needed to deal with different applications. At this point, let's think again, take replicaset controller as an example. The main function of rs is to maintain the number of copies. When pod is hung up / deleted for some reason, for stateless applications, the way to recover is to increase the corresponding number of pod. From this point of view, for stateless applications, rs controller is actually the operator of stateless applications.

The core value of operator

We used to talk about devops, which is the combination of operation and development to improve the efficiency and quality of development delivery. This has also brought about a trend, that is, the integration of operation and development. For example, the people who originally developed the application solidified the deployment and startup of the application in the dockerfile/ image through the production of the docker image, sharing a lot of deployment work of the operation and maintenance. But in fact, the content and scope of operation and maintenance is actually very wide, especially the current distributed system, including cluster deployment, high availability, fault recovery, system upgrade and so on. And these cannot be solidified only with dockerfile/ images.

Operator provides a possibility, or a good framework, to precipitate the experience of operation and maintenance into code, so as to realize the coding, automation and intelligence of operation and maintenance. Previous operation and maintenance operations, such as high availability, expansion and contraction, and fault recovery, are all precipitated by operator. In the long run, it will promote the deep integration of dev, ops and devops. Solidify and inherit the operation and maintenance experience, application schemes and functions through the way of code, reduce the probability of man-made failure, and improve the efficiency of the whole operation and maintenance.

Many of the ideas of operator are not new. In the framework of application manager,mesos in yarn, you can find some clues of operator. The reason why it is said that operator may become another major change after docker, another important factor is that operator stands on the shoulders of kubernetes giants.

Kubernetes strengthens the encapsulation of basic resources and maintains flexibility and customization. Kubernetes has changed from the traditional delivery of resources (cpu/mem) to the delivery of resources such as pod/svc/pv/pvc, expanding the concept of resources and encapsulating the necessary or related concepts such as domain name, load balance, storage and so on. On the basis of common resources such as operator, the application cluster is also regarded as a kind of resource, which can be provided to users. And with the help of the existing working mechanism and framework of k8s, it can be realized more conveniently and flexibly

Although the change of operator is significant, because the distributed application is mainly limited to the industrial production field, the final use scenario may be limited for general development. So I judge that the ultimate influence of operator is limited from a global point of view, but it will have a huge impact in the vertical areas of many distributed applications.

Finally, the premise of using operator is that containerization can be achieved. That is, applications can use containers for automated deployment of applications. Operator is not only to develop an operator program, but also needs to combine the image production, delivery, packaging and other work. It still requires a lot of development work. But once mature and stable, it will also bring huge operation and maintenance benefits and long-term effects.

The above is all the content of this article "sample Analysis of Kubernetes operator". Thank you for reading! I believe we all have a certain understanding, hope to share the content to help you, if you want to learn more knowledge, 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.