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

In this issue, the editor will bring you about how to face the final state design and controller in Kubernetes. The article is rich in content and analyzes and describes for you from a professional point of view. I hope you can get something after reading this article.

An overview of final design

Overview

Kubernetes mainly stores all the metadata and senses the changes of data through ETCD to do related actions. Therefore, Kubernetes can be thought of as a set of final-state-oriented orchestration logic built around ETCD.

In the whole Kubernetes design concept, the final state-oriented is its core concept. Through this design concept, the competitiveness of Kubernetes and other container scheduling platforms is enhanced.

What is final state-oriented design?

For example, I need 10 instances of this application; I want a VIP; and a persistent disk; when this machine breaks down, help me change it automatically, and so on.

The above requirements are declared and submitted to the system, and the system will automatically accomplish what the user expects. In this way, it is a kind of design oriented to the final state. The final-state design of Kubernetes is similar, and the way it is exposed to users is "declarative API".

Users submit relevant expectations through this kind of declarative API. Kubernetes will parse and ensure that the final result is consistent with the expectations submitted by the user.

Declarative API

This set of declarative API in Kubernetes is mainly used to control internal resources, and mainly includes the following methods:

The following is a Deployment resource that can be created through the above API

ApiVersion: apps/v1 kind: Deployment metadata: labels: app: nginx name: nginx-test # above is the metadata of the resource spec: replicas: 1 # expected state For example, here you expect a copy of selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers:-image: nginx:latest name: nginx status: replicas: Actual status of 1 # Kubernetes

When the above resource is created through API, Kubernetes will constantly try to achieve the desired final state through the built-in controller.

Create: used to create a resource object

Update: used to update a resource and use optimistic locks to control the version

Patch: used for partial updates. This method does not have a lock and will directly overwrite updates. Several methods are provided, as follows: * Strategic Patch: native resources for K8s cannot be used for CRD resources, which are unique to K8s. * Json patch:RFC 6902 * Json merge:RFC 7386 * Server side apply * Delete: delete object

GET: query resources under a namespace through name

List: query a batch of objects under a given condition

The Core implementation of final State: controller Mode

What is the controller mode?

Through the "List Watch mechanism" to achieve the attention to the changes of Kubernetes-related resources, and trigger the processing of the controller logic, complete the final user expectations, and update to the ETCD through APIServer. This method is called "controller mode". Many components of Kubernetes realize the observation and processing of resources in this way, such as controller-manager,Kubelet,Scheduler and so on.

Interaction in controller mode

The components of the entire Kubernetes interact around APIServer, with the exception of APIServer components, other components generally do not interact directly.

The overall structure is as follows:

Users submit a resource to Kubernetes APIServer through kubectl, and then APIServer stores it in ETCD, where other components pay attention to the resources they are interested in, listen, and react.

For example, the user submits a Deployment resource and expects to deploy three instances. Then the APIServer of the Kubernetes stores the data in the ETCD, and the scheduler listens to the unscheduled Pod through the List Watch mechanism for scheduling. When the Pod in the resource is marked to be dispatched to which machine, another component, kubelet, will also be deployed through the List Watch mechanism to achieve the final state and complete the deployment of the three instances expected by the user.

This is how to design and control the final state in the Kubernetes shared by the editor. If you happen to have similar doubts, you might as well 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.