サポートコンソール開発者トライアルの開始お問い合わせ

9.3. Configuring Kafka with ZooKeeper

Update the spec properties of the Kafka custom resource to configure your deployment of Kafka with ZooKeeper.

As well as configuring Kafka, you can add configuration for ZooKeeper and the Streams for Apache Kafka operators. The configuration options for Kafka and the Streams for Apache Kafka operators are the same as when using Kafka in KRaft mode. For descriptions of the properties, see 「Configuring Kafka in KRaft mode」.

The inter-broker protocol version (inter.broker.protocol.version) must be a version supported by the Kafka version (spec.kafka.version). If the inter-broker protocol version is not set in the configuration, the Cluster Operator updates the version to the default for the Kafka version used.

If you are also using node pools, the following must be specified in the node pool configuration:

  • Roles assigned to each node within the Kafka cluster
  • Number of replica nodes used
  • Storage specification for the nodes

If set in the node pool configuration, the equivalent configuration in the Kafka resource, such as spec.kafka.replicas, is not required. Other optional properties may also be set in node pools.

For a deeper understanding of the ZooKeeper cluster configuration options, refer to the Streams for Apache Kafka Custom Resource API Reference.

Example Kafka custom resource configuration when using ZooKeeper

# Basic configuration (required)
apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
# Deployment specifications
spec:
  kafka:
    # Replicas (required)
    replicas: 3
    # Kafka version (recommended)
    version: 3.8.0
    # Logging configuration (optional)
    logging:
      type: inline
      loggers:
        kafka.root.logger.level: INFO
    # Resources requests and limits (recommended)
    resources:
      requests:
        memory: 64Gi
        cpu: "8"
      limits:
        memory: 64Gi
        cpu: "12"
    # Readiness probe (optional)
    readinessProbe:
      initialDelaySeconds: 15
      timeoutSeconds: 5
    # Liveness probe (optional)
    livenessProbe:
      initialDelaySeconds: 15
      timeoutSeconds: 5
    # JVM options (optional)
    jvmOptions:
      -Xms: 8192m
      -Xmx: 8192m
    # Custom image (optional)
    image: my-org/my-image:latest
    # Listener configuration (required)
    listeners:
      - name: plain
        port: 9092
        type: internal
        tls: false
        configuration:
          useServiceDnsDomain: true
      - name: tls
        port: 9093
        type: internal
        tls: true
        authentication:
          type: tls
      - name: external1
        port: 9094
        type: route
        tls: true
        configuration:
          brokerCertChainAndKey:
            secretName: my-secret
            certificate: my-certificate.crt
            key: my-key.key
    # Authorization (optional)
    authorization:
      type: simple
    # Kafka configuration (recommended)
    config:
      auto.create.topics.enable: "false"
      offsets.topic.replication.factor: 3
      transaction.state.log.replication.factor: 3
      transaction.state.log.min.isr: 2
      default.replication.factor: 3
      min.insync.replicas: 2
      inter.broker.protocol.version: "3.8"
    # Storage configuration (required)
    storage:
      type: persistent-claim
      size: 10000Gi
    # Rack awareness (optional)
    rack:
      topologyKey: topology.kubernetes.io/zone
    # Metrics configuration (optional)
    metricsConfig:
      type: jmxPrometheusExporter
      valueFrom:
        configMapKeyRef:
          name: my-config-map
          key: my-key
    # ...
  # ZooKeeper configuration (required)
  zookeeper:
1 

    # Replicas (required)
    replicas: 3
2 

    # Logging configuration (optional)
    logging:
3 

      type: inline
      loggers:
        zookeeper.root.logger: INFO
    # Resources requests and limits (recommended)
    resources:
4 

      requests:
        memory: 8Gi
        cpu: "2"
      limits:
        memory: 8Gi
        cpu: "2"
    # JVM options (optional)
    jvmOptions:
5 

      -Xms: 4096m
      -Xmx: 4096m
    # Storage configuration (required)
    storage:
6 

      type: persistent-claim
      size: 1000Gi
    # Metrics configuration (optional)
    metricsConfig:
7 

      type: jmxPrometheusExporter
      valueFrom:
        configMapKeyRef:
8 

          name: my-config-map
          key: my-key
    # ...
  # Entity operator (recommended)
  entityOperator:
    topicOperator:
      watchedNamespace: my-topic-namespace
      reconciliationIntervalSeconds: 60
      # Logging configuration (optional)
      logging:
        type: inline
        loggers:
          rootLogger.level: INFO
      # Resources requests and limits (recommended)
      resources:
        requests:
          memory: 512Mi
          cpu: "1"
        limits:
          memory: 512Mi
          cpu: "1"
    userOperator:
      watchedNamespace: my-topic-namespace
      reconciliationIntervalSeconds: 60
      # Logging configuration (optional)
      logging:
        type: inline
        loggers:
          rootLogger.level: INFO
      # Resources requests and limits (recommended)
      resources:
        requests:
          memory: 512Mi
          cpu: "1"
        limits:
          memory: 512Mi
          cpu: "1"
  # Kafka Exporter (optional)
  kafkaExporter:
    # ...
  # Cruise Control (optional)
  cruiseControl:
    # ...

1
ZooKeeper-specific configuration contains properties similar to the Kafka configuration.
2
The number of ZooKeeper nodes. ZooKeeper clusters or ensembles usually run with an odd number of nodes, typically three, five, or seven. The majority of nodes must be available in order to maintain an effective quorum. If the ZooKeeper cluster loses its quorum, it will stop responding to clients and the Kafka brokers will stop working. Having a stable and highly available ZooKeeper cluster is crucial for Streams for Apache Kafka.
3
ZooKeeper loggers and log levels.
4
Requests for reservation of supported resources, currently cpu and memory, and limits to specify the maximum resources that can be consumed.
5
JVM configuration options to optimize performance for the Virtual Machine (VM) running ZooKeeper.
6
Storage size for persistent volumes may be increased and additional volumes may be added to JBOD storage.
7
Prometheus metrics enabled. In this example, metrics are configured for the Prometheus JMX Exporter (the default metrics exporter).
8
Rules for exporting metrics in Prometheus format to a Grafana dashboard through the Prometheus JMX Exporter, which are enabled by referencing a ConfigMap containing configuration for the Prometheus JMX exporter. You can enable metrics without further configuration using a reference to a ConfigMap containing an empty file under metricsConfig.valueFrom.configMapKeyRef.key.

9.3.1. Default ZooKeeper configuration values
リンクのコピー

When deploying ZooKeeper with Streams for Apache Kafka, some of the default configuration set by Streams for Apache Kafka differs from the standard ZooKeeper defaults. This is because Streams for Apache Kafka sets a number of ZooKeeper properties with values that are optimized for running ZooKeeper within an OpenShift environment.

The default configuration for key ZooKeeper properties in Streams for Apache Kafka is as follows:

表9.1 Default ZooKeeper Properties in Streams for Apache Kafka
PropertyDefault valueDescription

tickTime

2000

The length of a single tick in milliseconds, which determines the length of a session timeout.

initLimit

5

The maximum number of ticks that a follower is allowed to fall behind the leader in a ZooKeeper cluster.

syncLimit

2

The maximum number of ticks that a follower is allowed to be out of sync with the leader in a ZooKeeper cluster.

autopurge.purgeInterval

1

Enables the autopurge feature and sets the time interval in hours for purging the server-side ZooKeeper transaction log.

admin.enableServer

false

Flag to disable the ZooKeeper admin server. The admin server is not used by Streams for Apache Kafka.

重要

Modifying these default values as zookeeper.config in the Kafka custom resource may impact the behavior and performance of your ZooKeeper cluster.

9.3.2. Deleting ZooKeeper nodes using annotations
リンクのコピー

This procedure describes how to delete an existing ZooKeeper node by using an OpenShift annotation. Deleting a ZooKeeper node consists of deleting both the Pod on which ZooKeeper is running and the related PersistentVolumeClaim (if the cluster was deployed with persistent storage). After deletion, the Pod and its related PersistentVolumeClaim are recreated automatically.

警告

Deleting a PersistentVolumeClaim can cause permanent data loss and the availability of your cluster cannot be guaranteed. The following procedure should only be performed if you have encountered storage issues.

Prerequisites

  • A running Cluster Operator

Procedure

  1. Find the name of the Pod that you want to delete.

    ZooKeeper pods are named <cluster_name>-zookeeper-<index_number>, where <index_number> starts at zero and ends at the total number of replicas minus one. For example, my-cluster-zookeeper-0.

  2. Use oc annotate to annotate the Pod resource in OpenShift: 

    oc annotate pod <cluster_name>-zookeeper-<index_number> strimzi.io/delete-pod-and-pvc="true"
  3. Wait for the next reconciliation, when the annotated pod with the underlying persistent volume claim will be deleted and then recreated.
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

Legal Notice

Theme

© 2026 Red Hatトップに戻る