Building a Pet Store Operator
Learn to build an operator from scratch and extend the Kubernetes API.
We'll cover the following...
In this lesson, we will build on the background information of CRDs, operators, and controllers to implement our own operator. This operator will have only one CRD, Pet, and only one controller to reconcile those Pet resources. The desired state of Pet will be reconciled to our pet store service, which we used in previous sections.
This will be an example of using Kubernetes control loops to reconcile the state of a resource that has no dependency on other resources within Kubernetes. Remember, we can model anything in CRDs and use Kubernetes as a tool for building robust APIs for any type of resource.
In this lesson, we will learn to build an operator from scratch. We will define a new CRD and controller. We will examine the build tools and the different code generation tools used to eliminate the majority of boilerplate code. We will deploy our controller and the pet store service to a local kind cluster and learn how to use Tilt.dev for faster inner-loop development cycles.
Initializing the new operator
In this lesson, we will initialize the new operator using the operator-sdk command-line tool. This will be used to scaffold out a project structure for our operator:
operator-sdk init --domain example.com --repo github.com/Go-for-DevOps/chapter/14/petstore-operatorgo get sigs.k8s.io/controller-runtime@v0.11.0go mod tidyoperator-sdk create api
With the preceding commands, operator-sdk will scaffold a new operator project using an example domain, which will form the suffix of the group name for our future CRDs. The –repo flag is based on the repo for the book's code, but we would want that to reflect the repo path for our project or omit it and allow it to default. Let's see what is in the repo after scaffolding:
total 368-rw------- 1 david staff 776 Feb 27 10:15 Dockerfile-rw------- 1 david staff 9884 Feb 27 10:16 Makefile-rw------- 1 david staff 261 Feb 27 10:16 PROJECTdrwx------ 8 david staff 256 Feb 27 10:16 config/-rw------- 1 david staff 3258 Feb 27 10:16 go.mod-rw-r--r-- 1 david staff 94793 Feb 27 10:16 go.sumdrwx------ 3 david staff 96 Feb 27 10:15 hack/-rw------- 1 david staff 2791 Feb 27 10:15 main.go
The preceding listing shows the top-level structure of the project. The Dockerfile contains commands to build the controller image. The Makefile contains a variety of helpful tasks; however, we will not use it much in this walk-through. The PROJECT file contains metadata about the operator. The config directory contains the manifests needed to describe and deploy the operator and CRDs to Kubernetes. The hack directory contains a boilerplate license header that will be added to generated files and is a good place to put helpful development or build scripts. The rest of the files are just regular Go application codes.
Now that we have a general idea of what was scaffolded for us, we can move on to generating our Pet resources and controller:
operator-sdk create api --group petstore --version v1alpha1 --kind Pet --resource --controllergo mod tidymake generatemake manifests
By executing the preceding commands, we've instructed operator-sdk to create a new API in the petstore group with the v1alpha1 version of the Pet kind and generate both the CRD and the controller for the type. Note that the command created api/v1alpha1/pet_types.go and controllers/pet_controller.go, and then ran make generate and make manifests. Shortly, we will see that code ...