kubebuilder combat three: a quick overview of basic knowledge

Welcome to my GitHub

https://github.com/zq2599/blog_demos

Content: Classification and summary of all original articles and supporting source code, involving Java, Docker, Kubernetes, DevOPS, etc.;

Links to series of articles

1. kubebuilder combat one: preparation
2. kubebuilder actual combat 2: first experience with kubebuilder
3. kubebuilder combat three: a
4. kubebuilder combat four: operator requirement description and design
5. kubebuilder combat five: operator code
6. kubebuilder combat six: build deployment operation
7. kubebuilder combat seven: webhook
8. kubebuilder combat eight: knowledge points

Overview of this article

• As the third article in the "kubebuilder combat" series, I was supposed to enter the real gun and live ammunition operator development link, but suddenly found that kubebuilder involves too many knowledge points and too scattered. If you type the command and write the code now to fight, even if you complete the operator once Development, but the lack of a lot of information (such as how to arrange the sequence of operations, how to relate the steps, etc.), not only the "kubebuilder combat" series loses reference value, after a few months, even I can not understand these contents, so this Let’s take a shorthand on the knowledge points in the kubebuilder development process, and then start the development work calmly;
• Special note: <font color="blue">webhook</font> is an important function in the operator, and its theory and actual combat require a lot of space, so there will be special articles in this area later, this article will not involve webhook knowledge points ；
• Next, a series of talks begin;

Knowledge reserve

• Can understand the code of kubebuilder official demo, and use client objects to manipulate kubernetes resources. The above two points are the most basic requirements for competent operator development. Otherwise, there will be a feeling of difficulty in the development process. To achieve these conditions requires a small amount of knowledge. Now Xinchen is ready for you, I hope you can briefly browse:
• "Kubernetes Group, Version, Resource Learning Notes"
• "client-go combat one: preparations"
• "client-go combat ii: RESTClient"
• "client-go combat three: Clientset"
• "client-go combat four: dynamicClient"
• "client-go combat five: DiscoveryClient"

Initialize related knowledge points

• The first step to create an operator is to use the kubebuilder command line to create the entire project. This "kubebuilder combat 2: First experience with kubebuilder" . The following three lines of commands were executed at the time:

mkdir -p $GOPATH/src/helloworld
cd $GOPATH/src/helloworld
kubebuilder init --domain com.bolingcavalry

• After using the module, everyone has got rid of the shackles of $GOPATH. Going to <font color="blue">$GOPATH/src</font> as above is a bit awkward. Let’s try it without $ The initialization method of GOPATH;
• Create a new directory anywhere (without Chinese and spaces in the path), such as <font color="blue">/Users/zhaoqin/temp/202102/15/elasticweb</font>
• In the directory, use the <font color="blue">go mod init elasticweb</font> command to create a new project named elasticweb;
• Then execute <font color="blue">kubebuilder init --domain com.bolingcavalry</font> to create a new operator project;

infrastructure

• After the completion of the operator project, many files and directories will be added. The following are the officially mentioned <font color="blue">infrastructure</font>:
• go.mod: module configuration file, which has been filled with several important dependencies;
• Makefile: a very important tool, we have used it before, and we will use it for compiling, building, deploying, and running;
• PROJECT: The metadata of the kubebuilder project, which will be used when generating various APIs;
• config/default: Based on the configuration file made by kustomize, it provides standard configuration for the controller, and it can also be modified and adjusted as needed;
• config/manager: some detailed configuration related to the manager, such as the resource limit of the mirror;

• config/rbac: As the name suggests, if you want to restrict the operator's operation permissions in kubernetes, you must use rbac to do fine permission configuration, which is the details of permission configuration;

  main.go

• main.go is the code automatically generated by kubebuilder. This is the startup code of the operator. There are several points worth noting:
• Two global variables, as shown below, setupLog is used to output logs. Needless to say, scheme is also a commonly used tool. It provides a mapping of data structures in Kind and Go code:

var (
    scheme   = runtime.NewScheme()
    setupLog = ctrl.Log.WithName("setup")
)

2. There are also some settings, such as those related to monitoring indicators, and the manager that manages the controller and webhook. It will run until it is terminated externally. There is one more thing to note about this manager, which is its parameters. The following figure is the default Parameters, if you want the operator to take effect within the specified namespace, you can also add a Namespace parameter in the afternoon. If you want to specify multiple nanospaces, use <font color="blue">cache.MultiNamespacedCacheBuilder(namespaces)</ font>Parameter:

• The content of main.go does not need to be changed in most scenarios, just understand, the next API is the highlight;

API related (data core)

• API is the core of operator. When you decide to use operator, you should start designing the entire CRD based on the real needs, and these designs are ultimately reflected in the data structure of the CRD and the processing logic of the real value and expected value;
• In "kubebuilder combat ii: first experience with kubebuilder" we created the API, the command at that time was:

kubebuilder create api \
--group webapp \
--version v1 \
--kind Guestbook

• • kubebuilder automatically adds a lot of content, as shown in the figure below, all for this CRD service:

• • Among the newly added content, the core of course is the CRD, which is the <font color="blue">guestbook_types.go</font> file where the Guestbook data structure is located in the figure above. The most important data structure is as follows:

type Guestbook struct {
    metav1.TypeMeta   `json:",inline"`
    metav1.ObjectMeta `json:"metadata,omitempty"`

    Spec   GuestbookSpec   `json:"spec,omitempty"`
    Status GuestbookStatus `json:"status,omitempty"`
}

1. metav1.TypeMeta: Group, Version, Kind that saved the resource
2. metav1.ObjectMeta: Save the name and namespace of the resource object
3. Spec: The desired state, for example, the deployment specifies that the pod has three copies when it is created
4. Status: The real status, for example, deployment has only one copy after creation (others have not been created successfully), most resource objects have this field, but ConfigMap is an exception (think about it, configuration information, it’s what you configure, There is no such thing as expected value and true value);
5. There is also a data structure, the GuestbookList corresponding to the Guestbook, which is a collection of single resource objects;
6. There are also two files in the directory where guestbook_types.go is located: groupversion_info.go defines Group and Version, and the instance SchemeBuilder used when registering to the scheme. zz_generated.deepcopy.go is used to implement deep copy of the instance, and they do not need to be modified. Just understand;

Controller related (core of business)

• I talked about the data core before, and then I will discuss how to achieve business requirements. In the development of the operator, although the business logic is different, there are two commonalities:
• Status (real status) is a data structure whose fields are business-defined, and its field values are also calculated by business code executing custom logic;
• The core goal of the business is to ensure that the Status and Spec reach an agreement. For example, the deployment specifies the number of pod copies as 3. If there are no real pods, the controller code of the deployment creates the pods. If the real pods exceed three, The controller code of the deployment deletes the pod;
• The above is what our controller has to do. Next, let’s look at the details of the code. The guestbook_controller.go created by kubebuilder is the controller. Our business code is written in this file. Let’s see what kubebuilder has prepared for us:
• Data structure definition, as shown below, the client tool client.Client, log tool, Kind and data structure relationship scheme used when manipulating resource objects are all prepared for us, so considerate:

type GuestbookReconciler struct {
    client.Client
    Log    logr.Logger
    Scheme *runtime.Scheme
}

4. The SetupWithManager method, which is called in main.go, specifies that the change of the Guestbook resource will be monitored by the manager, thereby triggering the Reconcile method:

func (r *GuestbookReconciler) SetupWithManager(mgr ctrl.Manager) error {
    return ctrl.NewControllerManagedBy(mgr).
        For(&webappv1.Guestbook{}).
        Complete(r)
}

5. As shown in the figure below, there are some comments with the prefix <font color="blue">+kubebuilder:rbac</font> in front of the Reconcile method. These are used to ensure that the controller has the corresponding resource operation permissions at runtime. For example, the red box is me Add it yourself, so that the controller has the right to query pod resource objects:

• guestbook_controller.go is the business core of the operator, and the core of the controller is its Reconcile method. In the future, most of our code will be written in it. The main thing to do is to get the status, and then make the status and spec reach an agreement;
• Regarding the status, the official description is worth paying attention to. The red box in the figure below mainly means that the status of the resource object should be recalculated each time. Here, we take deployment as an example. I want to know how many pods there are currently. There are two methods. The first method prepares a field record, and modifies this field every time a pod is added or deleted. Then you know the number of pods by reading this field. The second method is to use the client tool to query the number of pods in real time each time, currently <font color="red">Officially recommend the second method</font>:

• At this point, the basic knowledge series is complete. Let's go through the knowledge in the order of the official information. Next, we will go to the actual combat in the order of the official information. Let everyone wait for a long time. Next, the operator actual combat;

You are not alone, Xinchen and original are with you all the way

1. Java series
2. Spring series
3. Docker series
4. kubernetes series
5. database + middleware series
6. DevOps series

Welcome to pay attention to the public account: programmer Xin Chen

Search for "Programmer Xin Chen" on WeChat, I am Xin Chen, and I look forward to traveling the Java world with you...
https://github.com/zq2599/blog_demos