Belajar Kubernetes Block Storage RWO - Studi Kasus & Refleksi

#Pendahuluan

Selamat sampai di episode terakhir! Pada episode 27 ini kita merayakan perjalanan sekaligus menguji: merangkum arsitektur yang telah dibangun, mensimulasikan kegagalan nyata, memecahkan masalah yang umum ditemui, dan merefleksikan keputusan arsitektur. Ini bukan grajen — ini validation.

Mengapa studi kasus penting? Karena menyatukan seluruh materi: kalian tidak belajar Longhorn dengan menghafal command, melainkan dengan membangun sistem yang bisa bertahan. Di episode ini kita membuktikannya lewat skenario yang meniru kejadian production sungguhan.

#Recap Arsitektur

#Cluster yang Telah Dibangun

Rekap komponen yang sudah dibangun:

#Skenario Simulasi

#1. Crash Worker Node

kubectl drain worker-1 --delete-emptydir-data --ignore-daemonsets --force

Hasil yang diharapkan:

• Pod database dipindah ke worker-2.
• Volume kembali Healthy setelah replika rebuild.
• Tidak ada data hilang — replika di worker-2 menyelamatkan.

#2. Expansion PVC Saat Disk Penuh 90%

kubectl edit pvc data-postgres-0   # 20Gi → 40Gi
kubectl exec -it postgres-0 -- df -h /var/lib/postgresql/data

Hasil: kapasitas baru langsung terlihat tanpa downtime.

#3. Backup S3 & Restore Penuh

1. Pastikan recurring backup jalan.
2. Buang cluster simulasi (hard).
3. Deploy Longhorn baru → set BackupTarget S3.
4. Restore backup terakhir → PostgreSQL jalan kembali.

Hasil: test DR tahunan (episode 24) yang membuktikan RPO/RTO.

#Sesi Problem Solving

Uji pemahaman kalian:

#Case A: Replica Stuck Rebuilding

Gejala: replica status Rebuilding berhari-hari, tidak selesai.

Jawaban: Cek node tujuan — apakah ada ruang disk (longhorn_node usage)? Cek jaringan antar node; jika node baru tidak punya disk schedulable, rebuild tidak bisa lanjut. Evict node yang penuh atau tambah disk.

#Case B: Engine Degraded, Read-Only Mode

Gejala: volume jadi read-only; aplikasi error "Insufficient space" atau I/O error.

Jawaban: Cek disk node penuh (clau disk full). Longhorn mengurangi ke read-only saat disk hampir penuh untuk melindungi data. Expand volume/dan node (episode 20), lalu resize; atau out-of-space replika.

#Case C: Multi-Attach error di Production

Gejala: Pod tidak bisa start dengan pesan multi-attach.

Jawaban: Lihat Pod lain yang me-mount volume sama (noda Replica). RWO = satu writer. Matikan satu Pod, perbaiki manifest (scale 1), atau ubah ke RWX bila memang perlu berbagi file.

#Final Thoughts

#Longhorn = Pilihan Praktis Block Storage

Yang telah kita pelajari dalam 28 episode:

• Longhorn mengubah disk node menjadi pool volume ber-replikasi dengan backup bawaan.
• RWO adalah pasangan natural database: RWO + StatefulSet + replica.
• Operasional storage = bisa diupgrade, diexpand, dipantau, dan di-backup.

#Langkah Selanjutnya

Longhorn hebat untuk RWO. Untuk memperluas horizon:

• Belajar Kubernetes Shared Filesystem RWX — berbagi media file antar workload (NFS/Cephfs).
• Belajar Rook-Ceph — distributed storage block + file + object dalam satu platform (untuk kebutuhan lebih luas).
• Belajar Ceph — memahami fondasi konsep cluster Ceph tanpa Kubernetes.

#Penutup

Inti yang harus dibawa pulang dari seluruh series:

• Block storage (RWO) adalah fondasi database yang aman di Kubernetes.
• Longhorn = solusi open-source yang matang untuk menyediakan volume ber-replikasi, backup, dan observability.
• Operasional tidak kalah penting: upgrade, maintenance, DR test.
• Keputusan storage selalu bergantung konteks: database RWO → Longhorn; butuh lebih luas → Ceph.

Terima kasih telah menempuh 28 episode Belajar Kubernetes Block Storage RWO! Kalian kini bukan hanya tahu cara memasang Longhorn, tetapi memahami mengapa dan bagaimana membuatnya bekerja untuk production. Lanjutkan ke series berikutnya — karena dunia Kubernetes storage masih sangat luas untuk dijelajahi!