Belajar Kubernetes Shared Filesystem RWX - Scaling Horizontal Aplikasi Laravel

#Pendahuluan

Traffic naik, aplikasi melambat — saatnya menskalakan. Keindahan desain kita: karena semua replica memakai satu PVC RWX yang sama, scaling hanyalah soal menambah replica. Tidak ada petunjuk data untuk dikoordinasikan, tidak ada reseller per Pod.

Tapi scaling bukan tanpa batas. Episode 19 membahas sisi cerah (skala horizontal dengan HPA) dan sisi gelap (saat NFS menjadi bottleneck dan harus pindah).

#Menambah Replica

Cara paling langsung — scale manual:

Scale deployment

kubectl scale deployment laravel --replicas=6
kubectl rollout status deployment/laravel
kubectl get pods -l app=laravel -o wide

Semua 6 replica mount ke PVC RWX yang sama — file yang ditulis salah satunya langsung tampak di yang lain, tidak peduli di node mana ia berjalan.

#HPA Berbasis CPU/Memory

Untuk otomasi, gunakan HPA versi autoscaling/v2:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: laravel
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: laravel
  minReplicas: 3
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70
    - type: Resource
      resource:
        name: memory
        target:
          type: Utilization
          averageUtilization: 80

Apply dan pantau

kubectl apply -f hpa-laravel.yaml
kubectl get hpa -w

HPA menambah replica saat CPU/memoria rata-rata melampaui target — semuanya langsung mendapat akses ke media yang sama.

#Shared Storage Bottleneck

NFS adalah titik tunggal. Gejala bottleneck:

• Upload besar (file 100 MB+) membuat seluruh worker mengantre di server.
• Banyak replica membuka banyak file kecil — metadata NFS jadi tersendat.
• Latensi naik seiring jumlah replika.

#Redirect: Redis untuk Session & Cache

Langkah pertama yang hampir selalu benar: pindahkan session & cache dari disk ke Redis sejak awal. Ini memangkas lalu lintas file kecil ke NFS (yang justru paling mahal per operasinya):

CACHE_STORE=redis
SESSION_DRIVER=redis

Dengan begini, NFS hanya menahan media (upload/thumbnail) — pola yang sehat: media di NFS, cache di Redis.

#Kapan NFS Tidak Cukup

Ketika aplikasi tetap lambat setelah Redis dan banyak replica, kemungkinan besar karakter bebannya bukan lagi "web files":

• Metadata-heavy workload (ribuan file kecil, indeks pencarian) → switch ke CephFS/Rook (distributed) atau object storage.
• Large binary / streaming → object storage (S3/MinIO) + CDN; media disajikan dari edge, bukan dari NFS.
• Data kritis multi-site → distributed storage dengan replikasi.

Indikator: nfsstat menunjukkan RPC latency terus naik, iostat server selalu penuh, dan peningkatan replica tidak menurunkan p95 response. Saat indikator itu muncul, arsitektur NFS sudah selesai perannya — keputusan migrasi dibahas lengkap di episode 26.

#Topologi RWX Multi-node

Kenali lagi keunggulan struktural NFS vs RWO:

• PVC RWO hanya bisa diakses satu node — skala berarti menjadwalkan Pod ke node pemilik volume.
• PVC RWX bisa diakses dari semua worker — scheduler bebas menempatkan replica di mana saja, dan HPA bekerja tanpa koordinasi.

Inilah alasan desain series ini cocok untuk aplikasi web yang ramai: fleksibilitas menjadwalkan adalah hadiah dari shared filesystem.

#Penutup

Pada episode 19 ini, kalian telah menskalakan aplikasi dengan benar:

Inti yang harus dibawa pulang:

• kubectl scale dan HPA autoscaling/v2 menambah replica di atas PVC RWX yang sama.
• Bottleneck NFS muncul saat banyak replica memaksa I/O: pindahkan session/cache ke Redis.
• Pola sehat: media di NFS, cache di Redis.
• Metadata-heavy → CephFS/Rook; large binary → object storage + CDN.
• RWX memberi kebebasan penjadwalan yang tidak dimiliki RWO.

Di episode 20 selanjutnya kita akan mengatasi single point of failure: High Availability NFS Server — opsi DRBD + Pacemaker, NFS-as-a-Service cloud, failover VIP + STONITH, dan kapan harus upgrade ke distributed storage. Sampai jumpa di episode 20!