Kubernetes' in-depth understanding of kubernetes (II) declaring organizational objects

Core technology concepts and API object

---

Almost all objects contain the above four categories of attributes .

 

 

 

TypeMeta

---

Java There will be package management , There will be different classes in each package , We will put classes of the same type in a package ,kubernets It's the same , For each managed object , It has one kind,kubermets The same function , These objects with the same purpose are put into one group Inside ,kind Defines what it is ,group It is a way to organize different objects .

version Is used to support api A setting for forward compatibility , Versions are evolving ,kubernets The first version of this model will be designed as v1aplpha1, It's a alpha edition , As the version evolves , It will continue to upgrade this version , If it's a demo Version of , So forever alpha The stage of ,v1alpha1->v1alpha2->v1alpha3, If you think the function is relatively mature , You can try it , Almost ready for production , It will become beta, It will become v1beta1,v1beta1->v1beta2->v1beta3, Until I think this function is ready for production , This model basically won't change , This time will turn him into v1.

So it will have continuous version evolution , But version evolution should be forward compatible , that kubernetes For each object, we added version The control of , So when an object from v1alpha1 To v1alpha2 The evolution of , In this transitional version, it will support both versions , That is to say, we can start from v1alpha1 To access it , You can also get it from v1alpha2 To access it , But in kubernetes It's inside apiserver On the level of , It has achieved conversion Methods , Used to be responsible for the conversion between different versions , So-called version It is used to control the version .

So the whole thing typemeta It defines which group an object belongs to , What kind of , Which version of , So it basically defines what the object is .

 

Metadata 

---

Defines the original data of the object ,namespace Is used to place objects , Objects can pass through namespace Isolation .

Any kubernetes The objects of are divided into two categories , A class of objects like nodes , A computing node belongs to the entire cluster , Such objects are nonnamespace, its namespace The value is always empty .

The other is pod,service, All belong to a tenant / User , These objects belong to namespace.

An object namespace+name It represents the unique value in the whole cluster .

 typemeta Defines what I am ,metadata Defines who I am .

An object , When we created it , Send the request for this object to apiserver,apiserver After authentication, it is stored in etcd, If you delete this object , It also goes through the same link , It finally came from etcd Delete , The deletion itself is a physical deletion , amount to etcd This data is erased , The object disappears .

If the controller is written to monitor this object , Then it will listen to the creation of this object , Once this object is created, it will do something , When the object is deleted, it will do other things , We can't believe that the system is always working , Suppose the controller is wrong , Or the controller is being upgraded , The controller is not working at this time , Delete the object at this time , Suppose the object disappears , So this event has disappeared , After this object is deleted , Then start my controller , The controller cannot see the event that this object was deleted before , Because this event has already occurred before the controller is started , When starting a new controller instance , There is no notification of this message , Therefore, the event of object deletion is lost .

therefore fanalizer It is essentially a resource lock , An object is added finalizer, Physical deletion will not be performed when deleting objects , It will do logical deletion , In fact, it is in the event stamp of its attribute deletetimestamp Set to delete the timestamp at that moment .

The advantage is that when the user deletes an object , If the object has finalzer, Then this object will not disappear , The controller can then capture the event , Even when the controller is under maintenance , Then you can see this event after restarting , When an object is found deletetimestamp Not empty , Indicates that the user wants to delete it , Then some logic processing can be done in the controller .

resourceversion

It is also a lock , In the microservice scenario, if there are multiple components to modify an object , How to ensure the access security of objects .

That is, when multiple processes modify an object , How to ensure its safety .

The first is locking , You can modify it after locking it , When other processes or threads want to access the same object, they have to wait for the lock , If you can't get the lock, it will block , What problems does this approach bring ？ First of all, it is particularly safe , Secondly, many threads will block , Especially in the case of high concurrency , One gets the lock , Other people want to access the same resources , Then it needs to wait , In such a system, many processes will be blocked , So the efficiency of the whole system is low .

There is also an optimistic lock , Can you record a version information in one way , When two threads access the same object , At this time, add a version number to the object , such as v1, So all we got were from this object v1 edition , At this time, two people should modify the object at the same time , Although these two modification objects occur at the same time , But requests are sent to apiserver This end , When apiserver When this end receives the request , It must be handled first , A post-processing , It is also executed sequentially . At this time, when it processes the first request , It will see in v1 The version of , You have to update a property , This request is legal , that apiserver This request will be processed , Update this property , And change the version to v2, When processing the second request , It will also look at the version number of the second request , At present server The end version changes to v2 了 , Explain that the previous request is illegal , It is based on an old version of data , So I will refuse this request .

therefore resourceversion This is the version information , It is an optimistic lock , It maintains the version information of the object , When each component wants to modify the same object, it should bring the version , from apiserver To determine whether it is modified based on the latest version , If not, refuse , If so, accept , In this way, multiple components can modify the same object in an unlocked state .

apiserver Rejected a request , Then the client is obliged to get the latest version and try again , In this case, the system is running in an unlocked state .

  When querying objects, you can use the tag filter to query .

 

 

spec and status

---

 spec It's user input , That is what I expect you to be .

Every object has a controller ,status It is configured by the controller , Write back to this object after the configuration is completed ,status It is controlled by the controller .

 

 

Commonly used Kubernetes Objects and groups

---

You can see that different objects are placed in different group Inside , The core business is supported by core/v1 Inside , Application management needs to be done in apps/v1.