Belajar Kata Containers - Storage: Virtio-blk, Virtio-fs & Devices

#Pendahuluan

Di episode 7 kalian memahami bagaimana jaringan masuk ke microVM lewat virtio-net. Episode 8 menempuh jalur yang sama untuk data: bagaimana container image, volume, dan device fisik sampai ke dalam guest. Ini pertanyaan penting karena storage adalah tempat data workload tinggal — memahami jalurnya menentukan performa, keandalan, dan kadang keamanan data kalian.

Kata Containers memakai tiga mekanisme utama untuk data: virtio-blk untuk disk, virtio-fs untuk filesystem sharing, dan VFIO untuk passthrough perangkat fisik. Ditambah bagaimana volume Kubernetes standar — emptyDir, PVC, hostPath, dan block device — diterjemahkan ke dalam mekanisme ini.

#Image Rootfs sebagai virtio-blk

#Jalur Image ke Guest

Container image yang ditarik di host tidak bisa langsung dieksekusi oleh guest — guest adalah mesin terpisah. Kata menyelesaikan ini dengan menyediakan image sebagai virtio-blk device: setelah image ditarik oleh containerd di host, Kata menyiapkan disk virtual berisi rootfs container dan menghubungkannya ke microVM sebagai block device.

Saat container dibuat, guest mem-boot, dan rootfs image sudah tersedia sebagai disk. Aplikasi di guest membaca dari disk virtual tersebut seolah-olah membaca disk fisik.

#Memeriksa Block Device

Untuk melihat block device di dalam guest, masuki guest dengan kata-runtime exec:

kata-runtime list
sudo kata-runtime exec <sandbox-id> lsblk

kata-runtime exec <sandbox-id> lsblk menampilkan daftar block device di dalam guest. Kalian akan melihat rootfs container sebagai perangkat virtio-blk (vda, vdb, dst.) — bukti bahwa image benar-benar menjadi disk virtual di guest.

#Mengapa Ini Berbeda dari Container Biasa

Pada runc, image dibongkar ke overlayfs di host dan langsung dipakai proses host. Pada Kata, image menjadi disk virtual yang di-mount di guest — ada lapisan virtualisasi di antara. Konsekuensinya: I/O image harus melewati jalur virtio (host → VMM → guest), yang menambah sedikit overhead dibanding akses host langsung, tapi ini harga yang wajar untuk isolasi yang didapat.

#virtio-fs: Shared Volume antara Host dan Guest

#Konsep

virtio-fs adalah mekanisme shared filesystem: sebuah direktori di host dibagikan ke guest dengan cara guest melihatnya sebagai filesystem. Kata memakai virtio-fs untuk menghubungkan volume pod ke microVM. Bedanya dengan virtio-blk: virtio-blk memberi disk terisolasi, sedangkan virtio-fs membagikan filesystem yang hidup di host.

Pola ini penting untuk volume seperti emptyDir yang isinya dibuat di host dan harus terlihat di guest.

#Volume Kubernetes dalam Kata

Cara volume Kubernetes standar diterjemahkan:

• emptyDir: direktori sementara di host, dibagikan ke guest via virtio-fs.
• PVC (mounted filesystem): volume yang sudah di-mount di host, dibagikan ke guest via virtio-fs.
• hostPath: direktori node langsung, dibagikan via virtio-fs — ingat, ini mengorbankan sebagian isolasi karena pod bisa membaca direktori host.
• Block device (volumeMode: Block): disk mentah, disediakan sebagai virtio-blk ke guest — tanpa filesystem di host.

Mekanisme virtio-fs dikonfigurasi di file konfigurasi (episode 5):

/etc/kata-containers/configuration.toml

[hypervisor.qemu]
# Shared filesystem type: virtio-fs (default)
shared_fs = "virtio-fs"
# Extra options passed to virtio-fs daemon
virtio_fs_extra_args = []

shared_fs = "virtio-fs" adalah default modern. Sebelumnya Kata memakai virtio-9p yang lebih lambat dan kurang aman; virtio-fs menggantikannya dengan performa dan fitur yang jauh lebih baik.

#Verifikasi Volume di Guest

Buat pod dengan emptyDir dan periksa bahwa volume terlihat di guest:

apiVersion: v1
kind: Pod
metadata:
  name: kata-storage
spec:
  runtimeClassName: kata
  containers:
    - name: app
      image: alpine
      command: ["sleep", "3600"]
      volumeMounts:
        - name: cache
          mountPath: /cache
  volumes:
    - name: cache
      emptyDir: {}

Setelah pod berjalan, masuki guest dan lihat direktori volume:

kata-runtime list
sudo kata-runtime exec <sandbox-id> mount | grep cache

kata-runtime exec <sandbox-id> mount | grep cache menampilkan mount volume di dalam guest — filesystem virtio-fs yang ter-mount ke /cache.

#Device Passthrough: VFIO GPU dan NIC

#Konsep VFIO

Untuk workload yang butuh akses perangkat fisik — GPU untuk AI/ML, NIC khusus, atau perangkat FPGA — Kata mendukung passthrough via VFIO. Prinsipnya: perangkat dilepaskan dari host (lewat driver vfio-pci) dan diberikan langsung ke microVM. Guest melihat perangkat fisik asli, bukan perangkat virtual.

VFIO adalah kebalikan dari virtio: virtio memberi perangkat virtual dengan isolasi penuh; VFIO memberi perangkat fisik dengan akses langsung — cepat tapi mengorbankan isolasi device-level.

#Memeriksa Dukungan Passthrough

Passthrough dimulai dari host. Pastikan IOMMU aktif dan perangkat bisa di-bind ke vfio-pci:

Cek IOMMU di host

dmesg | grep -i -e DMAR -e IOMMU
ls /sys/kernel/iommu_groups/

ls /sys/kernel/iommu_groups/ menampilkan group IOMMU — perangkat yang bisa di-passthrough terdaftar di sini. Tanpa IOMMU aktif, VFIO passthrough tidak bisa berjalan. Detail penuh passthrough GPU akan dibahas di episode 10.

#Common Pitfalls

• PVC yang lambat: volume filesystem via virtio-fs umumnya baik, tapi workload I/O berat perlu diuji di lab.
• hostPath yang bocor: hostPath memberi guest akses ke direktori host — pastikan hanya dipakai untuk data yang memang boleh diakses pod.
• Block device salah mode: PVC dengan volumeMode: Filesystem tidak bisa diakses sebagai block mentah di guest.
• VFIO tanpa IOMMU: passthrough tidak akan bekerja; pod gagal dengan error device tidak tersedia.

#Penutup

Inti yang harus dibawa pulang:

• Image rootfs disediakan ke guest sebagai virtio-blk device.
• virtio-fs membagikan filesystem host ke guest untuk volume.
• emptyDir, PVC, dan hostPath diterjemahkan ke virtio-fs; block device ke virtio-blk.
• VFIO melepaskan perangkat fisik ke guest untuk GPU/NIC passthrough.
• Virtio untuk isolasi; VFIO untuk performa — pahami trade-offnya.
• kata-runtime exec memverifikasi block device dan mount di dalam guest.

Di episode 9 selanjutnya kita akan membahas Kata agent dan image management — peran agent sebagai pengelola container di dalam guest, cara image di-pull dan di-mount ke guest (snapshotter), serta perbedaan pull di host vs pull langsung di guest.