Configures a Kafka cluster.

[id='property-kafka-listeners-{context}']
= `listeners`

Use the `listeners` property to configure listeners to provide access to Kafka brokers.

.Example configuration of a plain (unencrypted) listener without authentication

[source,yaml,subs=attributes+]
----
apiVersion: {KafkaApiVersion}
kind: Kafka
spec:
  kafka:
    # ...
    listeners:
      - name: plain
        port: 9092
        type: internal
        tls: false
    # ...
  zookeeper:
    # ...
----

[id='property-kafka-config-{context}']
= `config`

Use the `config` properties to configure Kafka broker options as keys.

The values can be one of the following JSON types:

* String
* Number
* Boolean

*Exceptions*

You can specify and configure the options listed in the {ApacheKafkaBrokerConfig}.

However, Strimzi takes care of configuring and managing options related to the following, which cannot be changed:

* Security (encryption, authentication, and authorization)
* Listener configuration
* Broker ID configuration
* Configuration of log data directories
* Inter-broker communication
* ZooKeeper connectivity

Properties with the following prefixes cannot be set:

* `advertised.`
* `authorizer.`
* `broker.`
* `controller`
* `cruise.control.metrics.reporter.bootstrap.`
* `cruise.control.metrics.topic`
* `host.name`
* `inter.broker.listener.name`
* `listener.`
* `listeners.`
* `log.dir`
* `password.`
* `port`
* `process.roles`
* `sasl.`
* `security.`
* `servers,node.id`
* `ssl.`
* `super.user`
* `zookeeper.clientCnxnSocket`
* `zookeeper.connect`
* `zookeeper.set.acl`
* `zookeeper.ssl`

If the `config` property contains an option that cannot be changed, it is disregarded, and a warning message is logged to the Cluster Operator log file.
All other supported options are forwarded to Kafka, including the following exceptions to the options configured by Strimzi:

* Any `ssl` configuration for xref:con-common-configuration-ssl-reference[supported TLS versions and cipher suites]
* Configuration for the `zookeeper.connection.timeout.ms` property to set the maximum time allowed for establishing a ZooKeeper connection
* Cruise Control metrics properties: 
** `cruise.control.metrics.topic.num.partitions`
** `cruise.control.metrics.topic.replication.factor`
** `cruise.control.metrics.topic.retention.ms`
** `cruise.control.metrics.topic.auto.create.retries`
** `cruise.control.metrics.topic.auto.create.timeout.ms`
** `cruise.control.metrics.topic.min.insync.replicas`
* Controller properties:
** `controller.quorum.election.backoff.max.ms`
** `controller.quorum.election.timeout.ms`
** `controller.quorum.fetch.timeout.ms`

.Example Kafka broker configuration
[source,yaml,subs="attributes+"]
----
apiVersion: {KafkaApiVersion}
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
    config:
      num.partitions: 1
      num.recovery.threads.per.data.dir: 1
      default.replication.factor: 3
      offsets.topic.replication.factor: 3
      transaction.state.log.replication.factor: 3
      transaction.state.log.min.isr: 1
      log.retention.hours: 168
      log.segment.bytes: 1073741824
      log.retention.check.interval.ms: 300000
      num.network.threads: 3
      num.io.threads: 8
      socket.send.buffer.bytes: 102400
      socket.receive.buffer.bytes: 102400
      socket.request.max.bytes: 104857600
      group.initial.rebalance.delay.ms: 0
      zookeeper.connection.timeout.ms: 6000
    # ...
----

[id='property-kafka-brokerRackInitImage-{context}']
= `brokerRackInitImage`

When rack awareness is enabled, Kafka broker pods use init container to collect the labels from the Kubernetes cluster nodes.
The container image used for this container can be configured using the `brokerRackInitImage` property.
When the `brokerRackInitImage` field is missing, the following images are used in order of priority:

. Container image specified in `STRIMZI_DEFAULT_KAFKA_INIT_IMAGE` environment variable in the Cluster Operator configuration.
. `{DockerKafkaInit}` container image.

.Example `brokerRackInitImage` configuration
[source,yaml,subs=attributes+]
----
apiVersion: {KafkaApiVersion}
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
    rack:
      topologyKey: topology.kubernetes.io/zone
    brokerRackInitImage: my-org/my-image:latest
    # ...
----

NOTE: Overriding container images is recommended only in special situations, where you need to use a different container registry.
For example, because your network does not allow access to the container registry used by Strimzi. In this case, you should either copy the Strimzi images or build them from the source.
If the configured image is not compatible with Strimzi images, it might not work properly.

[id='property-kafka-logging-{context}']
= `logging`

Kafka has its own configurable loggers, which include the following:

* `log4j.logger.org.I0Itec.zkclient.ZkClient`
* `log4j.logger.org.apache.zookeeper`
* `log4j.logger.kafka`
* `log4j.logger.org.apache.kafka`
* `log4j.logger.kafka.request.logger`
* `log4j.logger.kafka.network.Processor`
* `log4j.logger.kafka.server.KafkaApis`
* `log4j.logger.kafka.network.RequestChannel$`
* `log4j.logger.kafka.controller`
* `log4j.logger.kafka.log.LogCleaner`
* `log4j.logger.state.change.logger`
* `log4j.logger.kafka.authorizer.logger`

Kafka uses the Apache `log4j` logger implementation.

Use the `logging` property to configure loggers and logger levels.

You can set the log levels by specifying the logger and level directly (inline) or use a custom (external) ConfigMap.
If a ConfigMap is used, you set `logging.valueFrom.configMapKeyRef.name` property to the name of the ConfigMap containing the external logging configuration. Inside the ConfigMap, the logging configuration is described using `log4j.properties`. Both `logging.valueFrom.configMapKeyRef.name` and `logging.valueFrom.configMapKeyRef.key` properties are mandatory. A ConfigMap using the exact logging configuration specified is created with the custom resource when the Cluster Operator is running, then recreated after each reconciliation. If you do not specify a custom ConfigMap, default logging settings are used. If a specific logger value is not set, upper-level logger settings are inherited for that logger.
For more information about log levels, see {ApacheLoggers}.

Here we see examples of `inline` and `external` logging.
The `inline` logging specifies the root logger level.
You can also set log levels for specific classes or loggers by adding them to the loggers property.

.Inline logging
[source,yaml,subs="+quotes,attributes"]
----
apiVersion: {KafkaApiVersion}
kind: Kafka
spec:
  # ...
  kafka:
    # ...
    logging:
      type: inline
      loggers:
        kafka.root.logger.level: INFO
        log4j.logger.kafka.coordinator.transaction: TRACE
        log4j.logger.kafka.log.LogCleanerManager: DEBUG
        log4j.logger.kafka.request.logger: DEBUG
        log4j.logger.io.strimzi.kafka.oauth: DEBUG
        log4j.logger.org.openpolicyagents.kafka.OpaAuthorizer: DEBUG
  # ...
----

NOTE: Setting a log level to `DEBUG` may result in a large amount of log output and may have performance implications.

.External logging
[source,yaml,subs="+quotes,attributes"]
----
apiVersion: {KafkaApiVersion}
kind: Kafka
spec:
  # ...
  logging:
    type: external
    valueFrom:
      configMapKeyRef:
        name: customConfigMap
        key: kafka-log4j.properties
  # ...
----

Any available loggers that are not configured have their level set to `OFF`.

If Kafka was deployed using the Cluster Operator,
changes to Kafka logging levels are applied dynamically.

If you use external logging, a rolling update is triggered when logging appenders are changed.

.Garbage collector (GC)

Garbage collector logging can also be enabled (or disabled) using the xref:con-common-configuration-garbage-collection-reference[`jvmOptions` property].
