The basic logic is :
- We define what CRD we would like to use , ie mysql-operator in github, postgres-operator....
Once they are defined, they will be stored in Etcd. They are purely text file, We can define whatever we want. K8S just regard them as text config file and put them in Etcd. K8S won't check if the CRD has been implemented or not. It won't error out if CRD is not implemented. Related kubectl commands:
lubectl get crd <name> -o yaml kubectl api-resources kubectl api-versions
- We implement the business logic via GO
This part will implement how we handle events related to the CRD we define. K8S will send events to this part, this part will do business logic for the events. K8S cluster is events driven system. All events are put in different queues inside K8S core.
- We create yaml files to use the CRD we define
We create yaml to generate some events (create, update, delete....) to K8S, our 2nd part above will receive these events and do the business logic we implement.
Fortunately kubebuilder does lots of scaffolding work for us. More details Refer kubebuilder book
No comments:
Post a Comment