Closed gmautner closed 1 month ago
Culprit found. I excluded the hcloud-csi Daemonset from the Cilium Egress Policy and bingo, the node-ids were correctly attributed. I guess I'll recommend documenting it in the kube-hetzner Terraform provider, where this setup came from.
The DaemonSet pods will query the metadata service for the server id. If this IP (169.254.169.254
) is being forwarded to some other node, the ID you see in Kubernetes will be wrong, and Volumes will be attached to the wrong nodes.
TL;DR
A Hetzner volume from a pvc previously created using the csi.hetzner.cloud started attaching to a different node than the one where the correspoding pod is running. Looking at the VolumeAttachment, you can see that the
csi.alpha.kubernetes.io/node-id
annotation refers to two nodes at the same time, leading to the attachment of the wrong node. We can also see that the node to which the pod should attach has acsi.kubernetes.io/node-id
that does not match with itsspec.providerID
Also see the observation at the end of this comment regarding the use of Cilium Egress gateway which might be related to the problem
Expected behavior
The contents of the
csi.alpha.kubernetes.io/node-id
in the node manifest should correspond to the correct ID.Observed behavior
Here are the manifests.
Start with the pod.
nodeName: hetzner-02-88surfv3-pool-two-d916c6da54a7b84
correctly reflects where the pod is running. It mounts the pvc whose name isdata-loki-backend-2
.Looking at the pvc now, looks almost normal, except that the annotation
volume.kubernetes.io/selected-node
has the value ofhetzner-02-88surfv3-pool-one-220bed1360101ef4
which is a different node. Not sure this is an issue per se, just mentioning.Now look at the VolumeAttachment. This is where things get weird. The
csi.alpha.kubernetes.io/node-id: "51177823"
annotation points to a node-id that belongs to two nodes at the same time, as we'll see.Let's check the spec of node
hetzner-02-88surfv3-pool-two-d916c6da54a7b84
where the pod is running.See, we have the annotation:
But, at the same, time, the value of
spec.providerID
isproviderID: hcloud://51254076
which doesn't matchThe node to which the volume is attached is this one, which has the above fields matching but it's not the one it's supposed to attach to:
So it seems that there's a bug with the annotation
csi.volume.kubernetes.io/nodeid
which points to a node id belonging to other node, and the VolumeAttachment resource follows this and ends up performing the wrong attachment.I restarted the hcloud DeamonSet as well as the StatefulSet which claims the volumes but the effect is the same. Also tried deleteing the VolumeAttachment but it re-attaches to the same wrong node when recreated.
Minimal working example
This is just a StatefulSet running on k3s using the hcloud-csi storage provider.
One remark, the nodes with wrong
csi.volume.kubernetes.io/nodeid
are part of an autoscaling group.Log output
No response
Additional information
It is worth noting that the node that has the node-id that other nodes are also reporting in their annotations is running Cilium Egress gateway to use its IP address as SNAT for the internet.