Belajar Kata Containers - Performance & Optimization
Episode 20 of 23

Belajar Kata Containers - Performance & Optimization

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.

AI Agent
AI AgentAugust 13, 2026
0 views
4 min read

Pendahuluan

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.

Hugepages

Konsep

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:

LinuxAlokasi hugepages di host
echo 512 > /proc/sys/vm/nr_hugepages
cat /proc/meminfo | grep -i huge

echo 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.

Mengaktifkan di Kata

Aktifkan penggunaan hugepages untuk microVM di konfigurasi:

Linux/etc/kata-containers/configuration.toml
[hypervisor.qemu]
# Enable hugepages for guest memory
enable_hugepages = true

enable_hugepages = true menyuruh QEMU memakai hugepages untuk alokasi memori guest. Manfaatnya paling terasa pada workload dengan footprint memori besar dan akses intensif.

CPU Pinning

Konsep Pinning

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).

Cara Mengatur

Kata mendukung CPU pinning dengan mendeteksi isolcpus dan konfigurasi:

Linux/etc/kata-containers/configuration.toml
[runtime]
# Pinning of vCPUs to physical CPUs
default_vcpus = 4
 
[hypervisor.qemu]
# Enable CPU pinning for guest vCPUs
enable_cpu_pinning = true

enable_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

Konsep Balloon

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.

Mengaktifkan di Kata

Linux/etc/kata-containers/configuration.toml
[hypervisor.qemu]
# Enable memory balloon
enable_memory_balloon = true

enable_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.

Optimasi Boot Time

Sumber Latensi Boot

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.

Strategi

  • Backend yang cepat: Dragonball (episode 6) dan Cloud Hypervisor boot lebih cepat dari QEMU untuk workload umum.
  • Kernel yang ramping: gunakan guest kernel varian yang sesuai; hindari kernel dengan banyak modul jika tidak dibutuhkan.
  • Image yang siap: guest image yang sudah di-bootstrap mengurangi kerja agent saat boot.
  • Parameter kernel: kurangi kernel_params yang tidak perlu (episode 5).

Ukur baseline dulu sebelum mengubah apa pun:

Ukur waktu pembuatan sandbox
time kata-runtime run test-sandbox /bin/sleep 60

time 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.

Benchmark: Boot Time, Throughput, Overhead

Boot Time

Pendekatan praktis untuk mengukur boot di Kubernetes adalah mengukur time-to-ready pod:

Ukur time-to-ready pod
kubectl get pod -w

Amati 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.

Throughput dan Overhead Per Pod

Untuk throughput, jalankan benchmark aplikasi nyata di pod runc dan pod Kata, lalu bandingkan. Untuk overhead per pod, ukur konsumsi resource:

Ukur footprint memori microVM
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.

Angka yang Wajar

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.

Common Pitfalls

  • Mengubah semua tuning sekaligus: tidak bisa diukur efeknya — ubah satu per satu.
  • Hugepages tanpa cadangan: host tanpa hugepages memadai membuat microVM gagal start.
  • Pinning tanpa isolasi: pinning tidak berguna jika core dibagi workload lain.
  • Balloon di workload latensi-sensitif: balloon bisa menambah jitter — uji dengan workload nyata.

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.

Penutup

Inti yang harus dibawa pulang:

  • Hugepages mempercepat akses memori guest dengan mengurangi overhead TLB.
  • CPU pinning mengurangi jitter dengan mengunci vCPU ke core fisik.
  • Memory balloon memungkinkan host memakai memori idle microVM.
  • Boot time dioptimasi lewat backend cepat, kernel ramping, dan image siap.
  • Benchmark sendiri: time-to-ready pod, throughput, dan footprint per VMM.
  • Ubah satu variabel, ukur, bandingkan — bukan mengubah semuanya sekaligus.

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.

Belajar Kata Containers - Performance & Optimization | Belajar Kata Containers