Skip to main content
A “local” operator is a workshop build of your controller. A “deployed” operator is a shipped artifact: a container image in a registry plus manifests installed into the cluster. This lesson walks the full packaging and deployment path and verifies that the in-cluster controller can still reconcile a WebApp custom resource.

​
Overview

High-level steps:
  1. Choose an image registry and tag that the cluster nodes can pull.
  2. Build the controller image and tag it with that value.
  3. Push the image to the registry so cluster nodes can fetch it.
  4. Deploy the operator manifests (CRDs, RBAC, ServiceAccount, Deployment) with the image patched to the pushed tag.
  5. Verify the operator’s Deployment becomes available.
  6. Create a demo WebApp custom resource and confirm the in-cluster controller reconciles it.
Important: use a single IMG value for build, push, and deploy. A common packaging mistake is using different tags at each step: you might push one image but deploy another.

​
Set the registry and image tag

Choose a registry reachable from your cluster nodes and export the environment values used by the Makefile:
This IMG value will be used for building, pushing, and deploying the controller image.

​
Build the controller image

Run the Makefile target that builds and tags the manager image:
Notes:
  • The Kubebuilder-generated Makefile passes the tag into Docker.
  • Docker builds the manager image from the project Dockerfile. The resulting image contains the compiled manager binary (not your live source directory).

​
Push the image to the registry

Push the image so cluster nodes can pull it by name:
Pushing makes the image available outside the local Docker cache. Example push output:

​
Deploy the operator manifests

Apply the CRDs, RBAC, ServiceAccount, and the Deployment for the controller manager, and patch the manager image to the IMG value:
You may see the Makefile invoke kustomize to set the image reference, for example:

​
Wait for the operator Deployment to become available

This is an important runtime check: if the image tag is wrong, the registry is unreachable, or the image cannot start, the rollout will fail and surface the error here.
If the wait completes, validate:
  • The Deployment and pods indicate the controller is running as a cluster workload.
  • The CRD is installed so the API server recognizes the WebApp (or webapp) resource.

​
Smoke test: create a WebApp CR and verify reconciliation

Create a demo namespace and apply a sample WebApp custom resource to confirm the installed operator responds to cluster objects (a successful make deploy is not sufficient proof on its own):
You should see the CR creation:
Wait for the child Deployment (the site deployment created by the operator) to become available. This Deployment is created by the in-cluster operator controller and proves it is watching and reconciling the WebApp resource:
Finally, check the WebApp Ready condition from the resource status to confirm the operator reported success:
Expected output: True When that condition is True, the packaging loop is closed: the operator image was built, pushed, installed, and the in-cluster controller reconciled the custom resource and its child resources.
Ensure the registry referenced by IMG_REGISTRY is reachable from your cluster nodes (for example, a local registry may require special configuration or a registry running inside the cluster). If the cluster cannot pull the image, the controller deployment will remain unavailable.

​
Quick reference: common commands

Watch Video