You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When a pod specifies the reservation affinity with a label selector, the candidate reservations will inherit the labels of their nodes before doing the match. It is helpful when the pod wants to select the reservation according to some node-level attributes, e.g. node.kubernetes.io/zone. However, it corrupts the label selector of the reservations themselves. When a pod wants to affinity according to a reservation label instead of the same label on the node, it can not work.
In this proposal, we want to clean up the label casting logic for the reservation from the node labels. However, some special labels like the node.kubernetes.io/zone should be optional to keep. Perhaps we need to add fields in the ReservationArgs.
Why is this needed:
Is there a suggested solution, if so, please add it:
The text was updated successfully, but these errors were encountered:
What is your proposal:
When a pod specifies the reservation affinity with a label selector, the candidate reservations will inherit the labels of their nodes before doing the match. It is helpful when the pod wants to select the reservation according to some node-level attributes, e.g. node.kubernetes.io/zone. However, it corrupts the label selector of the reservations themselves. When a pod wants to affinity according to a reservation label instead of the same label on the node, it can not work.
In this proposal, we want to clean up the label casting logic for the reservation from the node labels. However, some special labels like the node.kubernetes.io/zone should be optional to keep. Perhaps we need to add fields in the ReservationArgs.
Why is this needed:
Is there a suggested solution, if so, please add it:
The text was updated successfully, but these errors were encountered: