Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

How to analyze Informer mechanism through source code

2025-04-05 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Servers >

Share

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

This article is to share with you about how to analyze the Informer mechanism through the source code. The editor thinks it is very practical, so I share it with you to learn. I hope you can get something after reading this article.

Analysis of Informer mechanism through source code

In the previous article of kubernetes for final state design and controller, we mainly learned that the controller implements the final state architecture through ListAndWatch. The details of the internal implementation are not analyzed, so this chapter mainly analyzes the details of the internal implementation.

The reference project is the official sample-controller

In fact, each Kubernetes extension component can be thought of as a controller that handles the types of resources you care about (API objects). To associate the resources of our relationship with our own controller is through the Informer mechanism, which can be called a "notifier", and Informer and API objects are one-to-one corresponding, so we can create a custom resource, and our controller can use this Informer mechanism.

Official architecture map

From the figure above, we can see that the extension components of a Kubernetes are mainly divided into two parts: the client-go component and the custom Controller component.

Client-go:

Reflector: mainly interfacing with APIServer of Kubernetes, relying on ListWatch to synchronize data from ETCD to local cache (Delta Fifo queue).

Informer: used to index locally cached data and call pre-registered ResourceEventHandler.

Indexer: used to build the index, the underlying use of a thread-safe Map storage. The default Key for each resource is /.

Custom Controller

Workqueue is a deduplicated queue with processing and dirty set records in addition to the items list.

Multiple events of the same resource object are triggered, and will be repeated when queued.

The same resource object is not processed by multiple worker at the same time. For more information, you can see that all Learning Concurrent Reconciling controller queries for resource objects should look up cache from Informer instead of calling kube-apiserver query directly.

Informer reference: when writing a custom Controller, you need to create an Informer object that focuses on your own resources.

ResourceEventHandler: used to register related events. When data is available, Informer will make relevant callbacks.

ProcessItem: data is sent through Workqueue and processed by sending it to Handler.

Workqueue: work queue utility class, each controller needs to have a work queue. Events triggered from event handler are first put into the work queue and then taken out by the ProcessItem of controller.

Overall implementation process

Client-go

In HandleDeltas, Indexer is called to build the index, which is eventually stored in a thread-safe Map locally.

After that, the event is distributed, notifying all listener to call the user's registered ResourceEventHandler for processing.

Reflector first performs full data synchronization through List, from ETCD to local Delta Fifo queue. Reflector is finally connected to Kubernetes APIServer.

Reflector then carries out Watch data through the latest ResourceVersion, and if there is any data that has not been synchronized, it will be made up (because there may be an increase in new data after the completion of List, so there may be omissions).

When you start a custom controller, call Reflector through Informer to execute List&Watch for data synchronization and register to observe events.

When a user creates a custom resource, it is observed by Reflector's Watch and placed in the local Delta cache.

Informer calls the processLoop method through Controller timing (1s) in chche, and Pop the data out of the queue (Delta), which is handed over to the HandleDeltas of Informer for processing.

Custom Controller

Relevant filtering will be performed in the custom ResourceEventHandler, and will eventually be added to the Workqueue. The work queue only stores KEY, not specific objects.

Once joined, the ProcessItem scheme will Pop the data and give it to the Handle Object method for processing

Handle Object will call Indexer reference according to Key to get the specific object and start processing the business. Note: data must be cached here, and do not call Kubernetes's API directly, otherwise it will affect performance.

Native Controller code analysis initialization part

Initialize related structure and start Informer in main method

/ / https://github.com/kubernetes/sample-controller/blob/master/main.go#L62 kubeInformerFactory: = kubeinformers.NewSharedInformerFactory (kubeClient, time.Second*30) exampleInformerFactory: = informers.NewSharedInformerFactory (exampleClient, time.Second*30) controller: = NewController (kubeClient, exampleClient, kubeInformerFactory.Apps (). V1 (). Deployments () ExampleInformerFactory.Samplecontroller (). V1alpha1 (). Foos () / / notice that there is no need to run Start methods in a separate goroutine. (I.E. Go kubeInformerFactory.Start (stopCh) / / Start method is non-blocking and runs all registered informers in a dedicated goroutine. KubeInformerFactory.Start (stopCh) exampleInformerFactory.Start (stopCh) if err = controller.Run (2, stopCh); err! = nil {klog.Fatalf ("Error running controller:% s", err.Error ())}

The above code covers two parts:

Client-go part, build SharedInformerFactory and start, implement ListAndWatch, the first part parse

In the custom Controller part, the main internal business is to wait for events and make responses. The second part parses

Client-go code analysis

After building the Informer and starting it, the user will enter the Informer inside the client-go. The main logic is as follows

Call the Start method to initialize the requested Informer

/ / Start initializes all requested informers.func (f * sharedInformerFactory) Start (stopCh

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.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Servers

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report