With the exception of CRI, most kubernetes components are designed with declarative interfaces
There are two main reasons why CRI adopts command interface
All runtimes need to re implement the same logic and support many pod level functions and mechanisms;
The definition of pod evolves very quickly in CRI design, and functions such as initializing containers need the cooperation of runtime;
Although the community finally chose the command interface for CRI, kubelet will still ensure that the state of pod will continue to migrate to the desired state.
After receiving the request, apiserver will save the relevant state of the current pod in etcd, and then other components will query the state and migrate the state. You can refer to the kubernetes pod creation process. This mechanism will lead to excessive load and low efficiency of apiserver
Informer is mainly used to act as the middle layer between apiserver and the controller. Based on the event mechanism, on the one hand, it constructs the local cache, on the other hand, it triggers the event method, so that the controller can respond quickly and obtain data quickly. It mainly uses the list & watch mechanism
The controller does not get the expected state of the object by constantly polling the API and calling list and get
Instead, informer uses the watch mechanism that relies on etcd to know the change state of objects through events and establish a local cache
Etcd’s watch mechanism is a kind of subscription mode mechanism. It listens to one or a group of keys. Any change of keys will send a message
List & watch will only be executed once, that is, first execute list, pull the data to the queue, and then enter the watch stage. In order to enable different apiservers to load these watch requests evenly, the client will actively disconnect from the apiserver with a timeout of 60 seconds, and then reissue the watch request
