// Module included in the following assemblies:
//
// assembly-config.adoc

[id='con-config-kafka-kraft-{context}']
= Configuring Kafka in KRaft mode

[role="_abstract"]
Update the `spec` properties of the `Kafka` custom resource to configure your deployment of Kafka in KRaft mode.

As well as configuring Kafka, you can add configuration for Strimzi operators.

The KRaft metadata version (`.spec.kafka.metadataVersion`) must be a version supported by the Kafka version (`spec.kafka.version`).
If the metadata version is not set in the configuration, the Cluster Operator updates the version to the default for the Kafka version used.  

NOTE: The oldest supported metadata version is 3.3. 
Using a metadata version that is older than the Kafka version might cause some features to be disabled.

Kafka clusters operating in KRaft mode also use node pools.
The following must be specified in the xref:config-node-pools-{context}[node pool configuration]:

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

Other optional properties may also be set in node pools.

For a deeper understanding of the Kafka cluster configuration options, refer to the link:{BookURLConfiguring}[Strimzi Custom Resource API Reference^].

.Example `Kafka` custom resource configuration
[source,yaml,subs="+attributes"]
----
# Basic configuration (required)
apiVersion: {KafkaApiVersion}
kind: Kafka
metadata:
  name: my-cluster
# Deployment specifications
spec:
  kafka:
    # Listener configuration (required)
    listeners: # <1>
      - name: plain # <2>
        port: 9092 # <3>
        type: internal # <4>
        tls: false # <5>
        configuration:
          useServiceDnsDomain: true # <6>
      - name: tls
        port: 9093
        type: internal
        tls: true
        authentication: # <7>
          type: tls
      - name: external1 # <8>
        port: 9094
        type: route
        tls: true
        configuration:
          brokerCertChainAndKey: # <9>
            secretName: my-secret
            certificate: my-certificate.crt
            key: my-key.key
    # Kafka version (recommended)
    version: {DefaultKafkaVersion} # <10>
    # KRaft metadata version (recommended)
    metadataVersion: {DefaultKafkaMetadataVersion} # <11>
    # Kafka configuration (recommended)
    config: # <12>
      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
    # Resources requests and limits (recommended)
    resources: # <13>
      requests:
        memory: 64Gi
        cpu: "8"
      limits:
        memory: 64Gi
        cpu: "12"
    # Logging configuration (optional)
    logging: # <14>
      type: inline
      loggers:
        kafka.root.logger.level: INFO
    # Readiness probe (optional)
    readinessProbe: # <15>
      initialDelaySeconds: 15
      timeoutSeconds: 5
    # Liveness probe (optional)  
    livenessProbe:
      initialDelaySeconds: 15
      timeoutSeconds: 5
    # JVM options (optional)
    jvmOptions: # <16>
      -Xms: 8192m
      -Xmx: 8192m
    # Custom image (optional)  
    image: my-org/my-image:latest # <17>
    # Authorization (optional)
    authorization: # <18>
      type: simple
    # Rack awareness (optional) 
    rack: # <19>
      topologyKey: topology.kubernetes.io/zone
    # Metrics configuration (optional)
    metricsConfig: # <20>
      type: jmxPrometheusExporter
      valueFrom:
        configMapKeyRef: # <21>
          name: my-config-map
          key: my-key
  # Entity Operator (recommended)
  entityOperator: # <22>
    topicOperator:
      watchedNamespace: my-topic-namespace
      reconciliationIntervalMs: 60000
      # Resources requests and limits (recommended)
      resources:
        requests:
          memory: 512Mi
          cpu: "1"
        limits:
          memory: 512Mi
          cpu: "1"
      # Logging configuration (optional)
      logging: # <23>
        type: inline
        loggers:
          rootLogger.level: INFO
    userOperator:
      watchedNamespace: my-topic-namespace
      reconciliationIntervalMs: 60000
      # Resources requests and limits (recommended)
      resources:
        requests:
          memory: 512Mi
          cpu: "1"
        limits:
          memory: 512Mi
          cpu: "1"
      # Logging configuration (optional)
      logging: # <24>
        type: inline
        loggers:
          rootLogger.level: INFO
  # Kafka Exporter (optional)
  kafkaExporter: # <25>
    # ...
  # Cruise Control (optional)
  cruiseControl: # <26>
    # ...
----
<1> Listeners configure how clients connect to the Kafka cluster via bootstrap addresses. Listeners are configured as _internal_ or _external_ listeners for connection from inside or outside the Kubernetes cluster.
<2> Name to identify the listener. Must be unique within the Kafka cluster.
<3> Port number used by the listener inside Kafka. The port number has to be unique within a given Kafka cluster. Allowed port numbers are 9092 and higher with the exception of ports 9404 and 9999, which are already used for Prometheus and JMX. Depending on the listener type, the port number might not be the same as the port number that connects Kafka clients.
<4> Listener type specified as `internal` or `cluster-ip` (to expose Kafka using per-broker `ClusterIP` services), or for external listeners, as `route` (OpenShift only), `loadbalancer`, `nodeport` or `ingress` (Kubernetes only).
<5> Enables or disables TLS encryption for each listener. For `route` and `ingress` type listeners, TLS encryption must always be enabled by setting it to `true`.
<6> Defines whether the fully-qualified DNS names including the cluster service suffix (usually `.cluster.local`) are assigned.
<7> Listener authentication mechanism specified as mTLS, SCRAM-SHA-512, or token-based OAuth 2.0.
<8> External listener configuration specifies how the Kafka cluster is exposed outside Kubernetes, such as through a `route`, `loadbalancer` or `nodeport`.
<9> Optional configuration for a Kafka listener certificate managed by an external CA (certificate authority). The `brokerCertChainAndKey` specifies a `Secret` that contains a server certificate and a private key. You can configure Kafka listener certificates on any listener with enabled TLS encryption.
<10> Kafka version, which can be changed to a supported version by following the upgrade procedure.
<11> Kafka metadata version, which can be changed to a supported version by following the upgrade procedure.
<12> Broker configuration. Standard Apache Kafka configuration may be provided, restricted to those properties not managed directly by Strimzi.
<13> Requests for reservation of supported resources, currently `cpu` and `memory`, and limits to specify the maximum resources that can be consumed.
<14> Kafka loggers and log levels added directly (`inline`) or indirectly (`external`) through a ConfigMap. A custom Log4j configuration must be placed under the `log4j.properties` key in the ConfigMap. For the Kafka `kafka.root.logger.level` logger, you can set the log level to INFO, ERROR, WARN, TRACE, DEBUG, FATAL or OFF.
<15> Healthchecks to know when to restart a container (liveness) and when a container can accept traffic (readiness).
<16> JVM configuration options to optimize performance for the Virtual Machine (VM) running Kafka.
<17> ADVANCED OPTION: Container image configuration, which is recommended only in special situations.
<18> Authorization enables simple, OAUTH 2.0, or OPA authorization on the Kafka broker. Simple authorization uses the `AclAuthorizer` and `StandardAuthorizer` Kafka plugins.
<19> Rack awareness configuration to spread replicas across different racks, data centers, or availability zones. The `topologyKey` must match a node label containing the rack ID. The example used in this configuration specifies a zone using the standard `{K8sZoneLabel}` label.
<20> Prometheus metrics enabled. In this example, metrics are configured for the Prometheus JMX Exporter (the default metrics exporter).
<21> 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`.
<22> Entity Operator configuration, which specifies the configuration for the Topic Operator and User Operator.
<23> Specified Topic Operator loggers and log levels. This example uses `inline` logging.
<24> Specified User Operator loggers and log levels.
<25> Kafka Exporter configuration. Kafka Exporter is an optional component for extracting metrics data from Kafka brokers, in particular consumer lag data. For Kafka Exporter to be able to work properly, consumer groups need to be in use.
<26> Optional configuration for Cruise Control, which is used to rebalance the Kafka cluster.