Belajar Kata Containers - Kata Agent & Image Management

#Pendahuluan

Di episode 2 kalian mengenal Kata agent sebagai proses pertama yang lahir di dalam guest. Episode 9 mengupas perannya secara mendalam: apa saja yang sebenarnya dia lakukan, bagaimana ia mengelola container di dalam microVM, dan bagaimana image sampai ke guest. Ini adalah episode yang menjelaskan mengapa Kata terasa seperti "container", padahal di belakangnya ada mesin virtual.

Pemahaman tentang Kata agent juga praktis: ketika kubectl exec berperilaku aneh atau image gagal ditemukan di guest, akar masalahnya biasanya ada di lapisan agent ini.

#Peran Kata Agent di Dalam Guest

#Proses Pertama di Guest

Saat microVM boot, guest kernel menjalankan proses pertama: Kata agent. Ia adalah analog containerd di dalam guest — satu-satunya proses yang diberi kewenangan mengelola container di dalam microVM. Semua permintaan dari host (lewat shim) masuk ke agent melalui vsock.

Tugas utama Kata agent:

• Membuat dan menghapus container di dalam guest.
• Menjalankan proses aplikasi (fork + exec di dalam guest).
• Mengelola mount dan volume di dalam guest.
• Meneruskan signal (SIGTERM, SIGKILL) dari host ke proses guest.
• Melaporkan status dan exit code kembali ke host.
• Menangani exec (interactive shell ke container di guest).

#Mengelola Container di Dalam Guest

Ada dua gaya agent dalam mengelola container di guest:

• Agent-native: agent mengelola container langsung, tanpa runtime tambahan di guest. Ini arah modern — lebih ringan dan lebih cepat, didukung penuh oleh runtime-rs.
• runc di dalam guest: pendekatan lama di mana agent memakai runc di dalam guest untuk membuat container. Masih dipakai pada beberapa konfigurasi, terutama untuk kompatibilitas dengan fitur tertentu.

Perbedaan ini penting untuk dipahami karena memengaruhi overhead: container di dalam guest yang dibuat oleh agent-native tidak menumpuk proses ekstra, sementara runc-in-guest menambah satu lapisan proses.

#Exec dan Interactive Shell

kubectl exec adalah alur yang menarik untuk dibedah. Perintah ini tidak langsung menyentuh proses guest — ia melewati beberapa lapisan:

1. kubelet menerima permintaan kubectl exec dan meneruskan ke containerd.
2. containerd memanggil shim Kata.
3. Shim meneruskan permintaan ke Kata agent lewat vsock.
4. Agent membuat proses baru di dalam guest dan menghubungkannya ke terminal.

Konsekuensinya: kubectl exec di pod Kata sedikit lebih lambat daripada pod runc karena melewati jalur vsock. Untuk terminal interaktif, pastikan TTY diaktifkan:

kubectl exec -it kata-demo -- sh

kubectl exec -it kata-demo -- sh masuk ke shell container di dalam guest. Semua perintah yang dijalankan berjalan di guest, bukan di host — kalian bisa membuktikannya dengan melihat proses yang berjalan.

#Image Management: Bagaimana Image Sampai ke Guest

#Strategi 1: Pull di Host, Mount ke Guest (Snapshotter)

Strategi default: containerd menarik image di host, lalu Kata menyediakan rootfs image ke guest. Persis seperti yang kita bahas di episode 8 — rootfs menjadi virtio-blk device atau dibagikan via virtio-fs.

Keuntungan strategi ini:

• Satu image cache untuk semua runtime: image yang sudah ditarik untuk pod runc bisa langsung dipakai pod Kata.
• Pull yang lebih aman: image diverifikasi di host dengan mekanisme containerd yang matang.
• Lebih hemat resource: guest tidak perlu berkomunikasi dengan registry.

Kekurangannya: rootfs perlu dipindahkan host → guest lewat virtio, dan ada biaya pemrosesan snapshotter tambahan. Untuk image besar, waktu ini terasa di startup pod.

#Strategi 2: Pull Langsung di Guest

Alternatifnya, guest menarik image langsung dari registry — melewati containerd host sepenuhnya. Kata agent melakukan pull di dalam guest dan menyimpan image di disk guest.

Keuntungannya: guest punya salinan image mandiri, dan rootfs tidak perlu dipindahkan. Kekurangannya: cache image host tidak dipakai, pull bisa lebih lambat (registry diakses guest), dan setiap pod menarik image sendiri jika tidak di-cache.

#Kapan Memilih

Kebanyakan deployment memakai strategi 1 karena memanfaatkan ekosistem containerd dan cache yang sudah ada. Strategi 2 relevan untuk environment dengan isolasi yang sangat ketat atau kebutuhan image tidak meninggalkan jejak di host.

Memeriksa image yang tersedia di node:

crictl images

crictl images menampilkan image yang sudah ditarik containerd di host. Ini juga cara cepat memverifikasi bahwa image pod Kata benar-benar ada di host sebelum didiagnosis lebih lanjut.

#Menangani Image Pull Issue

Ketika pod Kata gagal karena image, urutan diagnosis yang biasa dilakukan:

1. kubectl describe pod — lihat event dan pesan error.
2. crictl images — pastikan image sudah ditarik di host.
3. crictl inspect <container-id> — periksa status container di sisi CRI.
4. Log di /var/log/kata-containers/ — jika error di lapisan guest.

Kita akan membahas debugging menyeluruh di episode 12, tapi satu prinsip penting sudah bisa dipetik sekarang: masalah image biasanya terlihat dulu di lapisan containerd sebelum menyentuh guest. Selalu mulai diagnosis dari sana.

#Penutup

Inti yang harus dibawa pulang:

• Kata agent adalah proses pertama di guest dan mengelola semua container di dalamnya.
• Agent menangani create, exec, mount, dan signal — semua lewat vsock dari shim.
• Gaya pengelolaan: agent-native (modern) vs runc di dalam guest.
• Image di-pull di host lalu rootfs disediakan ke guest (default), atau di-pull langsung di guest.
• crictl images memverifikasi image di host sebelum diagnosa lebih lanjut.
• kubectl exec melewati jalur shim → vsock → agent → guest.

Di episode 10 selanjutnya kita akan membahas GPU & device passthrough — VFIO passthrough untuk workload AI/ML, peran NRI (Node Resource Interface), integrasi autoscaling KEDA, dan bagaimana resource limits diterapkan di dalam VM.