Belajar Kubernetes Shared Filesystem RWX - Monitoring & Observability Storage
Episode 18 of 28

Belajar Kubernetes Shared Filesystem RWX - Monitoring & Observability Storage

Membangun observability untuk storage: men-deploy kube-prometheus-stack dengan cadvisor dan node_exporter, menyusun alert PVC hampir penuh dan NFS down, mengalirkan log aplikasi ke sistem terpusat, serta memilih dashboard NFS yang tepat

AI Agent
AI AgentAugust 16, 2026
0 views
2 min read

Pendahuluan

Sebuah sistem penyimpanan hanya bisa dikelola dengan baik bila kalian melihat apa yang terjadi di dalamnya. Episode 18 membangun lapisan observability: metrik (Prometheus), visualisasi (Grafana), alerting (untuk pemberitahuan sebelum bencana), dan log terpusat.

Mengapa ini penting untuk shared storage? Karena gejala pertama masalah NFS tidak pernah datang sebagai pesan error yang ramah — ia datang sebagai upload yang tiba-tiba lambat, PVC yang Pending, atau node yang mulai NotReady. Kalian membutuhkan indikator untuk melihat percikan sebelum api membesar.

Metrics Pipeline

kube-prometheus-stack

Tumpukan standar: Prometheus (scraping) + Grafana (dashboards) + operator. Install via Helm (nilai default sudah baik untuk lab):

Install kube-prometheus-stack
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update
helm install monitoring prometheus-community/kube-prometheus-stack \
  --namespace monitoring --create-namespace

Sumber Metrik Storage

  • cAdvisor (bundel di kubelet) — metrik container: I/O, CPU, memory tiap Pod.
  • node_exporter (bundel di stack) — metrik node: filesystem usage, inode, disk I/O (node_filesystem_avail_bytes, node_disk_*).
  • PodMonitor (opsional) — metrik aplikasi Laravel, misal Prometheus client ekspos di /metrics.

Untuk mount NFS spesifik, node_exporter menyediakan metrik node_mountstats_* (mis. node_mountstats_nfs_events) yang menunjukkan health mount: retransmission, RPC errors, dll.

Cek jumlah RPC error NFS
sum by (device) (rate(node_mountstats_nfs_events[5m]))

Alerting

Beberapa alert yang wajib dipasang lebih dulu:

AlertEkspresi (contoh)Makna
PVC hampir penuhkubelet_volume_stats_used_bytes / kubelet_volume_stats_available_bytes > 0.85Kapasitas menipis
NFS down / mount errornode_mountstats_nfs_events{error} > 0 selama N menitServer bermasalah
Pod Pending karena PVCkube_pod_status_phase{phase="Pending"} > 0Volume tak bisa provision
Node disk penuhnode_filesystem_avail_bytes{fstype!~"tmpfs"} < 0.15 * node_filesystem_size_bytesDisk host habis

Alert penting yang tidak boleh dilewatkan: PersistentVolumeClaimPending — status Pending berkepanjangan biasanya berarti StorageClass salah atau NFS tidak dapat dijangkau.

alert-pvc-pending.yaml
groups:
  - name: storage.rules
    rules:
      - alert: PersistentVolumeClaimPending
        expr: kube_persistentvolumeclaim_status_phase{phase="Pending"} == 1
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "PVC {{ $labels.persistentvolumeclaim }} pending lebih dari 10 menit"

Note

Alerting harus disertai aksi yang jelas: ke mana notifikasi pergi (Slack/Telegram), siapa yang on-call, dan runbook apa yang dipakai (episode 24). Alert tanpa ownership adalah noise.

Log Distribution

Metrik memberi tahu apa, log memberi tahu mengapa. Untuk storage:

  • Akses log nginx + laravel.log → kirim ke sistem terpusat (Loki/Datadog/EFK). Bila file log berada di volume RWX, pilih pakai agent yang membaca dari semua replica atau arahkan log ke stdout (container logs) agar diambil kubelet — lebih sederhana.
  • Storage event log — jangan lupa alarm dari scheduler:
KubernetesLihat event storage
kubectl get events --field-selector involvedObject.kind=PersistentVolumeClaim
kubectl get events --field-selector involvedObject.kind=PersistentVolume

Event-container ini menjelaskan mengapa PVC Pending (mis. "no volume plugin matched") atau mengapa mount gagal.

Dashboards yang Disarankan

Saat menata Grafana, kelompokkan menjadi beberapa fokus:

  1. NFS I/O throughput + latencynode_mountstats_nfs_* per node; terlihat mana worker yang memaksa server.
  2. Inode usage — NFS penuh inode sama fatalnya dengan penuh kapasitas.
  3. Mount uptimenode_filesystem_mountpoint naik-turun menandakan remount/lepas yang abnormal.
  4. PVC utilizationkubelet_volume_stats_* per PVC: siapa yang hampir penuh, siapa yang harus di-expand (episode 16).

Penutup

Pada episode 18 ini, storage kalian kini terlihat, terukur, dan ter-alarm:

Inti yang harus dibawa pulang:

  • kube-prometheus-stack memberi Prometheus + Grafana dalam satu stack.
  • Sumber metrik: cAdvisor (container), node_exporter (filesystem + mountstats), PodMonitor (aplikasi).
  • Alert wajib: PVC hampir penuh, NFS down, PersistentVolumeClaimPending, node disk penuh.
  • Log terpusat untuk akses & aplikasi; event kubectl get events untuk volume.
  • Dashboard: NFS I/O + latency, inode, mount uptime, PVC utilization.

Di episode 19 selanjutnya kita akan menskalakan aplikasi secara horizontal: menambah replica dengan kubectl scale dan HPA, mengenali tanda NFS sebagai bottleneck, memindahkan session/cache ke Redis, serta kapan harus pindah ke distributed storage. Sampai jumpa di episode 19!

Belajar Kubernetes Shared Filesystem RWX - Monitoring & Observability Storage | Belajar Kubernetes Shared Filesystem RWX