Belajar Kubernetes Shared Filesystem RWX - Resize Volume, Volume Expansion & Performance

#Pendahuluan

Data tidak pernah menyusut. Portfolio upload Laravel yang tumbuh bulan demi bulan akan menekan kapasitas volume. Pertanyaan yang menghantui banyak tim: apakah menambah kapasitas harus menghentikan aplikasi?

Jawabannya, dengan allowVolumeExpansion: true di StorageClass kita (episode 5), adalah tidak. Episode 16 membahas tiga hal yang saling berkaitan: resize volume online, mount options yang menentukan perilaku saat NFS bermasalah, dan monitoring/optimasi performa.

#Masalah Volume Fixed di Produksi

Volume statis = waktu penuh = downtime. Ketika NFS penuh, aplikasi tidak bisa menulis, upload gagal diam-diam, dan pengguna mengeluh. Karena itu:

• Aktifkan allowVolumeExpansion: true di StorageClass NFS sejak awal.
• Pantau pemanfaatan (episode 18) supaya expand dilakukan sebelum penuh, bukan saat sudah darurat.

#Konsep Expansion di NFS CSI Driver

Perlu dipahami: volume NFS hanyalah subdirektori virtual di sisi server. "Menambah kapasitas PVC" berarti:

1. Kubernetes memperbarui spec.capacity.storage PV.
2. Driver me-resize filesystem client (mis. ext4/xfs, harus mendukung online grow).
3. Ruang fisik harus tersedia di server — jika server nyaris penuh, resize "berhasil" di sisi Kubernetes tetapi sebenarnya tidak menambah ruang apa pun.

Jadi yang wajib disiapkan adalah kapasitas backend: jika disk NFS server berupa ZFS dataset atau LVM pool, perluas pool-nya dulu:

Perluas kapasitas backend (contoh ZFS dataset dan LVM)

# ZFS
sudo zpool online <pool> <new-disk>
sudo zfs set quota=200G <pool>/k8s-shared
 
# LVM
sudo pvcreate /dev/sdc
sudo vgextend vg-storage /dev/sdc
sudo lvextend -L +100G /dev/vg-storage/lv-nfs
sudo resize2fs /dev/vg-storage/lv-nfs

#Manifest StorageClass

Pastikan StorageClass yang dipakai aplikasi punya allowVolumeExpansion:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: nfs-csi
provisioner: nfs.csi.k8s.io
parameters:
  server: 192.168.10.20
  share: /srv/k8s-shared
  subDir: dynamic/${pvc.namespace}/${pvc.name}
mountOptions:
  - nfsvers=4.2
  - hard
reclaimPolicy: Delete
volumeBindingMode: Immediate
allowVolumeExpansion: true

#Ekspansi PVC (Online)

Perbesar kapasitas tanpa downtime:

Edit request storage PVC

kubectl edit pvc media-storage

Ubah baris berikut (contoh 1Gi → 20Gi):

  resources:
    requests:
      storage: 20Gi   # ubah dari 1Gi

Verifikasi:

Cek kapasitas baru

kubectl get pvc media-storage
kubectl get pv -o yaml | grep -A2 capacity

PV menampilkan kapasitas baru, dan filesystem di client sudah di-grow oleh CSI expansion secara online.

#Mount Options Optimal

Mount options menentukan perilaku saat koneksi NFS terganggu. Dua pendekatan yang berbeda filosofinya:

Rekomendasi untuk produksi:

mountOptions:
  - nfsvers=4.2
  - hard
  - timeo=600
  - retrans=5

• timeo=600 (dalam sepersepuluh detik → 60 detik) — interval retry lebih santai dari default 0.7 detik.
• retrans=5 — jumlah pengiriman ulang sebelum minor timeout.

hard dipilih karena melindungi data: proses menunggu server kembali alih-alih menulis ke posisi korup. Konsekuensinya adalah proses "hang" yang tampak — itu lebih baik daripada data rusak, dan ini alasan kenapa HA server (episode 20) sangat penting.

#Monitoring I/O NFS

#Di Client

nfsstat -m
df -h /var/www/storage
iostat -x 5

• nfsstat -m — informasi dan statistik tiap mount NFS.
• df -h — kapasitas & penggunaan.
• iostat -x 5 — beban perangkat; amati await dan %util.

#Di Server

Statistik di server

nfsstat -s

nfsstat -s menampilkan panggilan NFS yang masuk dari seluruh server. Untuk grafik berbasis waktu, scrap metrics node_exporter mountstats ke Prometheus/Grafana — kita bangun dashboards-nya di episode 18.

#Performance Optimasi

• Jauhkan NFS dari worker yang berlatensi tinggi. Latensi LAN 1-2 ms bagus; lintas VLAN dengan banyak hop akan membunuh I/O kecil.
• Gunakan dedicated NIC atau 10GbE bila workload upload-nya besar.
• Batasi request upload besar di Nginx supaya memori tetap terkendali:

server {
    client_max_body_size 50m;
}

• Perhatikan df server sebagai peringatan dini — NFS yang penuh sama fatalnya dengan mount yang mati.

#Penutup

Pada episode 16 ini, kalian telah menguasai pengelolaan pertumbuhan dan performa volume:

Inti yang harus dibawa pulang:

• allowVolumeExpansion: true memungkinkan resize PVC online; pastikan StorageClass aplikasi mengaktifkannya.
• Ruang fisik harus tersedia di backend (expand ZFS dataset / LVM pool) agar resize bermakna.
• kubectl edit pvc mengubah request storage; tidak bisa dikurangi.
• Mount options: hard (aman data) vs soft/softerr (cepat error); produksi memakai hard,timeo=600,retrans=5.
• Monitoring: nfsstat -m, df -h, iostat -x di client; nfsstat -s di server; metrics ke Grafana.

Di episode 17 selanjutnya kita akan membangun snapshot & restore PVC NFS: memasang snapshot-controller, membuat VolumeSnapshot, merestore PVC dari snapshot, dan memahami batasan snapshot NFS CSI. Sampai jumpa di episode 17!