Configuring the Eventing Operator custom resource

You can configure the Knative Eventing operator by modifying settings in the KnativeEventing custom resource (CR). You can configure Knative Eventing with the following options:

Installing a specific version of Eventing

Cluster administrators can install a specific version of Knative Eventing by using the spec.version field. For example, if you want to install Knative Eventing v0.19.0, you can apply the following KnativeEventing CR:

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

If spec.version is not specified, the Knative Operator will install the latest available version of Knative Eventing. If users specify an invalid or unavailable version, the Knative Operator will do nothing. The Knative Operator always includes the latest 3 minor release versions.

If Knative Eventing is already managed by the Operator, updating the spec.version field in the KnativeEventing CR enables upgrading or downgrading the Knative Eventing version, without requiring modifications to the Operator.

Note that the Knative Operator only permits upgrades or downgrades by one minor release version at a time. For example, if the current Knative Eventing deployment is version 0.18.x, you must upgrade to 0.19.x before upgrading to 0.20.x.

Installing customized Knative Eventing

The Operator provides you with the flexibility to install Knative Eventing customized to your own requirements. As long as the manifests of customized Knative Eventing are accessible to the Operator, you can install them.

There are two modes available for you to install customized manifests: overwrite mode and append mode. With overwrite mode, under .spec.manifests, you must define all manifests needed for Knative Eventing to install because the Operator will no longer install any default manifests. With append mode, under .spec.additionalManifests, you only need to define your customized manifests. The customized manifests are installed after default manifests are applied.

Overwrite mode

Use overwrite mode when you want to customize all Knative Eventing manifests to be installed.

For example, if you want to install a customized Knative Eventing only, you can create and apply the following Eventing CR:

  1. apiVersion: v1
  2. kind: Namespace
  3. metadata:
  4.   name: knative-eventing
  5. ---
  6. apiVersion: operator.knative.dev/v1beta1
  7. kind: KnativeEventing
  8. metadata:
  9.   name: knative-eventing
  10.   namespace: knative-eventing
  11. spec:
  12.   version: $spec_version
  13.   manifests:
  14.   - URL: https://my-eventing/eventing.yaml

This example installs the customized Knative Eventing at version $spec_version which is available at https://my-eventing/eventing.yaml.

Attention

You can make the customized Knative Eventing available in one or multiple links, as the spec.manifests supports a list of links. The ordering of the URLs is critical. Put the manifest you want to apply first on the top.

We strongly recommend you to specify the version and the valid links to the customized Knative Eventing, by leveraging both spec.version and spec.manifests. Do not skip either field.

Append mode

You can use append mode to add your customized manifests into the default manifests.

For example, if you only want to customize a few resources but you still want to install the default Knative Eventing, you can create and apply the following Eventing CR:

  1. apiVersion: v1
  2. kind: Namespace
  3. metadata:
  4.   name: knative-eventing
  5. ---
  6. apiVersion: operator.knative.dev/v1beta1
  7. kind: KnativeEventing
  8. metadata:
  9.   name: knative-eventing
  10.   namespace: knative-eventing
  11. spec:
  12.   version: $spec_version
  13.   additionalManifests:
  14.   - URL: https://my-eventing/eventing-custom.yaml

This example installs the default Knative Eventing, and installs your customized resources available at https://my-eventing/eventing-custom.yaml.

Knative Operator installs the default manifests of Knative Eventing at the version $spec_version, and then installs your customized manifests based on them.

Setting a default channel

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:

  1. apiVersion: operator.knative.dev/v1beta1
  2. kind: KnativeEventing
  3. metadata:
  4.   name: knative-eventing
  5.   namespace: knative-eventing
  6. spec:
  7.   config:
  8.     default-ch-webhook:
  9.       default-ch-config: |
  10.         clusterDefault:
  11.           apiVersion: messaging.knative.dev/v1beta1
  12.           kind: KafkaChannel
  13.           spec:
  14.             numPartitions: 10
  15.             replicationFactor: 1
  16.         namespaceDefaults:
  17.           my-namespace:
  18.             apiVersion: messaging.knative.dev/v1
  19.             kind: InMemoryChannel
  20.             spec:
  21.               delivery:
  22.                 backoffDelay: PT0.5S
  23.                 backoffPolicy: exponential
  24.                 retry: 5

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

Private repository and private secrets

The Knative Eventing Operator CR is configured the same way as the Knative Serving Operator CR. See the documentation on Private repository and private secret.

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:

ComponentDeployment nameContainer name
Core eventingeventing-controllereventing-controller
Core eventingeventing-webhookeventing-webhook
Eventing Brokerbroker-controllereventing-controller
In-Memory Channelimc-controllercontroller
In-Memory Channelimc-dispatcherdispatcher

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.

Download images in a predefined format without secrets

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:

    DeploymentContainerDocker image
    eventing-controllereventing-controllerdocker.io/knative-images/eventing-controller:latest
    eventing-webhookdocker.io/knative-images/eventing-webhook:latest
    broker-controllereventing-controllerdocker.io/knative-images/broker-eventing-controller:latest
    controllerdocker.io/knative-images/controller:latest
    dispatcherdocker.io/knative-images/dispatcher:latest

  2. Define your KnativeEventing CR with following content:

    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
    • ${NAME} maps to the container name in each Deployment resource.
    • 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 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:

DeploymentContainerDocker Image
eventing-controllereventing-controllerdocker.io/knative-images-repo1/eventing-controller:latest
eventing-webhookdocker.io/knative-images-repo2/eventing-webhook:latest
controllerdocker.io/knative-images-repo3/imc-controller:latest
dispatcherdocker.io/knative-images-repo4/imc-dispatcher:latest
broker-controllereventing-controllerdocker.io/knative-images-repo5/broker-eventing-controller:latest

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

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 DISPATCHER_IMAGE, 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. 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
  14.       DISPATCHER_IMAGE: docker.io/knative-images-repo5/DISPATCHER_IMAGE:latest

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 Kubernetes documentation 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

Override system deployments

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.

Override the resources

The KnativeEventing custom resource is able to configure system resources for the Knative system containers based on the deployment. Requests and limits can be configured for all the available containers within the deployment, like eventing-controller, eventing-webhook, imc-controller, etc.

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: 100Mi
  14.       limits:
  15.         cpu: 1000m
  16.         memory: 250Mi

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

  1. nodeSelector:
  2.   disktype: hdd

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

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:
  2. - key: "key1"
  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. kind: KnativeEventing
  3. metadata:
  4.   name: knative-eventing
  5.   namespace: knative-eventing
  6. spec:
  7.   deployments:
  8.   - name: eventing-controller
  9.     tolerations:
  10.     - key: "key1"
  11.       operator: "Equal"
  12.       value: "value1"
  13.       effect: "NoSchedule"

Override the affinity

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