Ce contenu n'est pas disponible dans la langue sélectionnée.

Chapter 10. Tuning eventing configuration


You can override the default configurations for 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 and for the readiness and liveness fields for probes.

10.1.1. Overriding deployment configurations

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

Important

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.

Note

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

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

  • The eventing-controller readiness probe timeout is 10 seconds.
  • The deployment specifies CPU and memory resource limits.
  • The deployment runs with 3 replicas.
  • The deployment includes the example-label: label label.
  • The deployment includes the example-annotation: annotation annotation.
  • The nodeSelector field selects nodes with the disktype: hdd label.

The following example displayes KnativeEventing CR:

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
  • readinessProbes: 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.
Note

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

10.1.2. 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.
  • You have installed the OpenShift Serverless Operator, Knative Eventing, and the KnativeKafka custom resource (CR) 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, change the KnativeKafka resource:

    apiVersion: v1
    kind: KnativeKafka
    metadata:
      name: knative-kafka
      namespace: knative-eventing
    # ...
    spec:
      config:
        config-kafka-features:
          triggers.consumergroup.template: <template>
          brokers.topic.template: <template>
          channels.topic.template: <template>
    • triggers.consumergroup.template: 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 }}".
    • brokers.topic.template: The template for generating Kafka topic names used by your brokers. Use a valid Go text/template value. Defaults to "knative-broker-{{ .Namespace }}-{{ .Name }}".
    • channels.topic.template: The template for generating Kafka topic names used by your channels. Use a valid Go text/template value. Defaults to "messaging-kafka.{{ .Namespace }}.{{ .Name }}".

    The following example displayes 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 by running the following command:

    $ oc apply -f <knative_kafka_filename>

10.2. High availability

High availability (HA) keeps Kubernetes APIs operational during disruptions. If an active controller fails, another controller takes over and continues processing requests.

OpenShift Serverless uses leader election for HA. After installation, the system runs multiple controller instances that compete for a shared leader election lock. The controller that holds the lock acts as the leader.

By default, Knative Eventing runs the eventing-controller, eventing-webhook, imc-controller, imc-dispatcher, and mt-broker-controller components with high availability (HA). Each component runs with two replicas. You can change the number of replicas for these components by modifying the spec.high-availability.replicas value in the KnativeEventing custom resource (CR).

Note

For Knative Eventing, the mt-broker-filter and mt-broker-ingress deployments are not scaled by HA. If your environment requires more deployments, scale these components manually.

Prerequisites

  • You have cluster administrator permissions on OpenShift Container Platform, or you have cluster or dedicated administrator permissions on Red Hat OpenShift Service on AWS or OpenShift Dedicated.
  • You have installed the OpenShift Serverless Operator and Knative Eventing are on your cluster.

Procedure

  1. In the OpenShift Container Platform web console, navigate to OperatorHub Installed Operators.
  2. Select the knative-eventing namespace.
  3. Click Knative Eventing in the list of Provided APIs for the OpenShift Serverless Operator to go to the Knative Eventing tab.
  4. Click knative-eventing, then go to the YAML tab in the knative-eventing page.
  5. Change the number of replicas in the KnativeEventing CR:

    You get an output similar to the following example:

    apiVersion: operator.knative.dev/v1beta1
    kind: KnativeEventing
    metadata:
      name: knative-eventing
      namespace: knative-eventing
    spec:
      high-availability:
        replicas: 3
  6. You can also specify the number of replicas for a specific workload.

    Note

    Workload-specific configuration overrides the global setting for Knative Eventing.

    You get an output similar to the following example:

    apiVersion: operator.knative.dev/v1beta1
    kind: KnativeEventing
    metadata:
      name: knative-eventing
      namespace: knative-eventing
    spec:
      high-availability:
        replicas: 3
      workloads:
      - name: mt-broker-filter
        replicas: 3
  7. Verify that the deployment respects the high availability limits:

    You get an output similar to the following example command:

    $ oc get hpa -n knative-eventing

    You get an output similar to the following example:

    NAME                 REFERENCE                      TARGETS   MINPODS   MAXPODS   REPLICAS   AGE
    broker-filter-hpa    Deployment/mt-broker-filter    1%/70%    3         12        3          112s
    broker-ingress-hpa   Deployment/mt-broker-ingress   1%/70%    3         12        3          112s
    eventing-webhook     Deployment/eventing-webhook    4%/100%   3         7         3          115s

By default, the Knative broker implementation for Apache Kafka runs the kafka-controller and kafka-webhook-eventing components with high availability (HA). Each component runs with two replicas. You can change the number of replicas for these components by modifying the spec.high-availability.replicas value in the KnativeKafka custom resource (CR).

Prerequisites

  • You have cluster administrator permissions on OpenShift Container Platform, or you have cluster or dedicated administrator permissions on Red Hat OpenShift Service on AWS or OpenShift Dedicated.
  • You have installed the OpenShift Serverless Operator and Knative broker for Apache Kafka on your cluster.

Procedure

  1. In the OpenShift Container Platform web console, navigate to OperatorHub Installed Operators.
  2. Select the knative-eventing namespace.
  3. Click Knative Kafka in the list of Provided APIs for the OpenShift Serverless Operator to go to the Knative Kafka tab.
  4. Click knative-kafka, then go to the YAML tab in the knative-kafka page.
  5. Change the number of replicas in the KnativeKafka CR:

    You get an output similar to the following example:

    apiVersion: operator.serverless.openshift.io/v1alpha1
    kind: KnativeKafka
    metadata:
      name: knative-kafka
      namespace: knative-eventing
    spec:
      high-availability:
        replicas: 3

10.2.3. Overriding disruption budgets

A Pod Disruption Budget (PDB) is a standard feature of Kubernetes APIs that helps limit the disruption to an application when its pods need to be rescheduled for maintenance reasons.

Procedure

  • Override the default PDB for a specific resource by modifying the minAvailable configuration value in the KnativeEventing custom resource (CR).

    The following example displayes PDB with a minAvailable seting of 70%:

    apiVersion: operator.knative.dev/v1beta1
    kind: KnativeEventing
    metadata:
     name: knative-eventing
     namespace: knative-eventing
    spec:
     podDisruptionBudgets:
     - name: eventing-webhook
       minAvailable: 70%
    Note

    If you disable high-availability, for example, by changing the high-availability.replicas value to 1, make sure you also update the corresponding PDB minAvailable value to 0. Otherwise, the pod disruption budget prevents automatic cluster or Operator updates.

Red Hat logoGithubredditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance. Découvrez nos récentes mises à jour.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez le Blog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

Theme

© 2026 Red Hat
Retour au début