-
Notifications
You must be signed in to change notification settings - Fork 1.4k
/
running.md
85 lines (62 loc) · 2.49 KB
/
running.md
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
# 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
```bash
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](/quick-start.md). This will automatically update the YAML
manifests using controller-tools, if needed:
```bash
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.
<aside class="note">
<h1>Running webhooks locally</h1>
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.
</aside>
In a separate terminal, run
```bash
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:
```yaml
{{#include ./testdata/project/config/samples/batch_v1_cronjob.yaml}}
```
```bash
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:
```bash
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
```bash
make docker-build docker-push IMG=<some-registry>/<project-name>:tag
make deploy IMG=<some-registry>/<project-name>:tag
```
<aside class="note">
<h1>registry permission</h1>
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.
</aside>
If we list cronjobs again like we did before, we should see the controller
functioning again!