Configuring the Eventing Operator custom resource

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

    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.

    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/v1alpha1
    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/v1alpha1
    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.

    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 the following 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}.

    • Push images to the following image tags:

    1. Define your the KnativeEventing CR with following content:
    1. apiVersion: operator.knative.dev/v1alpha1
    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
    2. field to specify individually, by using `broker-controller/eventing-controller` as the key.

    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, to define the following list of images:

    The KnativeEventing CR must be modified to include the full list. For example:

    1. apiVersion: operator.knative.dev/v1alpha1
    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:

    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/v1alpha1
    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/v1alpha1
    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.       ...

    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.

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

    The KnativeEventing CR allows you to configure system resources for Knative system containers.

    Requests and limits can be configured for the following containers:

    • eventing-controller
    • eventing-webhook
    • imc-controller
    • imc-dispatcher
    • mt-broker-ingress
    • mt-broker-ingress
    • mt-broker-controller

    To override resource settings for a specific container, you must create an entry in the spec.resources list with the container name and the .

    Info

    If multiple deployments share the same container name, the configuration in spec.resources for that certain container will apply to all the deployments. Visit Override System Resources based on the deployment to specify the resources for a container within a specific deployment.

    For example, the following KnativeEventing CR configures the eventing-webhook container to request 0.3 CPU and 100MB of RAM, and sets hard limits of 1 CPU, 250MB RAM, and 4GB of local storage:

    1. apiVersion: operator.knative.dev/v1alpha1
    2. kind: KnativeEventing
    3. metadata:
    4.   name: knative-eventing
    5.   namespace: knative-eventing
    6. spec:
    7.   resources:
    8.   - container: eventing-webhook
    9.     requests:
    10.       cpu: 300m
    11.       memory: 100Mi
    12.     limits:
    14.       memory: 250Mi

    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/v1alpha1
    2. kind: KnativeEventing
    3.   name: knative-eventing
    4.   namespace: knative-eventing
    5. spec:
    6.   deployments:
    7.   - name: eventing-controller
    8.     resources:
    9.     - container: eventing-controller
    10.       requests:
    11.         cpu: 300m
    12.         memory: 100Mi
    13.       limits:
    14.         cpu: 1000m
    15.         memory: 250Mi

    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/v1alpha1
    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/v1alpha1
    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
    1. apiVersion: operator.knative.dev/v1alpha1
    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.               - ssd