You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
OpenAPIv3 schemas are added to CRD manifests in the `spec.validation` block when the manifests are generated. This validation block allows Kubernetes to validate the properties in a Memcached Custom Resource when it is created or updated.
8
+
9
+
[Markers][markers] (annotations) are available to configure validations for your API. These markers will always have a `+kubebuilder:validation` prefix.
10
+
11
+
Usage of markers in API code is discussed in the kubebuilder [CRD generation][generating-crd] and [marker][markers] documentation. A full list of OpenAPIv3 validation markers can be found [here][crd-markers].
12
+
13
+
To learn more about OpenAPI v3.0 validation schemas in CRDs, refer to the [Kubernetes Documentation][doc-validation-schema].
Read the [operator scope][operator_scope] documentation on how to run your operator as namespace-scoped vs cluster-scoped.
63
60
64
-
### Multi-Group APIs
65
-
66
-
Before creating an API and controller, consider if your operator requires multiple API [groups][api-groups]. Then to change the layout of your project to support multi-group run the command `operator-sdk edit --multigroup`. It will update the `PROJECT` file which should look like the following:
67
-
68
-
```YAML
69
-
domain: example.com
70
-
layout: go.kubebuilder.io/v3
71
-
multigroup: true
72
-
...
73
-
```
74
-
For multi-group projects, the API Go type files are created under `apis/<group>/<version>/` and the controllers under `controllers/<group>/` and then, the Dockerfile will be updated accordingly. For further information see the [multi-group migration doc][multigroup-kubebuilder-doc]
75
-
76
-
This guide will cover the default case of a single group API.
77
-
78
61
## Create a new API and Controller
79
62
80
63
Create a new Custom Resource Definition(CRD) API with group `cache` version `v1alpha1` and Kind Memcached.
This will scaffold the Memcached resource API at `api/v1alpha1/memcached_types.go` and the controller at `controllers/memcached_controller.go`.
92
75
93
-
See the [API terminology doc][api_terms_doc] for details on the CRD API conventions.
76
+
**Note:** This guide will cover the default case of a single group API. If you would like to support Multi-Group APIs see the [Single Group to Multi-Group][multigroup-kubebuilder-doc] doc.
77
+
78
+
#### Understanding Kubernetes APIs
94
79
95
-
To understand the API Go types and controller scaffolding see the Kubebuilder [api doc][kb_api_doc] and [controller doc][kb_controller_doc].
80
+
For an in-depth explanation of Kubernetes APIs and the group-version-kind model, check out these [kubebuilder docs][kb-doc-gkvs].
81
+
82
+
In general, it's recommended to have one controller responsible for manage each API created for the project to
83
+
properly follow the design goals set by [controller-runtime][controller-runtime].
96
84
97
85
### Define the API
98
86
87
+
To begin, we will represent our API by defining the `Memcached` type, which will have a `MemcachedSpec.Size` field to set the quantity of memcached instances (CRs) to be deployed, and a `MemcachedStatus.Nodes` field to store a CR's Pod names.
88
+
89
+
**Note** The Node field is just to illustrate an example of a Status field. In real cases, it would be recommended to use [Conditions][conditionals].
90
+
99
91
Define the API for the Memcached Custom Resource(CR) by modifying the Go type definitions at `api/v1alpha1/memcached_types.go` to have the following spec and status:
100
92
101
93
```Go
@@ -143,30 +135,20 @@ Once the API is defined with spec/status fields and CRD validation markers, the
143
135
make manifests
144
136
```
145
137
146
-
This makefile target will invoke controller-gen to generate the CRD manifests at `config/crd/bases/cache.example.com_memcacheds.yaml`.
147
-
148
-
#### OpenAPI validation
149
-
150
-
OpenAPIv3 schemas are added to CRD manifests in the `spec.validation` block when the manifests are generated. This validation block allows Kubernetes to validate the properties in a Memcached Custom Resource when it is created or updated.
138
+
This makefile target will invoke [controller-gen][controller_tools] to generate the CRD manifests at `config/crd/bases/cache.example.com_memcacheds.yaml`.
151
139
152
-
Markers (annotations) are available to configure validations for your API. These markers will always have a `+kubebuilder:validation` prefix.
140
+
### OpenAPI validation
153
141
154
-
Usage of markers in API code is discussed in the kubebuilder [CRD generation][generating-crd] and [marker][markers] documentation. A full list of OpenAPIv3 validation markers can be found [here][crd-markers].
142
+
OpenAPI validation defined in a CRD ensures CRs are validated based on a set of declarative rules. All CRDs should have validation.
143
+
See the [OpenAPI valiation][openapi-validation] doc for details.
155
144
156
-
To learn more about OpenAPI v3.0 validation schemas in CRDs, refer to the [Kubernetes Documentation][doc-validation-schema].
157
-
158
-
### Implement the Controller
145
+
## Implement the Controller
159
146
160
147
For this example replace the generated controller file `controllers/memcached_controller.go` with the example [`memcached_controller.go`][memcached_controller] implementation.
161
148
162
-
The example controller executes the following reconciliation logic for each Memcached CR:
163
-
- Create a memcached Deployment if it doesn't exist
164
-
- Ensure that the Deployment size is the same as specified by the Memcached CR spec
165
-
- Update the Memcached CR status using the status writer with the names of the memcached pods
166
-
167
-
The next two subsections explain how the controller watches resources and how the reconcile loop is triggered. Skip to the ["run the Operator"](#run-the-operator) section to see how to build and run the operator.
149
+
**Note**: The next two subsections explain how the controller watches resources and how the reconcile loop is triggered. Skip to the [Build](#build-and-push-the-image) section to see how to build and run the operator.
168
150
169
-
####Resources watched by the Controller
151
+
### Resources watched by the Controller
170
152
171
153
The `SetupWithManager()` function in `controllers/memcached_controller.go` specifies how the controller is built to watch a CR and other resources that are owned and managed by that controller.
172
154
@@ -191,7 +173,7 @@ The `NewControllerManagedBy()` provides a controller builder that allows various
191
173
192
174
`Owns(&appsv1.Deployment{})` specifies the Deployments type as the secondary resource to watch. For each Deployment type Add/Update/Delete event, the event handler will map each event to a reconcile `Request` for the owner of the Deployment. Which in this case is the Memcached object for which the Deployment was created.
193
175
194
-
####Controller Configurations
176
+
### Controller Configurations
195
177
196
178
There are a number of other useful configurations that can be made when initialzing a controller. For more details on these configurations consult the upstream [builder][builder_godocs] and [controller][controller_godocs] godocs.
197
179
@@ -208,10 +190,11 @@ There are a number of other useful configurations that can be made when initialz
208
190
- Filter watch events using [predicates][event_filtering]
209
191
- Choose the type of [EventHandler][event_handler_godocs] to change how a watch event will translate to reconcile requests for the reconcile loop. For operator relationships that are more complex than primary and secondary resources, the [`EnqueueRequestsFromMapFunc`][enqueue_requests_from_map_func] handler can be used to transform a watch event into an arbitrary set of reconcile requests.
210
192
193
+
### Reconcile loop
211
194
212
-
#### Reconcile loop
195
+
The reconcile function is responsible for enforcing the desired CR state on the actual state of the system. It runs each time an event occurs on a watched CR or resource, and will return some value depending on whether those states match or not.
213
196
214
-
Every Controller has a Reconciler object with a `Reconcile()` method that implements the reconcile loop. The reconcile loop is passed the [`Request`][request-go-doc] argument which is a Namespace/Name key used to lookup the primary resource object, Memcached, from the cache:
197
+
In this way, every Controller has a Reconciler object with a `Reconcile()` method that implements the reconcile loop. The reconcile loop is passed the [`Request`][request-go-doc] argument which is a Namespace/Name key used to lookup the primary resource object, Memcached, from the cache:
For a guide on Reconcilers, Clients, and interacting with resource Events, see the [Client API doc][doc_client_api].
236
+
For more details, check the Reconcile and its [Reconcile godoc][reconcile-godoc].
254
237
255
238
### Specify permissions and generate RBAC manifests
256
239
257
-
The controller needs certain RBAC permissions to interact with the resources it manages. These are specified via [RBAC markers][rbac_markers] like the following:
240
+
The controller needs certain [RBAC][rbac-k8s-doc] permissions to interact with the resources it manages. These are specified via [RBAC markers][rbac_markers] like the following:
@@ -284,15 +267,11 @@ There are three ways to run the operator:
284
267
285
268
### 1. Run locally outside the cluster
286
269
287
-
Execute the following command, which install your CRDs and run the manager locally:
288
-
289
-
```sh
290
-
make install run ENABLE_WEBHOOKS=false
291
-
```
270
+
The following steps will show how to deploy the operator on the Cluster. However, to run locally for development purposes and outside of a Cluster use the target `make install run`.
292
271
293
272
### 2. Run as a Deployment inside the cluster
294
273
295
-
####Build and push the image
274
+
### Build and push the image
296
275
297
276
Before building the operator image, ensure the generated Dockerfile references
298
277
the base image you want. You can change the default "runner" image `gcr.io/distroless/static:nonroot`
@@ -331,9 +310,6 @@ Run the following to deploy the operator. This will also install the RBAC manife
331
310
make deploy IMG=quay.io/$USERNAME/memcached-operator:v0.0.1
332
311
```
333
312
334
-
*NOTE* If you have enabled webhooks in your deployments, you will need to have cert-manager already installed
335
-
in the cluster or `make deploy` will fail when creating the cert-manager resources.
336
-
337
313
Verify that the memcached-operator is up and running:
338
314
339
315
```console
@@ -368,7 +344,6 @@ operator-sdk run bundle $BUNDLE_IMG
368
344
369
345
Check out the [docs][quickstart-bundle] for a deep dive into `operator-sdk`'s OLM integration.
370
346
371
-
372
347
## Create a Memcached CR
373
348
374
349
Update the sample Memcached CR manifest at `config/samples/cache_v1alpha1_memcached.yaml` and define the `spec` as the following:
@@ -454,12 +429,11 @@ make undeploy
454
429
455
430
## Further steps
456
431
457
-
The following guides build off the operator created in this example, adding advanced features:
458
-
459
-
-[Create a validating or mutating Admission Webhook][create_a_webhook]
460
-
461
-
Also see the [advanced topics][advanced_topics] doc for more use cases and under the hood details.
432
+
Next, try adding the following to your project:
433
+
1. Validating and mutating [admission webhooks][create_a_webhook].
434
+
2. Operator packaging and distribution with [OLM][olm-integration].
462
435
436
+
Also see the [advanced topics][advanced_topics] doc for more use cases and under the hood details.
0 commit comments