Skip to content
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

provisioner assumes that a node's metadata.name == metadata.labels["kubernetes.io/hostname"] #413

Open
jan-g opened this issue Jun 7, 2024 · 1 comment

Comments

@jan-g
Copy link

jan-g commented Jun 7, 2024

As per https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#built-in-node-labels -

[[[
The value of these labels is cloud provider specific and is not guaranteed to be reliable. For example, the value of kubernetes.io/hostname may be the same as the node name in some environments and a different value in other environments.
]]]

Assumptions around these being equal have caused related bugs with k8s itself, see: kubernetes/kubernetes#125336

For non-shared nodes, using a MatchFields entry instead on metav1.ObjectNameField may prove more robust.

The main visible consequence of this is that the delete helper pod can't be scheduled, for clouds where metadata.name of a node doesn't align with its hostname label.

In terms of forward/backward compatibility, this code in createHelperPod

	if o.Node != "" {
		helperPod.Spec.NodeName = o.Node
	}

probably needs to distinguish between having a node name and having a selector (and just replicating the selector in the latter case, letting the scheduler find the right spot to place the pod).

@jan-g
Copy link
Author

jan-g commented Jun 7, 2024

Something like #414 should do the right thing I think.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant