Skip to content

Commit 35accbf

Browse files
authored
Merge pull request #27667 from adellape/operators_apiupdate
Update Operator modules for API object & unwrap changes
2 parents 28852b3 + bf0fc02 commit 35accbf

File tree

158 files changed

+1234
-2648
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

158 files changed

+1234
-2648
lines changed

_topic_map.yml

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -932,7 +932,7 @@ Topics:
932932
File: olm-workflow
933933
- Name: Dependency resolution
934934
File: olm-understanding-dependency-resolution
935-
- Name: OperatorGroups
935+
- Name: Operator groups
936936
File: olm-understanding-operatorgroups
937937
- Name: Metrics
938938
File: olm-understanding-metrics
@@ -996,7 +996,7 @@ Topics:
996996
File: osdk-ansible
997997
- Name: Creating Helm-based Operators
998998
File: osdk-helm
999-
- Name: Generating a ClusterServiceVersion (CSV)
999+
- Name: Generating a cluster service version (CSV)
10001000
File: osdk-generating-csvs
10011001
- Name: Working with bundle images
10021002
File: osdk-working-bundle-images

modules/building-memcached-operator-using-osdk.adoc

Lines changed: 39 additions & 95 deletions
Original file line numberDiff line numberDiff line change
@@ -5,14 +5,9 @@
55
[id="building-memcached-operator-using-osdk_{context}"]
66
= Building a Go-based Operator using the Operator SDK
77

8-
The Operator SDK makes it easier to build Kubernetes native applications, a
9-
process that can require deep, application-specific operational knowledge. The
10-
SDK not only lowers that barrier, but it also helps reduce the amount of
11-
boilerplate code needed for many common management capabilities, such as
12-
metering or monitoring.
8+
The Operator SDK makes it easier to build Kubernetes native applications, a process that can require deep, application-specific operational knowledge. The SDK not only lowers that barrier, but it also helps reduce the amount of boilerplate code needed for many common management capabilities, such as metering or monitoring.
139

14-
This procedure walks through an example of building a simple Memcached Operator
15-
using tools and libraries provided by the SDK.
10+
This procedure walks through an example of building a simple Memcached Operator using tools and libraries provided by the SDK.
1611

1712
.Prerequisites
1813

@@ -48,10 +43,9 @@ $ operator-sdk new memcached-operator
4843
$ cd memcached-operator
4944
----
5045

51-
. *Add a new Custom Resource Definition (CRD).*
46+
. *Add a new custom resource definition (CRD).*
5247

53-
.. Use the CLI to add a new CRD API called `Memcached`, with `APIVersion` set to
54-
`cache.example.com/v1apha1` and `Kind` set to `Memcached`:
48+
.. Use the CLI to add a new CRD API called `Memcached`, with `APIVersion` set to `cache.example.com/v1apha1` and `Kind` set to `Memcached`:
5549
+
5650
[source,terminal]
5751
----
@@ -62,8 +56,7 @@ $ operator-sdk add api \
6256
+
6357
This scaffolds the Memcached resource API under `pkg/apis/cache/v1alpha1/`.
6458

65-
.. Modify the spec and status of the `Memcached` Custom Resource (CR) at the
66-
`pkg/apis/cache/v1alpha1/memcached_types.go` file:
59+
.. Modify the spec and status of the `Memcached` custom resource (CR) at the `pkg/apis/cache/v1alpha1/memcached_types.go` file:
6760
+
6861
[source,go]
6962
----
@@ -77,8 +70,7 @@ type MemcachedStatus struct {
7770
}
7871
----
7972

80-
.. After modifying the `*_types.go` file, always run the following command to
81-
update the generated code for that resource type:
73+
.. After modifying the `*_types.go` file, always run the following command to update the generated code for that resource type:
8274
+
8375
[source,terminal]
8476
----
@@ -87,39 +79,21 @@ $ operator-sdk generate k8s
8779

8880
. *Optional: Add custom validation to your CRD.*
8981
+
90-
OpenAPI v3.0 schemas are added to CRD manifests in the `spec.validation` block when
91-
the manifests are generated. This validation block allows Kubernetes to validate
92-
the properties in a Memcached CR when it is created or updated.
82+
OpenAPI v3.0 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 CR when it is created or updated.
9383
+
94-
Additionally, a `pkg/apis/<group>/<version>/zz_generated.openapi.go` file is
95-
generated. This file contains the Go representation of this validation block if
96-
the `+k8s:openapi-gen=true annotation` is present above the `Kind` type
97-
declaration, which is present by default. This auto-generated code is your Go
98-
`Kind` type's OpenAPI model, from which you can create a full OpenAPI
99-
Specification and generate a client.
84+
Additionally, a `pkg/apis/<group>/<version>/zz_generated.openapi.go` file is generated. This file contains the Go representation of this validation block if the `+k8s:openapi-gen=true annotation` is present above the `Kind` type declaration, which is present by default. This auto-generated code is the OpenAPI model of your Go `Kind` type, from which you can create a full OpenAPI Specification and generate a client.
10085
+
101-
As an Operator author, you can use Kubebuilder markers (annotations) to
102-
configure custom validations for your API. These markers must always have a
103-
`+kubebuilder:validation` prefix. For example, adding an enum-type specification
104-
can be done by adding the following marker:
86+
As an Operator author, you can use Kubebuilder markers (annotations) to configure custom validations for your API. These markers must always have a `+kubebuilder:validation` prefix. For example, adding an enum-type specification can be done by adding the following marker:
10587
+
10688
[source,go]
10789
----
10890
// +kubebuilder:validation:Enum=Lion;Wolf;Dragon
10991
type Alias string
11092
----
11193
+
112-
Usage of markers in API code is discussed in the Kubebuilder
113-
link:https://book.kubebuilder.io/reference/generating-crd.html[Generating CRDs]
114-
and link:https://book.kubebuilder.io/reference/markers.html[Markers for Config/Code Generation]
115-
documentation. A full list of OpenAPIv3 validation markers is also available in
116-
the Kubebuilder
117-
link:https://book.kubebuilder.io/reference/markers/crd-validation.html[CRD Validation]
118-
documentation.
94+
Usage of markers in API code is discussed in the Kubebuilder link:https://book.kubebuilder.io/reference/generating-crd.html[Generating CRDs] and link:https://book.kubebuilder.io/reference/markers.html[Markers for Config/Code Generation] documentation. A full list of OpenAPIv3 validation markers is also available in the Kubebuilder link:https://book.kubebuilder.io/reference/markers/crd-validation.html[CRD Validation] documentation.
11995
+
120-
If you add any custom validations, run the following command to update the
121-
OpenAPI validation section in the CRD's
122-
`deploy/crds/cache.example.com_memcacheds_crd.yaml` file:
96+
If you add any custom validations, run the following command to update the OpenAPI validation section in the `deploy/crds/cache.example.com_memcacheds_crd.yaml` file for the CRD:
12397
+
12498
[source,terminal]
12599
----
@@ -140,10 +114,9 @@ spec:
140114
type: integer
141115
----
142116

143-
. *Add a new Controller.*
117+
. *Add a new controller.*
144118

145-
.. Add a new Controller to the project to watch and reconcile the Memcached
146-
resource:
119+
.. Add a new controller to the project to watch and reconcile the `Memcached` resource:
147120
+
148121
[source,terminal]
149122
----
@@ -152,44 +125,31 @@ $ operator-sdk add controller \
152125
--kind=Memcached
153126
----
154127
+
155-
This scaffolds a new Controller implementation under
156-
`pkg/controller/memcached/`.
128+
This scaffolds a new controller implementation under `pkg/controller/memcached/`.
157129

158-
.. For this example, replace the generated controller file
159-
`pkg/controller/memcached/memcached_controller.go` with the
160-
link:https://github.com/operator-framework/operator-sdk/blob/master/example/memcached-operator/memcached_controller.go.tmpl[example implementation].
130+
.. For this example, replace the generated controller file `pkg/controller/memcached/memcached_controller.go` with the link:https://github.com/operator-framework/operator-sdk/blob/master/example/memcached-operator/memcached_controller.go.tmpl[example implementation].
161131
+
162-
The example controller executes the following reconciliation logic for each
163-
`Memcached` CR:
132+
The example controller executes the following reconciliation logic for each `Memcached` resource:
164133
+
165134
--
166-
* Create a Memcached Deployment if it does not exist.
135+
* Create a Memcached deployment if it does not exist.
167136
* Ensure that the Deployment size is the same as specified by the `Memcached` CR spec.
168-
* Update the `Memcached` CR status with the names of the Memcached pods.
137+
* Update the `Memcached` resource status with the names of the Memcached pods.
169138
--
170139
+
171-
The next two sub-steps inspect how the Controller watches resources and how the
172-
reconcile loop is triggered. You can skip these steps
173-
to go directly to building and running the Operator.
140+
The next two sub-steps inspect how the controller watches resources and how the reconcile loop is triggered. You can skip these steps to go directly to building and running the Operator.
174141

175-
.. Inspect the Controller implementation at the
176-
`pkg/controller/memcached/memcached_controller.go` file to see how the
177-
Controller watches resources.
142+
.. Inspect the controller implementation at the `pkg/controller/memcached/memcached_controller.go` file to see how the controller watches resources.
178143
+
179-
The first watch is for the Memcached type as the primary resource. For each Add,
180-
Update, or Delete event, the reconcile loop is sent a reconcile `Request` (a
181-
`<namespace>:<name>` key) for that Memcached object:
144+
The first watch is for the `Memcached` type as the primary resource. For each add, update, or delete event, the reconcile loop is sent a reconcile `Request` (a `<namespace>:<name>` key) for that `Memcached` object:
182145
+
183146
[source,go]
184147
----
185148
err := c.Watch(
186149
&source.Kind{Type: &cachev1alpha1.Memcached{}}, &handler.EnqueueRequestForObject{})
187150
----
188151
+
189-
The next watch is for Deployments, but the event handler maps each event to a
190-
reconcile `Request` for the owner of the Deployment. In this case, this is the
191-
Memcached object for which the Deployment was created. This allows the
192-
controller to watch Deployments as a secondary resource:
152+
The next watch is for `Deployment` objects, but the event handler maps each event to a reconcile `Request` for the owner of the deployment. In this case, this is the `Memcached` object for which the deployment was created. This allows the controller to watch deployments as a secondary resource:
193153
+
194154
[source,go]
195155
----
@@ -199,10 +159,7 @@ err := c.Watch(&source.Kind{Type: &appsv1.Deployment{}}, &handler.EnqueueRequest
199159
})
200160
----
201161

202-
.. Every Controller has a Reconciler object with a `Reconcile()` method that
203-
implements the reconcile loop. The reconcile loop is passed the `Request`
204-
argument which is a `<namespace>:<name>` key used to lookup the primary resource
205-
object, Memcached, from the cache:
162+
.. Every controller has a `Reconciler` object with a `Reconcile()` method that implements the reconcile loop. The reconcile loop is passed the `Request` argument which is a `<namespace>:<name>` key used to lookup the primary resource object, `Memcached`, from the cache:
206163
+
207164
[source,go]
208165
----
@@ -214,8 +171,7 @@ func (r *ReconcileMemcached) Reconcile(request reconcile.Request) (reconcile.Res
214171
}
215172
----
216173
+
217-
Based on the return value of `Reconcile()` the reconcile `Request` may be
218-
requeued and the loop may be triggered again:
174+
Based on the return value of the `Reconcile()` function, the reconcile `Request` might be requeued, and the loop might be triggered again:
219175
+
220176
[source,go]
221177
----
@@ -230,8 +186,7 @@ return reconcile.Result{Requeue: true}, nil
230186

231187
. *Build and run the Operator.*
232188

233-
.. Before running the Operator, the CRD must be registered with the Kubernetes API
234-
server:
189+
.. Before running the Operator, the CRD must be registered with the Kubernetes API server:
235190
+
236191
[source,terminal]
237192
----
@@ -248,7 +203,7 @@ $ oc create \
248203
+
249204
Choose one of the following methods.
250205

251-
... _Option A:_ Running as a Deployment inside the cluster.
206+
... _Option A:_ Running as a deployment inside the cluster.
252207

253208
.... Build the `memcached-operator` image and push it to a registry:
254209
+
@@ -257,18 +212,14 @@ Choose one of the following methods.
257212
$ operator-sdk build quay.io/example/memcached-operator:v0.0.1
258213
----
259214

260-
.... The Deployment manifest is generated at `deploy/operator.yaml`. Update the
261-
Deployment image as follows since the default is just a placeholder:
215+
.... The deployment manifest is generated at `deploy/operator.yaml`. Update the deployment image as follows since the default is just a placeholder:
262216
+
263217
[source,terminal]
264218
----
265219
$ sed -i 's|REPLACE_IMAGE|quay.io/example/memcached-operator:v0.0.1|g' deploy/operator.yaml
266220
----
267221

268-
.... Ensure you have an account on link:https://quay.io[Quay.io] for the next step,
269-
or substitute your preferred container registry. On the registry,
270-
link:https://quay.io/new/[create a new public image] repository named
271-
`memcached-operator`.
222+
.... Ensure you have an account on link:https://quay.io[Quay.io] for the next step, or substitute your preferred container registry. On the registry, link:https://quay.io/new/[create a new public image] repository named `memcached-operator`.
272223

273224
.... Push the image to the registry:
274225
+
@@ -277,7 +228,7 @@ link:https://quay.io/new/[create a new public image] repository named
277228
$ podman push quay.io/example/memcached-operator:v0.0.1
278229
----
279230

280-
.... Setup RBAC and deploy `memcached-operator`:
231+
.... Set up RBAC and create the `memcached-operator` manifests:
281232
+
282233
[source,terminal]
283234
----
@@ -299,7 +250,7 @@ $ oc create -f deploy/service_account.yaml
299250
$ oc create -f deploy/operator.yaml
300251
----
301252

302-
.... Verify that `memcached-operator` is up and running:
253+
.... Verify that the `memcached-operator` deploy is up and running:
303254
+
304255
[source,terminal]
305256
----
@@ -317,22 +268,18 @@ memcached-operator 1 1 1 1 1m
317268
+
318269
This method is preferred during development cycle to deploy and test faster.
319270
+
320-
Run the Operator locally with the default Kubernetes configuration file present
321-
at `$HOME/.kube/config`:
271+
Run the Operator locally with the default Kubernetes configuration file present at `$HOME/.kube/config`:
322272
+
323273
[source,terminal]
324274
----
325275
$ operator-sdk run --local --namespace=default
326276
----
327277
+
328-
You can use a specific `kubeconfig` using the flag
329-
`--kubeconfig=<path/to/kubeconfig>`.
278+
You can use a specific `kubeconfig` using the flag `--kubeconfig=<path/to/kubeconfig>`.
330279

331-
. *Verify that the Operator can deploy a Memcached application* by creating a
332-
Memcached CR.
280+
. *Verify that the Operator can deploy a Memcached application* by creating a `Memcached` CR.
333281

334-
.. Create the example `Memcached` CR that was generated at
335-
`deploy/crds/cache_v1alpha1_memcached_cr.yaml`.
282+
.. Create the example `Memcached` CR that was generated at `deploy/crds/cache_v1alpha1_memcached_cr.yaml`.
336283

337284
.. View the file:
338285
+
@@ -359,7 +306,7 @@ spec:
359306
$ oc apply -f deploy/crds/cache_v1alpha1_memcached_cr.yaml
360307
----
361308

362-
.. Ensure that `memcached-operator` creates the Deployment for the CR:
309+
.. Ensure that `memcached-operator` creates the deployment for the CR:
363310
+
364311
[source,terminal]
365312
----
@@ -374,8 +321,7 @@ memcached-operator 1 1 1 1 2m
374321
example-memcached 3 3 3 3 1m
375322
----
376323

377-
.. Check the pods and CR status to confirm the status is updated with the
378-
`memcached` pod names:
324+
.. Check the pods and CR to confirm the CR status is updated with the pod names:
379325
+
380326
[source,terminal]
381327
----
@@ -420,8 +366,7 @@ status:
420366
- example-memcached-6fd7c98d8-m7vn7
421367
----
422368

423-
. *Verify that the Operator can manage a deployed Memcached application* by
424-
updating the size of the deployment.
369+
. *Verify that the Operator can manage a deployed Memcached application* by updating the size of the deployment.
425370

426371
.. Change the `spec.size` field in the `memcached` CR from `3` to `4`:
427372
+
@@ -448,7 +393,7 @@ spec:
448393
$ oc apply -f deploy/crds/cache_v1alpha1_memcached_cr.yaml
449394
----
450395

451-
.. Confirm that the Operator changes the Deployment size:
396+
.. Confirm that the Operator changes the deployment size:
452397
+
453398
[source,terminal]
454399
----
@@ -496,5 +441,4 @@ $ oc delete -f deploy/service_account.yaml
496441

497442
.Additional resources
498443

499-
* For more information about OpenAPI v3.0 validation schemas in CRDs, refer to the
500-
link:https://kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/#specifying-a-structural-schema[Kubernetes documentation].
444+
* For more information about OpenAPI v3.0 validation schemas in CRDs, refer to the link:https://kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/#specifying-a-structural-schema[Kubernetes documentation].

modules/crd-creating-aggregated-cluster-roles.adoc

Lines changed: 5 additions & 18 deletions
Original file line numberDiff line numberDiff line change
@@ -3,21 +3,13 @@
33
// * operators/understanding/crds/extending-api-with-crds.adoc
44

55
[id="crd-creating-aggregated-cluster-role_{context}"]
6-
= Creating cluster roles for Custom Resource Definitions
6+
= Creating cluster roles for custom resource definitions
77

8-
Cluster administrators can grant permissions to existing cluster-scoped Custom
9-
Resource Definitions (CRDs). If you use the `admin`, `edit`, and `view` default
10-
cluster roles, take advantage of cluster role aggregation for their rules.
8+
Cluster administrators can grant permissions to existing cluster-scoped custom resource definitions (CRDs). If you use the `admin`, `edit`, and `view` default cluster roles, you can take advantage of cluster role aggregation for their rules.
119

1210
[IMPORTANT]
1311
====
14-
You must explicitly assign permissions to each of these roles. The roles with
15-
more permissions do not inherit rules from roles with fewer permissions. If you
16-
assign a rule to a role, you must also assign that verb to roles that have more
17-
permissions. For example, if you grant the `get crontabs` permission to the view
18-
role, you must also grant it to the `edit` and `admin` roles. The `admin` or
19-
`edit` role is usually assigned to the user that created a project through the
20-
project template.
12+
You must explicitly assign permissions to each of these roles. The roles with more permissions do not inherit rules from roles with fewer permissions. If you assign a rule to a role, you must also assign that verb to roles that have more permissions. For example, if you grant the `get crontabs` permission to the view role, you must also grant it to the `edit` and `admin` roles. The `admin` or `edit` role is usually assigned to the user that created a project through the project template.
2113
====
2214

2315
.Prerequisites
@@ -31,10 +23,7 @@ endif::[]
3123

3224
.Procedure
3325

34-
. Create a cluster role definition file for the CRD. The cluster role definition
35-
is a YAML file that contains the rules that apply to each cluster role. The
36-
{product-title} controller adds the rules that you specify to the default
37-
cluster roles.
26+
. Create a cluster role definition file for the CRD. The cluster role definition is a YAML file that contains the rules that apply to each cluster role. A {product-title} controller adds the rules that you specify to the default cluster roles.
3827
+
3928
.Example YAML file for a cluster role definition
4029
[source,yaml]
@@ -70,9 +59,7 @@ rules:
7059
<4> Specify this label to grant permissions to the edit default role.
7160
<5> Specify the group name of the CRD.
7261
<6> Specify the plural name of the CRD that these rules apply to.
73-
<7> Specify the verbs that represent the permissions that are granted to the role.
74-
For example, apply read and write permissions to the `admin` and `edit` roles
75-
and only read permission to the `view` role.
62+
<7> Specify the verbs that represent the permissions that are granted to the role. For example, apply read and write permissions to the `admin` and `edit` roles and only read permission to the `view` role.
7663
<8> Specify this label to grant permissions to the `view` default role.
7764
<9> Specify this label to grant permissions to the `cluster-reader` default role.
7865

0 commit comments

Comments
 (0)