Repository navigation
fix(cli): turn Connect's rack off on clusters without zones - #589
Merged
Merged
Conversation
Strimzi turns rack.topologyKey into a required node affinity, so on nodes with no topology.kubernetes.io/zone label the workers stay Pending forever and the deploy fails its Connect wait. Introspection already knows: with no zones, deploy now sets rack.enabled=false.
This was referenced Nov 3, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
On a cluster whose nodes have no
topology.kubernetes.io/zonelabel,kates deployinstalls Kafka Connect workers that can never be scheduled. The chart defaults torack.enabled=true, and Strimzi turnsrack.topologyKeyinto a required node affinity. On a single-node k3d the 3 workers stayed Pending for 43 hours, andkates deploy statusshowedDegraded: kafkaconnects.kafka.strimzi.io CRD missing Ready condition. Kafka itself was fine, because the values generator already falls back tokubernetes.io/hostnamethere.What
kafkaConnectHelmArgssetsrack.enabled=falsewhen introspection found no zones. Clusters with zones keep rack on. A re-run heals an existing install, sincekafkaConnectNeedsReconcilealready upgrades a Connect that isn't Ready.Behaviour to review
An admin-less deploy reads no nodes, so
report.Zonesis always empty and it now turns rack off too, even on a zoned cluster. That is deliberate: rack on an unknown cluster can hang forever, while rack off only gives up cross-zone fetch savings.Deliberately not done
The chart default is unchanged, so a plain
helm installon a zoneless cluster still hits this. Changing it would turn rack off for everyone who relies on the default.Tests
TestKafkaConnectHelmArgsRack, confirmed failing without the fix.helm upgrade --reuse-values --set rack.enabled=false): the dry-run diff was only the rack block and its init container, then KafkaConnect wentReady=Truewith 3/3 workers. The rebuilt CLI has not been run against the cluster.go vet,go test ./...,golangci-lint --new-from-rev=origin/main,govulncheck,check-cli-style.sh,check-cli-compat.sh, and./mvnw verifywith Docker up.