Disable CC resource goals when resource capacities are not set.

[kyguy]

Type of change

• Enhancement / new feature

Description

This PR adds logic to the Strimzi Cluster Operator to remove resource related Cruise Control goals from the default.goals and hard.goals lists by default if the capacity configurations for those resources are not explicitly set in the .spec.kafka.resources or .spec.cruiseControl.brokerCapacity sections of the Kafka custom resource. The following Cruise Control goals are affected:

com.linkedin.kafka.cruisecontrol.analyzer.goals.CpuCapacityGoal
com.linkedin.kafka.cruisecontrol.analyzer.goals.CpuUsageDistributionGoal
com.linkedin.kafka.cruisecontrol.analyzer.goals.NetworkInboundCapacityGoal
com.linkedin.kafka.cruisecontrol.analyzer.goals.NetworkOutboundCapacityGoal
com.linkedin.kafka.cruisecontrol.analyzer.goals.NetworkInboundUsageDistributionGoal
com.linkedin.kafka.cruisecontrol.analyzer.goals.NetworkOutboundUsageDistributionGoal
com.linkedin.kafka.cruisecontrol.analyzer.goals.PotentialNwOutGoal

This will prevent users from balancing partitions based on compute resources without defining capacities for those compute resources in their Kafka custom resource.

Addresses the issue raised here: #11409

Checklist

Please go through this checklist and make sure all applicable tasks have been done

• Write tests
• Make sure all tests pass
• Update documentation
• Check RBAC rights for Kubernetes / OpenShift roles
• Try your changes from Pod inside your Kubernetes and OpenShift cluster, not just locally
• Reference relevant issue(s) and close them after merging
• Update CHANGELOG.md
• Supply screenshots for visual changes, such as Grafana dashboards

[scholzj]

As I suggested in one of the comments. Resources are not configured in the Kafka CR anymore. It would be also good to understand what is the plan when some nodes have resources defined and some not. What will you do then?

[scholzj]

Why are these classes needed (maybe they are, but I'm not really sure)? And why are they needed here in this module (I'm actually pretty sure they are not)?

[kyguy]

You are right, I have refactored the enums into the ResourceRequirementsUtils class and moved it into the cluster-operator module where it is used in the most recent commit. Please have a look when you get a chance and let me know if it needs more work.

[scholzj]

We do not use it in the places where we work with Kubernetes resources. So this Javadoc is wrong. If it is needed, You should properly explain why and where because this is completely insufficient.

[kyguy]

You are right, this is not accurate. I have refactored this class a bit in the latest commit in attempt to make it's purpose more clear. Please have a look and let me know if the changes make sense or if it needs more work.

[scholzj]

We do not use it in the places where we work with Kubernetes resources. So this Javadoc is wrong. If it is needed, You should properly explain why and where because this is completely insufficient.

[kyguy]

You are right, this is not accurate. I have refactored this class a bit in the latest commit in attempt to make it's purpose more clear. Please have a look and let me know if the changes make sense or if it needs more work.

[scholzj]

Why is this important? The CPiu capacity is configured even if request and limit are not the same.

[kyguy]

This ensures that each broker's CPU capacity has been explicitly defined as a guaranteed resource - neither more or less CPU resources - enabling more accurate rebalancing decisions based on CPU availability.

The CPU capacity is configured even if request and limit are not the same.

Yes, we still set the CPU capacity to the configured requests or limits even if they are not the same in case the user sets the CPU-dependent Cruise Control goals themselves. Although the rebalances won't be as accurate as if the requests == limits, it'll for sure be better than the default CPU capacity value.

Added a comment above the conditional, let me know if it is suitable!

[kyguy]

It would be also good to understand what is the plan when some nodes have resources defined and some not. What will you do then?

Thanks for the catch (and review), we only want to consider the CPU capacity for a cluster to be considered to be properly configured for CPU-dependent Cruise Control goals if there is a capacity value explicitly configured for every broker whether through the general capacity or broker specific overrides, or the resource requirements. So if none of these are defined for a broker, including the resource requirement, we want to disable the CPU-dependent Cruise Control goals.

I had wrongly assumed that all the node pools had their resources defined in the kafkaBrokerResources map, I have updated the logic to disable the CPU-dependent Cruise Control goals if there is a broker in the kafkaBrokerNodes set that doesn't have it's node pool (and resource requirements) defined in the kafkaBrokerResources map.