[Part 12 of #758] Preset: scheduling.podAffinity.preferScheduleNextToRealUsers
#930
Conversation
This file contains 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
We are now using a trick to restart the hub whenever the hash of the hub's configmap changes. This commit modernizes old logic from when that trick wasn't in use and reduces the need for an inline explanation of the code.
```yaml hub.jupyter.org/storage-kind: user # or core, for the hub-db-dir ``` Extra storage labels are also configurable through config.yaml and `singleuser.storageExtraLabels`.
<core|user> pods now get `tolerations` for the node taint `hub.jupyter.org/dedicated=<user|core>:NoSchedule` that could optionally be added to nodes or all nodes in a node group (aka. node pool). Note that due to a bug with using the `gcloud` CLI, we also add the toleration for the same taint where `/` is replaced with `_`. In this commit, `singleuser.extraTolerations` are now also made configurable allowing you to add your own custom tolerations to the user pods.
These affinities allow for more fine grained control of where a pod will schedule.
Read about them in schema.yaml
When a user pod is about to schedule, should it favor scheduling on a node with real users on it? A real user is a user pod as compared to a user-placeholder pod. Enabling this will pack real users together with each other even in situations where a few situations where the scheduler may fail to discern two nodes from a resource request perspective. Note that this is a minor tweak, and is not recommended for very large clusters as it can reduce the schedulers performance.
20 tasks
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.
Warning
This PR needs rebase before merge. The new content of this PR is actually only the following commit.
scheduling.podAffinity.preferScheduleNextToRealUsersClosing remarks
Decided to be too detailed and of too little use.
About
When a user pod is about to schedule, should it favor scheduling on a
node with real users on it? A real user is a user pod as compared to a
user-placeholder pod.
Enabling this will pack real users together with each other even in
situations where a few situations where the scheduler may fail to
discern two nodes from a resource request perspective.
Note that this is a minor tweak, and is not recommended for very large
clusters as it can reduce the schedulers performance.