Add Topology Spread Constraints support #410
Conversation
|
Related: #340 |
| func CustomizeTopologySpreadConstraints(pts *corev1.PodTemplateSpec, zoneDomainMatchLabels map[string]string) { | ||
| pts.Spec.TopologySpreadConstraints = make([]corev1.TopologySpreadConstraint, 0) | ||
| if len(zoneDomainMatchLabels) > 0 { | ||
| pts.Spec.TopologySpreadConstraints = append(pts.Spec.TopologySpreadConstraints, corev1.TopologySpreadConstraint{ |
There was a problem hiding this comment.
Should we add a similar constraint using topology key kubernetes.io/hostname? It'll find the most ideal node I believe as per this statement in the k8s doc:
"When a Pod defines more than one topologySpreadConstraint, those constraints are combined using a logical AND operation: the kube-scheduler looks for a node for the incoming Pod that satisfies all the configured constraints."
There was a problem hiding this comment.
Yes, I think it's okay to add here. It's been documented to not always work the way we expect (because the scheduler adds one pod at a time). But in such cases, we are covered by the ScheduleAnyway flag and our pod anti-affinity rules.
| @@ -1215,6 +1232,25 @@ func GetWatchNamespaces() ([]string, error) { | |||
| return watchNamespaces, nil | |||
| } | |||
|
|
|||
| // MergeTopologySpreadConstraints returns the union of all TopologySpreadConstraint lists. The order of lists passed into the | |||
| // func, defines the importance. | |||
| func MergeTopologySpreadConstraints(constraints ...[]corev1.TopologySpreadConstraint) []corev1.TopologySpreadConstraint { | |||
There was a problem hiding this comment.
Customers could set default constraints for the entire cluster. But those defaults would be overridden by our default constraints. It'll be good to consider providing an option/way, so they can disable our defaults without having to override each constraint (using the relevant topology key)
There was a problem hiding this comment.
Added flag .spec.topologySpreadConstraints.disableOperatorDefaults. It defaults to false, so operator default TopologySpreadConstraints will be applied if the flag isn't specified. However, this also means upgrading the operator will cause brief downtime for the pod to apply our default constraints.
api/v1/runtimecomponent_types.go
Outdated
| @@ -146,6 +146,21 @@ type RuntimeComponentSpec struct { | |||
| // Security context for the application container. | |||
| // +operator-sdk:csv:customresourcedefinitions:order=25,type=spec,displayName="Security Context" | |||
| SecurityContext *corev1.SecurityContext `json:"securityContext,omitempty"` | |||
|
|
|||
| // Topology spread constraints for the application pod. | |||
There was a problem hiding this comment.
This line can be removed, so the comment above RuntimeComponentTopologySpreadConstraints type's struct can be used
There was a problem hiding this comment.
Sounds good, I removed line 150.
What this PR does / why we need it?:
Does this PR introduce a user-facing change?
CHANGELOG.mdWhich issue(s) this PR fixes:
Fixes #