Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add ConcurrentBrokerRestartCountPerRack to RollingUpgradeConfig #1002

Merged
merged 2 commits into from
Jul 27, 2023
Merged

Add ConcurrentBrokerRestartCountPerRack to RollingUpgradeConfig #1002

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
777a971
Add ConcurrentBrokerRestartCountPerRack to RollingUpgradeConfig
ctrlaltluc Jun 22, 2023
f01c008
empty commit to retrigger tests
ctrlaltluc Jul 27, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 12 additions & 0 deletions api/v1beta1/kafkacluster_types.go
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down
17 changes: 17 additions & 0 deletions charts/kafka-operator/templates/crds.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down
17 changes: 17 additions & 0 deletions config/base/crds/kafka.banzaicloud.io_kafkaclusters.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down
Loading