Repository navigation
fix(cli): size brokers by the three brokers deploy emits - #583
Merged
Merged
Conversation
The capacity budget split the broker CPU, memory and storage share by BrokerReplicas × zones, which is 1 with no zones or one zone and 2 with two. buildBrokerPools emits three brokers in every case, so each broker was sized as if it were the only one. On a single 18-CPU k3d node that asked for three 8-CPU brokers; the controllers never scheduled and the brokers crash-looped waiting for a quorum, failing deploy's Kafka readiness wait. Divide by the three brokers instead, and test the share against the replicas the pools actually run.
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
Deploying on one Kubernetes node (k3d, 18 CPU) failed with
kafka readiness failed: timeout waiting for pods (selector=strimzi.io/cluster=krafter). Each of the 3 brokers asked for 8 CPU / 16Gi, the node reached 98% CPU requested, the 3 controllers stayedPending("Insufficient cpu"), and the brokers that did start crash-looped waiting for the controller quorum.The cause is in
computeCapacityBudget: it split the broker share byBrokerReplicas × max(len(zones), 1), which is 1 with zero or one zone and 2 with two.buildBrokerPoolsemits 3 brokers in every case, so each broker got the whole share (clamped at 8000m / 16Gi). Broker storage was split the same way.What changes
totalBrokersisBrokerReplicas × 3, matching the pools emitted. On the 18-CPU node that's about 2.9 CPU per broker.TestGenerateValues_BrokerSizingMatchesThePoolsEmittedchecks the split against the replicas the pools actually run for 0–3 zones, and that a single 18-CPU node fits brokers plus controllers. It fails on main for 0, 1 and 2 zones.Not done
krafterrelease there has to be uninstalled first.Checks run locally
go test ./pkg/detect/... ./cmd/...,golangci-lint run --new-from-rev=origin/main ./pkg/detect/...,scripts/check-cli-style.sh,scripts/check-cli-compat.sh.