Belajar Kubernetes Simple Shared Storage - Skenario Kompleks & Studi Kasus

#Pendahuluan

Semua keputusan episode 1-25 sekarang diuji dalam skenario nyata: banyak namespace, volume bersama, migrasi data, dan cluster lintas lokasi. Episode 26 menyusun studi kasus — bukan cerita teoritis, tetapi keputusan yang bisa diambil (dan alasannya) saat kompleksitas menaik.

#Kasus 1: Multi-Namespace Berbagi RWX

Situasi: Dua tim (media & cms) memakai satu shared volume untuk konten bersama.

Keputusan yang tepat:

Satu PVC + satu NFS Server Pod (per-PVC) sebagai titik tunggal mount.
NetworkPolicy per namespace — hanya namespace tim yang berhak akses service NFS (episode 11).
Struktur folder dibatasi per aplikasi: /media/, /cms/ — bukan mencampur akar.

networkpolicy-allow-media.yaml

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-nfs-media-cms
  namespace: openebs-nfs
spec:
  podSelector:
    matchLabels:
      app: nfs-shared-content
  policyTypes: [Ingress]
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              team: media
        - namespaceSelector:
            matchLabels:
              team: cms
      ports:
        - protocol: TCP
          port: 2049

Warning

Berbagi satu volume antar-tim mengurangi isolasi (episode 12). Sepakati kontrak: namespace mana yang boleh tulis, siapa pemilik data, dan aturan pembersihan volume — sebelum mencampur tim dalam satu PVC.

#Kasus 2: Migrasi Local PV Antar Node

Situasi: Node worker-2 (memuat data-postgres) mau pensiun.

Local PV terikat node — kita pindahkan datanya (bukan volume-nya):

Dump data di node lama

kubectl exec sts/postgres-0 -- pg_dumpall -U postgres | gzip > pgdump.sql.gz

Restore di node baru

gunzip -c pgdump.sql.gz | kubectl exec -i sts/postgres-0 -- psql -U postgres

Atau lebih sederhana: deploy StatefulSet baru di node target (volume baru hostpath), restore data, cut-over DNS.

Rangkuman:

Data database = 1 file (pg_dump) yang bisa pindah ke mana pun.
Media RWX otomatis pindah saat Pod di-reschedule (NFS, episode 16).
Local PV yang benar-benar "pindah" adalah data, bukan volume.

#Kasus 3: Cluster Multi-DC & Latency

Situasi: Dua DC dihubungkan jaringan WAN; media diakses kedua sisi.

Kenyataan OpenEBS:

Hostpath/Local PV bersifat single-DC — volume hidup di node suatu DC.
RWX NFS lintas node dalam satu kontrol-plane — latency lintas DC menambahkan RTT pada tiap operasi.

Keputusan realistis:

Jangan me-mount RWX lintas DC dalam satu PV.
Gunakan tiap DC dengan storage lokal-nya sendiri (per-cluster atau per-region).
Data disinkronkan level file/DB (Velero/rsync, episode 20; atau file sync ke object storage), bukan live-LVM lintas WAN.

Note

Produk replicated seperti Mayastor menjanjikan block HA lintas node — tetapi untuk multi-DC dengan latency nyata, biaya RTT menghalangi media files yang peka. Pilih sync-asinkron dan deploy-close-to-data.

#Skala Menengah

Cara berpindah dari small ke medium tanpa menumbuh kompleksitas tak terkendali:

Model "satu PVC = satu aplikasi" tetap — tambah POD tanpa bongkar arsitektur.
Engine beragam — hostpath untuk disposable, LVM/ZFS untuk data penting, NFS RWX untuk share.
Namespace sebagai unit isolasi — storage & NetworkPolicy mengikuti batas tim.
Kebiasaan (alert, runbook, uji restore bulanan) tidak berubah — hanya jumlah yang bertambah.

Jangan menambah engine (Mayastor, LVM, dll) sekaligus: satu fitur baru per periode, dengan pengujian dulu (episode 14/23).

#Penutup

Pada episode 26 ini, kalian bukan lagi pembaca — kalian pengambil keputusan:

Inti yang harus dibawa pulang:

Multi-namespace RWX: 1 PVC + NetworkPolicy per tim + kontrak data.
Migrasi Local PV: pindahkan data (pg_dump/rsync), bukan volume.
Multi-DC: local-per-DC + sync file; jangan RWX live lintas WAN.
Skala menengah: pertahankan model per-PVC, tambah engine satu per satu.
Semua keputusan menyilangkan: kebutuhan, biaya, dan kesederhanaan operasi.

Di episode 27 — yang terakhir — kita akan berrefleksi dan memetakan roadmap: rekap seluruh perjalanan, panggung-panggung keputusan, daftar bahan bacaan, dan langkah-langkah konkret setelah series ini selesai. Sampai jumpa di episode 27!