Beobachtung
Ein deployter Pod steckt im Status “pending” fest. Mit Hilfe des Befehls describe pod sehen wir folgende Warnung:
Warning FailedScheduling [..] 0/3 nodes are available: 3 node(s) had no available volume zone.
Was ist passiert?
Wir wollten eine Sicherung einer bereits existierenden PVC (PVC_A) erstellen. Hierfür haben wir ein zweites PVC (PVC_dummy) erstellt, und versucht beide PVCs in den Pod zu mounten.
Allerdings befanden sich die im Hintergrund existierenden PVs scheinbar in verschiedenen availability domains (AD). Dies kann beobachtet werden, indem describe PV ausgeführt wird.
Ein Pod kann scheinbar nicht auf Speicher zugreifen, der sich in verschiedenen AD befindet. (Normalerweise würde Kubernetes bei der Erstellung des pods sicherstellen, dass er sich in der gleichen AD befindet, wie der Speicher. Siehe storage access for zones )
Aushilfe kann hier schaffen, indem der zweite PVC in der gleichen AD deployt wird, wie der bereits vorhandene. Dies kann bewerkstelligt werden, indem beim deployment dem PVC noch ein passendes Label mitgegeben wird. Labels verteilt Kubernetes bei jedem Startvorgang automatisch an die entsprechenden Knoten (siehe node-behaviour).
Alternativ kann beim deployment des neuen PVCs auch eine storageclass ausgewählt werden, die als binding mode WaitForFirstConsumer (siehe volume binding mode) eingestellt hat, sodass die Bereitstellung des PVs erst geschieht, wenn ein Pod erstellt wird, der den dazugehörigen PVC auslöst. Dies stellt sicher, dass der Pod im richtigem AD mit dem bereits existierendem PVC deployt wird und dann die Bereitstellung des neuen PVCs im geeignetem AD triggert.
