Belajar Linux Filesystem - Filesystem untuk Container & Kubernetes

#Pendahuluan

Container tidak menyimpan data sendiri — image bersifat read-only dan setiap tulis membutuhkan lapisan baru. Inilah alasan mengapa pemahaman filesystem menjadi fondasi bagi container dan Kubernetes. Episode 15 menghubungkan konsep filesystem yang sudah kalian pelajari dengan dunia container modern.

Kita mulai dari OverlayFS — mesin copy-on-write yang menjadi inti manajemen image container. Lalu kita bahas volume dan snapshot, rootless container, dan masuk ke Kubernetes: CSI dengan Rook-Ceph dan TopoLVM, local persistent volumes, dan semantik filesystem untuk workload stateful.

Di akhir episode, kalian akan paham mengapa storage di Kubernetes bukan sekadar "pasang disk", melainkan keputusan arsitektur.

#OverlayFS: Jantung Container

#Prinsip Overlay

OverlayFS adalah filesystem yang menggabungkan beberapa direktori (layer) menjadi satu view. Layer bawah bersifat read-only (image), layer atas menampung perubahan (container). Saat container menulis file, OverlayFS menyalin blok yang diubah ke layer atas — ini Copy-on-Write yang persis seperti btrfs dan ZFS.

Lihat bagaimana runtime container memakai overlay:

mount | grep overlay
df -hT /var/lib/docker

Output mount | grep overlay menampilkan baris dengan tipe overlay dan opsi lowerdir, upperdir, serta workdir — itulah tiga layer pembentuk filesystem container.

#Perintah untuk Menganalisis

Periksa image dan lapisannya dengan tool container:

docker image inspect ubuntu:24.04 --format '{{.RootFS.Layers}}'

Setiap layer adalah delta dari layer sebelumnya. Karena itu image container efisien: dua container dari image yang sama berbagi semua layer read-only, hanya layer atas yang berbeda per container.

#Volume dan Snapshot

#Volume vs Filesystem Container

Tulis di dalam container hilang saat container dihapus. Volume menyimpan data di luar layer container — dan di sinilah filesystem host berperan. Volume container pada dasarnya adalah direktori di filesystem host (biasanya btrfs atau ZFS jika dipasang driver storage tersebut).

#Snapshot Image Container

Dengan driver btrfs atau ZFS, snapshot image container hampir gratis:

sudo zfs snapshot docker-pool/ubuntu@v1
sudo zfs clone docker-pool/ubuntu@v1 docker-pool/ubuntu-staging

Pola snapshot + clone ini membuat image staging atau rollback environment tanpa menggandakan penyimpanan — teknik yang sama seperti episode 10, sekarang diterapkan pada image container.

#Rootless Container

#Apa itu Rootless

Container rootless menjalankan seluruh proses user space tanpa root, sehingga mengurangi dampak kerentanan runtime. Konsekuensinya, filesystem dipasang di namespace user — mount overlay di bawah /etc/subuid dan fuse-overlayfs untuk kasus tertentu:

dockerd-rootless-setuptool.sh install
systemctl --user start docker

Periksa mount yang dihasilkan:

mount | grep -E "overlay|fuse" | head

fuse-overlayfs adalah fallback berbasis FUSE ketika kernel tidak mengizinkan overlay biasa di namespace user. Tradeoff-nya: performa sedikit lebih rendah dibanding overlay kernel native.

#Kubernetes: CSI dan Persistent Volumes

#CSI: Container Storage Interface

Kubernetes memisahkan manajemen storage melalui CSI — driver yang berjalan sebagai pod dan menangani provision, mount, dan snapshot. Dua contoh populer:

• Rook-Ceph: mengelola Ceph (RBD block dan CephFS) di dalam klaster — storage terdistribusi yang lahir dari filesystem yang menangani redundansi sendiri.
• TopoLVM: memakai LVM di node untuk memprovision logical volume lokal — storage yang memanfaatkan konsep LVM snapshot yang kita bahas di episode 9.

Melihat storage class yang tersedia:

kubectl get storageclass
kubectl get pv,pvc

Output kubectl get pv,pvc menampilkan PersistentVolume dan PersistentVolumeClaim — abstraksi yang memisahkan konsumen storage (pod) dari penyedia (CSI).

#Local Persistent Volume

Untuk workload yang harus menempel pada node tertentu (misalnya database dengan data besar), local persistent volume memakai disk atau filesystem lokal tanpa replikasi jaringan:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: local-fast
provisioner: kubernetes.io/no-provisioner
volumeBindingMode: WaitForFirstConsumer

volumeBindingMode: WaitForFirstConsumer menunda pengikatan sampai pod dijadwalkan — memastikan PV dibuat di node yang sama dengan pod.

#Semantik Filesystem untuk Workload Stateful

#Saat fsync Berarti Sesuatu

Workload stateful (database) sangat bergantung pada semantik filesystem: fsync, O_DIRECT, dan konsistensi crash. Ini beberapa pertimbangan:

• Gunakan filesystem dengan fsync yang jujur — ZFS dengan ZIL atau ext4 dengan data=ordered.
• Hindari driver storage yang menyerap fsync secara diam-diam tanpa durability nyata.
• Pahami dataSource dari PVC untuk meng-clone volume dari snapshot.

Simulasikan pembuatan PVC dari snapshot dengan CSI Rook-Ceph:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: restore-pg
spec:
  storageClassName: rook-ceph-block
  dataSource:
    name: pg-snapshot
    kind: VolumeSnapshot
    apiGroup: snapshot.storage.k8s.io
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 20Gi

Pola ini menerjemahkan snapshot filesystem (episode 9) ke dalam dunia Kubernetes: memulihkan database dari titik waktu tanpa mengembalikan seluruh klaster.

#Penutup

Container dan Kubernetes tidak menggantikan filesystem — mereka membungkusnya dengan abstraksi baru. OverlayFS memberi image yang efisien, volume meneruskan data ke filesystem host, dan CSI menerjemahkan semantik filesystem ke API Kubernetes. Konsep yang kalian pelajari di episode 0-14 tetap relevan, hanya dengan lapisan baru di atasnya.

Inti yang harus dibawa pulang:

• OverlayFS adalah COW di level direktori: lowerdir image, upperdir tulis, workdir transaksi.
• Snapshot image efisien dengan driver btrfs atau ZFS.
• Rootless container memakai mount namespace terbatas dan kadang fuse-overlayfs.
• CSI memisahkan provision, mount, dan snapshot dari workload.
• Rook-Ceph memberi storage terdistribusi; TopoLVM memberi LVM lokal.
• Semantik fsync dan snapshot filesystem menembus hingga ke pod stateful.

Di episode 16 selanjutnya kita membahas performance tuning — mount options noatime/discard/compress, recordsize, scheduler I/O mq-deadline dan bfq, tuning page cache, lalu benchmarking dengan fio dan dd. Kalian akan belajar mengukur dan mengoptimalkan filesystem secara ilmiah.