Episode ini membahas tuning performa microVM: hugepages, CPU pinning, memory balloon, dan optimasi boot time dengan Dragonball dan Cloud Hypervisor. Kalian juga belajar benchmarking boot time, throughput, dan overhead per pod dibandingkan runc.

Sepanjang series ini kita berkali-kali menyebut klaim "the speed of containers". Episode 20 menguji klaim itu secara ilmiah: berapa biaya nyata memakai microVM, dan bagaimana meminimalkannya? Kalian tidak akan mendapat jawaban pasti dalam episode ini — karena jawabannya bergantung pada environment kalian. Yang kalian dapatkan adalah toolkit: teknik tuning dan cara mengukur sendiri.
Dari episode 5 dan 6 kalian sudah mengenal parameter konfigurasi dan pilihan backend. Episode 20 memakai semuanya untuk membuat microVM seefisien mungkin: hugepages, CPU pinning, memory balloon, dan optimasi boot time.
Linux membagi memori menjadi halaman (pages) berukuran default 4 KiB. Hugepages memperbesar ukuran halaman — biasanya 2 MiB atau 1 GiB. Keuntungannya: lebih sedikit entry di TLB (translation lookaside buffer), sehingga akses memori lebih cepat — terutama untuk VM yang menahan memori dalam jumlah besar.
Untuk microVM, hugepages berarti guest memory dialokasikan dari halaman besar, mengurangi overhead TLB dan fragmentasi. Siapkan hugepages di host:
echo 512 > /proc/sys/vm/nr_hugepages
cat /proc/meminfo | grep -i hugeecho 512 > /proc/sys/vm/nr_hugepages mengalokasikan 512 hugepages (default 2 MiB → 1 GiB). cat /proc/meminfo | grep -i huge memverifikasi alokasi. Untuk persistensi, set di /etc/sysctl.conf.
Aktifkan penggunaan hugepages untuk microVM di konfigurasi:
[hypervisor.qemu]
# Enable hugepages for guest memory
enable_hugepages = trueenable_hugepages = true menyuruh QEMU memakai hugepages untuk alokasi memori guest. Manfaatnya paling terasa pada workload dengan footprint memori besar dan akses intensif.
Default-nya, vCPU microVM bisa dijadwalkan ke core host mana pun — berpindah-pindah seperti proses biasa. CPU pinning mengunci vCPU ke core host tertentu. Manfaatnya: cache L2/L3 yang lebih hangat dan prediktabilitas latensi — penting untuk workload yang sensitif terhadap jitter (inference, trading, media processing).
Kata mendukung CPU pinning dengan mendeteksi isolcpus dan konfigurasi:
[runtime]
# Pinning of vCPUs to physical CPUs
default_vcpus = 4
[hypervisor.qemu]
# Enable CPU pinning for guest vCPUs
enable_cpu_pinning = trueenable_cpu_pinning = true membuat vCPU di-pin ke core fisik. Untuk hasil terbaik, pastikan core yang dipakai tidak dipakai workload lain — kombinasi dengan cpuset host yang diisolasi untuk Kata.
Perhatikan trade-off: pinning meningkatkan performa per microVM tapi mengurangi fleksibilitas scheduling host. Untuk node yang didedikasikan untuk Kata, ini hampir selalu sepadan.
Memory balloon memungkinkan hypervisor mengambil kembali memori yang tidak dipakai guest. Virtual device "balloon" mengembang untuk menekan guest membebaskan halaman memori, atau mengempis untuk memberi kembali. Hasilnya: memori host bisa dipakai lebih efisien — microVM yang idle tidak menahan semua memori alokasinya.
[hypervisor.qemu]
# Enable memory balloon
enable_memory_balloon = trueenable_memory_balloon = true mengaktifkan balloon device pada microVM. Untuk melengkapi, gunakan memory hotplug (episode 5) agar VM bisa menambah memori saat dibutuhkan dan mengempiskan balloon saat idle.
Warning
Memory balloon bergantung pada guest kernel yang mau membebaskan halaman — tidak semua workload merespons dengan baik. Uji dengan workload nyata dan perhatikan jitter performa. Untuk workload yang sangat sensitif latensi, pertimbangkan mematikan balloon dan memberi alokasi penuh.
Boot time microVM terdiri dari: VMM launch, guest kernel boot, agent init, dan koneksi vsock. Komponen terbesar biasanya kernel boot dan inisialisasi agent. Optimasi menyasar ketiganya.
kernel_params yang tidak perlu (episode 5).Ukur baseline dulu sebelum mengubah apa pun:
time kata-runtime run test-sandbox /bin/sleep 60time kata-runtime run test-sandbox /bin/sleep 60 mengukur waktu pembuatan dan boot sandbox dari sisi runtime. Catat angka ini, lakukan optimasi satu per satu, dan bandingkan — jangan mengubah banyak hal sekaligus, karena kalian tidak akan tahu mana yang berpengaruh.
Pendekatan praktis untuk mengukur boot di Kubernetes adalah mengukur time-to-ready pod:
kubectl get pod -wAmati berapa lama pod berpindah dari Pending ke Running. Bandingkan pod Kata dengan pod runc yang identik di cluster yang sama. Selisihnya adalah biaya isolasi yang nyata di environment kalian — bukan angka dari dokumen.
Untuk throughput, jalankan benchmark aplikasi nyata di pod runc dan pod Kata, lalu bandingkan. Untuk overhead per pod, ukur konsumsi resource:
kata-runtime list
ps aux | grep -E "(qemu|cloud-hypervisor|dragonball)" | awk '{print $11, $6/1024 "MB"}'ps aux | grep -E "(qemu|cloud-hypervisor|dragonball)" menampilkan konsumsi memori setiap proses VMM di host — inilah overhead per pod yang sebenarnya: memori yang ditahan microVM di luar resource aplikasi.
Sebagai gambaran umum: pod Kata berjalan dalam boot 150-300 ms dan menahan overhead memori beberapa ratus MB (dominan dari hypervisor dan guest kernel). Angka persisnya sangat bergantung pada backend, kernel, dan workload. Jangan mengambil kesimpulan dari angka orang lain — ukur sendiri di environment kalian.
Tip
Prinsip tuning yang sehat: ukur → ubah satu variabel → ukur lagi → bandingkan → pertahankan yang terbaik. Selalu simpan baseline awal, karena tanpa baseline, semua optimasi hanyalah tebakan.
Inti yang harus dibawa pulang:
Di episode 21 selanjutnya kita akan membahas ekosistem & community — peran OpenInfra Foundation, GitHub kata-containers dengan 8.5k+ stars, Project Teams Gathering (PTG), mailing list, dan cadence rilis bulanan. Kalian juga belajar memanfaatkan dokumentasi resmi dan design docs untuk mendalami Kata.