Belajar Kubernetes Simple Shared Storage - Database (PostgreSQL) di atas Local PV

#Pendahuluan

Media aplikasi sudah berbagi via NFS RWX. Sekarang tibalah pertanyaan penting: di mana database? Insting yang benar: JANGAN taruh PostgreSQL di volume RWX bersama media. Database punya kebutuhan sendiri — konsistensi I/O, latensi rendah, dan biasanya pola akses satu writer.

Untuk lab/small cluster, jawaban paling sehat: PostgreSQL di Local PV (openebs-hostpath) — volume RWO yang menempel pada node. Episode 8 membangun StatefulSet Postgres di atas Local PV, dan membahas jujur resiko "volume terikat node" beserta mitigasinya.

#Storage terpisah untuk DB

Mengapa tidak memakai NFS RWX untuk database?

• Lokal PV = I/O disk langsung node tanpa lapisan NFS — kebutuhan DB akan performance terpenuhi.
• RWO menghindari dua Pod menulis file data yang sama (korupsi).
• Backing Local PV tidak menyeberangi jaringan — latensi deterministik.

Pemisahan arsitektural yang kita pakai:

Media aplikasi  → openebs-nfs-rwx   (RWX, shared, latensi ok)
Database        → openebs-hostpath  (RWO, lokal, cepat)

#StatefulSet Postgres

StatefulSet memberi identitas stabil (postgres-0) dan skema volume per-replica:

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: postgres
spec:
  serviceName: postgres
  replicas: 1
  selector:
    matchLabels:
      app: postgres
  template:
    metadata:
      labels:
        app: postgres
    spec:
      containers:
        - name: postgres
          image: postgres:16
          env:
            - name: POSTGRES_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: postgres-secret
                  key: password
          volumeMounts:
            - name: data
              mountPath: /var/lib/postgresql/data
  volumeClaimTemplates:
    - metadata:
        name: data
      spec:
        accessModes: ["ReadWriteOnce"]
        storageClassName: openebs-hostpath
        resources:
          requests:
            storage: 5Gi

Apply dan cek volume

kubectl apply -f statefulset-postgres.yaml
kubectl get pod -l app=postgres
kubectl get pvc -l app.kubernetes.io/name=postgres -o wide

PVC dengan template otomatis bernama data-postgres-0 — menempel pada node tempat postgres-0 berjalan.

#Kehatian

Local PV punya perilaku yang harus diingat:

• Terikat node: volume tidak bisa pindah sendiri. Jika node mati, Pod database menjadi Pending sampai node kembali — ia tidak otomatis pindah ke node lain.
• Backup wajib: karena data lokal, satu-satunya penyelamat adalah backup eksternal. Untuk lab: pg_dump harian + Velero (episode 20).
• Bila memakai Mayastor (opsional, episode 17): rbd image memungkinkan migrasi + snapshot; untuk setup simple, anggap Local PV sebagai "storage sekali node".

Verifikasi data tersimpan di jalur hostpath:

Lihat data Postgres di node

ls -la /var/lib/openebs/openebs-hostpath/data-postgres-0/

#Backup & Recovery Cepat

Karena resiko terikat node, backup menjadi fitur keamanan utama:

Backup harian dengan pg_dump

kubectl exec postgres-0 -- pg_dump -U postgres laravel > laravel-$(date +%F).sql

Untuk simulasi recovery lab-to-lab, restore ke Postgres baru:

Restore ke instance baru

kubectl exec -i postgres-new -- psql -U postgres laravel < laravel-2026-08-16.sql

Detail backup lengkap (jadwal cron, Velero, uji restore) dibahas di episode 20.

#Penutup

Pada episode 8 ini, database telah menempati lapisan yang tepat:

Inti yang harus dibawa pulang:

• Media → RWX NFS; database → RWO Local PV (performa & keamanan konsistensi).
• StatefulSet + volumeClaimTemplates menghasilkan PVC data-postgres-0.
• Local PV terikat node — Pod DB Pending saat node mati, tidak auto-migrate.
• Backup wajib: pg_dump + Velero; jangan memindah folder mentah antar node.
• Cocok untuk lab/small; replikasi DB baru dipertimbangkan bila produksi critical.

Di episode 9 selanjutnya kita akan mempertimbangkan object storage: kapan MinIO di atas Local PV masuk akal, endpoint S3, integrasi Laravel Flysystem, dan kapan cukup shared filesystem saja. Sampai jumpa di episode 9!