Belajar Firecracker - Orchestrator: firectl, Flintlock & MicroVMs

#Pendahuluan

Di episode 11 kita menjalankan container di dalam microVM dengan firecracker-containerd. Tapi mengelola microVM satu per satu tidak akan pernah menjadi produksi. Episode 12 memperkenalkan lapisan orchestrator: firectl untuk kemudahan, Flintlock untuk skala, dan Kubernetes sebagai control plane — supaya ratusan microVM bisa dilahirkan dan dimatikan seperti container biasa.

Mengapa episode ini penting? Firecracker hanyalah mesin; tanpa orchestrator, ia tidak bisa menjadi platform. Memahami firectl memberi kalian cara tercepat menyalakan microVM untuk eksperimen; memahami Flintlock dan runtime class microvm memberi kalian arsitektur untuk melayani ribuan pengguna dengan sandbox isolasi penuh.

#firectl: Launch Firecracker dengan Satu Perintah

firectl adalah CLI sederhana yang membungkus API Firecracker sehingga microVM bisa di-launch tanpa menulis puluhan baris curl. Ia mengambil image OCI container, membongkarnya menjadi rootfs microVM, dan mem-boot Firecracker:

firectl \
  --firecracker-binary=/usr/local/bin/firecracker \
  --kernel=vmlinux.bin \
  --root-drive=rootfs.ext4 \
  --kernel-opts="console=ttyS0 reboot=k panic=1 pci=off" \
  --vcpus=2 \
  --memory=1024

Dengan firectl, alur yang di episode 4-5 kita lakukan lewat 5 curl berubah menjadi satu perintah. Ia bahkan bisa memakai image container sebagai sumber rootfs:

firectl --firecracker-binary=/usr/local/bin/firecracker \
  --kernel=vmlinux.bin \
  --root-drive=docker:alpine:latest \
  --vcpus=1 --memory=512

Kapan memakai firectl? Untuk lab, eksperimen, dan script — kapan pun kalian butuh microVM cepat tanpa boilerplate API. Ia bukan control plane produksi, tapi pintu masuk yang sempurna untuk memahami apa yang sebenarnya dilakukan orchestrator besar di belakang layar.

#Flintlock: MicroVM as a Service

Flintlock (dari liquidmetal — proyek microVMs dari CNCF) adalah service yang mengelola siklus hidup banyak microVM di satu atau banyak host. Ia menawarkan MicroVM as a Service (MVMaaS): API untuk create, delete, dan mengelola microVM, dengan Firecracker (atau Cloud Hypervisor) sebagai VMM di belakangnya.

Alur Flintlock:

1. Create microVM spec — definisikan kernel, rootfs (dari image OCI), vCPU, memori, network.
2. Flintlock menangani sisanya — ia menjalankan jailer, membangun image, membuat TAP, mem-boot Firecracker, dan melaporkan status.
3. Delete / manage — matikan, lihat status, restart, dan bersihkan resource.

Karena Flintlock adalah service (bukan proses per VM), ia menjadi lapisan yang bisa dipegang orchestrator di atasnya — termasuk Kubernetes. Desainnya meniru container runtime: API konsisten, state terpusat, dan tiap microVM punya identitas yang bisa di-track.

curl -s -X POST http://flintlock:9090/v1/microvms \
  -H 'Content-Type: application/json' \
  -d '{
    "namespace": "default",
    "spec": {
      "kernel": { "image": "registry.example.com/kernel:1.16", "filename": "vmlinux.bin" },
      "rootVolume": { "image": "registry.example.com/rootfs:latest", "filename": "rootfs.ext4" },
      "vcpus": 2,
      "memoryMb": 1024,
      "interfaces": [{ "deviceId": "eth0", "type": "tap" }]
    }
  }'

#Kubernetes: Runtime Class microvm

Pola paling nyaman untuk menempatkan microVM di production adalah lewat Kubernetes. Dengan containerd + plugin microVM, tiap Pod bisa berjalan di dalam microVM sendiri. Kuncinya adalah RuntimeClass:

apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: microvm
handler: firecracker

Lalu Pod meminta isolasi microVM lewat runtimeClassName:

apiVersion: v1
kind: Pod
metadata:
  name: sandbox-a
spec:
  runtimeClassName: microvm
  containers:
    - name: app
      image: docker.io/library/nginx:latest

Konsekuensinya: Pod sandbox-a dijalankan di dalam microVM Firecracker — kernel guest sendiri, isolasi penuh dari node. Ini sama dengan pola firecracker-containerd di episode 11, tapi sekarang diangkat ke API Kubernetes: Pod = microVM.

Keuntungan pola ini di Kubernetes:

• Isolasi per Pod: escape dari container tidak menyentuh node; workload untrusted aman di-schedule bareng workload trusted.
• API standar: developer tetap menulis Pod biasa; runtime yang memutuskan tempat eksekusi.
• Scheduling alami: Kubernetes mengatur penempatan dan density; tiap node menampung microVM sesuai kapasitas.

#Pola Sandbox per User/Job

Dengan Kubernetes + runtime class microvm, pola bisnis yang memakai Firecracker menjadi mudah diwujudkan: sandbox per user atau per job. Setiap pengguna (atau setiap tugas) mendapat microVM sendiri yang terisolasi total:

• Pengguna A mengeksekusi kode → Pod dengan runtimeClassName: microvm → microVM khusus, dihapus setelah selesai.
• Job CI yang menjalankan test → microVM per job, tidak saling mencemari.
• Agent AI yang butuh environment bebas → microVM per session.

Keuntungan dibanding berbagi VM: satu pengguna yang men-download malware atau menghabiskan resource tidak berdampak pada pengguna lain. Ini pola yang sama dengan AWS Lambda MicroVMs (episode 18) — isolasi VM-level per user — sekarang tersedia untuk platform kalian sendiri.

#firectl vs Flintlock vs Kubernetes

Peta perbandingan yang berguna:

Semuanya memakai API Firecracker di bawahnya; yang membedakan adalah tingkat abstraksi dan skala. Mulailah dari firectl untuk belajar, lalu naik ke Flintlock atau Kubernetes saat butuh kontrol terpusat.

#Common Pitfalls

• RuntimeClass tanpa handler: Pod gagal schedule; verifikasi containerd config node.
• firectl memakai kernel berbeda dari jailer: pastikan image dan binary versi konsisten.
• Lupa rate limiter di scale: saat banyak microVM, rate limiter dan cgroup wajib — tanpa itu satu VM merusak tetangga.
• Sandbox per user tanpa quota: batasi vCPU/memori per sandbox dengan ResourceQuota atau limit Pod.
• Image besar: tiap microVM butuh rootfs; image gemuk memperlambat cold start dan menghabiskan disk.

#Penutup

Inti yang harus dibawa pulang:

• firectl menyederhanakan launch microVM jadi satu perintah — ideal untuk belajar.
• Flintlock menawarkan MicroVM as a Service dengan API terpusat.
• Kubernetes + RuntimeClass microvm menjadikan Pod = microVM, isolasi per Pod.
• Pola sandbox per user/job memakai isolasi VM-level untuk workload untrusted.
• Skala abstraksi: firectl → firecracker-containerd → Flintlock → Kubernetes.

Di episode 13 selanjutnya kita akan memperdalam keamanan jaringan: Network Isolation & Filtering — membangun bridge dan TAP per guest, memfilter traffic dengan eBPF dan iptables, memblokir outbound yang tidak perlu, serta tuning virtio-net dengan vhost, TSO/GSO, dan ukuran ring untuk performa puncak.