Tanzu Default Storage Class

Kürzlich habe ich mit Helm-Charts auf Tanzu Kubernetes-Clustern herumgespielt und bin auf einige Probleme gestoßen. Hier ist ein schneller Tipp, falls Du auf ähnliche Probleme stößt.

Beim Bereitstellen eines Helm-Charts bin ich auf das Problem gestoßen, dass meine Pods in eine Crash-Schleife geraten sind. Nach Untersuchungen habe ich herausgefunden, dass die persistenten Volumes nicht erstellt wurden. Der Chart hat einige PVCs erstellt, konnte aber die zugehörigen PVs nicht erstellen. Nach dem Beschreiben des PVC habe ich folgenden Fehler gefunden:

Obwohl TKG-Cluster den vSphere CSI als PV-Bereitsteller haben, muss dem PVC eine zugehörige Speicherklasse zugewiesen werden, damit es weiß, wo es die Volumes erstellen soll. Bei Helm-Charts kannst Du beim Installieren eines Charts nicht angeben, welche Speicherklasse verwendet werden soll, wie Du es bei Deployments tun würdest.

Standard-Speicherklasse festlegen

Wenn Du eine Standard-Speicherklasse festlegst, bedeutet das, dass alle PVCs, die ohne festgelegte Speicherklasse erstellt werden, standardmäßig diese verwenden. Und theoretisch ist es einfach, in Kubernetes eine Speicherklasse als Standard festzulegen, indem Du Folgendes ausführst:

Finde heraus, welche Speicherklassen Du hast, indem Du kubectl get sc ausführst:

Wie Du sehen kannst, gibt es zwei Speicherklassen, aber da die zweite genauso ist wie die erste, nur mit einem anderen Bindungsmodus, ist keine als Standard festgelegt, was hier durch (default) angezeigt werden würde.

Nun kannst Du es als Standard festlegen, indem Du die Klasse patchst:

Ersetze dabei sp-tanzu-global durch den Namen Deiner Speicherklasse. Wenn Du nun erneut kubectl get sc ausführst, solltest Du Folgendes sehen:

Bis hierhin ist alles gut. Wenn Du nun Deinen Helm-Chart sofort ausführst, sollte es funktionieren. Aber ich habe ein anderes Problem gesehen: Nach etwa einer Minute wird die Speicherklasse wieder auf nicht standardmäßig zurückgesetzt, was bedeutet, dass nachfolgend installierte Helm-Charts erneut den Fehler werfen, dass keine Speicherklasse für den PVC festgelegt ist.

Das ist speziell bei Tanzu-Clustern so. Da der Cluster mit einer YAML-Datei bereitgestellt wird, ändert sich die Konfiguration des Clusters nicht, wenn Du die Standard-Speicherklasse im Cluster selbst änderst. Und von Zeit zu Zeit überprüft Tanzu die tatsächliche Konfiguration des Clusters und die YAML-Clusterkonfiguration und behebt Unterschiede (wobei die YAML-Priorität hat). Das bedeutet, wir müssen die Standard-Speicherklasse dort festlegen:

Ändere Deinen Kontext zum vSphere-Namespace und zeige Deine Cluster an (kubectl config use-context <namespace-name>). Je nachdem, welche API-Version zum Bereitstellen des Clusters verwendet wurde, könnte dies unterschiedlich sein:

Wenn Du siehst:

Bedeutet das, dass Du Deinen Cluster mit v1beta1 bereitgestellt hast. Wenn Du Deinen Cluster hier siehst, bedeutet das, dass er mit v1alpha3 oder älter bereitgestellt wurde. Je nachdem, welches es ist, siehe die entsprechende Konfiguration:

Standard-Speicherklasse in v1beta1

Führe kubectl edit cluster <cluster name> aus. Die Konfiguration ist wahrscheinlich ziemlich lang. Wonach Du suchst, ist der Block spec.topology.variables. Mit vielen Auslassungen sollte es in etwa so aussehen:

Suche nach storageClass und defaultStorageClass. Dies fehlt höchstwahrscheinlich, also füge es auf dieser Ebene irgendwo hinzu. Danach solltest Du eine Standard-Speicherklasse haben, also prüfe in Deinem Cluster mit kubectl get sc.

Standard-Speicherklasse in v1alpha3

Wenn Dein Cluster vom Typ TKC ist (wie oben festgestellt), kannst Du es nicht mit dem Befehl kubectl edit cluster bearbeiten und musst stattdessen kubectl edit tkc verwenden.

Was Du hier suchst, ist die Ebene spec.settings.storage und am Ende sollte es in etwa so aussehen (verkürzt):

Du hast wahrscheinlich den Wert defaultClass vermisst, füge ihn also mit Deiner Speicherklasse hinzu. Danach solltest Du Deine Speicherklasse sehen, wenn Du zum Cluster zurückkehrst und erneut kubectl get sc ausführst.

Volumes werden immer noch nicht erstellt

Selbst nach all dem hatten einige meiner PVCs Volumes zugeordnet, aber einige nicht. Wenn Du nach all dem immer noch auf das Problem stößt, dass keine PVs für Deine Bereitstellung erstellt werden, sieh Dir das Alter Deiner PVCs an, wenn Du sie mit kubectl get PVC -A ansiehst. Wenn die problematischen PVCs immer noch da sind, selbst nachdem Du den Helm-Chart gelöscht und neu bereitgestellt hast, wurden sie möglicherweise nicht durch ein manifestbasiertes persistentVolumeClaim im Chart erstellt, sondern durch einen Job. Deshalb werden sie beim Deinstallieren des Helm-Charts nicht automatisch gelöscht. Lösche sie manuell und versuche es erneut. Das hat mein Problem gelöst.