Skip to content

Commit a63fa5d

Browse files
authored
Glue Intro
1 parent 64fbd7e commit a63fa5d

File tree

1 file changed

+18
-4
lines changed

1 file changed

+18
-4
lines changed

README.md

Lines changed: 18 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -105,14 +105,28 @@ spec:
105105
# Omitted Details
106106
```
107107

108-
There are multiple aspects to see here. If such a resource is created, the four related resources will be templated
109-
and applied to the cluster. If anything changes in the custom or managed resources, the reconciliation
110-
will be triggered again.
108+
There are multiple aspects to see here. The four related resources will be templated
109+
and applied to the cluster if such a resource is created. The reconciliation will be triggered if anything changes in the custom or managed resources.
111110

112111
Note also the `condition` part for `Ingress` resource contains multiple types of conditions, `JSCondition` is
113112
used in this example, which allows writing conditions in Javascript. The `Ingress` will be created if the `.spec.exposed` property
114113
is true. If the property is changed to `false` after, the resource is deleted.
115114

116115
### The `Glue` Resource
117116

118-
`Glue` is very similar to `GlueOperator`, and has almost the same properties, but does not have a parent. Thus does not define an operator, just a set of resources to reconcile.
117+
`Glue` is very similar to `GlueOperator`, and has almost the same properties, but does not have a parent. Thus, it does not define an operator, just a set of resources to reconcile.
118+
Let's take a look at another example, that will show also additional features (both for `Glue` and `GlueOperator`). Typically Kubernetes does not require ordering regarding how
119+
resources are applied, however, there are certain cases when this is needed also for Kubernetes, but especially useful when external resources are managed by Kubernetes controllers.
120+
The following example shows how to deploy a [dynamic admission controller](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/) that mutates
121+
all the `Pods`, adding annotation on them. Note that this is a tricky situation since the endpoint for the `MutatingWebhookConfiguration` is also a `Pod`, thus it should be
122+
first up and running before the configuration is applied, otherwise, the mutation webhook will block the changes on the pods, which would render the cluster unable to manage `Pods':
123+
124+
```yaml
125+
126+
127+
128+
129+
```
130+
131+
132+

0 commit comments

Comments
 (0)