Configuring the Eventing Operator custom resource

    If you are using different channel implementations, like the KafkaChannel, or you want a specific configuration of the InMemoryChannel to be the default configuration, you can change the default behavior by updating the default-ch-webhook ConfigMap.

    You can do this by modifying the KnativeEventing CR:

    Note

    The clusterDefault setting determines the global, cluster-wide default channel type. You can configure channel defaults for individual namespaces by using the namespaceDefaults setting.

    Setting the default channel for the broker

    If you are using a channel-based broker, you can change the default channel type for the broker from InMemoryChannel to KafkaChannel, by updating the config-br-default-channel ConfigMap.

    You can do this by modifying the KnativeEventing CR:

    1. apiVersion: operator.knative.dev/v1beta1
    2. kind: KnativeEventing
    3. metadata:
    4.   name: knative-eventing
    5.   namespace: knative-eventing
    6. spec:
    7.   config:
    8.     config-br-default-channel:
    9.       channel-template-spec: |
    10.         apiVersion: messaging.knative.dev/v1beta1
    11.         kind: KafkaChannel
    12.         spec:
    13.           numPartitions: 6
    14.           replicationFactor: 1

    The Knative Eventing Operator CR is configured the same way as the Knative Serving Operator CR. See the documentation on .

    Knative Eventing also specifies only one container within each Deployment resource. However, the container does not use the same name as its parent Deployment, which means that the container name in Knative Eventing is not the same unique identifier as it is in Knative Serving.

    List of containers within each Deployment resource:

    The default field can still be used to replace the images in a predefined format. However, if the container name is not a unique identifier, for example eventing-controller, you must use the override field to replace it, by specifying deployment/container as the unique key.

    Some images are defined by using the environment variable in Knative Eventing. They can be replaced by taking advantage of the override field.

    This example shows how you can define custom image links that can be defined in the KnativeEventing CR using the simplified format docker.io/knative-images/${NAME}:{CUSTOM-TAG}.

    In this example:

    • The custom tag latest is used for all images.
    • All image links are accessible without using secrets.
    • Images are defined in the accepted format docker.io/knative-images/${NAME}:{CUSTOM-TAG}.

    To define your image links:

    1. Push images to the following image tags:

      1. apiVersion: operator.knative.dev/v1beta1
      2. kind: KnativeEventing
      3. metadata:
      4.   name: knative-eventing
      5.   namespace: knative-eventing
      6. spec:
      7.   registry:
      8.     default: docker.io/knative-images/${NAME}:latest
      9.     override:
      10.       broker-controller/eventing-controller: docker.io/knative-images-repo1/broker-eventing-controller:latest

    You can also run the following commands to make the equivalent change:

    1. ```bash
    2. kn operator configure images --component eventing --imageKey default --imageURL docker.io/knative-images/${NAME}:latest -n knative-eventing
    3. kn operator configure images --component eventing --deployName broker-controller --imageKey eventing-controller --imageURL docker.io/knative-images-repo1/broker-eventing-controller:latest -n knative-eventing
    4. ```
    6. - `${NAME}` maps to the container name in each `Deployment` resource.
    7. - `default` is used to define the image format for all containers, except the container `eventing-controller` in the deployment `broker-controller`. To replace the image for this container, use the `override`
    8. field to specify individually, by using `broker-controller/eventing-controller` as the key.

    Download images from different repositories without secrets

    If your custom image links are not defined in a uniform format, you will need to individually include each link in the KnativeEventing CR.

    For example, given the following list of images:

    You must modify the KnativeEventing CR to include the full list. For example:

    1. apiVersion: operator.knative.dev/v1beta1
    2. kind: KnativeEventing
    3. metadata:
    4.   name: knative-eventing
    5.   namespace: knative-eventing
    6. spec:
    7.   registry:
    8.     override:
    9.       eventing-controller/eventing-controller: docker.io/knative-images-repo1/eventing-controller:latest
    10.       eventing-webhook/eventing-webhook: docker.io/knative-images-repo2/eventing-webhook:latest
    11.       imc-controller/controller: docker.io/knative-images-repo3/imc-controller:latest
    12.       imc-dispatcher/dispatcher: docker.io/knative-images-repo4/imc-dispatcher:latest
    13.       broker-controller/eventing-controller: docker.io/knative-images-repo5/broker-eventing-controller:latest

    You can also run the following commands to make the equivalent change:

    1. kn operator configure images --component eventing --deployName eventing-controller --imageKey eventing-controller --imageURL docker.io/knative-images-repo1/eventing-controller:latest -n knative-eventing
    1. kn operator configure images --component eventing --deployName eventing-webhook --imageKey eventing-webhook --imageURL docker.io/knative-images-repo2/eventing-webhook:latest -n knative-eventing
    1. kn operator configure images --component eventing --deployName imc-controller --imageKey controller --imageURL docker.io/knative-images-repo3/imc-controller:latest -n knative-eventing
    1. kn operator configure images --component eventing --deployName imc-dispatcher --imageKey dispatcher --imageURL docker.io/knative-images-repo4/imc-dispatcher:latest -n knative-eventing
    1. kn operator configure images --component eventing --deployName broker-controller --imageKey eventing-controller --imageURL docker.io/knative-images-repo5/broker-eventing-controller:latest -n knative-eventing

    If you want to replace the image defined by the environment variable, you must modify the KnativeEventing CR. For example, if you want to replace the image defined by the environment variable , in the container controller, of the deployment imc-controller, and the target image is docker.io/knative-images-repo5/DISPATCHER_IMAGE:latest, the KnativeEventing CR would be as follows:

    1. apiVersion: operator.knative.dev/v1beta1
    2. kind: KnativeEventing
    3. metadata:
    4.   name: knative-eventing
    5.   namespace: knative-eventing
    6.   registry:
    7.     override:
    8.       eventing-controller/eventing-controller: docker.io/knative-images-repo1/eventing-controller:latest
    9.       eventing-webhook/eventing-webhook: docker.io/knative-images-repo2/eventing-webhook:latest
    10.       imc-controller/controller: docker.io/knative-images-repo3/imc-controller:latest
    11.       imc-dispatcher/dispatcher: docker.io/knative-images-repo4/imc-dispatcher:latest
    12.       broker-controller/eventing-controller: docker.io/knative-images-repo5/broker-eventing-controller:latest
    13.       DISPATCHER_IMAGE: docker.io/knative-images-repo5/DISPATCHER_IMAGE:latest

    You can also run the following commands to make the equivalent change:

    1. kn operator configure images --component eventing --deployName eventing-webhook --imageKey eventing-webhook --imageURL docker.io/knative-images-repo2/eventing-webhook:latest -n knative-eventing
    1. kn operator configure images --component eventing --deployName imc-controller --imageKey controller --imageURL docker.io/knative-images-repo3/imc-controller:latest -n knative-eventing
    1. kn operator configure images --component eventing --deployName imc-dispatcher --imageKey dispatcher --imageURL docker.io/knative-images-repo4/imc-dispatcher:latest -n knative-eventing
    1. kn operator configure images --component eventing --deployName broker-controller --imageKey eventing-controller --imageURL docker.io/knative-images-repo5/broker-eventing-controller:latest -n knative-eventing
    1. kn operator configure images --component eventing --imageKey DISPATCHER_IMAGE -controller --imageURL docker.io/knative-images-repo5/DISPATCHER_IMAGE:latest -n knative-eventing

    Download images with secrets

    If your image repository requires private secrets for access, you must append the imagePullSecrets attribute to the KnativeEventing CR.

    This example uses a secret named regcred. Refer to the to create your own private secrets.

    After you create the secret, edit the KnativeEventing CR:

    1. apiVersion: operator.knative.dev/v1beta1
    2. kind: KnativeEventing
    3. metadata:
    4.   name: knative-eventing
    5.   namespace: knative-eventing
    6. spec:
    7.   registry:
    8.     ...
    9.     imagePullSecrets:
    10.       - name: regcred

    The field imagePullSecrets requires a list of secrets. You can add multiple secrets to access the images:

    1. apiVersion: operator.knative.dev/v1beta1
    2. kind: KnativeEventing
    3. metadata:
    4.   name: knative-eventing
    5.   namespace: knative-eventing
    6. spec:
    7.   registry:
    8.     ...
    9.     imagePullSecrets:
    10.       - name: regcred
    11.       - name: regcred-2
    12.       ...

    Configuring the default broker class

    Knative Eventing allows you to define a default broker class when the user does not specify one. The Operator provides two broker classes by default: ChannelBasedBroker and MTChannelBasedBroker.

    The field defaultBrokerClass indicates which class to use; if empty, the ChannelBasedBroker is used.

    The following example CR specifies MTChannelBasedBroker as the default:

    1. apiVersion: operator.knative.dev/v1beta1
    2. kind: KnativeEventing
    3. metadata:
    4.   name: knative-eventing
    5.   namespace: knative-eventing
    6. spec:
    7.   defaultBrokerClass: MTChannelBasedBroker

    If you would like to override some configurations for a specific deployment, you can override the configuration by using spec.deployments in the CR. Currently resources, replicas, labels, annotations and nodeSelector are supported.

    For example, the following KnativeEventing resource configures the container eventing-controller in the deployment eventing-controller to request 0.3 CPU and 100MB of RAM, and sets hard limits of 1 CPU and 250MB RAM:

    1. apiVersion: operator.knative.dev/v1beta1
    2. kind: KnativeEventing
    3. metadata:
    4.   name: knative-eventing
    5.   namespace: knative-eventing
    6. spec:
    7.   deployments:
    8.   - name: eventing-controller
    9.     resources:
    10.     - container: eventing-controller
    11.       requests:
    12.         cpu: 300m
    13.         memory: 100M
    14.       limits:
    15.         cpu: 1000m
    16.         memory: 250M

    You can also run the following command to make the equivalent change:

    1. kn operator configure resources --component eventing --deployName eventing-controller --container eventing-controller --requestCPU 300m --requestMemory 100M --limitCPU 1000m --limitMemory 250M -n knative-eventing

    Override the nodeSelector

    The KnativeEventing resource is able to override the nodeSelector for the Knative Eventing deployment resources. For example, if you would like to add the following tolerations

    to the deployment eventing-controller, you need to change your KnativeEventing CR as below:

    1. apiVersion: operator.knative.dev/v1beta1
    2. kind: KnativeEventing
    3. metadata:
    4.   name: knative-eventing
    5.   namespace: knative-eventing
    6. spec:
    7.   deployments:
    8.   - name: eventing-controller
    9.     nodeSelector:
    10.       disktype: hdd

    You can also run the following command to make the equivalent change:

    1. kn operator configure nodeSelector --component eventing --deployName eventing-controller --key disktype --value hdd -n knative-eventing

    Override the tolerations

    The KnativeEventing resource is able to override tolerations for the Knative Eventing deployment resources. For example, if you would like to add the following tolerations

    1. tolerations:
    3.   operator: "Equal"
    4.   value: "value1"
    5.   effect: "NoSchedule"

    to the deployment eventing-controller, you need to change your KnativeEventing CR as below:

    1. apiVersion: operator.knative.dev/v1beta1
    2. metadata:
    3.   name: knative-eventing
    4.   namespace: knative-eventing
    5. spec:
    6.   deployments:
    7.   - name: eventing-controller
    8.     tolerations:
    9.     - key: "key1"
    10.       operator: "Equal"
    11.       value: "value1"
    12.       effect: "NoSchedule"

    You can also run the following command to make the equivalent change:

    1. kn operator configure tolerations --component eventing --deployName eventing-controller --key key1 --operator Equal --value value1 --effect NoSchedule -n knative-eventing

    The KnativeEventing resource is able to override the affinity, including nodeAffinity, podAffinity, and podAntiAffinity, for the Knative Eventing deployment resources. For example, if you would like to add the following nodeAffinity

    1. affinity:
    2.   nodeAffinity:
    3.     preferredDuringSchedulingIgnoredDuringExecution:
    4.     - weight: 1
    5.       preference:
    6.         matchExpressions:
    7.         - key: disktype
    8.           operator: In
    9.           values:
    10.           - ssd

    to the deployment activator, you need to change your KnativeEventing CR as below:

    1. apiVersion: operator.knative.dev/v1beta1
    2. kind: KnativeEventing
    3. metadata:
    4.   name: knative-eventing
    5.   namespace: knative-eventing
    6. spec:
    7.   deployments:
    8.   - name: activator
    9.     affinity:
    10.       nodeAffinity:
    11.         preferredDuringSchedulingIgnoredDuringExecution:
    12.         - weight: 1
    13.           preference:
    14.             matchExpressions:
    15.             - key: disktype
    16.               operator: In
    17.               values:
    18.               - ssd

    Override the environment variables

    The KnativeEventing resource is able to override or add the environment variables for the containers in the Knative Eventing deployment resources. For example, if you would like to change the value of environment variable METRICS_DOMAIN in the container eventing-controller into “knative.dev/my-repo” for the deployment eventing-controller, you need to change your KnativeEventing CR as below:

    1. apiVersion: operator.knative.dev/v1beta1
    2. kind: KnativeEventing
    3. metadata:
    4.   name: knative-eventing
    5.   namespace: knative-eventing
    6. spec:
    7.   deployments:
    8.   - name: eventing-controller
    9.     env:
    10.     - container: eventing-controller
    11.       envVars:
    12.       - name: METRICS_DOMAIN
    13.         value: "knative.dev/my-repo"

    You can also run the following command to make the equivalent change:

    1. kn operator configure envvars --component eventing --deployName eventing-controller --container eventing-controller --name METRICS_DOMAIN --value "knative.dev/my-repo" -n knative-eventing

    Override system services

    If you would like to override some configurations for a specific service, you can override the configuration by using spec.services in CR. Currently labels, annotations and selector are supported.

    Override labels and annotations and selector

    The following KnativeEventing resource overrides the eventing-webhook service to have the label mylabel: foo, the annotation myannotations: bar, the selector myselector: bar.

    1. apiVersion: operator.knative.dev/v1beta1
    2. kind: KnativeEventing
    3. metadata:
    4.   name: knative-eventing
    5.   namespace: knative-eventing
    6. spec:
    7.   services:
    8.   - name: eventing-webhook
    9.     labels:
    10.       mylabel: foo
    11.     annotations:
    12.       myannotations: bar
    13.     selector:
    14.       myselector: bar

    You can also run the following commands to make the equivalent change:

    1. apiVersion: operator.knative.dev/v1beta1
    2. kind: KnativeEventing
    3. metadata:
    4.   name: knative-eventing
    5.   namespace: knative-eventing
    6. spec:
    7.   podDisruptionBudgets: