:_mod-docs-content-type: CONCEPT

Configures a Kafka cluster using the `Kafka` custom resource.

The `config` properties are one part of the overall configuration for the resource.
Use the `config` properties to configure Kafka broker options as keys.

.Example Kafka configuration
[source,yaml,subs="+attributes"]
----
apiVersion: {KafkaApiVersion}
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    version: {DefaultKafkaVersion}
    metadataVersion: {DefaultKafkaMetadataVersion}
    # ...
    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
# ...
----

The values can be one of the following JSON types:

* String
* Number
* Boolean

*Exceptions*

You can specify and configure the options listed in the link:{ApacheKafkaDocsBase}configuration/broker-configs/[Kafka broker configuration documentation^].

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

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`

NOTE: Strimzi supports only KRaft-based Kafka deployments. As a result, ZooKeeper-related configuration options are not supported.

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]
* 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`
* Listener properties (which are configured in the following format: `listener.name.listener1-9900.connections.max.reauth.ms` where `listener1-9900` is the listener name and port joined by `-`):
** `connections.max.reauth.ms`
** `max.connections`
** `max.connections.per.ip`
** `max.connections.per.ip.overrides`
** `max.connection.creation.rate`

[id='property-kafka-brokerRackInitImage-{context}']
= Configuring rack awareness and init container images

Rack awareness is enabled using the `rack` property.
When rack awareness is enabled, Kafka broker pods use init container to collect the labels from the Kubernetes cluster nodes.
The container image for this init container can be specified using the `brokerRackInitImage` property. 
If the `brokerRackInitImage` field is not provided, the images used are prioritized as follows:

. 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, such as when your network does not allow access to the container registry used by Strimzi. 
In such cases, you should either copy the Strimzi images or build them from the source. 
Be aware that 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 preconfigured loggers:

[cols="1m,2,1",options="header"]
|===
| Logger              | Description                                              | Default Level

| rootLogger          | Default logger for all classes                           | INFO
| kafka               | Logs Kafka node classes                                  | INFO
| orgapachekafka      | Logs Kafka library classes                               | INFO
| requestlogger       | Logs client request details                              | WARN
| requestchannel      | Logs request handling in the broker                      | WARN
| controller          | Logs controller activity, such as leadership changes     | INFO
| logcleaner          | Logs log compaction and cleanup processes                | INFO
| statechange         | Logs broker and partition state transitions              | INFO
| authorizer          | Logs access control decisions                            | INFO
|===

Kafka uses the Apache `log4j2` logger implementation.
Use the `logging` property to configure loggers and logger levels.

You can set log levels using either the `inline` or `external` logging configuration types.

Specify loggers and levels directly in the custom resource for inline configuration:

.Example inline logging configuration
[source,yaml,subs="+quotes,attributes"]
----
apiVersion: {KafkaApiVersion}
kind: Kafka
spec:
  # ...
  kafka:
    # ...
    logging:
      type: inline
      loggers:
        rootLogger.level: INFO
        logger.kafka.level: DEBUG 
        logger.logcleaner.level: DEBUG 
        logger.authorizer.level: TRACE
  # ...
----

You can define additional loggers by specifying the full class or package name using `logger.<name>.name`. 
For example, to configure logging for OAuth components inline:

.Example custom inline loggers
[source,yaml]
----
# ...
logger.oauth.name: io.strimzi.kafka.oauth # <1>
logger.oauth.level: DEBUG # <2>
----
<1> Creates a logger for the `io.strimzi.kafka.oauth` package.
<2> Sets the logging level for the OAuth package.

Alternatively, you can reference an external `ConfigMap` containing a complete `log4j2.properties` file that defines your own log4j2 configuration, including loggers, appenders, and layout configuration:

.Example external logging configuration
[source,yaml,subs="+quotes,attributes"]
----
apiVersion: {KafkaApiVersion}
kind: Kafka
spec:
  # ...
  logging:
    type: external
    valueFrom:
      configMapKeyRef:
        # name and key are mandatory
        name: customConfigMap
        key: log4j2.properties
  # ...
----

.Garbage collector (GC)

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