Skip to main content
The deployment helper describes the desired state for a child Deployment. In the Reconcile loop, we must:
  • construct that desired Deployment,
  • set an owner reference so the parent WebApp controls the child,
  • look up whether the child already exists, and
  • create it if it does not (the get-or-create pattern).
Below we walk through the imports and the Reconcile wiring step-by-step.

Minimal imports (starting point)

Start with the minimal imports you already had for the controller:
These are required to reference the Kubernetes Deployment and core types in Go. Next we expand imports to handle error recognition, namespaced lookups, and owner references.

Expanded imports (recognize not-found and build lookup keys)

Add the API error helper and types so the controller can detect “not found” and form lookup keys:
These additions let you call apierrors.IsNotFound(err) and work with metadata types.

Final import set (needed by Get/Create and setting owner refs)

We add types, controllerutil, runtime, and the controller-runtime client so the Get/Create and SetControllerReference code compiles and runs:
These imports do not create resources by themselves; they enable the Get/Create and owner-setting code to compile.
Always keep imports minimal but explicit. Add apierrors to check for IsNotFound and controllerutil to set owner references. This makes your controller resilient to the common “get or create” reconciliation pattern.

Wiring the Deployment in Reconcile

After you fetch the WebApp resource inside Reconcile, call the deployment helper and set the controller reference on the desired Deployment. The helper returns an *appsv1.Deployment representing the state you want in the cluster.
  • desiredDeploy is the desired child object.
  • controllerutil.SetControllerReference sets the owner reference so garbage collection and ownership semantics work.
Example Reconcile skeleton with these steps:
The scheme tells controller-runtime how Go types map to Kubernetes API resource kinds. The SetControllerReference call follows the standard Go error pattern: functions return an error value which you must check.

Lookup (get-or-create) and create-if-missing

Declare an empty found Deployment and query the API server using a NamespacedName made from the desired deployment’s namespace and name. If the Get returns a “not found” error, create the desired Deployment. Otherwise, if another error occurred, return it. Complete Get-or-create pattern:
This pattern avoids creating duplicates and keeps the first reconcile loop simple. You can add update/drift-repair logic later to reconcile spec differences.
When calling SetControllerReference, ensure the owner and object types are valid and the scheme includes the owner type. Otherwise SetControllerReference will return an error and reconciliation should stop.

Example deployment helper

We intentionally keep the Deployment shape consistent with the WebApp spec. The helper returns a Deployment configured with labels, replicas, and a Pod template using the WebApp image.
This keeps the Deployment consistent with the WebApp resource and makes it straightforward to compare and reconcile later.

Build and test locally

After wiring the controller, run a local build to ensure there are no compile-time errors, then run the manager and apply the sample WebApp manifest:
Run the manager (attached to the first terminal), then in another terminal apply the sample:
Seeing the Deployment named webapp-sample confirms the parent WebApp created the child workload successfully.

Repetition and pattern reuse

The same get-or-create pattern is repeated for other child objects such as ConfigMaps and Services. Repetition is useful because most reconciler code follows this pattern:
Table — Common reconciliation checks This wiring — importing the right helpers, creating a desired object, setting the controller reference, and using a safe get-or-create pattern — is the core of many Kubernetes reconciler implementations.

Watch Video