This glossary explains terminology unique to Strimzi and its components. It supports consistent usage and understanding across Strimzi documentation. Terms from Kafka and Kubernetes are outside its scope.
An optional operator that simplifies the sharing of Kafka connection information and credentials between namespaces.
Connection details are stored centrally in a Secret resource.
Defines how clients prove their identity to the Kafka cluster. Strimzi manages authentication as a client-server relationship:
Server-Side: The Kafka cluster’s listeners are configured to require a specific authentication type.
Client-Side: A client (a KafkaUser or a client-based Kafka component managed by Strimzi) must be configured to provide matching credentials.
Listener authentication is configured per listener in the spec.kafka.listeners array of the Kafka custom resource.
Supported types include tls, scram-sha-512, and custom.
For Kafka users, authentication is managed using the KafkaUser custom resource. Supported types are tls, tls-external (using an external CA), and scram-sha-512.
Strimzi automatically creates the necessary Secret resources for the user.
For Strimzi-managed components, authentication is managed in the custom resource of the component, such as KafkaConnect.
Supported types include tls, scram-sha-256, scram-sha-512, plain, and custom.
For more information, see the following:
Defines which actions an authenticated client is permitted to perform on Kafka resources, such as writing to or reading from a topic. Configuration involves setting a cluster-wide mechanism and then, if required, defining user-specific rules.
This defines the overall mechanism used by the Kafka cluster to control client actions.
It’s configured in the spec.kafka.authorization section of the Kafka custom resource.
Supported types include simple (using the Kafka’s built-in authorizer) and custom (using custom authorizers).
This defines specific Access Control Lists (ACLs) for a user, granting permissions to perform actions on Kafka resources.
The ACLs are defined in the spec.authorization section of the KafkaUser custom resource.
If using a custom authorization mechanism, user permissions are typically managed within the external authorization system and not through the KafkaUser resource.
For more information, see the following:
A Certificate Authority managed by the Strimzi Cluster Operator that issues TLS certificates for Kafka clients. These certificates are used for mutual TLS (mTLS) authentication between external clients and Kafka brokers.
A Certificate Authority managed by the Strimzi Cluster Operator that issues TLS certificates to secure communication between Kafka brokers, internal components, and Kafka clients. These certificates enable encrypted and authenticated communication over TLS.
The central operator responsible for deploying and managing Kafka clusters, Kafka Connect, Kafka MirrorMaker, and related components.
For more information, see the following:
A component that provides automated Kafka cluster rebalancing and optimization.
Cruise Control is configured through the Kafka custom resource, while rebalancing operations are managed using the KafkaRebalance custom resource.
For more information, see the following:
A utility installed as a separate component that ensures safe pod evictions during rolling updates to prevent data loss or downtime.
For more information, see Evicting pods with the Strimzi Drain Cleaner.
Strimzi supports Transport Layer Security (TLS) to encrypt communication between Kafka and its clients.
TLS is enabled per listener in the Kafka custom resource, and communication between internal components is always encrypted.
The Entity Operator runs the Topic Operator and User Operator in separate containers within its pod, allowing them to handle topic and user management.
Used to enable or disable specific features and functions managed by Strimzi operators. New features may be introduced initially through feature gates.
For more information, see Feature gates.
A custom resource for deploying and configuring a Kafka cluster, including settings for nodes, listeners, storage, security, and internal components like Cruise Control and the Entity Operator.
For more information, see the Kafka schema reference.
Provides a RESTful interface that allows HTTP-based clients to interact with a Kafka cluster.
For more information, see Using the HTTP Bridge.
A custom resource used to deploy and configure a HTTP Bridge instance, specifying replicas, authentication, and connection details.
For more information, see the KafkaBridge schema reference.
A custom resource used to deploy and configure a Kafka Connect cluster for integrating external systems with Kafka.
For more information, see the KafkaConnect schema reference.
A custom resource for managing individual Kafka connectors in a Kafka Connect cluster declaratively and independently of the KafkaConnect deployment.
For more information, see the KafkaConnector schema reference.
The Kafka Exporter exposes Kafka metrics for Prometheus.
It is configured as part of the Kafka custom resource.
For more information, see the KafkaExporterSpec schema reference.
A custom resource for deploying a Kafka MirrorMaker 2 instance to replicate data between Kafka clusters.
For more information, see the KafkaMirrorMaker2 schema reference.
A custom resource used to configure distinct groups of nodes within a Kafka cluster. Nodes in a node pool can be configured to operate as Kafka brokers, controllers, or both.
For more information, see the KafkaNodePool schema reference.
A custom resource that triggers and manages cluster rebalancing through Cruise Control by setting optimization goals.
Rebalance modes:
Load rebalanced across all brokers
Replicas moved to newly added brokers
Replicas moved off brokers being removed
Data moved between storage volumes within the same broker
For more information, see the KafkaRebalance schema reference.
A custom resource for managing Kafka topics (creation, configuration, deletion) through the Topic Operator.
For more information, see the KafkaTopic schema reference.
A custom resource for managing Kafka users (creation, configuration, deletion) through the User Operator, including their authentication credentials and access permissions.
For more information, see the KafkaUser schema reference.
Defines how clients connect to the Kafka cluster. Strimzi supports several listener types for exposing Kafka internally or externally.
Listener types:
Kafka exposed only within the Kubernetes cluster
Kafka exposed externally using OpenShift Routes
Kafka exposed externally using a LoadBalancer service
Kafka exposed externally using NodePort services
Kafka exposed externally using Kubernetes NGINX Ingress with TLS passthrough
Kafka exposed using a per-broker ClusterIP service
Logging for Kafka components and Strimzi operators is configured through their custom resources. The configuration uses Log4j2 and supports dynamic updates without restarting pods.
Configuration methods:
Loggers and levels are defined directly in the custom resource. Used for simple changes to log levels.
Loggers and levels are defined in a ConfigMap referenced by the custom resource.
Used for complex, reusable, or filtered configurations.
Strimzi components can expose Prometheus-formatted metrics for monitoring. Metrics for components are enabled through its custom resource.
For more information, see Introducing metrics.
A component that exposes metrics from Strimzi-managed components such as Kafka brokers, Kafka Connect, Kafka MirrorMaker 2, and HTTP Bridge in Prometheus format.
The Metrics Reporter is enabled through the metricsConfig property in the corresponding custom resource.
Strimzi automatically creates a NetworkPolicy resource for each listener, allowing connections from all namespaces by default. You can configure the networkPolicyPeers property to restrict access to specific applications or namespaces.
Defines disk storage for Kafka nodes within the KafkaNodePool custom resource.
Supported storage types:
Temporary storage tied to the pod lifecycle
Durable storage using PersistentVolumeClaims (PVCs)
Multiple disks or volumes (ephemeral or persistent)
For more information, see Configuring Kafka storage.
The formal specification that defines the structure, properties, and validation rules for Strimzi custom resources. Also referred to as the Strimzi custom resource schema.
The primary deployment artifact for Strimzi. An operator that installs and configures components for running Kafka on Kubernetes, including the Cluster Operator.
The suite of Kubernetes operators (Cluster Operator, Topic Operator, User Operator) that automate Kafka cluster management.
A custom resource used by the Strimzi Cluster Operator to manage the lifecycle of broker pods, replacing Kubernetes StatefulSet resources to provide greater control over pod identity and updates.
A Kafka user principal with full administrative access that bypasses all ACL checks. Super users are configured via the superUsers property in the Kafka custom resource when simple authorization is enabled.
A capability enabling Kafka brokers to store topic log segments across different storage tiers, such as local disk and remote object storage.
It is configured through the Kafka custom resource.
For more information, see the following:
The operator responsible for managing Kafka topics through KafkaTopic custom resources.
The process of updating the Cluster Operator and the Kafka cluster it manages. Upgrade typically involves upgrading the operator first, then the Kafka version, and finally the metadata version.
Upgrade paths:
Move between consecutive minor versions
Skip one or more minor versions
For more information, see Upgrading Strimzi.
The operator responsible for managing Kafka users and ACLs through KafkaUser custom resources.