When targeting target types that have multiple pods, we select a pod using the target object's label selector, however, it seems we are currently ignoring the matchExpressions field of the label selector, and only take the matchLabels field.
Impact
Those two fields are ANDed, so if a user defines a condition using both matchLabels and matchExpressions, we would ignore the restriction defined by the matchExpressions on selected pods, and in the worse case scenario we would select a pod from a different deployment/rollout/...
Also, we return an error if there are no matchLabels, but I think that's a valid case - when the label selector is defined based on match expressions alone.
Example for one of the places we only use selector.match_labels:
When targeting target types that have multiple pods, we select a pod using the target object's label selector, however, it seems we are currently ignoring the
matchExpressions
field of the label selector, and only take thematchLabels
field.Impact
Those two fields are
AND
ed, so if a user defines a condition using bothmatchLabels
andmatchExpressions
, we would ignore the restriction defined by thematchExpressions
on selected pods, and in the worse case scenario we would select a pod from a different deployment/rollout/...Also, we return an error if there are no
matchLabels
, but I think that's a valid case - when the label selector is defined based on match expressions alone.Example for one of the places we only use
selector.match_labels
:https://github.com/metalbear-co/mirrord/blob/7b8dae671f4cc2d70864100c1cc4d10659368bf6/mirrord/kube/src/api/runtime/deployment.rs#L20-L26
Reproduction
no-expressions.yaml
has-expressions.yaml
If you define those two deployments, and run mirrord with the operator, targeting
deploy/has-exps
, agents will be created for both pods.If you run without the operator, targeting
deploy/has-exps
, you might target the pod from the wrong deployment: