Belajar Kata Containers - Debugging & Troubleshooting

#Pendahuluan

Sampai episode 11, semua berjalan mulus di lab. Episode 12 bersiap untuk saat-saat semuanya tidak mulus — dan percayalah, itu akan terjadi. Karena pod Kata punya lapisan ekstra (shim, VMM, guest kernel, agent), troubleshooting-nya juga punya lapisan ekstra. Mengetahui cara berpikir terstruktur akan menyelamatkan kalian berjam-jam menebak-nebak.

Episode 12 membangun mental model diagnosis: mulai dari Kubernetes (paling luar), turun ke containerd, ke shim, ke VMM, hingga guest. Kita juga membahas kasus-kasus nyata: pod pending, OOM di dalam VM, image pull yang gagal, dan konfigurasi hypervisor yang salah.

#Strategi Diagnosis: Dari Luar ke Dalam

Ketika pod Kata bermasalah, ikuti urutan ini — jangan melompat ke dalam guest lebih dulu:

1. Kubernetes: kubectl describe pod dan kubectl get events — status dan alasan di level cluster.
2. containerd: crictl ps dan crictl inspect — apa yang terjadi di sisi CRI.
3. Runtime/shims: kata-runtime list dan kata-runtime state — sandbox yang diketahui runtime.
4. Log Kata: /var/log/kata-containers/ — detail dari shim, VMM, dan agent.
5. Di dalam guest: kata-runtime exec dan debug console — melihat langsung apa yang terjadi di microVM.

Mulai selalu dari lapisan luar. Sebagian besar masalah — image, quota, scheduling — terlihat di lapisan pertama dan tidak perlu menyentuh guest.

#Toolkit Kata untuk Debugging

#kata-runtime list dan state

kata-runtime list menampilkan sandbox microVM yang sedang dikelola runtime di node:

kata-runtime list

kata-runtime list menampilkan tabel sandbox: ID, versi CRI, status, dan PID hypervisor. Ini jawaban cepat untuk pertanyaan "apakah microVM benar-benar ada dan berjalan?".

kata-runtime state menampilkan detail status sebuah sandbox tertentu:

kata-runtime state <sandbox-id>

kata-runtime state <sandbox-id> menampilkan state lengkap: status sandbox, PID proses, rootfs, dan versi. Jika sandbox tidak ditemukan di sini padahal pod mengaku berjalan, ada ketidaksesuaian antara containerd dan runtime — mulai curigai masalah pada shim.

#Log Kata di /var/log/kata-containers/

Semua komponen Kata menulis log ke direktori /var/log/kata-containers/. File log utama:

ls -la /var/log/kata-containers/
tail -f /var/log/kata-containers/shim.log

tail -f /var/log/kata-containers/shim.log menampilkan log shim secara real-time — tempat pertama error VMM dan agent terlihat. Untuk masalah hypervisor, log QEMU/CH juga berada di direktori ini.

Perhatikan bahwa level debug default rendah. Untuk log yang lebih detail, aktifkan debug di konfigurasi (episode 5):

/etc/kata-containers/configuration.toml

[runtime]
enable_debug = true
enable_debug_console = true

enable_debug = true memperbanyak log runtime, dan enable_debug_console = true mengaktifkan console ke guest untuk kata-runtime exec — pasangan yang sangat membantu saat troubleshooting.

#kata-runtime exec dan Debug Console

Untuk melihat langsung ke dalam guest:

kata-runtime list
sudo kata-runtime exec <sandbox-id> bash

kata-runtime exec <sandbox-id> bash memberikan shell di dalam microVM. Dari sini kalian bisa memeriksa proses, mount, jaringan, dan memori di dalam guest — persis seperti nsenter untuk container, tapi untuk VM.

#Kasus 1: Pod Pending atau ContainerCreating

Gejala: pod stuck di ContainerCreating tanpa progress. Diagnosis berurutan:

kubectl describe pod kata-demo
kubectl get events --sort-by=.lastTimestamp | tail -20

kubectl describe pod menampilkan event seperti FailedCreatePodSandBox dengan pesan yang menunjuk akar masalah. Penyebab yang paling sering:

• KVM tidak tersedia: microVM gagal boot. Cek /dev/kvm di node.
• Handler tidak cocok: RuntimeClass menyebut handler yang tidak dikenal containerd.
• Resource node habis: VM tidak bisa dialokasikan.

Jika event tidak jelas, periksa log shim yang biasanya berisi error QEMU/KVM:

journalctl -u containerd -n 100 | grep -i kata
tail -50 /var/log/kata-containers/shim.log

journalctl -u containerd -n 100 | grep -i kata menampilkan log containerd terkait Kata. Kombinasi event Kubernetes + log containerd + log shim biasanya sudah cukup untuk menemukan akar masalah.

#Kasus 2: OOM di Dalam VM

Gejala: proses di guest terbunuh meskipun node punya memori cukup. Ini bedanya dengan OOM container biasa: yang kehabisan memori adalah microVM, bukan node.

Karena limit pod menentukan ukuran VM (episode 5), OOM di guest biasanya berarti VM terlalu kecil untuk workload. Diagnosis:

kata-runtime list
sudo kata-runtime exec <sandbox-id> dmesg | grep -i "out of memory"
sudo kata-runtime exec <sandbox-id> cat /sys/fs/cgroup/memory.events

kata-runtime exec <sandbox-id> dmesg | grep -i "out of memory" menampilkan catatan OOM di kernel guest. cat /sys/fs/cgroup/memory.events menampilkan counter oom — kalau oom_count naik, workload memang melewati batas VM.

Solusinya: naikkan memory limit pod, atau pastikan request/limit sesuai kebutuhan aplikasi. Ingat dari episode 5 — nilai di guest mencerminkan limit pod.

#Kasus 3: Image Pull Gagal

Dari episode 9 kita tahu image dipull di host lalu disediakan ke guest. Gejala image pull gagal biasanya terlihat di event pod. Periksa di sisi host:

crictl images | grep <nama-image>
crictl pull <nama-image>

crictl images | grep <nama-image> memverifikasi image di cache host. Jika pull gagal di containerd, masalahnya di registry/credentials — bukan di Kata. Perluas dengan kubectl describe pod untuk melihat pesan ErrImagePull atau ImagePullBackOff.

Jika image ada di host tapi pod tetap gagal, baru curigai lapisan Kata: rootfs image yang tidak bisa disediakan ke guest, atau snapshotter yang tidak kompatibel.

#Kasus 4: Misconfiguration Hypervisor

Gejala: pod gagal dengan error yang menyebut QEMU, KVM, atau device. Ini biasanya konfigurasi hypervisor yang salah:

• valid_hypervisor_paths tidak menyertakan path binary yang ada.
• kernel atau image menunjuk file yang tidak ada.
• Backend dipilih di RuntimeClass tapi file konfigurasi (mis. configuration-fc.toml) tidak ada.

Verifikasi konfigurasi yang sedang efektif:

kata-runtime kata-env | grep -E "(path|kernel|image)"

kata-runtime kata-env | grep -E "(path|kernel|image)" menampilkan path binary hypervisor, guest kernel, dan guest image yang sedang dipakai. Jika salah satu tidak ada di filesystem, itu akar masalahnya.

#Penutup

Inti yang harus dibawa pulang:

• Diagnosis dari luar ke dalam: Kubernetes → containerd → shim → VMM → guest.
• kata-runtime list dan kata-runtime state memeriksa sandbox dari sisi runtime.
• Log Kata di /var/log/kata-containers/ — aktifkan debug untuk detail lebih banyak.
• kata-runtime exec membuka shell di dalam guest untuk pemeriksaan langsung.
• OOM di guest berbeda dari OOM cgroup: VM yang kehabisan memori, bukan node.
• kata-runtime kata-env memverifikasi konfigurasi hypervisor yang efektif.

Di episode 13 selanjutnya kita akan membahas security model & trust boundary — pertanyaan "do you trust the guest?", analisis CVE-2026-24834 yang menyerang guest root via pmem/DAX, serta praktik hardening: minimal device, non-root, seccomp, dan update rutin. Inilah episode yang menjelaskan batas keamanan sebenarnya dari Kata.