Skip to main content
This lesson walks through recreating the webapp-operator scaffold using Kubebuilder. The objective is to:
  • Initialize the project with the exact course identifiers,
  • Generate CRD manifests from your API types,
  • Build the manager binary to verify the scaffold compiles.
Follow the numbered steps below in order and watch for common slip points noted along the way.
  1. Initialize the Kubebuilder project scaffold
Run kubebuilder init with the exact domain, repository, and project name. These identifiers are critical because downstream labs and generated import paths depend on them.
Make sure the --domain, --repo, and --project-name values exactly match the course. If these are incorrect, the fully qualified group names and import paths will differ and later steps will fail.
  1. Add the WebApp API
Create the API group, version, and kind. Use --resource to generate API types and --controller to scaffold a reconciler:
  • --resource generates the Go types for the custom resource (CR).
  • --controller scaffolds the reconciler (controller) skeleton that watches and reconciles WebApp objects.
After this command completes, confirm the following generated files and locations:
  1. Inspect scheme registration in cmd/main.go
Open cmd/main.go and ensure your API package registers with the manager’s scheme. This registration lets controller-runtime encode/decode webapp.kodekloud.com/v1 objects. A typical snippet looks like:
If the call to webappv1.AddToScheme(scheme) is missing, the manager will not recognize your CRD types at runtime.
  1. Generate CRD manifests
Generate CRD YAML and RBAC manifests using the project’s Makefile target, which runs controller-gen and produces artifacts under config/:
You should see output similar to:
Confirm the CRD YAML exists in config/crd/bases and follows the naming pattern group_domain_plural.yaml, for example:
  • webapp.kodekloud.com_webapps.yaml
If the CRD file is missing or out of date, you most likely edited the Go type definitions without rerunning make manifests. Always regenerate manifests after changing API types.
  1. Sanity build the manager binary
Compile the project to verify it builds cleanly:
This runs a build that produces bin/manager. You can also run the equivalent steps manually:
If the build fails, examine the compiler errors for missing imports or incorrectly defined types in api/ or controllers/.
  1. Confirm project metadata (PROJECT file)
Kubebuilder stores project-wide settings in the PROJECT file at the repository root. Verify the domain, repo, project name, and resources entry. A representative PROJECT YAML:
Verify the resources entry lists group: webapp, version: v1, kind: WebApp, and the correct domain and path. Mismatches here lead to incorrect scaffold behavior and import path errors.
  1. Summary & next steps
  • kubebuilder init sets up the project with the correct domain/repo/project name.
  • kubebuilder create api adds the API types and controller scaffold.
  • make manifests generates CRD YAML from API markers.
  • make build compiles the manager binary to confirm the scaffold is valid.
This scaffold is the skeleton of your operator. After validating it, implement the controller logic in controllers/webapp_controller.go, update your API types in api/v1/webapp_types.go, and keep regenerating manifests whenever you modify the API. Links and references

Watch Video