Why do you want to be a controller
The role of the controller is to monitor the addition, deletion, modification and other changes of the specified object, and make corresponding responses to these changes (for example, the response of the newly added pod is to create a docker container),
As shown in the figure above, the changes of API objects will be stored in the queue (WorkQueue) through the Informer, and the data of the queue will be consumed in the Controller to respond, and the specific code related to the response is the real business logic we need to do;
What is the automatic code generation?
From the above figure, we can find that the whole logic is relatively complicated. In order to simplify the development of our custom controller, the masters of k8s use the automatic code generation tool to do everything outside the controller. We only need to focus on The development of the controller is good.
Regarding the controller code, we will leave it to the next chapter to complete. This chapter focuses on the actual combat of how to automatically generate code, and completes all things other than the controller in the above figure;
Start the actual combat
The next thing to do is to write the definition code of the API object Student-related declaration, and then use the code generation tool to combine these codes to automatically generate the code related to Client, Informet, and WorkQueue;
1. Create a folder k8s_customize_controller in the $GOPATH/src/ directory:
2. Enter the folder k8s_customize_controller and execute the following command to create a three-level directory:
mkdir -p pkg/apis/bolingcavalry
3. Create a file register in the newly created bolingcavalry directory .go with the following content:
package bolingcavalry
const (
GroupName = "bolingcavalry.k8s.io"
Version = "v1"
)4. Create a folder named v1 in the newly created bolingcavalry directory;
5. Create a file doc.go in the newly created v1 folder with the following contents:
// +k8s:deepcopy-gen=package
// +groupName=bolingcavalry.k8s.io
package v1The two lines of comments in the above code are all used by the code generation tool. One is to declare that the DeepCopy method is generated for the type definition under the entire v1 package, and the other is to declare the group name of the API corresponding to this package, and the CRD in the The group name is the same;
6. Create a file types.go in the v1 folder, which defines the specific content of the Student object:
package v1
import (
metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
)
// +genclient
// +genclient:noStatus
// +k8s:deepcopy-gen:interfaces=k8s.io/apimachinery/pkg/runtime.Object
type Student struct {
metav1.TypeMeta `json:",inline"`
metav1.ObjectMeta `json:"metadata,omitempty"`
Spec StudentSpec `json:"spec"`
}
type StudentSpec struct {
name string `json:"name"`
school string `json:"school"`
}
// +k8s:deepcopy-gen:interfaces=k8s.io/apimachinery/pkg/runtime.Object
// StudentList is a list of Student resources
type StudentList struct {
metav1.TypeMeta `json:",inline"`
metav1.ListMeta `json:"metadata"`
Items []Student `json:"items"`
}
It can be seen from the above source code that the content of the Student object has been set. There are mainly two fields, name and school, which represent the student's name and school. Therefore, when the Student object is created, the content must match here;
7. In Create the register.go file in the v1 directory. The function of this file is to make the client know the API object of the Student type through the addKnownTypes method:
package v1
import (
metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
"k8s.io/apimachinery/pkg/runtime"
"k8s.io/apimachinery/pkg/runtime/schema"
"k8s_customize_controller/pkg/apis/bolingcavalry"
)
var SchemeGroupVersion = schema.GroupVersion{
Group: bolingcavalry.GroupName,
Version: bolingcavalry.Version,
}
var (
SchemeBuilder = runtime.NewSchemeBuilder(addKnownTypes)
AddToScheme = SchemeBuilder.AddToScheme
)
func Resource(resource string) schema.GroupResource {
return SchemeGroupVersion.WithResource(resource).GroupResource()
}
func Kind(kind string) schema.GroupKind {
return SchemeGroupVersion.WithKind(kind).GroupKind()
}
func addKnownTypes(scheme *runtime.Scheme) error {
scheme.AddKnownTypes(
SchemeGroupVersion,
&Student{},
&StudentList{},
)
// register the type in the scheme
metav1.AddToGroupVersion(scheme, SchemeGroupVersion)
return nil
}
8. At this point, the preparations for the automatic code generation have been completed. So far, the file and directory structure in the $GOPATH/src directory is as follows:
[root@golang src]# tree
.
└── k8s_customize_controller
└── pkg
└── apis
└── bolingcavalry
├── register.go
└── v1
├── doc.go
├── register.go
└── types.go
5 directories, 4 files
9. Execute the following command, the dependency package will be downloaded first, then the code generation tool will be downloaded, and then the code generation will be executed:
cd $GOPATH/src \
&& go get -u k8s.io/apimachinery/pkg/apis/meta/v1 \
&& go get -u k8s.io/code-generator/... \
&& cd $GOPATH/src/k8s.io/code-generator \
&& ./generate-groups.sh all \
k8s_customize_controller/pkg/client \
k8s_customize_controller/pkg/apis \
bolingcavalry:v1
If the code is written correctly, you will see the following output:
Generating deepcopy funcs
Generating clientset for bolingcavalry:v1 at k8s_customize_controller/pkg/client/clientset
Generating listers for bolingcavalry:v1 at k8s_customize_controller/pkg/client/listers
Generating informers for bolingcavalry:v1 at k8s_customize_controller/pkg/client/informers
10. At this point, go to the $GOPATH/src/k8s_customize_controller directory and execute the tree command. It can be seen that a lot of content has been generated:
[root@master k8s_customize_controller]# tree
.
└── pkg
├── apis
│ └── bolingcavalry
│ ├── register.go
│ └── v1
│ ├── doc.go
│ ├── register.go
│ ├── types.go
│ └── zz_generated.deepcopy.go
└── client
├── clientset
│ └── versioned
│ ├── clientset.go
│ ├── doc.go
│ ├── fake
│ │ ├── clientset_generated.go
│ │ ├── doc.go
│ │ └── register.go
│ ├── scheme
│ │ ├── doc.go
│ │ └── register.go
│ └── typed
│ └── bolingcavalry
│ └── v1
│ ├── bolingcavalry_client.go
│ ├── doc.go
│ ├── fake
│ │ ├── doc.go
│ │ ├── fake_bolingcavalry_client.go
│ │ └── fake_student.go
│ ├── generated_expansion.go
│ └── student.go
├── informers
│ └── externalversions
│ ├── bolingcavalry
│ │ ├── interface.go
│ │ └── v1
│ │ ├── interface.go
│ │ └── student.go
│ ├── factory.go
│ ├── generic.go
│ └── internalinterfaces
│ └── factory_interfaces.go
└── listers
└── bolingcavalry
└── v1
├── expansion_generated.go
└── student.go
21 directories, 27 files
As shown above, zz_generated.deepcopy.go is the DeepCopy code file, and the content in the client directory is the client-related code, which will be used when developing the controller;
the identities and functions of the clientset, informers, and listers in the client directory can be the same as the previous ones. to understand by combining the diagrams;
At this point, the steps of automatically generating code have been completed, and we are fully prepared for writing the controller later. The next chapter is to write the controller.