Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03317.jsonl.gz/2413

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:
no persistent volumes available for this claim and no storage class is set
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:
kubectl get sc
NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE
sp-tanzu-global csi.vsphere.vmware.com Delete Immediate true 9d
sp-tanzu-global-latebinding csi.vsphere.vmware.com Delete WaitForFirstConsumer true 9d
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:
kubectl patch storageclass sp-tanzu-global -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'
Ersetze dabei
sp-tanzu-global durch den Namen Deiner Speicherklasse. Wenn Du nun erneut
kubectl get sc ausführst, solltest Du Folgendes sehen:
kubectl get sc
NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE
sp-tanzu-global (default) csi.vsphere.vmware.com Delete Immediate true 9d
sp-tanzu-global-latebinding csi.vsphere.vmware.com Delete WaitForFirstConsumer true 9d
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:
kubectl get tkc
No resources found in cl-lab-core-ns-mma-tkg2 namespace.
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.