Add ConcurrentBrokerRestartCountPerRack to RollingUpgradeConfig (#1002)

* Add ConcurrentBrokerRestartCountPerRack to RollingUpgradeConfig
banzaicloud · Jul 27, 2023 · a384f4b · a384f4b
1 parent 8839af4
commit a384f4b
Show file tree

Hide file tree

Showing 3 changed files with 46 additions and 0 deletions.
diff --git a/api/v1beta1/kafkacluster_types.go b/api/v1beta1/kafkacluster_types.go
@@ -143,6 +143,18 @@ type RollingUpgradeConfig struct {
 	// distinct broker replicas with either offline replicas or out of sync replicas and the number of alerts triggered by
 	// alerts with 'rollingupgrade'
 	FailureThreshold int `json:"failureThreshold"`
+
+	// ConcurrentBrokerRestartCountPerRack controls how many brokers can be restarted in parallel during a rolling upgrade. If
+	// it is set to a value greater than 1, the operator will restart up to that amount of brokers in parallel, if the
+	// brokers are within the same rack (as specified by "broker.rack" in broker read-only configs). Since using Kafka broker
+	// racks spreads out the replicas, we know that restarting multiple brokers in the same rack will not cause more than
+	// 1/Nth of the replicas of a topic-partition to be unavailable at the same time, where N is the number of racks used.
+	// This is a safe way to speed up the rolling upgrade. Note that for the rack distribution explained above, Cruise Control
+	// requires `com.linkedin.kafka.cruisecontrol.analyzer.goals.RackAwareDistributionGoal` to be configured. Default value is 1.
+	// +kubebuilder:validation:Minimum=1
+	// +kubebuilder:default=1
+	// +optional
+	ConcurrentBrokerRestartCountPerRack int `json:"concurrentBrokerRestartCountPerRack,omitempty"`
 }
 
 // DisruptionBudget defines the configuration for PodDisruptionBudget where the workload is managed by the kafka-operator

diff --git a/charts/kafka-operator/templates/crds.yaml b/charts/kafka-operator/templates/crds.yaml
@@ -21689,6 +21689,23 @@ spec:
                 description: RollingUpgradeConfig defines the desired config of the
                   RollingUpgrade
                 properties:
+                  concurrentBrokerRestartCountPerRack:
+                    default: 1
+                    description: ConcurrentBrokerRestartCountPerRack controls how
+                      many brokers can be restarted in parallel during a rolling upgrade.
+                      If it is set to a value greater than 1, the operator will restart
+                      up to that amount of brokers in parallel, if the brokers are
+                      within the same rack (as specified by "broker.rack" in broker
+                      read-only configs). Since using Kafka broker racks spreads out
+                      the replicas, we know that restarting multiple brokers in the
+                      same rack will not cause more than 1/Nth of the replicas of
+                      a topic-partition to be unavailable at the same time, where
+                      N is the number of racks used. This is a safe way to speed up
+                      the rolling upgrade. Note that for the rack distribution explained
+                      above, Cruise Control requires `com.linkedin.kafka.cruisecontrol.analyzer.goals.RackAwareDistributionGoal`
+                      to be configured. Default value is 1.
+                    minimum: 1
+                    type: integer
                   failureThreshold:
                     description: FailureThreshold controls how many failures the cluster
                       can tolerate during a rolling upgrade. Once the number of failures

diff --git a/config/base/crds/kafka.banzaicloud.io_kafkaclusters.yaml b/config/base/crds/kafka.banzaicloud.io_kafkaclusters.yaml
@@ -21526,6 +21526,23 @@ spec:
                 description: RollingUpgradeConfig defines the desired config of the
                   RollingUpgrade
                 properties:
+                  concurrentBrokerRestartCountPerRack:
+                    default: 1
+                    description: ConcurrentBrokerRestartCountPerRack controls how
+                      many brokers can be restarted in parallel during a rolling upgrade.
+                      If it is set to a value greater than 1, the operator will restart
+                      up to that amount of brokers in parallel, if the brokers are
+                      within the same rack (as specified by "broker.rack" in broker
+                      read-only configs). Since using Kafka broker racks spreads out
+                      the replicas, we know that restarting multiple brokers in the
+                      same rack will not cause more than 1/Nth of the replicas of
+                      a topic-partition to be unavailable at the same time, where
+                      N is the number of racks used. This is a safe way to speed up
+                      the rolling upgrade. Note that for the rack distribution explained
+                      above, Cruise Control requires `com.linkedin.kafka.cruisecontrol.analyzer.goals.RackAwareDistributionGoal`
+                      to be configured. Default value is 1.
+                    minimum: 1
+                    type: integer
                   failureThreshold:
                     description: FailureThreshold controls how many failures the cluster
                       can tolerate during a rolling upgrade. Once the number of failures