-
Notifications
You must be signed in to change notification settings - Fork 14.4k
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
Updated the podAffinity concept documentation #48083
base: main
Are you sure you want to change the base?
Conversation
Welcome @aryasoni98! |
✅ Pull request preview available for checkingBuilt without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify site configuration. |
cc @dom4ha |
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.
it looks good overall from a technical perspective, but maybe tech writers can help determine whether the same idea can be communicated more concisely?
Thank you for your valuable feedback! I agree that clarity and conciseness are essential for effective documentation. I'll collaborate with our technical writers to streamline the content while ensuring all critical information is accurately conveyed. If you have any specific suggestions or areas you'd like us to focus on, please let me know! |
/hold We prefer not to put issue references in commit messages or PR titles (it causes trouble if / when people fork the repository). OK to unhold when that's fixed. |
@sftim Thank you for the feedback! I understand that including issue references in commit messages and PR titles can cause complications, especially with repository forks. I will update the commit messages and PR titles to omit these references accordingly. |
podAffinity
concept documentation
podAffinity
concept documentation- mismatchLabelKeys: | ||
- tenant # whatever the value of the "tenant" label for this Pod, prevent | ||
# scheduling to nodes in any pool where any Pod from a different | ||
# tenant is running. | ||
labelSelector: | ||
# We have to have the labelSelector which selects only Pods with the tenant label, | ||
# otherwise this Pod would hate Pods from daemonsets as well, for example, | ||
# otherwise this Pod would anti-affine Pods from daemonsets as well, for example, |
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.
Oh, that was not a good word for the concept, but affine is not a word, so, maybe this:
# otherwise this Pod would anti-affine Pods from daemonsets as well, for example, | |
# otherwise this Pod would have anti-affinity against Pods from daemonsets as well, for example, |
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.
Thank you for catching that! You're absolutely right—using "affine" in that context isn't appropriate. I'll update the comment to:
otherwise this Pod would have anti-affinity against Pods from daemonsets as well, for example,
This change makes the comment clearer and more accurate. I appreciate your suggestion!
content/en/docs/concepts/scheduling-eviction/assign-pod-node.md
Outdated
Show resolved
Hide resolved
content/en/docs/concepts/scheduling-eviction/assign-pod-node.md
Outdated
Show resolved
Hide resolved
content/en/docs/concepts/scheduling-eviction/assign-pod-node.md
Outdated
Show resolved
Hide resolved
@alculquicondor @sftim When you have a moment, could you kindly review my PR and let me know if there are any updates or changes needed? Your feedback is greatly appreciated. |
Hello @aryasoni98,
I still see commit messages are referencing issue #47922. Can you please squash your commits into one and update final message to not include references. |
@aryasoni98, |
Thank you for bringing this to my attention. I apologize for the oversight. I will squash my commits into one and update the final commit message to remove any references to issue #47922, ensuring it aligns with the repository guidelines. |
Thank you for the guidance and the link. I appreciate your assistance. I'll follow the instructions to squash my commits into a single commit and update the final commit message to remove any references to the issue. |
fa3c81a
to
22184da
Compare
@davidopp @alculquicondor @T-Lakshmi Just wanted to follow up on the PR—everything is looking good on your end, and no further changes are needed. Could you please review it when you have a moment? If all looks good to you, feel free to go ahead and merge. |
content/en/docs/concepts/scheduling-eviction/assign-pod-node.md
Outdated
Show resolved
Hide resolved
I believe I've addressed all the feedback and resolved the issues you've pointed out. The commit history has been cleaned up, and all unnecessary references have been removed as per the repository guidelines. Please review the latest changes at your convenience and let me know if there's anything else that needs attention. Thank you for your guidance and assistance! |
- Incoming Pod's `podAffinity` or `podAntiAffinity` with `requiredDuringSchedulingIgnoredDuringExecution`: | ||
The scheduler ensures the new Pod is assigned to nodes that satisfy these required affinity and anti-affinity rules based on existing Pods. | ||
- Existing Pods' `podAntiAffinity.requiredDuringSchedulingIgnoredDuringExecution`: | ||
Treated as hard constraints, filtering out nodes that violate existing Pods' required anti-affinity rules. |
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 requiredDuringSchedulingIgnoredDuringExecution
property, as its name suggests,
is not supposed impact an existing Pod.
In Kubernetes, Pods are by default scheduled only once. I'm not sure when the scheduler
will "filter out nodes" for an existing Pod.
With that, I think there are things to improve in the organization of these constraints/conditions.
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.
I believe I have addressed all the feedback and resolved the issues you pointed out. The commit history has been cleaned up, and all unnecessary references have been removed as per the repository guidelines. Additionally, the documentation has been reorganized for better clarity and understanding.
Please review the latest changes at your convenience and let me know if there's anything else that needs attention.
Thank you for your guidance and assistance!
As per
/unhold |
/remove-language es |
/remove-area blog |
There are still unresolved comments from my side that are marked as resolved in the UI. |
Could you please pin the unresolved issues for me and mark them as resolved |
Updated the podAffinity concept documentation Updated the podAffinity concept documentation
0b00e00
to
1880648
Compare
@alculquicondor @sftim @T-Lakshmi Just wanted to follow up on the PR—everything is looking good on your end, and no further changes are needed. Could you please review it when you have a moment? If all looks good to you, feel free to go ahead and merge. |
content/en/docs/concepts/scheduling-eviction/assign-pod-node.md
Outdated
Show resolved
Hide resolved
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.
Thanks for the work so far.
Watch out for writing like an AI language model; we try to use a human tone of voice.
Please review the pending feedback.
Description
Summary of Changes
Added "Existing Pods' Affinity and Anti-Affinity Considerations" Section:
podAffinity
andpodAntiAffinity
fields.Updated "Inter-pod affinity and anti-affinity" Section:
Ensured Consistency and Clarity:
Issue
Closes: #47922