This is a cache of https://docs.openshift.com/serverless/1.33/eventing/tuning/overriding-config-eventing.html. It is a snapshot of the page at 2024-11-21T16:41:29.324+0000.
Overriding deployment configurations - Tuning eventing configuration | Eventing | Red Hat OpenShift Serverless 1.33
    OpenShift docs are moving and will soon only be available at docs.redhat.com, the home of all Red Hat product documentation. Explore the new docs experience today.
  1. Documentation
    2. history bug_report picture_as_pdf
×

Overriding Knative Eventing system deployment configurations

You can override the default configurations for some specific deployments by modifying the workloads spec in the KnativeEventing custom resource (CR). Currently, overriding default configuration settings is supported for the eventing-controller, eventing-webhook, and imc-controller fields, as well as for the readiness and liveness fields for probes.

The replicas spec cannot override the number of replicas for deployments that use the Horizontal Pod Autoscaler (HPA), and does not work for the eventing-webhook deployment.

You can only override probes that are defined in the deployment by default.

Overriding deployment configurations

Currently, overriding default configuration settings is supported for the eventing-controller, eventing-webhook, and imc-controller fields, as well as for the readiness and liveness fields for probes.

The replicas spec cannot override the number of replicas for deployments that use the Horizontal Pod Autoscaler (HPA), and does not work for the eventing-webhook deployment.

In the following example, a KnativeEventing CR overrides the eventing-controller deployment so that:

  • The readiness probe timeout eventing-controller is set to be 10 seconds.

  • The deployment has specified CPU and memory resource limits.

  • The deployment has 3 replicas.

  • The example-label: label label is added.

  • The example-annotation: annotation annotation is added.

  • The nodeSelector field is set to select nodes with the disktype: hdd label.

KnativeEventing CR example
apiVersion: operator.knative.dev/v1beta1
kind: KnativeEventing
metadata:
  name: knative-eventing
  namespace: knative-eventing
spec:
  workloads:
  - name: eventing-controller
    readinessProbes: (1)
      - container: controller
        timeoutSeconds: 10
    resources:
    - container: eventing-controller
      requests:
        cpu: 300m
        memory: 100Mi
      limits:
        cpu: 1000m
        memory: 250Mi
    replicas: 3
    labels:
      example-label: label
    annotations:
      example-annotation: annotation
    nodeSelector:
      disktype: hdd
1 You can use the readiness and liveness probe overrides to override all fields of a probe in a container of a deployment as specified in the Kubernetes API except for the fields related to the probe handler: exec, grpc, httpGet, and tcpSocket.

The KnativeEventing CR label and annotation settings override the deployment’s labels and annotations for both the deployment itself and the resulting pods.

Modifying consumer group IDs and topic names

You can change templates for generating consumer group IDs and topic names used by your triggers, brokers, and channels.

Prerequisites

  • You have cluster or dedicated administrator permissions on OpenShift Container Platform.

  • The OpenShift Serverless Operator, Knative Eventing, and the KnativeKafka custom resource (CR) are installed on your OpenShift Container Platform cluster.

  • You have created a project or have access to a project that has the appropriate roles and permissions to create applications and other workloads in OpenShift Container Platform.

  • You have installed the OpenShift CLI (oc).

Procedure

  1. To change templates for generating consumer group IDs and topic names used by your triggers, brokers, and channels, modify the KnativeKafka resource:

    apiVersion: v1
kind: KnativeKafka
metadata:
  name: knative-kafka
  namespace: knative-eventing
# ...
spec:
  config:
    config-kafka-features:
      triggers.consumergroup.template: <template> (1)
      brokers.topic.template: <template> (2)
      channels.topic.template: <template> (3)
    1 The template for generating the consumer group ID used by your triggers. Use a valid Go text/template value. Defaults to "knative-trigger-{{ .Namespace }}-{{ .Name }}".
    2 The template for generating Kafka topic names used by your brokers. Use a valid Go text/template value. Defaults to "knative-broker-{{ .Namespace }}-{{ .Name }}".
    3 The template for generating Kafka topic names used by your channels. Use a valid Go text/template value. Defaults to "messaging-kafka.{{ .Namespace }}.{{ .Name }}".
    Example template configuration
    apiVersion: v1
kind: KnativeKafka
metadata:
  name: knative-kafka
  namespace: knative-eventing
# ...
spec:
  config:
    config-kafka-features:
      triggers.consumergroup.template: "{% raw %}"knative-trigger-{{ .Namespace }}-{{ .Name }}-{{ .annotations.my-annotation }}"{% endraw %}"
      brokers.topic.template: "{% raw %}"knative-broker-{{ .Namespace }}-{{ .Name }}-{{ .annotations.my-annotation }}"{% endraw %}"
      channels.topic.template: "{% raw %}"messaging-kafka.{{ .Namespace }}.{{ .Name }}-{{ .annotations.my-annotation }}"{% endraw %}"

  2. Apply the KnativeKafka YAML file:

    $ oc apply -f <knative_kafka_filename>
Additional resources