Skip to content

Latest commit

 

History

History
102 lines (73 loc) · 3.32 KB

running.md

File metadata and controls

102 lines (73 loc) · 3.32 KB

Running and deploying the controller

Optional

If opting to make any changes to the API definitions, then before proceeding, generate the manifests like CRs or CRDs with

make manifests

To test out the controller, we can run it locally against the cluster. Before we do so, though, we'll need to install our CRDs, as per the quick start. This will automatically update the YAML manifests using controller-tools, if needed:

make install

Now that we've installed our CRDs, we can run the controller against our cluster. This will use whatever credentials that we connect to the cluster with, so we don't need to worry about RBAC just yet.

Running webhooks locally

If you want to run the webhooks locally, you'll have to generate certificates for serving the webhooks, and place them in the right directory (/tmp/k8s-webhook-server/serving-certs/tls.{crt,key}, by default).

If you're not running a local API server, you'll also need to figure out how to proxy traffic from the remote cluster to your local webhook server. For this reason, we generally recommend disabling webhooks when doing your local code-run-test cycle, as we do below.

In a separate terminal, run

export ENABLE_WEBHOOKS=false
make run

You should see logs from the controller about starting up, but it won't do anything just yet.

At this point, we need a CronJob to test with. Let's write a sample to config/samples/batch_v1_cronjob.yaml, and use that:

{{#include ./testdata/project/config/samples/batch_v1_cronjob.yaml}}
kubectl create -f config/samples/batch_v1_cronjob.yaml

At this point, you should see a flurry of activity. If you watch the changes, you should see your cronjob running, and updating status:

kubectl get cronjob.batch.tutorial.kubebuilder.io -o yaml
kubectl get job

Now that we know it's working, we can run it in the cluster. Stop the make run invocation, and run

make docker-build docker-push IMG=<some-registry>/<project-name>:tag
make deploy IMG=<some-registry>/<project-name>:tag

Registry Permission

This image ought to be published in the personal registry you specified. And it is required to have access to pull the image from the working environment. Make sure you have the proper permission to the registry if the above commands don't work.

Consider incorporating Kind into your workflow for a faster, more efficient local development and CI experience. Note that, if you're using a Kind cluster, there's no need to push your image to a remote container registry. You can directly load your local image into your specified Kind cluster:

kind load docker-image <your-image-name>:tag --name <your-kind-cluster-name>

To know more, see: Using Kind For Development Purposes and CI

RBAC errors

If you encounter RBAC errors, you may need to grant yourself cluster-admin privileges or be logged in as admin. See Prerequisites for using Kubernetes RBAC on GKE cluster v1.11.x and older which may be your case.

If we list cronjobs again like we did before, we should see the controller functioning again!