-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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.
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
Add affinity-rules feature to configmap config-deployment #15250
Changes from 18 commits
ee19514
3b9f7aa
dd0d599
0d0bdc7
4d73f10
92f0ab5
a633eba
7d0f070
cc096da
bad694c
e56c559
9ef849b
8daaa67
a2610e4
905443c
def1a18
da265ce
1e5f200
3470332
376cd87
1f4fde2
7dec43d
6c9252f
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -39,6 +39,7 @@ import ( | |
"k8s.io/apimachinery/pkg/util/intstr" | ||
|
||
apiconfig "knative.dev/serving/pkg/apis/config" | ||
deploymentconfig "knative.dev/serving/pkg/deployment" | ||
) | ||
|
||
const certVolumeName = "server-certs" | ||
|
@@ -150,6 +151,22 @@ func rewriteUserLivenessProbe(p *corev1.Probe, userPort int) { | |
} | ||
} | ||
|
||
func makePreferSpreadRevisionOverNodes(revisionLabelValue string) *corev1.PodAntiAffinity { | ||
return &corev1.PodAntiAffinity{ | ||
PreferredDuringSchedulingIgnoredDuringExecution: []corev1.WeightedPodAffinityTerm{{ | ||
Weight: 100, | ||
PodAffinityTerm: corev1.PodAffinityTerm{ | ||
TopologyKey: corev1.LabelHostname, | ||
LabelSelector: &metav1.LabelSelector{ | ||
MatchLabels: map[string]string{ | ||
serving.RevisionLabelKey: revisionLabelValue, | ||
}, | ||
}, | ||
}, | ||
}}, | ||
} | ||
} | ||
|
||
func makePodSpec(rev *v1.Revision, cfg *config.Config) (*corev1.PodSpec, error) { | ||
queueContainer, err := makeQueueContainer(rev, cfg) | ||
tokenVolume := varTokenVolume.DeepCopy() | ||
|
@@ -210,6 +227,10 @@ func makePodSpec(rev *v1.Revision, cfg *config.Config) (*corev1.PodSpec, error) | |
} | ||
} | ||
|
||
if cfg.Deployment.Affinity == deploymentconfig.PreferSpreadRevisionOverNodes && cfg.Features.PodSpecAffinity == apiconfig.Disabled { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The way I view the I still think if that feature is enabled and the user hasn't set the affinity then we should still use the default set by the operator. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hmm, ok. I misunderstood then. I'll take a look at the code again and adjust it accordingly There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hm. IMHO, isn't the current config variation seems a bit unintuitive:
Could we rename the flag to "defaultAffinity" and apply it, regardless of the feature config is enabled/disabled (so that is clear that we apply this by default if not specified otherwise). The user could then still enable the feature flag and override it on a service basis. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Changing it to
Thats my intent and what I'm asking for. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Renamed the config to defaultAffinityType |
||
podSpec.Affinity = &corev1.Affinity{PodAntiAffinity: makePreferSpreadRevisionOverNodes(rev.Name)} | ||
} | ||
|
||
return podSpec, nil | ||
} | ||
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That is fine as a starting point as this is probably most folks would use. I am wondering about our defaulting strategy though, as we don't allow the user to set up as default config whatever is needed each time. For example I can imagine folks asking "required-spread-revision-over-nodes" (assuming they dont want more than one pods on the same node) or adjust the topology key (
topology.kubernetes.io/zone
).There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can add more types in the future and even a
custom
option that allows the operator to specify a template maybeI don't understand what do you mean?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The comment is about defaulting but not with all options available upfront. Anyway we can add later for sure.