Belajar Firecracker - Balloon, Entropy & Resource Control

#Pendahuluan

Di episode 9 kita bisa membekukan dan menghidupkan microVM. Sekarang tantangan yang lebih halus: bagaimana ratusan microVM berbagi satu host secara adil? Episode 10 membahas pengendalian sumber daya — memori lewat device balloon, entropy lewat virtio-rng, dan batas keras CPU/memori lewat cgroup v2.

Mengapa episode ini penting? Tanpa kontrol sumber daya, satu microVM bisa menyedot semua memori atau memonopoli CPU, menjatuhkan tetangganya. Dengan balloon dan cgroup, operator bisa menentukan dengan presisi berapa banyak sumber daya yang boleh dipakai tiap VM — dasar dari ekonomi multi-tenant yang membuat Firecracker layak dipakai di skala AWS.

#Balloon: Menarik Kembali Memori

Device virtio-balloon adalah mekanisme Firecracker untuk menarik kembali memori dari guest ke host. Konsepnya: host "mengembang" balloon di dalam guest, mendorong guest untuk melepaskan halaman memori yang tidak terpakai; halaman itu kembali ke pool host dan bisa dipakai VM lain.

Konfigurasikan balloon sebelum boot:

curl --unix-socket /tmp/firecracker.sock -i \
  -X PUT http://localhost/balloon \
  -H 'Accept: application/json' -H 'Content-Type: application/json' \
  -d '{
    "amount_mib": 128,
    "deflate_on_oom": true,
    "stats_polling_interval_s": 10
  }'

Field penting:

• amount_mib — berapa MiB memori yang ditarik dari guest (balloon di-inflate sebesar ini).
• deflate_on_oom — saat guest kekurangan memori (OOM), balloon otomatis mengempis memberi memori balik — pengaman yang mencegah guest di-kill.
• stats_polling_interval_s — interval pengumpulan statistik memori guest.

Ukuran balloon bisa diubah dinamis setelah boot via PATCH /balloon — mengembang saat VM idle, mengempis saat VM butuh:

curl --unix-socket /tmp/firecracker.sock -i \
  -X PATCH http://localhost/balloon \
  -H 'Accept: application/json' -H 'Content-Type: application/json' \
  -d '{ "amount_mib": 512 }'

#Statistik Balloon: Mengukur Tekanan Memori

Statistik balloon memberi jendela ke kondisi memori guest dari sisi host. Dengan stats_polling_interval_s aktif, host bisa membaca:

curl --unix-socket /tmp/firecracker.sock http://localhost/balloon/statistics

Outputnya berbentuk JSON berisi metrik seperti free_memory, available_memory, pages_reclaimed — data yang bisa dipakai orchestrator untuk memutuskan kapan mengembang/mengempis balloon secara otomatis. Ini pola control loop yang sama dengan memory reclamation di hypervisor modern: monitor → decide → adjust.

Device balloon di Firecracker dipetakan via MMIO, sama seperti device virtio lain. Artinya, ia berpartisipasi dalam aturan yang sama: hanya bisa dikonfigurasi sebelum boot, dan berjalan sebagai device virtio standar yang dikenali kernel guest.

#Entropy: Virtio-rng

MicroVM yang baru lahir sering kekurangan entropy — sumber keacakan untuk kriptografi (TLS, UUID, kunci). Host punya getrandom dan hardware RNG; guest di dalam VM tidak otomatis mendapat akses ke sana. Tanpa entropy, proses kriptografi di guest bisa terblokir menunggu keacakan.

Solusinya adalah device virtio-rng, yang diaktifkan secara default di konfigurasi Firecracker dan menyuntikkan entropy dari host ke guest. Konfigurasinya bisa disesuaikan melalui machine config:

curl --unix-socket /tmp/firecracker.sock -i \
  -X PUT http://localhost/machine-config \
  -H 'Accept: application/json' -H 'Content-Type: application/json' \
  -d '{
    "vcpu_count": 2,
    "mem_size_mib": 1024,
    "entropy": { "rate_limiter": { "ops": { "size": 1000, "refill_time": 100 } } }
  }'

Cek entropy di dalam guest:

cat /proc/sys/kernel/random/entropy_avail

Jika angkanya tinggi dan tidak pernah macet, virtio-rng bekerja. Perhatikan juga bahwa rate limiter bisa diterapkan ke device entropy — mencegah satu VM menguras sumber entropy host lewat permintaan berlebihan.

#cgroup v2: Batas Keras CPU dan Memori

Balloon bersifat persuasif (minta guest melepas memori). Batas cgroup bersifat memaksa — di level kernel, tanpa kerja sama guest. Dengan cgroup v2, tiap microVM ditempatkan di cgroup sendiri:

mkdir -p /sys/fs/cgroup/fc/<id>
echo 1024 > /sys/fs/cgroup/fc/<id>/memory.max
echo 500000 > /sys/fs/cgroup/fc/<id>/cpu.max

Membaca nilai ini:

• memory.max — memori maksimal (byte) untuk grup. Jika dilewati, kernel melakukan reclaim; jika tidak bisa, OOM-kill di dalam grup.
• cpu.max — dalam format quota period (misal 500000 100000 = 500 ms per 100 ms period = 5 vCPU).
• cpuset.cpus — pilih CPU mana yang boleh dipakai, membantu isolasi dan NUMA.

Lalu tempatkan proses Firecracker ke dalam cgroup:

echo <firecracker-pid> > /sys/fs/cgroup/fc/<id>/cgroup.procs

Jailer sudah membuat cgroup dasar untuk tiap VM; dengan cgroup v2, operator memperluasnya dengan batas eksplisit. Kombinasi balloon + cgroup adalah pola lengkap:

• cgroup menegakkan maximum (VM tidak pernah melewati batas).
• balloon mengatur distribution (memori mengalir ke VM yang membutuhkannya saat idle VM lain).

Keduanya bekerja di lapisan berbeda dan saling melengkapi.

#Cap per Device dan Rate Limiter

Selain cgroup, tiap device I/O punya batas sendiri lewat rate limiter (dibahas di episode 5). Peta lengkap pengendalian sumber daya:

• CPU: cgroup cpu.max + pilihan vCPU di machine config.
• Memory: cgroup memory.max + balloon amount_mib.
• Network I/O: rate limiter bandwidth + ops di network interface.
• Block I/O: rate limiter bandwidth + ops di drive.
• Entropy: rate limiter ops di device entropy.

Dengan peta ini, operator bisa memberikan janji layanan yang terukur per VM — dan menegakkannya di beberapa lapisan sekaligus.

#Common Pitfalls

• Balloon tanpa driver guest: balloon tidak efektif bila kernel guest tidak mendukung virtio-balloon.
• deflate_on_oom false: risiko guest di-kill saat pressure memori; aktifkan kecuali ada alasan kuat.
• Batas cgroup lebih kecil dari memori VM: kernel host akan OOM-kill proses Firecracker — selalu memory.max > mem_size_mib + overhead.
• Lupa rate limiter entropy: satu VM dengan permintaan entropy tinggi bisa menguras host.
• Statistik balloon tanpa interval: stats_polling_interval_s harus diset agar data statistik dikumpulkan.

#Penutup

Inti yang harus dibawa pulang:

• Balloon menarik memori dari guest dengan kerja sama driver virtio.
• deflate_on_oom mencegah OOM di guest saat balloon terlalu agresif.
• Statistik balloon memberi data untuk control loop pengelolaan memori.
• Virtio-rng menyediakan entropy; cek dengan entropy_avail.
• cgroup v2 menegakkan batas keras CPU (cpu.max) dan memori (memory.max).
• Rate limiter menutup sisi I/O; balloon + cgroup = persuasi + paksaan.

Di episode 11 selanjutnya kita akan menjembatani Firecracker dengan dunia container: Integrasi Container — firecracker-containerd — runtime containerd yang menjalankan tiap container di dalam microVM Firecracker, memahami komponen runtime dan snapshotter overlay, serta alur pull image, unpack, dan menjalankan container dalam microVM dengan bridge network.