Datenbanken

Eine ManagedPostgres ist eine PostgreSQL-Instanz. Sie rendert einen CloudNativePG-Cluster im selben Namespace, mit Backups von Anfang an und einem Credentials-Secret, das eine App direkt lesen kann.

apiVersion: paas.paasbox.com/v1alpha1
kind: ManagedPostgres
metadata: { name: db, namespace: shop }
spec:
  plan: s
  version: "17"
  storage: 20Gi
  backup:
    retention: 7d
    objectStoreSecretRef: { name: s3-backups }
status:
  conditions: [Reconciled, Ready, Degraded, BackupHealthy, ArchivingHealthy]
  phase: Ready
  endpoint: { host: db-rw.shop.svc, port: 5432, roHost: db-ro.shop.svc }
  secretName: db-credentials

Pläne

Plan	CPU	Speicher	Instanzen	Speicher-Untergrenze
xs	250m	256Mi	1	10Gi
s	500m	1Gi	2	10Gi
m	1	2Gi	2	20Gi
l	2	4Gi	2	50Gi

Jeder Plan außer xs läuft mit zwei Instanzen (ein Primary und eine streamende Replica) für automatisches Failover; xs ist eine Instanz, für Entwicklung und Previews. Preise pro Plan sind noch nicht veröffentlicht.

Was du einstellen kannst

• plan — xs, s, m oder l. Pflicht.
• version — 16 oder 17, Standard 17. Einmal erstellt, auf ihre Major-Version festgelegt: ein Upgrade der Major-Version ist noch nicht verfügbar.
• storage — die Größe des Datenvolumes. Sie kann nur wachsen, nie schrumpfen, und die Untergrenze des Plans gilt, wenn du weniger einstellst.
• backup — retention (ein Zeitfenster wie 7d oder 30d, Standard 7d) und objectStoreSecretRef, das ein Secret im selben Namespace nennt, mit den Werten accessKeyID, secretAccessKey, endpoint, bucket deines Object Stores, und optional region und path.
• hibernated — true stoppt die Pods der Instanz und behält ihre Volumes, für eine Datenbank, die du gerade nicht nutzt.
• restoreFrom — nur beim Erstellen des Objekts gesetzt: { managedPostgres: <Quelle>, targetTime: <optional> } stellt aus den Backups einer anderen Instanz in diese neue Instanz wieder her, bis zu einem Zeitpunkt, wenn du einen angibst. Die Quelle wird nie angefasst.

Backups sind nie optional

Jede ManagedPostgres wird mit fortlaufenden Backups von Anfang an bereitgestellt — Retention und Object Store sind die einzigen Entscheidungen, nicht ob Backups überhaupt laufen. Fehlt backup.objectStoreSecretRef, kommt die Datenbank trotzdem hoch, aber ihre BackupHealthy-Condition wird False und die Phase des Objekts wird Degraded: laut, damit ein fehlender Object Store etwas ist, das du siehst, nicht etwas, das genau an dem Tag lautlos scheitert, an dem du eine Wiederherstellung brauchst.

Das Credentials-Secret

status.secretName nennt ein Secret mit den servicebinding.io-Schlüsseln: type, provider, host, port, username, password, database, uri. Es gibt kein separates Binding-Objekt — dieses Secret ist die Verbindung, und App.spec.uses ist eine Abkürzung, um es zu lesen.

# an der App
uses: [{ name: db, kind: ManagedPostgres, prefix: DB_ }]

injiziert DB_HOST, DB_PORT, DB_USER, DB_PASSWORD, DB_NAME und DB_URI in die Umgebung der App als Referenzen auf db-credentials — nie als Kopien, sodass eine Rotation der Zugangsdaten die App erreicht, sobald ihr Pod das nächste Mal startet. Das Präfix ist standardmäßig der Name der Abhängigkeit, groß geschrieben, mit einem angehängten Unterstrich, wenn du keinen setzt.

CloudNativePG direkt nutzen

Der Operator hinter ManagedPostgres ist eine normale, geteilte CNPG-Installation: Schreib selbst ein Cluster-Objekt, wenn du eine Form brauchst, die ManagedPostgres nicht abdeckt. pb status listet es, markiert als unmanaged, und paasbox fasst es nie an. Siehe beide Wege.