Belajar Kata Containers - Konfigurasi Runtime (kata-configuration.toml)

#Pendahuluan

Pod Kata pertama kalian sudah berjalan di episode 4. Sekarang waktunya memahami mengapa ia berjalan seperti itu. Di balik setiap microVM ada satu file konfigurasi: /etc/kata-containers/configuration.toml. File ini menentukan hypervisor mana yang dipakai, guest kernel mana yang di-boot, berapa banyak resource yang dialokasikan, dan bagaimana agent berperilaku.

Episode 5 membedah file ini bagian demi bagian. Kemampuan membaca dan mengubah configuration.toml membedakan operator yang sekadar menjalankan Kata dari operator yang bisa men-tuning Kata untuk workload spesifik — dan akan menjadi dasar penting saat kita membahas tuning performa di episode 20.

#Struktur Umum configuration.toml

Instalasi Kata menyediakan beberapa file konfigurasi, satu per backend:

• /etc/kata-containers/configuration.toml — default (QEMU).
• /etc/kata-containers/configuration-clh.toml — untuk Cloud Hypervisor.
• /etc/kata-containers/configuration-fc.toml — untuk Firecracker.

Semua file mengikuti struktur yang sama: satu bagian [hypervisor.*] untuk konfigurasi VMM, satu bagian [agent.kata] untuk konfigurasi Kata agent, dan bagian-bagian [runtime] untuk perilaku runtime. Mari bedah bagian yang paling sering disentuh:

/etc/kata-containers/configuration.toml

# Hypervisor configuration
[hypervisor.qemu]
path = "/usr/bin/qemu-system-x86_64"
kernel = "/usr/share/kata-containers/vmlinux.container"
image = "/usr/share/kata-containers/kata-containers.img"
 
machine_type = "pc"
 
# Default memory and CPU for the VM
default_memory = 2048
default_vcpus = 1
 
# Kernel parameters passed to the guest kernel
kernel_params = ""
 
# Agent configuration
[agent.kata]
kernel_modules = []
 
# Runtime configuration
[runtime]
enable_debug = false
sandbox_cgroup_only = false

path menunjuk ke binary hypervisor, kernel ke guest kernel, dan image ke guest image (initrd atau filesystem root guest). Tiga nilai inilah yang menghidupkan microVM.

#Hypervisor dan Guest Kernel

#Menentukan Backend

Bagian [hypervisor.qemu] mengontrol VMM. Nama bagian menentukan hypervisor mana yang dipakai — [hypervisor.qemu], [hypervisor.clh], [hypervisor.firecracker]. RuntimeClass kata-clh (episode 4) menunjuk ke file configuration-clh.toml yang bagian hypervisornya adalah [hypervisor.clh].

Pilihan hypervisor berdampak besar pada fitur dan kecepatan — topik penuh di episode 6. Di file ini, kalian bisa menyesuaikan parameter tambahan:

Parameter VMM tambahan

[hypervisor.qemu]
firmware = ""
enable_vhost_user_store = false
valid_hypervisor_paths = [
    "/usr/bin/qemu-system-x86_64",
    "/usr/libexec/qemu-kvm"
]
enable_iothreads = true

enable_iothreads = true mengizinkan QEMU memakai thread terpisah untuk I/O — mengurangi blokade antar device. valid_hypervisor_paths memberi daftar path alternatif agar runtime bisa menemukan binary di berbagai distro.

#Guest Kernel

Guest kernel adalah kernel Linux terpisah yang di-boot di dalam microVM. Field kernel menunjuk ke file kernel ini. Kata menyediakan varian: vmlinux (ELF uncompressed, boot lebih cepat) dan vmlinuz (compressed). Untuk confidential computing (episode 11), kernel dengan dukungan TDX/SEV dipakai.

#Memory, CPU, dan Resource Limits

#Konfigurasi Default di File

Saat pod tidak menyebut limits, Kata memakai nilai default dari file:

Konfigurasi resource default

default_memory = 2048
default_memoryslots = 2
default_vcpus = 1
 
# Enable/disable memory hotplug
enable_memory_hotplug = true

default_memory = 2048 berarti 2 GiB RAM dialokasikan untuk microVM, dan default_vcpus = 1 berarti satu vCPU. Ketika pod menyebut resources.limits, nilai pod menimpa default ini.

#Bagaimana Limit Pod Diterapkan

Pod Kata menerjemahkan request/limit Kubernetes langsung ke alokasi microVM. Jika pod menyebut:

spec:
  containers:
    - name: app
      resources:
        requests:
          memory: 512Mi
          cpu: 500m
        limits:
          memory: 1Gi
          cpu: "1"

microVM yang dihasilkan akan dialokasikan sekitar 1 GiB memory dan 1 vCPU — mencerminkan limit, bukan request. Inilah yang dibahas di episode 10 sebagai "resource limits yang diterapkan di VM": pod tidak lagi bersaing cgroup di host, melainkan diberi porsi hardware virtual yang jelas.

#Block Device Driver: virtio-blk vs virtio-scsi

Salah satu parameter yang paling berdampak pada I/O adalah pilihan block device driver. Dua opsi utama:

• virtio-blk: sederhana, satu device per disk, overhead rendah. Cocok untuk workload umum.
• virtio-scsi: lebih kompleks, memungkinkan banyak disk per device, dan mendukung operasi SCSI seperti persistent reservation — dibutuhkan untuk cluster filesystem dan sebagian workload database.

Pengaturan di file konfigurasi:

Pilihan block device driver

[hypervisor.qemu]
# Support block device driver: virtio-blk or virtio-scsi
block_device_driver = "virtio-blk"
 
# Use virtio-fs for shared filesystems (episode 8)
shared_fs = "virtio-fs"
 
# Whether to use SCSI controller
enable_virtio_mem = false

block_device_driver = "virtio-blk" memilih virtio-blk sebagai default. Untuk workload yang butuh virtio-scsi, ubah nilainya menjadi "virtio-scsi" dan pastikan guest kernel mendukungnya.

Keputusan ini biasanya jarang diubah setelah production berjalan, karena memengaruhi cara guest melihat disk. Uji di environment lab sebelum diterapkan ke cluster.

#kernel_params: Menyesuaikan Guest Kernel

Field kernel_params meneruskan parameter ke guest kernel saat boot. Ini pintu masuk untuk men-tuning guest tanpa membangun kernel baru:

Menambahkan parameter kernel guest

kernel_params = "console=ttyS0 quiet net.ifnames=0"
 
# Example: enable swap inside the guest
# kernel_params = "swapaccount=1"

kernel_params = "console=ttyS0 quiet net.ifnames=0" mengatur konsol serial untuk debugging dan menonaktifkan penamaan interface yang prediktif. Parameter lain yang berguna: page_poison=1 untuk keamanan memori, atau nokaslr untuk debugging dengan symbol resolution yang stabil.

Perhatikan bahwa mengubah kernel_params memengaruhi semua pod di node yang memakai konfigurasi ini — nilainya diterapkan ke setiap microVM yang di-boot. Untuk kebutuhan per-pod, gunakan pod annotations yang didukung Kata.

#Agent Configuration

Bagian [agent.kata] mengontrol perilaku Kata agent di dalam guest:

Konfigurasi Kata agent

[agent.kata]
# When enabled, kernel modules can be loaded inside the guest
kernel_modules = []
 
# Enable debug logging inside the guest
debug_console_enabled = false
 
# Whether the agent can use vsock for communication
use_vsock = true

use_vsock = true mengaktifkan komunikasi shim-agent lewat vsock — mekanisme yang kita bahas di episode 2. debug_console_enabled = true akan memberi kalian akses console ke dalam guest, sangat berguna saat troubleshooting di episode 12.

#Memverifikasi Konfigurasi

Untuk melihat konfigurasi yang sedang aktif dipakai runtime:

kata-runtime kata-env
kata-runtime version

kata-runtime kata-env menampilkan konfigurasi runtime yang efektif: path hypervisor, kernel, image, dan nilai default — dalam format JSON. Ini cara tercepat memastikan file konfigurasi yang kalian ubah benar-benar terbaca oleh runtime.

#Penutup

Inti yang harus dibawa pulang:

• configuration.toml mengontrol hypervisor, kernel, resource, dan agent per backend.
• configuration-clh.toml dan configuration-fc.toml untuk backend Cloud Hypervisor dan Firecracker.
• default_memory dan default_vcpus dipakai saat pod tidak menyebut limits.
• Limit pod Kubernetes diterjemahkan langsung ke alokasi microVM.
• block_device_driver memilih virtio-blk atau virtio-scsi.
• kernel_params meneruskan argumen ke guest kernel.
• kata-runtime kata-env memverifikasi konfigurasi yang efektif.

Di episode 6 selanjutnya kita akan membandingkan hypervisor backends — QEMU sebagai default dengan kompatibilitas luas, Cloud Hypervisor yang modern dan cepat, Firecracker yang minimalis, dan Dragonball yang built-in di runtime Rust. Kalian akan belajar kapan memilih masing-masing dan trade-off fitur versus kecepatannya.