|
| 1 | +--- |
| 2 | +title: "Configuring the Eventing Operator Custom Resource" |
| 3 | +weight: 60 |
| 4 | +type: "docs" |
| 5 | +aliases: |
| 6 | +- /docs/operator/configuring-eventing-cr/ |
| 7 | +--- |
| 8 | + |
| 9 | +The Knative Eventing operator can be configured with these options: |
| 10 | + |
| 11 | +- [Private repository and private secret](#private-repository-and-private-secrets) |
| 12 | +- [Configuring default broker class](#configuring-default-broker-class) |
| 13 | + |
| 14 | +__NOTE:__ Kubernetes spec level policies cannot be configured using the Knative operators. |
| 15 | + |
| 16 | +## Private repository and private secrets |
| 17 | + |
| 18 | +The Knative Eventing operator CR is configured the same way as the Knative Serving operator CR. For more information, |
| 19 | +see the documentation on “[Private repository and private secret](configuring-serving-cr.md#private-repository-and-private-secrets)” in Serving operator for detailed instruction. |
| 20 | + |
| 21 | +Knative Eventing also specifies only one container within one `Deployment` resource. However, the container does not use |
| 22 | +the same name as its parent `Deployment`, which means the container name in Knative Eventing is not the unique identifier |
| 23 | +as in Knative Serving. Here is the list of containers within each `Deployment` resource: |
| 24 | + |
| 25 | +| Component | Deployment name | Container name | |
| 26 | +|-----------|-----------------|----------------| |
| 27 | +| Core eventing | `eventing-controller` | `eventing-controller` | |
| 28 | +| Core eventing | `eventing-webhook` | `eventing-webhook` | |
| 29 | +| Eventing Broker | `broker-controller` | `eventing-controller` | |
| 30 | +| In-Memory Channel | `imc-controller` | `controller` | |
| 31 | +| In-Memory Channel | `imc-dispatcher` | `dispatcher` | |
| 32 | + |
| 33 | +The `default` field can still be used to replace the images in a predefined format. However, if the container name is not |
| 34 | +a unique identifier, e.g. `eventing-controller`, you need to use the `override` field to replace it, by specifying |
| 35 | +`deployment/container` as the unique key. |
| 36 | + |
| 37 | +Some images are defined via environment variable in Knative Eventing. They can be replaced by taking advantage of the |
| 38 | +`override` field. As Knative does not have a consistent way to specify container images, we have a known issue [here](https://github.com/knative-sandbox/operator/issues/22). |
| 39 | + |
| 40 | +### Download images in predefined format without secrets: |
| 41 | + |
| 42 | +This example shows how you can define custom image links that can be defined in the CR using the simplified format |
| 43 | +`docker.io/knative-images/${NAME}:{CUSTOM-TAG}`. |
| 44 | + |
| 45 | +In the example below: |
| 46 | + |
| 47 | +- the custom tag `v0.13.0` is used for all images |
| 48 | +- all image links are accessible without using secrets |
| 49 | +- images are defined in the accepted format `docker.io/knative-images/${NAME}:{CUSTOM-TAG}` |
| 50 | + |
| 51 | +First, you need to make sure your images are pushed to the following image tags: |
| 52 | + |
| 53 | +| Deployment | Container | Docker image | |
| 54 | +|----|----|----| |
| 55 | +| `eventing-controller` | `eventing-controller` | `docker.io/knative-images/eventing-controller:v0.13.0` | |
| 56 | +| | `eventing-webhook` | `docker.io/knative-images/eventing-webhook:v0.13.0` | |
| 57 | +| `broker-controller` | `eventing-controller` | `docker.io/knative-images/broker-eventing-controller:v0.13.0` | |
| 58 | +| | `controller` | `docker.io/knative-images/controller:v0.13.0` | |
| 59 | +| | `dispatcher` | `docker.io/knative-images/dispatcher:v0.13.0` | |
| 60 | + |
| 61 | +Then, you need to define your operator CR with following content: |
| 62 | + |
| 63 | +``` |
| 64 | +apiVersion: operator.knative.dev/v1alpha1 |
| 65 | +kind: KnativeEventing |
| 66 | +metadata: |
| 67 | + name: knative-eventing |
| 68 | + namespace: knative-eventing |
| 69 | +spec: |
| 70 | + registry: |
| 71 | + default: docker.io/knative-images/${NAME}:v0.13.0 |
| 72 | + override: |
| 73 | + broker-controller/eventing-controller: docker.io/knative-images-repo1/broker-eventing-controller:v0.13.0 |
| 74 | +``` |
| 75 | + |
| 76 | +As indicated, you replace `{CUSTOM-TAG}` with the custom tag `v0.13.0`. `${NAME}` maps to the container name in each `Deployment` resource. |
| 77 | +The field `default` is used to define the image format for all containers, except the container `eventing-controller` in |
| 78 | +the deployment `broker-controller`. To replace the image for this container, you need to take advatage of the `override` |
| 79 | +field to specify individually, by using `broker-controller/eventing-controller` as the key`. |
| 80 | + |
| 81 | +### Download images from different repositories without secrets: |
| 82 | + |
| 83 | +If your custom image links are not defined in a uniform format by default, you will need to individually include each |
| 84 | +link in the CR. |
| 85 | + |
| 86 | +For example, to define the list of images: |
| 87 | + |
| 88 | +| Deployment | Container | Docker Image | |
| 89 | +|----|----|----| |
| 90 | +| `eventing-controller` | `eventing-controller` | `docker.io/knative-images/eventing-controller:v0.13.0` | |
| 91 | +| | `eventing-webhook` | `docker.io/knative-images/eventing-webhook:v0.13.0` | |
| 92 | +| | `controller` | `docker.io/knative-images/controller:v0.13.0` | |
| 93 | +| | `dispatcher` | `docker.io/knative-images/dispatcher:v0.13.0` | |
| 94 | +| `broker-controller` | `eventing-controller` | `docker.io/knative-images/broker-eventing-controller:v0.13.0` | |
| 95 | + |
| 96 | + |
| 97 | +The operator CR should be modified to include the full list: |
| 98 | + |
| 99 | +``` |
| 100 | +apiVersion: operator.knative.dev/v1alpha1 |
| 101 | +kind: KnativeServing |
| 102 | +metadata: |
| 103 | + name: knative-serving |
| 104 | + namespace: knative-serving |
| 105 | +spec: |
| 106 | + registry: |
| 107 | + override: |
| 108 | + eventing-controller/eventing-controller: docker.io/knative-images-repo1/eventing-controller:v0.13.0 |
| 109 | + eventing-webhook/eventing-webhook: docker.io/knative-images-repo2/eventing-webhook:v0.13.0 |
| 110 | + imc-controller/controller: docker.io/knative-images-repo3/imc-controller:v0.13.0 |
| 111 | + imc-dispatcher/dispatcher: docker.io/knative-images-repo4/imc-dispatcher:v0.13.0 |
| 112 | + broker-controller/eventing-controller: docker.io/knative-images-repo5/broker-eventing-controller:v0.13.0 |
| 113 | +``` |
| 114 | + |
| 115 | +If you would like to replace the image defined by environment variable, e.g. the envorinment variable `DISPATCHER_IMAGE` |
| 116 | +in the container `controller` of the deployment `imc-controller`, you need to adjust your CR into the following, if the |
| 117 | +target image is `docker.io/knative-images-repo5/DISPATCHER_IMAGE:v0.13.0`: |
| 118 | + |
| 119 | +``` |
| 120 | +apiVersion: operator.knative.dev/v1alpha1 |
| 121 | +kind: KnativeServing |
| 122 | +metadata: |
| 123 | + name: knative-serving |
| 124 | + namespace: knative-serving |
| 125 | +spec: |
| 126 | + registry: |
| 127 | + override: |
| 128 | + eventing-controller/eventing-controller: docker.io/knative-images-repo1/eventing-controller:v0.13.0 |
| 129 | + eventing-webhook/eventing-webhook: docker.io/knative-images-repo2/eventing-webhook:v0.13.0 |
| 130 | + imc-controller/controller: docker.io/knative-images-repo3/imc-controller:v0.13.0 |
| 131 | + imc-dispatcher/dispatcher: docker.io/knative-images-repo4/imc-dispatcher:v0.13.0 |
| 132 | + broker-controller/eventing-controller: docker.io/knative-images-repo5/broker-eventing-controller:v0.13.0 |
| 133 | + DISPATCHER_IMAGE: docker.io/knative-images-repo5/DISPATCHER_IMAGE:v0.13.0 |
| 134 | +``` |
| 135 | + |
| 136 | +### Download images with secrets: |
| 137 | + |
| 138 | +If your image repository requires private secrets for access, you must append the `imagePullSecrets` attribute. |
| 139 | + |
| 140 | +This example uses a secret named `regcred`. Refer to [this guide](https://kubernetes.io/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod) to create your own private secrets. |
| 141 | +After you create the secret, edit your operator CR by appending the content below: |
| 142 | + |
| 143 | +``` |
| 144 | +apiVersion: operator.knative.dev/v1alpha1 |
| 145 | +kind: KnativeEventing |
| 146 | +metadata: |
| 147 | + name: knative-eventing |
| 148 | + namespace: knative-eventing |
| 149 | +spec: |
| 150 | + registry: |
| 151 | + ... |
| 152 | + imagePullSecrets: |
| 153 | + - name: regcred |
| 154 | +``` |
| 155 | + |
| 156 | +The field `imagePullSecrets` expects a list of secrets. You can add multiple secrets to access the images as below: |
| 157 | + |
| 158 | +``` |
| 159 | +apiVersion: operator.knative.dev/v1alpha1 |
| 160 | +kind: KnativeEventing |
| 161 | +metadata: |
| 162 | + name: knative-eventing |
| 163 | + namespace: knative-eventing |
| 164 | +spec: |
| 165 | + registry: |
| 166 | + ... |
| 167 | + imagePullSecrets: |
| 168 | + - name: regcred |
| 169 | + - name: regcred-2 |
| 170 | + ... |
| 171 | +``` |
| 172 | + |
| 173 | +## Configuring default broker class |
| 174 | + |
| 175 | +Knative Eventing allows you to define a default broker class when the user does not specify one. The operator ships with two broker classes: `ChannelBasedBroker` and `MTChannelBasedBroker`. The field `defaultBrokerClass` indicates which class to use; if empty, the `ChannelBasedBroker` will be used. |
| 176 | +Here is an example specifying `MTChannelBasedBroker` as the default: |
| 177 | + |
| 178 | +``` |
| 179 | +apiVersion: operator.knative.dev/v1alpha1 |
| 180 | +kind: KnativeEventing |
| 181 | +metadata: |
| 182 | + name: knative-eventing |
| 183 | + namespace: knative-eventing |
| 184 | +spec: |
| 185 | + defaultBrokerClass: MTChannelBasedBroker |
| 186 | +``` |
0 commit comments