Überraschungen bei Storage und Kosten

Ein PVC bleibt Pending

kubectl get pvc
kubectl describe pvc <name>

Der Name der Storage-Klasse stimmt nicht. Die Read-Write-Many-Klasse heißt nfs-rwx, nicht nfs. Ein PVC, das eine nicht existierende Klasse nennt, wartet ewig ohne Fehler, denn Kubernetes nimmt an, die Klasse könnte noch auftauchen. Auflisten kannst du die Klassen nicht, deshalb stehen die beiden Namen unter Storage.

Du bist im Free Tier und hast Blockspeicher angefordert. Das wird schon beim Apply abgelehnt und bleibt nicht pending, siehe Die API sagt nein.

Noch mountet es niemand. Die Standardklasse bindet erst bei der ersten Verwendung. Ein PVC ohne Pod bleibt also Pending, und das ist richtig so. Es bindet, sobald ein Pod es mountet.

Das Kontingent ist voll. Storage zählt wie alles andere gegen das Kontingent deines Namespace.

Ein Volume wächst immer weiter

Der Autoresize tut genau das, was du konfiguriert hast, und die Konfiguration bedeutet meistens das Gegenteil von dem, was gemeint war.

resize.topolvm.io/threshold ist freier Platz, nicht belegter Platz.

• "20%" heißt: wachsen, wenn weniger als 20% frei sind, also bei 80% Füllung. Das ist, was du willst.
• "80%" heißt: wachsen, wenn weniger als 80% frei sind, also bei 20% Füllung. Das Volume wächst fast sofort, dann Schritt für Schritt weiter bis storage_limit, und du zahlst die ganze Zeit dafür, obwohl es nie annähernd voll war.

Prüf, was bei dir steht:

kubectl get pvc <name> -o jsonpath='{.metadata.annotations}'

Ein Volume kann nie schrumpfen. Weder per Autoresize noch, indem du resources.requests.storage von Hand kleiner machst. Um kleiner zu werden, legst du ein neues PVC an, kopierst die Daten und löschst das alte.

Auf nfs-rwx tut der Autoresize außerdem gar nichts. Wenn du die Annotationen dort setzt und nichts passiert, ist das der Grund.

Die Rechnung ist höher als erwartet

Fang im Portal an, es zeigt Kosten pro Workload und eine Hochrechnung für den Monat. Prüf danach diese Punkte, in der Reihenfolge, in der sie sich meistens als Ursache herausstellen.

Abgerechnet werden Requests, nicht Verbrauch. Ein Pod, der 1 vCPU anfordert und 5% davon nutzt, kostet eine volle vCPU. Zu großzügige Requests sind das Teuerste, was in einem Manifest stehen kann, und nichts geht kaputt, um dich darauf hinzuweisen: Die Anwendung läuft, die Auslastung sieht entspannt aus, und nur die Rechnung stimmt nicht.

Das Portal berechnet aus dem tatsächlichen Verbrauch über sieben Tage einen Vorschlag pro Workload. Das ist der schnellste Weg, die Lücke zu finden.

Ein Container ohne Requests ist nicht kostenlos. Er bekommt einen Namespace-Standard und wird dafür abgerechnet.

kubectl top pods

Vergleich das mit dem, was deine Manifeste anfordern.

Storage wird nach bereitgestellter Kapazität abgerechnet, nicht nach geschriebenen Bytes. Ein leeres 100-GiB-Volume kostet so viel wie ein volles, und es gibt eine Untergrenze von 10 GiB pro Volume. Fünf 2-GiB-Volumes kosten also so viel wie fünf 10-GiB-Volumes.

Ein schlafender Workload hat trotzdem Volumes. Scale-to-Zero nimmt die Kosten für CPU und Speicher weg, nicht die für Storage und die Grundgebühr. Ein Namespace mit einem 20-GiB-Volume, der den ganzen Monat schläft, zahlt dieses Volume weiter.

Etwas hält einen Workload wach. Siehe Skalierung tut nicht, was du erwartest.

Wie es weitergeht

• Abrechnung und Kontingente, wie der Zähler arbeitet
• Storage für Klassen und Autoresize