Belajar Kata Containers - Hypervisor Backends: QEMU, Cloud Hypervisor, Firecracker
Episode ini membandingkan backend VMM Kata Containers: QEMU sebagai default dengan kompatibilitas luas, Cloud Hypervisor yang modern dan cepat, Firecracker yang minimalis, serta Dragonball yang built-in di runtime Rust. Kalian belajar trade-off fitur versus kecepatan dan kapan memilih masing-masing backend.
#Pendahuluan
Di episode 5 kalian melihat bahwa configuration.toml memiliki bagian per hypervisor. Episode 6 menjawab pertanyaan yang mengikutinya: backend mana yang harus dipakai? Kata Containers tidak terikat satu VMM — ia dirancang sebagai runtime yang memakai VMM sebagai plugin. Pilihan VMM menentukan karakter microVM kalian: seberapa cepat boot, fitur apa yang tersedia, dan seberapa besar overhead yang harus dibayar.
Ini bukan keputusan "sekali pilih, selamanya". RuntimeClass (episode 4) memungkinkan kalian menjalankan backend berbeda untuk workload berbeda dalam satu cluster. Memahami trade-offnya akan membuat kalian memilih dengan alasan, bukan kebetulan.
#QEMU: Default dengan Kompatibilitas Luas
#Profil
QEMU adalah VMM paling tua dan paling lengkap yang didukung Kata. Ia adalah default untuk RuntimeClass kata — pilihan yang paling aman untuk memulai karena kompatibilitasnya paling luas. QEMU mendukung berbagai perangkat, arsitektur, dan fitur yang belum tentu ada di VMM lain.
#Kelebihan
- Kompatibilitas terluas: perangkat, arsitektur (x86_64, aarch64, s390x), dan fitur.
- Dukungan fitur lengkap: confidential computing (TDX/SEV-SNP), passthrough device, berbagai macam virtual device.
- Ekosistem matang: didokumentasikan dengan baik, banyak operator yang sudah terbiasa.
- Default Kata: paling banyak diuji oleh komunitas dan CI Kata.
#Kekurangan
- Overhead lebih tinggi: binary lebih besar, footprint memori lebih besar, boot relatif lebih lambat dibanding VMM modern.
- Permukaan serangan lebih luas: mengekspos lebih banyak perangkat yang tidak selalu dibutuhkan.
#Kapan Memilih
Pilih QEMU ketika kalian butuh fleksibilitas penuh, memakai fitur yang hanya ada di QEMU (seperti confidential containers), atau ketika belum yakin backend mana yang cocok. Untuk uji coba pertama, QEMU adalah jawaban yang benar.
#Cloud Hypervisor: Modern dan Cepat
#Profil
Cloud Hypervisor (dikembangkan komunitas Cloud Hypervisor Project) adalah VMM yang dirancang khusus untuk cloud-native workload. Ia hanya mendukung workload Linux 64-bit modern dengan device virtio — tanpa mengekspos perangkat legacy. RuntimeClass kata-clh menunjuk ke backend ini.
#Kelebihan
- Boot lebih cepat dibanding QEMU untuk workload umum.
- Footprint lebih kecil: lebih sedikit kode, lebih sedikit perangkat, permukaan serangan lebih sempit.
- Fokus cloud-native: dirancang untuk workload container yang dipakai Kata.
#Kekurangan
- Dukungan perangkat terbatas: tidak semua perangkat QEMU tersedia.
- Ekosistem lebih muda: meskipun sudah production-grade di Kata, dokumentasi dan kebiasaan operator masih berkembang.
#Kapan Memilih
Pilih Cloud Hypervisor untuk workload umum di cluster besar yang mengutamakan kecepatan boot dan overhead rendah, dan ketika kalian tidak membutuhkan fitur eksotis QEMU. Banyak deployment modern memakai kata-clh sebagai default karena keseimbangan fitur-kecepatannya.
#Firecracker: Minimalis untuk Serverless
#Profil
Firecracker adalah VMM yang dibuat AWS untuk menopang Lambda dan Fargate. Filosofinya: sesedikit mungkin perangkat, keamanan maksimal. RuntimeClass kata-fc memakai backend ini.
#Kelebihan
- Footprint sangat kecil: satu binary, device minimal.
- Boot sangat cepat: salah satu VMM tercepat untuk boot microVM.
- Permukaan serangan sangat sempit: ideal untuk workload untrusted.
#Kekurangan
- Fitur sangat terbatas: banyak fitur Kata (passthrough device, confidential computing) tidak tersedia.
- Perangkat terbatas: cocok untuk workload komputasi sederhana.
#Kapan Memilih
Pilih Firecracker untuk workload sandbox yang paling ringan dan untrusted — misalnya sandbox eksekusi kode tak dikenal (dibahas di episode 19). Jika workload butuh GPU atau device khusus, Firecracker bukan pilihan.
#Dragonball: Built-in Rust di Runtime
#Profil
Dragonball adalah VMM yang dibangun langsung di dalam runtime Rust Kata (runtime-rs). Ia adalah in-process VMM — tidak ada binary VMM terpisah seperti QEMU. Ini adalah arah strategis Kata: Rust-first architecture yang dipuncaki Kata 4.0.0.
#Kelebihan
- In-process: tanpa proses VMM terpisah, komunikasi host-guest lebih efisien.
- Optimasi untuk container workload: dirancang khusus untuk workload yang dibawa Kata.
- Selaras dengan runtime-rs: satu bahasa, satu toolchain, satu permukaan kode.
#Kekurangan
- Fitur belum selengkap QEMU: masih dalam pengembangan aktif.
- Bergantung pada runtime-rs: memakai Dragonball berarti memakai runtime Rust.
#Kapan Memilih
Pilih Dragonball ketika kalian memakai runtime Rust (runtime-rs) dan menginginkan pengalaman Kata yang paling terintegrasi dan ringan. Ini adalah backend yang paling menarik untuk dipantau — di episode 17 kita akan membahas bagaimana Dragonball menjadi pusat strategi performa Kata 4.0.
#Perbandingan Langsung
Ringkasan praktis untuk pengambilan keputusan:
| Aspek | QEMU | Cloud Hypervisor | Firecracker | Dragonball |
|---|---|---|---|---|
| RuntimeClass | kata | kata-clh | kata-fc | via runtime-rs |
| Boot speed | Sedang | Cepat | Sangat cepat | Cepat |
| Footprint | Besar | Kecil | Sangat kecil | Kecil |
| Fitur perangkat | Terluas | Sedang | Terbatas | Sedang |
| Confidential computing | Ya | Sebagian | Tidak | Tidak |
| Profil cocok | Umum/lengkap | Workload cloud-native | Sandbox ringan | Runtime Rust |
Ingat: tabel ini adalah titik awal. Angka pasti boot time dan overhead sangat bergantung pada kernel, perangkat keras, dan workload. Episode 20 akan menunjukkan cara mengukur sendiri.
Tip
Tidak harus memilih satu backend untuk seluruh cluster. RuntimeClass memungkinkan workload berbeda memakai backend berbeda: kata untuk workload umum, kata-fc untuk sandbox untrusted ringan, dan kata-clh sebagai default yang seimbang.
#Praktik: Memeriksa Backend Aktif
Untuk melihat backend yang sedang dipakai microVM yang berjalan:
kata-runtime kata-env | grep -i hypervisor
kubectl get pod kata-demo -o jsonpath='{.spec.runtimeClassName}{"\n"}'kata-runtime kata-env | grep -i hypervisor menampilkan hypervisor yang aktif pada node. kubectl get pod ... -o jsonpath='{.spec.runtimeClassName}' menunjukkan RuntimeClass pod — dari sana kalian tahu backend mana yang dipakai.
#Penutup
Inti yang harus dibawa pulang:
- QEMU (
kata): default, kompatibilitas terluas, fitur paling lengkap. - Cloud Hypervisor (
kata-clh): modern, cepat, seimbang untuk workload umum. - Firecracker (
kata-fc): minimalis, boot tercepat, untuk sandbox ringan. - Dragonball: in-process Rust VMM, arah strategis Kata 4.0.
- Trade-off utama: fitur versus kecepatan dan footprint.
- RuntimeClass memungkinkan mencampur backend dalam satu cluster.
Di episode 7 selanjutnya kita akan membahas networking — bagaimana Kata terintegrasi dengan CNI, peran virtio-net di dalam guest, opsi plugin bridge/macvlan/host-device, multi-interface, dan opsi eksperimental seperti disableNewNetns. Jaringan adalah bagian yang paling sering membuat bingung saat pindah dari container biasa ke microVM.