kubectl set env install/cluster-operator STRIMZI_FEATURE_GATES=""
+env:
+ - name: STRIMZI_FEATURE_GATES
+ value: +KafkaNodePools, +UseKRaftRevised on 2023-06-22 15:42:43 UTC
+Revised on 2023-06-22 19:18:19 UTC
diff --git a/contributing/guide/full.html b/contributing/guide/full.html index 488deb207..e74083e74 100644 --- a/contributing/guide/full.html +++ b/contributing/guide/full.html @@ -1957,7 +1957,7 @@Revised on 2023-06-22 15:42:41 UTC
+Revised on 2023-06-22 19:18:16 UTC
@@ -1965,7 +1965,7 @@Revised on 2023-06-22 15:42:43 UTC
+Revised on 2023-06-22 19:18:19 UTC
diff --git a/docs/operators/in-development/deploying-book.html b/docs/operators/in-development/deploying-book.html index 2cf7f4077..b696c6bc5 100644 --- a/docs/operators/in-development/deploying-book.html +++ b/docs/operators/in-development/deploying-book.html @@ -42,9 +42,10 @@If you are trying the preview of the node pools feature, you can deploy a Kafka cluster with one or more node pools. +Node pools provide configuration for a set of Kafka nodes. +By using node pools, nodes can have different configuration within the same Kafka cluster.
+Node pools are not enabled by default, so you must enable the KafkaNodePools feature gate before using them.
If you haven’t deployed a Kafka cluster as a Kafka resource, you can’t use the Cluster Operator to manage it.
This applies, for example, to a Kafka cluster running outside of Kubernetes.
However, you can use the Topic Operator and User Operator with a Kafka cluster that is not managed by Strimzi, by deploying them as standalone components.
@@ -2066,7 +2081,7 @@
READY shows the number of replicas that are ready/expected.
-The deployment is successful when the STATUS shows as Running.
STATUS displays as Running.
This procedure shows how to deploy Kafka node pools to your Kubernetes cluster using the Cluster Operator.
+Node pools represent a distinct group of Kafka nodes within a Kafka cluster that share the same configuration.
+For each Kafka node in the node pool, any configuration not defined in node pool is inherited from the cluster configuration in the kafka resource.
|
+ Note
+ |
+
+The node pools feature is available as a preview. Node pools are not enabled by default, so you must enable the KafkaNodePools feature gate before using them.
+ |
+
The deployment uses a YAML file to provide the specification to create a KafkaNodePool resource.
+You can use node pools with Kafka clusters that use KRaft (Kafka Raft metadata) mode or ZooKeeper for cluster management.
|
+ Important
+ |
++KRaft mode is not ready for production in Apache Kafka or in Strimzi. + | +
Strimzi provides the following example files that you can use to create a Kafka node pool:
+kafka-with-dual-role-kraft-nodes.yamlDeploys a Kafka cluster with one pool of KRaft nodes that share the broker and controller roles.
+kafka-with-kraft.yamlDeploys a Kafka cluster with one pool of controller nodes and one pool of broker nodes.
+kafka.yamlDeploys ZooKeeper with 3 nodes, and 2 different pools of Kafka brokers. Each of the pools has 3 brokers. The pools in the example use different storage configuration.
+|
+ Note
+ |
+
+You don’t need to start using node pools right away. If you decide to use them, you can perform the steps outlined here to deploy a new Kafka cluster with KafkaNodePool resources or migrate your existing Kafka cluster.
+ |
+
You have created and deployed a Kafka cluster.
+|
+ Note
+ |
++If you want to migrate an existing Kafka cluster to use node pools, see the steps to migrate existing Kafka clusters. + | +
Enable the KafkaNodePools feature gate.
If using KRaft mode, enable the UseKRaft feature gate too.
kubectl set env install/cluster-operator STRIMZI_FEATURE_GATES=""
+env:
+ - name: STRIMZI_FEATURE_GATES
+ value: +KafkaNodePools, +UseKRaftThis updates the Cluster Operator.
+Create a node pool.
+To deploy a Kafka cluster in KRaft mode with a single node pool that uses dual-role nodes:
+kubectl apply -f examples/kafka/nodepools/kafka-with-dual-role-kraft-nodes.yamlTo deploy a Kafka cluster in KRaft mode with separate node pools for broker and controller nodes:
+kubectl apply -f examples/kafka/nodepools/kafka-with-kraft.yamlTo deploy a Kafka cluster and ZooKeeper cluster with two node pools of three brokers:
+kubectl apply -f examples/kafka/nodepools/kafka.yamlCheck the status of the deployment:
+kubectl get pods -n <my_cluster_operator_namespace>NAME READY STATUS RESTARTS
+my-cluster-entity-operator 3/3 Running 0
+my-cluster-pool-a-kafka-0 1/1 Running 0
+my-cluster-pool-a-kafka-1 1/1 Running 0
+my-cluster-pool-a-kafka-4 1/1 Running 0my-cluster is the name of the Kafka cluster.
pool-a is the name of the node pool.
A sequential index number starting with 0 identifies each Kafka pod created.
+If you are using ZooKeeper, you’ll also see the ZooKeeper pods.
READY shows the number of replicas that are ready/expected.
+The deployment is successful when the STATUS displays as Running.
Information on the deployment is also shown in the status of the KafkaNodePool resource, including a list of IDs for nodes in the pool.
|
+ Note
+ |
++Node IDs are assigned sequentially starting at 0 (zero) across all node pools within a cluster. This means that node IDs might not run sequentially within a specific node pool. If there are gaps in the sequence of node IDs across the cluster, the next node to be added is assigned an ID that fills the gap. When scaling down, the node with the highest node ID within a pool is removed. + | +
This procedure describes how to deploy the Topic Operator using the Cluster Operator.
READY shows the number of replicas that are ready/expected.
-The deployment is successful when the STATUS shows as Running.
STATUS displays as Running.
This procedure describes how to deploy the User Operator using the Cluster Operator.
READY shows the number of replicas that are ready/expected.
-The deployment is successful when the STATUS shows as Running.
STATUS displays as Running.
The following resources are created by the Cluster Operator in the Kubernetes cluster:
READY shows the number of replicas that are ready/expected.
-The deployment is successful when the STATUS shows as Running.
STATUS displays as Running.
READY shows the number of replicas that are ready/expected.
-The deployment is successful when the STATUS shows as Running.
STATUS displays as Running.
@@ -3978,7 +4191,7 @@ READY shows the number of replicas that are ready/expected.
-The deployment is successful when the STATUS shows as Running.
STATUS displays as Running.
@@ -4773,6 +4986,9 @@ (Preview) Specifying node pools
+Securing client access to Kafka brokers
Kafka custom resource configuration for a deployment of Kafka. Includes example configuration for an ephemeral or persistent single or multi-node deployment.
Kafka custom resource with a deployment configuration for Cruise Control. Includes KafkaRebalance custom resources to generate optimizations proposals from Cruise Control, with example configurations to use the default or user optimization goals.
(Preview) KafkaNodePool configuration for Kafka nodes in a Kafka cluster. Includes example configuration for nodes in clusters that use KRaft (Kafka Raft metadata) mode or ZooKeeper.
Kafka custom resource with a deployment configuration for Cruise Control. Includes KafkaRebalance custom resources to generate optimization proposals from Cruise Control, with example configurations to use the default or user optimization goals.
KafkaConnect and KafkaConnector custom resource configuration for a deployment of Kafka Connect. Includes example configuration for a single or multi-node deployment.
KafkaConnect and KafkaConnector custom resource configuration for a deployment of Kafka Connect. Includes example configurations for a single or multi-node deployment.
KafkaBridge custom resource configuration for a deployment of Kafka Bridge.
Specified User Operator loggers and log levels.
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.
+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.
+Optional configuration for Cruise Control, which is used to rebalance the Kafka cluster.
+Use the Kafka Static Quota plugin to set throughput and storage limits on brokers in your Kafka cluster.
+You enable the plugin and set limits by configuring the Kafka resource.
+You can set a byte-rate threshold and storage quotas to put limits on the clients interacting with your brokers.
You can set byte-rate thresholds for producer and consumer bandwidth. +The total limit is distributed across all clients accessing the broker. +For example, you can set a byte-rate threshold of 40 MBps for producers. +If two producers are running, they are each limited to a throughput of 20 MBps.
+Storage quotas throttle Kafka disk storage limits between a soft limit and hard limit. +The limits apply to all available disk space. +Producers are slowed gradually between the soft and hard limit. +The limits prevent disks filling up too quickly and exceeding their capacity. +Full disks can lead to issues that are hard to rectify. +The hard limit is the maximum storage limit.
+|
+ Note
+ |
++For JBOD storage, the limit applies across all disks. +If a broker is using two 1 TB disks and the quota is 1.1 TB, one disk might fill and the other disk will be almost empty. + | +
The Cluster Operator that manages the Kafka cluster is running.
+Add the plugin properties to the config of the Kafka resource.
The plugin properties are shown in this example configuration.
+apiVersion: kafka.strimzi.io/v1beta2
+kind: Kafka
+metadata:
+ name: my-cluster
+spec:
+ kafka:
+ # ...
+ config:
+ client.quota.callback.class: io.strimzi.kafka.quotas.StaticQuotaCallback (1)
+ client.quota.callback.static.produce: 1000000 (2)
+ client.quota.callback.static.fetch: 1000000 (3)
+ client.quota.callback.static.storage.soft: 400000000000 (4)
+ client.quota.callback.static.storage.hard: 500000000000 (5)
+ client.quota.callback.static.storage.check-interval: 5 (6)Loads the Kafka Static Quota plugin.
+Sets the producer byte-rate threshold. 1 MBps in this example.
+Sets the consumer byte-rate threshold. 1 MBps in this example.
+Sets the lower soft limit for storage. 400 GB in this example.
+Sets the higher hard limit for storage. 500 GB in this example.
+Sets the interval in seconds between checks on storage. 5 seconds in this example. You can set this to 0 to disable the check.
+Update the resource.
+kubectl apply -f <kafka_configuration_file>When deploying ZooKeeper with Strimzi, some of the default configuration set by Strimzi differs from the standard ZooKeeper defaults. +This is because Strimzi sets a number of ZooKeeper properties with values that are optimized for running ZooKeeper within a Kubernetes environment.
+The default configuration for key ZooKeeper properties in Strimzi is as follows:
+| Property | +Default value | +Description | +
|---|---|---|
|
+
+ 2000 + |
+The length of a single tick in milliseconds, which determines the length of a session timeout. |
+
|
+
+ 5 + |
+The maximum number of ticks that a follower is allowed to fall behind the leader in a ZooKeeper cluster. |
+
|
+
+ 2 + |
+The maximum number of ticks that a follower is allowed to be out of sync with the leader in a ZooKeeper cluster. |
+
|
+
+ 1 + |
+Enables the |
+
|
+
+ false + |
+Flag to disable the ZooKeeper admin server. The admin server is not used by Strimzi. |
+
|
+ Important
+ |
+
+Modifying these default values as zookeeper.config in the Kafka custom resource may impact the behavior and performance of your ZooKeeper cluster.
+ |
+
Update the spec properties of the KafkaNodePool custom resource to configure a node pool deployment.
|
+ Note
+ |
+
+The node pools feature is available as a preview. Node pools are not enabled by default, so you must enable the KafkaNodePools feature gate before using them.
+ |
+
A node pool refers to a distinct group of Kafka nodes within a Kafka cluster. +Each pool has its own unique configuration, which includes mandatory settings for the number of replicas, roles, and storage allocation.
+Optionally, you can also specify values for the following properties:
+resources to specify memory and cpu requests and limits
template to specify custom configuration for pods and other Kubernetes resources
jvmOptions to specify custom JVM configuration for heap size, runtime and other options
The Kafka resource represents the configuration for all nodes in the Kafka cluster.
+The KafkaNodePool resource represents the configuration for nodes only in the node pool.
+If a configuration property is not specified in KafkaNodePool, it is inherited from the Kafka resource.
+Configuration specified in the KafkaNodePool resource takes precedence if set in both resources.
+For example, if both the node pool and Kafka configuration includes jvmOptions, the values specified in the node pool configuration are used.
+When -Xmx: 1024m is set in KafkaNodePool.spec.jvmOptions and -Xms: 512m is set in Kafka.spec.kafka.jvmOptions, the node uses the value from its node pool configuration.
Properties from Kafka and KafkaNodePool schemas are not combined.
+To clarify, if KafkaNodePool.spec.template includes only podSet.metadata.labels, and Kafka.spec.kafka.template includes podSet.metadata.annotations and pod.metadata.labels, the template values from the Kafka configuration are ignored since there is a template value in the node pool configuration.
Node pools can be used with Kafka clusters that operate in KRaft mode (using Kafka Raft metadata) or use ZooKeeper for cluster management. +If you are using KRaft mode, you can specify roles for all nodes in the node pool to operate as brokers, controllers, or both. +If you are using ZooKeeper, nodes must be set as brokers only.
+|
+ Important
+ |
++KRaft mode is not ready for production in Apache Kafka or in Strimzi. + | +
For a deeper understanding of the node pool configuration options, refer to the Strimzi Custom Resource API Reference.
+|
+ Note
+ |
+
+While the KafkaNodePools feature gate that enables node pools is in alpha phase, replica and storage configuration properties in the KafkaNodePool resource must also be present in the Kafka resource. The configuration in the Kafka resource is ignored when node pools are used. Similarly, ZooKeeper configuration properties must also be present in the Kafka resource when using KRaft mode. These properties are also ignored.
+ |
+
apiVersion: kafka.strimzi.io/v1beta2
+kind: KafkaNodePool
+metadata:
+ name: pool-a
+ labels:
+ strimzi.io/cluster: my-cluster
+spec:
+ replicas: 3
+ roles:
+ - broker # (1)
+ storage:
+ type: jbod
+ volumes:
+ - id: 0
+ type: persistent-claim
+ size: 100Gi
+ deleteClaim: false
+ resources:
+ requests:
+ memory: 64Gi
+ cpu: "8"
+ limits:
+ memory: 64Gi
+ cpu: "12"Roles for the nodes in the node pool, which can only be broker when using Kafka with ZooKeeper.
apiVersion: kafka.strimzi.io/v1beta2
+kind: KafkaNodePool
+metadata:
+ name: kraft-dual-role # (1)
+ labels:
+ strimzi.io/cluster: my-cluster # (2)
+spec:
+ replicas: 3 # (3)
+ roles: # (4)
+ - controller
+ - broker
+ storage: # (5)
+ type: jbod
+ volumes:
+ - id: 0
+ type: persistent-claim
+ size: 20Gi
+ deleteClaim: false
+ resources: # (6)
+ requests:
+ memory: 64Gi
+ cpu: "8"
+ limits:
+ memory: 64Gi
+ cpu: "12"Unique name for the node pool.
+The Kafka cluster the node pool belongs to. A node pool can only belong to a single cluster.
+Number of replicas for the nodes.
+Roles for the nodes in the node pool. In this example, the nodes have dual roles as controllers and brokers.
+Storage specification for the nodes.
+Requests for reservation of supported resources, currently cpu and memory, and limits to specify the maximum resources that can be consumed.
|
+ Note
+ |
+
+The configuration for the Kafka resource must be suitable for KRaft mode. Currently, KRaft mode has a number of limitations.
+ |
+
This procedure describes how to move nodes between source and target Kafka node pools without downtime. +You create a new node on the target node pool and reassign partitions to move data from the old node on the source node pool. +When the replicas on the new node are in-sync, you can delete the old node.
+The steps assume that you are using ZooKeeper for cluster management. +The operation is not possible for clusters using KRaft mode.
+In this procedure, we start with two node pools:
+pool-a with three replicas is the target node pool
pool-b with four replicas is the source node pool
We scale up pool-a, and reassign partitions and scale down pool-b, which results in the following:
pool-a with four replicas
pool-b with three replicas
|
+ Note
+ |
++During this process, the ID of the node that holds the partition replicas changes. Consider any dependencies that reference the node ID. + | +
Create a new node in the target node pool.
+For example, node pool pool-a has three replicas. We add a node by increasing the number of replicas:
kubectl scale kafkanodepool pool-a --replicas=4Check the status of the deployment and wait for the pods in the node pool to be created and have a status of READY.
kubectl get pods -n <my_cluster_operator_namespace>NAME READY STATUS RESTARTS
+my-cluster-pool-a-kafka-0 1/1 Running 0
+my-cluster-pool-a-kafka-1 1/1 Running 0
+my-cluster-pool-a-kafka-4 1/1 Running 0
+my-cluster-pool-a-kafka-5 1/1 Running 0|
+ Note
+ |
++The node IDs appended to each name start at 0 (zero) and run sequentially across the Kafka cluster. This means that they might not run sequentially within a node pool. + | +
Reassign the partitions from the old node to the new node using the kafka-reassign-partitions.sh tool.
For more information, see Reassigning partitions before removing brokers.
+Optional configuration for Cruise Control, which is used to rebalance the Kafka cluster.
+After the reassignment process is complete, reduce the number of Kafka nodes in the source node pool.
+For example, node pool pool-b has four replicas. We remove a node by decreasing the number of replicas:
kubectl scale kafkanodepool pool-b --replicas=3The node with the highest ID within a pool is removed.
+NAME READY STATUS RESTARTS
+my-cluster-pool-b-kafka-2 1/1 Running 0
+my-cluster-pool-b-kafka-3 1/1 Running 0
+my-cluster-pool-b-kafka-6 1/1 Running 0Use the Kafka Static Quota plugin to set throughput and storage limits on brokers in your Kafka cluster.
-You enable the plugin and set limits by configuring the Kafka resource.
-You can set a byte-rate threshold and storage quotas to put limits on the clients interacting with your brokers.
This procedure describes how to migrate existing Kafka clusters to use Kafka node pools. +After you have updated the Kafka cluster, you can use the node pools to manage the configuration of nodes within each pool.
You can set byte-rate thresholds for producer and consumer bandwidth. -The total limit is distributed across all clients accessing the broker. -For example, you can set a byte-rate threshold of 40 MBps for producers. -If two producers are running, they are each limited to a throughput of 20 MBps.
-Storage quotas throttle Kafka disk storage limits between a soft limit and hard limit. -The limits apply to all available disk space. -Producers are slowed gradually between the soft and hard limit. -The limits prevent disks filling up too quickly and exceeding their capacity. -Full disks can lead to issues that are hard to rectify. -The hard limit is the maximum storage limit.
+The steps assume that you are using ZooKeeper for cluster management. +The operation is not possible for clusters using KRaft mode.
-For JBOD storage, the limit applies across all disks.
-If a broker is using two 1 TB disks and the quota is 1.1 TB, one disk might fill and the other disk will be almost empty.
+While the KafkaNodePools feature gate that enables node pools is in alpha phase, replica and storage configuration in the KafkaNodePool resource must also be present in the Kafka resource. The configuration is ignored when node pools are being used.
|
The Cluster Operator that manages the Kafka cluster is running.
+Add the plugin properties to the config of the Kafka resource.
The plugin properties are shown in this example configuration.
-Create a new KafkaNodePool resource.
apiVersion: kafka.strimzi.io/v1beta2
-kind: Kafka
-metadata:
- name: my-cluster
-spec:
- kafka:
- # ...
- config:
- client.quota.callback.class: io.strimzi.kafka.quotas.StaticQuotaCallback (1)
- client.quota.callback.static.produce: 1000000 (2)
- client.quota.callback.static.fetch: 1000000 (3)
- client.quota.callback.static.storage.soft: 400000000000 (4)
- client.quota.callback.static.storage.hard: 500000000000 (5)
- client.quota.callback.static.storage.check-interval: 5 (6)Loads the Kafka Static Quota plugin.
-Sets the producer byte-rate threshold. 1 MBps in this example.
-Sets the consumer byte-rate threshold. 1 MBps in this example.
+Name the resource kafka.
Sets the lower soft limit for storage. 400 GB in this example.
+Point a strimzi.io/cluster label to your existing Kafka resource.
Sets the higher hard limit for storage. 500 GB in this example.
+Set the replica count and storage configuration to match your current Kafka cluster.
Sets the interval in seconds between checks on storage. 5 seconds in this example. You can set this to 0 to disable the check.
+Set the roles to broker.
apiVersion: kafka.strimzi.io/v1beta2
+kind: KafkaNodePool
+metadata:
+ name: kafka
+ labels:
+ strimzi.io/cluster: my-cluster
+spec:
+ replicas: 3
+ roles:
+ - broker
+ storage:
+ type: jbod
+ volumes:
+ - id: 0
+ type: persistent-claim
+ size: 100Gi
+ deleteClaim: falseUpdate the resource.
+Apply the KafkaNodePool resource:
kubectl apply -f <kafka_configuration_file>kubectl apply -f <node_pool_configuration_file>By applying this resource, you switch Kafka to using node pools.
There is no change or rolling update and resources are identical to how they were before.
+KafkaUserQuotas schema reference
Update the STRIMZI_FEATURE_GATES environment variable in the Cluster Operator configuration to include +KafkaNodePools.
env:
+ - name: STRIMZI_FEATURE_GATES
+ value: +KafkaNodePoolsEnable the KafkaNodePools feature gate in the Kafka resource using the strimzi.io/node-pools: enabled annotation.
apiVersion: kafka.strimzi.io/v1beta2
+kind: Kafka
+metadata:
+ name: my-cluster
+ annotations:
+ strimzi.io/node-pools: enabled
+spec:
+ kafka:
+ version: 3.5.0
+ replicas: 3
+ # ...
+ storage:
+ type: jbod
+ volumes:
+ - id: 0
+ type: persistent-claim
+ size: 100Gi
+ deleteClaim: falseWhen deploying ZooKeeper with Strimzi, some of the default configuration set by Strimzi differs from the standard ZooKeeper defaults. -This is because Strimzi sets a number of ZooKeeper properties with values that are optimized for running ZooKeeper within a Kubernetes environment.
+ +Apply the Kafka resource:
kubectl apply -f <kafka_configuration_file>The default configuration for key ZooKeeper properties in Strimzi is as follows:
| Property | -Default value | -Description | -
|---|---|---|
|
-
- 2000 - |
-The length of a single tick in milliseconds, which determines the length of a session timeout. |
-
|
-
- 5 - |
-The maximum number of ticks that a follower is allowed to fall behind the leader in a ZooKeeper cluster. |
-
|
-
- 2 - |
-The maximum number of ticks that a follower is allowed to be out of sync with the leader in a ZooKeeper cluster. |
-
|
-
- 1 - |
-Enables the |
-
|
-
- false - |
-Flag to disable the ZooKeeper admin server. The admin server is not used by Strimzi. |
-
|
- Important
- |
-
-Modifying these default values as zookeeper.config in the Kafka custom resource may impact the behavior and performance of your ZooKeeper cluster.
- |
-
Use the entityOperator property in Kafka.spec to configure the Entity Operator.
The Entity Operator is responsible for managing Kafka-related entities in a running Kafka cluster. It comprises the following operators:
Use topicOperator properties in Kafka.spec.entityOperator to configure the Topic Operator.
The following properties are supported:
Use userOperator properties in Kafka.spec.entityOperator to configure the User Operator.
The following properties are supported:
Update the spec properties of the KafkaConnect custom resource to configure your Kafka Connect deployment.
This procedure describes how to authorize user access to Kafka Connect.
Update the spec properties of the KafkaMirrorMaker2 custom resource to configure your MirrorMaker 2 deployment.
MirrorMaker 2 uses source cluster configuration for data consumption and target cluster configuration for data output.
You can use MirrorMaker 2 in active/passive or active/active cluster configurations.
Use Mirrormaker 2 connector configuration for the internal connectors that orchestrate the synchronization of data between Kafka clusters.
MirrorMaker 2 connectors use internal producers and consumers. If needed, you can configure these producers and consumers to override the default settings.
@@ -7177,7 +7851,7 @@Connectors create the tasks that are responsible for moving data in and out of Kafka. Each connector comprises one or more tasks that are distributed across a group of worker pods that run the tasks. @@ -7282,7 +7956,7 @@
When using MirrorMaker 2 with Strimzi, it is possible to synchronize ACL rules for remote topics. However, this feature is only available if you are not using the User Operator.
@@ -7305,7 +7979,7 @@This procedure describes in outline the configuration required to secure a MirrorMaker 2 deployment.
Update the spec properties of the KafkaMirrorMaker custom resource to configure your Kafka MirrorMaker deployment.
Update the spec properties of the KafkaBridge custom resource to configure your Kafka Bridge deployment.
As stateful applications, Kafka and ZooKeeper store data on disk. Strimzi supports three storage types for this data:
@@ -8170,7 +8844,7 @@For Strimzi to work well, an efficient data storage infrastructure is essential. We strongly recommend using block storage. @@ -8240,7 +8914,7 @@
Ephemeral data storage is transient. All pods on a node share a local ephemeral storage space. @@ -8307,7 +8981,7 @@
Persistent data storage retains data in the event of system disruption. For pods that use persistent data storage, data is persisted across pod failures and restarts.
@@ -8575,7 +9249,7 @@Persistent volumes used by a cluster can be resized without any risk of data loss, as long as the storage infrastructure supports it. Following a configuration update to change the size of the storage, Strimzi instructs the storage infrastructure to make the change. @@ -8698,7 +9372,7 @@
You can configure Strimzi to use JBOD, a data storage configuration of multiple disks or volumes. JBOD is one approach to providing increased data storage for Kafka brokers. @@ -8776,7 +9450,7 @@
This procedure describes how to add volumes to a Kafka cluster configured to use JBOD storage. It cannot be applied to Kafka clusters configured to use any other storage type.
@@ -8872,7 +9546,7 @@This procedure describes how to remove volumes from Kafka cluster configured to use JBOD storage. It cannot be applied to Kafka clusters configured to use any other storage type. @@ -8962,7 +9636,7 @@
By default, the Strimzi Cluster Operator does not specify CPU and memory resource requests and limits for its deployed operands. Ensuring an adequate allocation of resources is crucial for maintaining stability and achieving optimal performance in Kafka. @@ -8973,7 +9647,7 @@
A Strimzi deployment creates Kubernetes resources, such as Deployment, Pod, and Service resources.
These resources are managed by Strimzi operators.
@@ -9017,6 +9691,9 @@
Strimzi allows you to customize the image pull policy for containers in all pods deployed by the Cluster Operator.
The image pull policy is configured using the environment variable STRIMZI_IMAGE_PULL_POLICY in the Cluster Operator deployment.
@@ -9102,7 +9779,7 @@
Apply a termination grace period to give a Kafka cluster enough time to shut down cleanly.
To avoid performance degradation caused by resource conflicts between applications scheduled on the same Kubernetes node, you can schedule Kafka pods separately from critical workloads. This can be achieved by either selecting specific nodes or dedicating a set of nodes exclusively for Kafka.
Use affinity, tolerations and topology spread constraints to schedule the pods of kafka resources onto nodes.
Affinity, tolerations and topology spread constraints are configured using the affinity, tolerations, and topologySpreadConstraint properties in following resources:
Many Kafka brokers or ZooKeeper nodes can run on the same Kubernetes worker node. If the worker node fails, they will all become unavailable at the same time. @@ -9373,7 +10050,7 @@
Pod anti-affinity configuration helps with the stability and performance of Kafka brokers. By using podAntiAffinity, Kubernetes will not schedule Kafka brokers on the same nodes as other workloads.
Typically, you want to avoid Kafka running on the same worker node as other network or storage intensive applications such as databases, storage or other messaging platforms.
Configure logging levels in the custom resources of Kafka components and Strimzi Operators.
You can specify the logging levels directly in the spec.logging property of the custom resource.
@@ -9655,7 +10332,7 @@
name or key is not set.
For more information on configuring logging for specific Kafka components or operators, see the following sections.
To use a ConfigMap to define logging properties, you create the ConfigMap and then reference it as part of the logging definition in the spec of a resource.
If you are using a ConfigMap to configure the (log4j2) logging levels for Strimzi Operators, you can also define logging filters to limit what’s returned in the log.
@@ -10005,7 +10682,7 @@Add specific configuration to your Strimzi deployment using ConfigMap resources.
ConfigMaps use key-value pairs to store non-confidential data.
@@ -10084,7 +10761,7 @@
Strimzi creates its own ConfigMaps and other resources when it is deployed to Kubernetes. The ConfigMaps contain data necessary for running components. @@ -10116,7 +10793,7 @@
Use configuration providers to load configuration data from external sources. The providers operate independently of Strimzi. @@ -10127,7 +10804,7 @@
You can enable one or more configuration providers using the config.providers properties in the spec configuration of a component.
Use the KubernetesSecretConfigProvider to provide configuration properties from a secret or the KubernetesConfigMapConfigProvider to provide configuration properties from a config map.
Use the EnvVarConfigProvider to provide configuration properties as environment variables.
Environment variables can contain values from config maps or secrets.
Use the FileConfigProvider to provide configuration properties from a file within a directory.
Files can be config maps or secrets.
Use the DirectoryConfigProvider to provide configuration properties from multiple files within a directory.
Files can be config maps or secrets.
The UseKRaft feature gate deploys the Kafka cluster in the KRaft (Kafka Raft metadata) mode without ZooKeeper.
-This feature gate is currently intended only for development and testing.
This feature gate is currently intended only for development and testing.
| -The KRaft mode is not ready for production in Apache Kafka or in Strimzi. +KRaft mode is not ready for production in Apache Kafka or in Strimzi. |
When the UseKRaft feature gate is enabled, the Kafka cluster is deployed without ZooKeeper.
-The .spec.zookeeper properties in the Kafka custom resource will be ignored, but still need to be present.
+The .spec.zookeeper properties in the Kafka custom resource are ignored, but still need to be present.
The UseKRaft feature gate provides an API that configures Kafka cluster nodes and their roles.
The API is still in development and is expected to change before the KRaft mode is production-ready.
If you are trying Kafka in KRaft mode, you can also enable the KafkaNodePools feature gate to manage Kafka node configurations in node pools.
Currently, the KRaft mode in Strimzi has the following major limitations:
The KafkaNodePools feature gate introduces a new KafkaNodePool custom resource that enables the configuration of different pools of Apache Kafka nodes.
-A node pool refers to a distinct group of Kafka nodes within a Kafka cluster.
+
The KafkaNodePools feature gate introduces a new KafkaNodePool custom resource that enables the configuration of different pools of Apache Kafka nodes.
A node pool refers to a distinct group of Kafka nodes within a Kafka cluster.
Each pool has its own unique configuration, which includes mandatory settings such as the number of replicas, storage configuration, and a list of assigned roles.
You can assign the controller role, broker role, or both roles to all nodes in the pool in the .spec.roles field.
-When used with ZooKeeper-based Apache Kafka cluster, it must be always set to the broker role only.
-When used with the UseKRaft feature gate, it can be set to broker, controller, or both.
-In addition, a node pool can have its own configuration of resource requests and limits, Java JVM options, and resource templates.
+When used with a ZooKeeper-based Apache Kafka cluster, it must be set to the broker role.
+When used with the UseKRaft feature gate, it can be set to broker, controller, or both.
In addition, a node pool can have its own configuration of resource requests and limits, Java JVM options, and resource templates.
Configuration options not set in the KafkaNodePool resource are inherited from the Kafka custom resource.
To migrate existing Kafka clusters to use KafkaNodePools, follow these steps:
Create a new KafkaNodePool resource:
Name the resource kafka and label it with strimzi.io/cluster, pointing to your existing Kafka resource.
Set the replica count and storage configuration in the KafkaNodePool resource to match your current Kafka cluster.
Set the roles to broker in the KafkaNodePool resource.
Enable the KafkaNodePools feature gate:
Update the STRIMZI_FEATURE_GATES environment variable in the Cluster Operator configuration to include +KafkaNodePools.
Add the strimzi.io/node-pools: enabled annotation to your existing Kafka custom resource.
Revised on 2023-06-22 15:42:41 UTC
+Revised on 2023-06-22 19:18:16 UTC
If you are trying the preview of the node pools feature, you can deploy a Kafka cluster with one or more node pools. +Node pools provide configuration for a set of Kafka nodes. +By using node pools, nodes can have different configuration within the same Kafka cluster.
+Node pools are not enabled by default, so you must enable the KafkaNodePools feature gate before using them.
If you haven’t deployed a Kafka cluster as a Kafka resource, you can’t use the Cluster Operator to manage it.
This applies, for example, to a Kafka cluster running outside of Kubernetes.
However, you can use the Topic Operator and User Operator with a Kafka cluster that is not managed by Strimzi, by deploying them as standalone components.
@@ -2507,7 +2522,7 @@
READY shows the number of replicas that are ready/expected.
-The deployment is successful when the STATUS shows as Running.
STATUS displays as Running.
This procedure shows how to deploy Kafka node pools to your Kubernetes cluster using the Cluster Operator.
+Node pools represent a distinct group of Kafka nodes within a Kafka cluster that share the same configuration.
+For each Kafka node in the node pool, any configuration not defined in node pool is inherited from the cluster configuration in the kafka resource.
|
+ Note
+ |
+
+The node pools feature is available as a preview. Node pools are not enabled by default, so you must enable the KafkaNodePools feature gate before using them.
+ |
+
The deployment uses a YAML file to provide the specification to create a KafkaNodePool resource.
+You can use node pools with Kafka clusters that use KRaft (Kafka Raft metadata) mode or ZooKeeper for cluster management.
|
+ Important
+ |
++KRaft mode is not ready for production in Apache Kafka or in Strimzi. + | +
Strimzi provides the following example files that you can use to create a Kafka node pool:
+kafka-with-dual-role-kraft-nodes.yamlDeploys a Kafka cluster with one pool of KRaft nodes that share the broker and controller roles.
+kafka-with-kraft.yamlDeploys a Kafka cluster with one pool of controller nodes and one pool of broker nodes.
+kafka.yamlDeploys ZooKeeper with 3 nodes, and 2 different pools of Kafka brokers. Each of the pools has 3 brokers. The pools in the example use different storage configuration.
+|
+ Note
+ |
+
+You don’t need to start using node pools right away. If you decide to use them, you can perform the steps outlined here to deploy a new Kafka cluster with KafkaNodePool resources or migrate your existing Kafka cluster.
+ |
+
You have created and deployed a Kafka cluster.
+|
+ Note
+ |
++If you want to migrate an existing Kafka cluster to use node pools, see the steps to migrate existing Kafka clusters. + | +
Enable the KafkaNodePools feature gate.
If using KRaft mode, enable the UseKRaft feature gate too.
kubectl set env install/cluster-operator STRIMZI_FEATURE_GATES=""
+env:
+ - name: STRIMZI_FEATURE_GATES
+ value: +KafkaNodePools, +UseKRaftThis updates the Cluster Operator.
+Create a node pool.
+To deploy a Kafka cluster in KRaft mode with a single node pool that uses dual-role nodes:
+kubectl apply -f examples/kafka/nodepools/kafka-with-dual-role-kraft-nodes.yamlTo deploy a Kafka cluster in KRaft mode with separate node pools for broker and controller nodes:
+kubectl apply -f examples/kafka/nodepools/kafka-with-kraft.yamlTo deploy a Kafka cluster and ZooKeeper cluster with two node pools of three brokers:
+kubectl apply -f examples/kafka/nodepools/kafka.yamlCheck the status of the deployment:
+kubectl get pods -n <my_cluster_operator_namespace>NAME READY STATUS RESTARTS
+my-cluster-entity-operator 3/3 Running 0
+my-cluster-pool-a-kafka-0 1/1 Running 0
+my-cluster-pool-a-kafka-1 1/1 Running 0
+my-cluster-pool-a-kafka-4 1/1 Running 0my-cluster is the name of the Kafka cluster.
pool-a is the name of the node pool.
A sequential index number starting with 0 identifies each Kafka pod created.
+If you are using ZooKeeper, you’ll also see the ZooKeeper pods.
READY shows the number of replicas that are ready/expected.
+The deployment is successful when the STATUS displays as Running.
Information on the deployment is also shown in the status of the KafkaNodePool resource, including a list of IDs for nodes in the pool.
|
+ Note
+ |
++Node IDs are assigned sequentially starting at 0 (zero) across all node pools within a cluster. This means that node IDs might not run sequentially within a specific node pool. If there are gaps in the sequence of node IDs across the cluster, the next node to be added is assigned an ID that fills the gap. When scaling down, the node with the highest node ID within a pool is removed. + | +
This procedure describes how to deploy the Topic Operator using the Cluster Operator.
READY shows the number of replicas that are ready/expected.
-The deployment is successful when the STATUS shows as Running.
STATUS displays as Running.
This procedure describes how to deploy the User Operator using the Cluster Operator.
READY shows the number of replicas that are ready/expected.
-The deployment is successful when the STATUS shows as Running.
STATUS displays as Running.
The following resources are created by the Cluster Operator in the Kubernetes cluster:
READY shows the number of replicas that are ready/expected.
-The deployment is successful when the STATUS shows as Running.
STATUS displays as Running.
READY shows the number of replicas that are ready/expected.
-The deployment is successful when the STATUS shows as Running.
STATUS displays as Running.
READY shows the number of replicas that are ready/expected.
-The deployment is successful when the STATUS shows as Running.
STATUS displays as Running.
(Preview) Specifying node pools
+Securing client access to Kafka brokers
Kafka custom resource configuration for a deployment of Kafka. Includes example configuration for an ephemeral or persistent single or multi-node deployment.
Kafka custom resource with a deployment configuration for Cruise Control. Includes KafkaRebalance custom resources to generate optimizations proposals from Cruise Control, with example configurations to use the default or user optimization goals.
(Preview) KafkaNodePool configuration for Kafka nodes in a Kafka cluster. Includes example configuration for nodes in clusters that use KRaft (Kafka Raft metadata) mode or ZooKeeper.
Kafka custom resource with a deployment configuration for Cruise Control. Includes KafkaRebalance custom resources to generate optimization proposals from Cruise Control, with example configurations to use the default or user optimization goals.
KafkaConnect and KafkaConnector custom resource configuration for a deployment of Kafka Connect. Includes example configuration for a single or multi-node deployment.
KafkaConnect and KafkaConnector custom resource configuration for a deployment of Kafka Connect. Includes example configurations for a single or multi-node deployment.
KafkaBridge custom resource configuration for a deployment of Kafka Bridge.
Update the spec properties of the KafkaNodePool custom resource to configure a node pool deployment.
|
+ Note
+ |
+
+The node pools feature is available as a preview. Node pools are not enabled by default, so you must enable the KafkaNodePools feature gate before using them.
+ |
+
A node pool refers to a distinct group of Kafka nodes within a Kafka cluster. +Each pool has its own unique configuration, which includes mandatory settings for the number of replicas, roles, and storage allocation.
+Optionally, you can also specify values for the following properties:
+resources to specify memory and cpu requests and limits
template to specify custom configuration for pods and other Kubernetes resources
jvmOptions to specify custom JVM configuration for heap size, runtime and other options
The Kafka resource represents the configuration for all nodes in the Kafka cluster.
+The KafkaNodePool resource represents the configuration for nodes only in the node pool.
+If a configuration property is not specified in KafkaNodePool, it is inherited from the Kafka resource.
+Configuration specified in the KafkaNodePool resource takes precedence if set in both resources.
+For example, if both the node pool and Kafka configuration includes jvmOptions, the values specified in the node pool configuration are used.
+When -Xmx: 1024m is set in KafkaNodePool.spec.jvmOptions and -Xms: 512m is set in Kafka.spec.kafka.jvmOptions, the node uses the value from its node pool configuration.
Properties from Kafka and KafkaNodePool schemas are not combined.
+To clarify, if KafkaNodePool.spec.template includes only podSet.metadata.labels, and Kafka.spec.kafka.template includes podSet.metadata.annotations and pod.metadata.labels, the template values from the Kafka configuration are ignored since there is a template value in the node pool configuration.
Node pools can be used with Kafka clusters that operate in KRaft mode (using Kafka Raft metadata) or use ZooKeeper for cluster management. +If you are using KRaft mode, you can specify roles for all nodes in the node pool to operate as brokers, controllers, or both. +If you are using ZooKeeper, nodes must be set as brokers only.
+|
+ Important
+ |
++KRaft mode is not ready for production in Apache Kafka or in Strimzi. + | +
For a deeper understanding of the node pool configuration options, refer to the Strimzi Custom Resource API Reference.
+|
+ Note
+ |
+
+While the KafkaNodePools feature gate that enables node pools is in alpha phase, replica and storage configuration properties in the KafkaNodePool resource must also be present in the Kafka resource. The configuration in the Kafka resource is ignored when node pools are used. Similarly, ZooKeeper configuration properties must also be present in the Kafka resource when using KRaft mode. These properties are also ignored.
+ |
+
apiVersion: kafka.strimzi.io/v1beta2
+kind: KafkaNodePool
+metadata:
+ name: pool-a
+ labels:
+ strimzi.io/cluster: my-cluster
+spec:
+ replicas: 3
+ roles:
+ - broker # (1)
+ storage:
+ type: jbod
+ volumes:
+ - id: 0
+ type: persistent-claim
+ size: 100Gi
+ deleteClaim: false
+ resources:
+ requests:
+ memory: 64Gi
+ cpu: "8"
+ limits:
+ memory: 64Gi
+ cpu: "12"Roles for the nodes in the node pool, which can only be broker when using Kafka with ZooKeeper.
apiVersion: kafka.strimzi.io/v1beta2
+kind: KafkaNodePool
+metadata:
+ name: kraft-dual-role # (1)
+ labels:
+ strimzi.io/cluster: my-cluster # (2)
+spec:
+ replicas: 3 # (3)
+ roles: # (4)
+ - controller
+ - broker
+ storage: # (5)
+ type: jbod
+ volumes:
+ - id: 0
+ type: persistent-claim
+ size: 20Gi
+ deleteClaim: false
+ resources: # (6)
+ requests:
+ memory: 64Gi
+ cpu: "8"
+ limits:
+ memory: 64Gi
+ cpu: "12"Unique name for the node pool.
+The Kafka cluster the node pool belongs to. A node pool can only belong to a single cluster.
+Number of replicas for the nodes.
+Roles for the nodes in the node pool. In this example, the nodes have dual roles as controllers and brokers.
+Storage specification for the nodes.
+Requests for reservation of supported resources, currently cpu and memory, and limits to specify the maximum resources that can be consumed.
|
+ Note
+ |
+
+The configuration for the Kafka resource must be suitable for KRaft mode. Currently, KRaft mode has a number of limitations.
+ |
+
This procedure describes how to move nodes between source and target Kafka node pools without downtime. +You create a new node on the target node pool and reassign partitions to move data from the old node on the source node pool. +When the replicas on the new node are in-sync, you can delete the old node.
+The steps assume that you are using ZooKeeper for cluster management. +The operation is not possible for clusters using KRaft mode.
+In this procedure, we start with two node pools:
+pool-a with three replicas is the target node pool
pool-b with four replicas is the source node pool
We scale up pool-a, and reassign partitions and scale down pool-b, which results in the following:
pool-a with four replicas
pool-b with three replicas
|
+ Note
+ |
++During this process, the ID of the node that holds the partition replicas changes. Consider any dependencies that reference the node ID. + | +
Create a new node in the target node pool.
+For example, node pool pool-a has three replicas. We add a node by increasing the number of replicas:
kubectl scale kafkanodepool pool-a --replicas=4Check the status of the deployment and wait for the pods in the node pool to be created and have a status of READY.
kubectl get pods -n <my_cluster_operator_namespace>NAME READY STATUS RESTARTS
+my-cluster-pool-a-kafka-0 1/1 Running 0
+my-cluster-pool-a-kafka-1 1/1 Running 0
+my-cluster-pool-a-kafka-4 1/1 Running 0
+my-cluster-pool-a-kafka-5 1/1 Running 0|
+ Note
+ |
++The node IDs appended to each name start at 0 (zero) and run sequentially across the Kafka cluster. This means that they might not run sequentially within a node pool. + | +
Reassign the partitions from the old node to the new node using the kafka-reassign-partitions.sh tool.
For more information, see Reassigning partitions before removing brokers.
+After the reassignment process is complete, reduce the number of Kafka nodes in the source node pool.
+For example, node pool pool-b has four replicas. We remove a node by decreasing the number of replicas:
kubectl scale kafkanodepool pool-b --replicas=3The node with the highest ID within a pool is removed.
+NAME READY STATUS RESTARTS
+my-cluster-pool-b-kafka-2 1/1 Running 0
+my-cluster-pool-b-kafka-3 1/1 Running 0
+my-cluster-pool-b-kafka-6 1/1 Running 0This procedure describes how to migrate existing Kafka clusters to use Kafka node pools. +After you have updated the Kafka cluster, you can use the node pools to manage the configuration of nodes within each pool.
+The steps assume that you are using ZooKeeper for cluster management. +The operation is not possible for clusters using KRaft mode.
+|
+ Note
+ |
+
+While the KafkaNodePools feature gate that enables node pools is in alpha phase, replica and storage configuration in the KafkaNodePool resource must also be present in the Kafka resource. The configuration is ignored when node pools are being used.
+ |
+
Create a new KafkaNodePool resource.
Name the resource kafka.
Point a strimzi.io/cluster label to your existing Kafka resource.
Set the replica count and storage configuration to match your current Kafka cluster.
+Set the roles to broker.
apiVersion: kafka.strimzi.io/v1beta2
+kind: KafkaNodePool
+metadata:
+ name: kafka
+ labels:
+ strimzi.io/cluster: my-cluster
+spec:
+ replicas: 3
+ roles:
+ - broker
+ storage:
+ type: jbod
+ volumes:
+ - id: 0
+ type: persistent-claim
+ size: 100Gi
+ deleteClaim: falseApply the KafkaNodePool resource:
kubectl apply -f <node_pool_configuration_file>By applying this resource, you switch Kafka to using node pools.
+There is no change or rolling update and resources are identical to how they were before.
+Update the STRIMZI_FEATURE_GATES environment variable in the Cluster Operator configuration to include +KafkaNodePools.
env:
+ - name: STRIMZI_FEATURE_GATES
+ value: +KafkaNodePoolsEnable the KafkaNodePools feature gate in the Kafka resource using the strimzi.io/node-pools: enabled annotation.
apiVersion: kafka.strimzi.io/v1beta2
+kind: Kafka
+metadata:
+ name: my-cluster
+ annotations:
+ strimzi.io/node-pools: enabled
+spec:
+ kafka:
+ version: 3.5.0
+ replicas: 3
+ # ...
+ storage:
+ type: jbod
+ volumes:
+ - id: 0
+ type: persistent-claim
+ size: 100Gi
+ deleteClaim: falseApply the Kafka resource:
kubectl apply -f <kafka_configuration_file>Use the entityOperator property in Kafka.spec to configure the Entity Operator.
The Entity Operator is responsible for managing Kafka-related entities in a running Kafka cluster. It comprises the following operators:
Use topicOperator properties in Kafka.spec.entityOperator to configure the Topic Operator.
The following properties are supported:
Use userOperator properties in Kafka.spec.entityOperator to configure the User Operator.
The following properties are supported:
Update the spec properties of the KafkaConnect custom resource to configure your Kafka Connect deployment.
This procedure describes how to authorize user access to Kafka Connect.
Update the spec properties of the KafkaMirrorMaker2 custom resource to configure your MirrorMaker 2 deployment.
MirrorMaker 2 uses source cluster configuration for data consumption and target cluster configuration for data output.
You can use MirrorMaker 2 in active/passive or active/active cluster configurations.
Use Mirrormaker 2 connector configuration for the internal connectors that orchestrate the synchronization of data between Kafka clusters.
MirrorMaker 2 connectors use internal producers and consumers. If needed, you can configure these producers and consumers to override the default settings.
@@ -7618,7 +8292,7 @@Connectors create the tasks that are responsible for moving data in and out of Kafka. Each connector comprises one or more tasks that are distributed across a group of worker pods that run the tasks. @@ -7723,7 +8397,7 @@
When using MirrorMaker 2 with Strimzi, it is possible to synchronize ACL rules for remote topics. However, this feature is only available if you are not using the User Operator.
@@ -7746,7 +8420,7 @@This procedure describes in outline the configuration required to secure a MirrorMaker 2 deployment.
Update the spec properties of the KafkaMirrorMaker custom resource to configure your Kafka MirrorMaker deployment.
Update the spec properties of the KafkaBridge custom resource to configure your Kafka Bridge deployment.
As stateful applications, Kafka and ZooKeeper store data on disk. Strimzi supports three storage types for this data:
@@ -8611,7 +9285,7 @@For Strimzi to work well, an efficient data storage infrastructure is essential. We strongly recommend using block storage. @@ -8681,7 +9355,7 @@
Ephemeral data storage is transient. All pods on a node share a local ephemeral storage space. @@ -8748,7 +9422,7 @@
Persistent data storage retains data in the event of system disruption. For pods that use persistent data storage, data is persisted across pod failures and restarts.
@@ -9016,7 +9690,7 @@Persistent volumes used by a cluster can be resized without any risk of data loss, as long as the storage infrastructure supports it. Following a configuration update to change the size of the storage, Strimzi instructs the storage infrastructure to make the change. @@ -9139,7 +9813,7 @@
You can configure Strimzi to use JBOD, a data storage configuration of multiple disks or volumes. JBOD is one approach to providing increased data storage for Kafka brokers. @@ -9217,7 +9891,7 @@
This procedure describes how to add volumes to a Kafka cluster configured to use JBOD storage. It cannot be applied to Kafka clusters configured to use any other storage type.
@@ -9313,7 +9987,7 @@This procedure describes how to remove volumes from Kafka cluster configured to use JBOD storage. It cannot be applied to Kafka clusters configured to use any other storage type. @@ -9403,7 +10077,7 @@
By default, the Strimzi Cluster Operator does not specify CPU and memory resource requests and limits for its deployed operands. Ensuring an adequate allocation of resources is crucial for maintaining stability and achieving optimal performance in Kafka. @@ -9414,7 +10088,7 @@
A Strimzi deployment creates Kubernetes resources, such as Deployment, Pod, and Service resources.
These resources are managed by Strimzi operators.
@@ -9458,6 +10132,9 @@
Strimzi allows you to customize the image pull policy for containers in all pods deployed by the Cluster Operator.
The image pull policy is configured using the environment variable STRIMZI_IMAGE_PULL_POLICY in the Cluster Operator deployment.
@@ -9543,7 +10220,7 @@
Apply a termination grace period to give a Kafka cluster enough time to shut down cleanly.
To avoid performance degradation caused by resource conflicts between applications scheduled on the same Kubernetes node, you can schedule Kafka pods separately from critical workloads. This can be achieved by either selecting specific nodes or dedicating a set of nodes exclusively for Kafka.
Use affinity, tolerations and topology spread constraints to schedule the pods of kafka resources onto nodes.
Affinity, tolerations and topology spread constraints are configured using the affinity, tolerations, and topologySpreadConstraint properties in following resources:
Many Kafka brokers or ZooKeeper nodes can run on the same Kubernetes worker node. If the worker node fails, they will all become unavailable at the same time. @@ -9814,7 +10491,7 @@
Pod anti-affinity configuration helps with the stability and performance of Kafka brokers. By using podAntiAffinity, Kubernetes will not schedule Kafka brokers on the same nodes as other workloads.
Typically, you want to avoid Kafka running on the same worker node as other network or storage intensive applications such as databases, storage or other messaging platforms.
Configure logging levels in the custom resources of Kafka components and Strimzi Operators.
You can specify the logging levels directly in the spec.logging property of the custom resource.
@@ -10096,7 +10773,7 @@
name or key is not set.
For more information on configuring logging for specific Kafka components or operators, see the following sections.
To use a ConfigMap to define logging properties, you create the ConfigMap and then reference it as part of the logging definition in the spec of a resource.
If you are using a ConfigMap to configure the (log4j2) logging levels for Strimzi Operators, you can also define logging filters to limit what’s returned in the log.
@@ -10446,7 +11123,7 @@Add specific configuration to your Strimzi deployment using ConfigMap resources.
ConfigMaps use key-value pairs to store non-confidential data.
@@ -10525,7 +11202,7 @@
Strimzi creates its own ConfigMaps and other resources when it is deployed to Kubernetes. The ConfigMaps contain data necessary for running components. @@ -10557,7 +11234,7 @@
Use configuration providers to load configuration data from external sources. The providers operate independently of Strimzi. @@ -10568,7 +11245,7 @@
You can enable one or more configuration providers using the config.providers properties in the spec configuration of a component.
Use the KubernetesSecretConfigProvider to provide configuration properties from a secret or the KubernetesConfigMapConfigProvider to provide configuration properties from a config map.
Use the EnvVarConfigProvider to provide configuration properties as environment variables.
Environment variables can contain values from config maps or secrets.
Use the FileConfigProvider to provide configuration properties from a file within a directory.
Files can be config maps or secrets.
Use the DirectoryConfigProvider to provide configuration properties from multiple files within a directory.
Files can be config maps or secrets.
The UseKRaft feature gate deploys the Kafka cluster in the KRaft (Kafka Raft metadata) mode without ZooKeeper.
-This feature gate is currently intended only for development and testing.
This feature gate is currently intended only for development and testing.
| -The KRaft mode is not ready for production in Apache Kafka or in Strimzi. +KRaft mode is not ready for production in Apache Kafka or in Strimzi. |
When the UseKRaft feature gate is enabled, the Kafka cluster is deployed without ZooKeeper.
-The .spec.zookeeper properties in the Kafka custom resource will be ignored, but still need to be present.
+The .spec.zookeeper properties in the Kafka custom resource are ignored, but still need to be present.
The UseKRaft feature gate provides an API that configures Kafka cluster nodes and their roles.
The API is still in development and is expected to change before the KRaft mode is production-ready.
If you are trying Kafka in KRaft mode, you can also enable the KafkaNodePools feature gate to manage Kafka node configurations in node pools.
Currently, the KRaft mode in Strimzi has the following major limitations:
The KafkaNodePools feature gate introduces a new KafkaNodePool custom resource that enables the configuration of different pools of Apache Kafka nodes.
-A node pool refers to a distinct group of Kafka nodes within a Kafka cluster.
+
The KafkaNodePools feature gate introduces a new KafkaNodePool custom resource that enables the configuration of different pools of Apache Kafka nodes.
A node pool refers to a distinct group of Kafka nodes within a Kafka cluster.
Each pool has its own unique configuration, which includes mandatory settings such as the number of replicas, storage configuration, and a list of assigned roles.
You can assign the controller role, broker role, or both roles to all nodes in the pool in the .spec.roles field.
-When used with ZooKeeper-based Apache Kafka cluster, it must be always set to the broker role only.
-When used with the UseKRaft feature gate, it can be set to broker, controller, or both.
-In addition, a node pool can have its own configuration of resource requests and limits, Java JVM options, and resource templates.
+When used with a ZooKeeper-based Apache Kafka cluster, it must be set to the broker role.
+When used with the UseKRaft feature gate, it can be set to broker, controller, or both.
In addition, a node pool can have its own configuration of resource requests and limits, Java JVM options, and resource templates.
Configuration options not set in the KafkaNodePool resource are inherited from the Kafka custom resource.
To migrate existing Kafka clusters to use KafkaNodePools, follow these steps:
Create a new KafkaNodePool resource:
Name the resource kafka and label it with strimzi.io/cluster, pointing to your existing Kafka resource.
Set the replica count and storage configuration in the KafkaNodePool resource to match your current Kafka cluster.
Set the roles to broker in the KafkaNodePool resource.
Enable the KafkaNodePools feature gate:
Update the STRIMZI_FEATURE_GATES environment variable in the Cluster Operator configuration to include +KafkaNodePools.
Add the strimzi.io/node-pools: enabled annotation to your existing Kafka custom resource.
For more information, see Feature gates.
+For more information, see Feature gates.
A node pool refers to a distinct group of Kafka nodes within a Kafka cluster. +By using node pools, nodes can have different configuration within the same Kafka cluster. +Configuration options not specified in the node pool are inherited from the Kafka configuration.
+The node pools feature is available as a preview that can be enabled using the KafkaNodePool feature gate.
+You can deploy a Kafka cluster with one or more node pools.
+The node pool configuration includes mandatory and optional settings.
+Configuration for replicas, roles, and storage is mandatory.
If you are using KRaft mode (which is also available as a preview), you can specify roles for all nodes in the node pool to operate as brokers, controllers, or both. +Controller and dual roles are specific to KRaft. +If you are using Kafka clusters that use ZooKeeper for cluster management, you can use node pools that are configured with broker roles only.
+apiVersion: kafka.strimzi.io/v1beta2
+kind: KafkaNodePool
+metadata:
+ name: pool-a
+ labels:
+ strimzi.io/cluster: my-cluster
+spec:
+ replicas: 3
+ roles:
+ - broker
+ storage:
+ type: jbod
+ volumes:
+ - id: 0
+ type: persistent-claim
+ size: 100Gi
+ deleteClaim: false|
+ Important
+ |
++KRaft mode is not ready for production in Apache Kafka or in Strimzi. + | +
Kafka MirrorMaker 2 replicates data between two or more active Kafka clusters, within or across data centers. To set up MirrorMaker 2, a source and target (destination) Kafka cluster must be running.
@@ -1857,7 +1911,7 @@Kafka MirrorMaker (also referred to as MirrorMaker 1) uses producers and consumers to replicate data across clusters as follows:
Use Strimzi’s KafkaConnect resource to quickly and easily create new Kafka Connect clusters.
A Kafka Bridge configuration requires a bootstrap server specification for the Kafka cluster it connects to, as well as any encryption and authentication options required.
For more information, see Feature gates.
+For more information, see Feature gates.
A node pool refers to a distinct group of Kafka nodes within a Kafka cluster. +By using node pools, nodes can have different configuration within the same Kafka cluster. +Configuration options not specified in the node pool are inherited from the Kafka configuration.
+The node pools feature is available as a preview that can be enabled using the KafkaNodePool feature gate.
+You can deploy a Kafka cluster with one or more node pools.
+The node pool configuration includes mandatory and optional settings.
+Configuration for replicas, roles, and storage is mandatory.
If you are using KRaft mode (which is also available as a preview), you can specify roles for all nodes in the node pool to operate as brokers, controllers, or both. +Controller and dual roles are specific to KRaft. +If you are using Kafka clusters that use ZooKeeper for cluster management, you can use node pools that are configured with broker roles only.
+apiVersion: kafka.strimzi.io/v1beta2
+kind: KafkaNodePool
+metadata:
+ name: pool-a
+ labels:
+ strimzi.io/cluster: my-cluster
+spec:
+ replicas: 3
+ roles:
+ - broker
+ storage:
+ type: jbod
+ volumes:
+ - id: 0
+ type: persistent-claim
+ size: 100Gi
+ deleteClaim: false|
+ Important
+ |
++KRaft mode is not ready for production in Apache Kafka or in Strimzi. + | +
Kafka MirrorMaker 2 replicates data between two or more active Kafka clusters, within or across data centers. To set up MirrorMaker 2, a source and target (destination) Kafka cluster must be running.
@@ -1416,7 +1470,7 @@Kafka MirrorMaker (also referred to as MirrorMaker 1) uses producers and consumers to replicate data across clusters as follows:
Use Strimzi’s KafkaConnect resource to quickly and easily create new Kafka Connect clusters.
A Kafka Bridge configuration requires a bootstrap server specification for the Kafka cluster it connects to, as well as any encryption and authentication options required.