Belajar Kata Containers - Konsep Dasar & Arsitektur Utama

#Pendahuluan

Di episode 1 kita memahami mengapa Kata Containers ada: isolasi hardware untuk container. Episode 2 menjawab pertanyaan berikutnya: bagaimana arsitekturnya bekerja? Kita akan membedah perjalanan sebuah permintaan membuat pod — dari kubelet sampai proses yang berjalan di dalam microVM — serta mengenal setiap komponen yang terlibat.

Pemahaman arsitektur ini bukan sekadar teori. Ketika pod nanti gagal boot, kalian harus tahu di lapisan mana masalahnya: CRI, shim, VMM, atau Kata agent di dalam guest. Episode 12 tentang troubleshooting akan terasa jauh lebih ringan jika arsitektur ini sudah melekat.

#Alur Utama: Dari Kubelet ke MicroVM

Perjalanan sebuah pod Kata melalui beberapa lapisan. Ini jalur lengkapnya:

kubelet memanggil containerd lewat CRI (gRPC) untuk membuat pod sandbox.
containerd mendeteksi bahwa pod memakai RuntimeClass Kata, lalu memanggil shim Kata — bukan shim runc biasa.
containerd-shim-kata-v2 berbicara dengan runtime Kata dan meminta VMM membangun microVM.
VMM (QEMU, Cloud Hypervisor, Firecracker, atau Dragonball) mem-boot guest kernel.
Di dalam guest, proses pertama yang dijalankan adalah Kata agent — proses yang mengelola container di dalam VM.
Kata agent menerima permintaan dari shim untuk membuat container, menyiapkan filesystem, dan memulai proses aplikasi.

Kata kunci dari alur ini: containerd shimv2 → Kata runtime → VMM → guest kernel → Kata agent.

#Mengapa Pola Ini Penting

Host tidak pernah menjalankan proses aplikasi secara langsung. Proses aplikasi lahir di dalam guest kernel, dikelola oleh Kata agent, dan diisolasi oleh VMM. Host hanya melihat satu proses VMM per microVM — itulah mengapa isolasinya setara VM, sementara API yang dilihat Kubernetes tetap API container.

Konsekuensi menariknya: kubelet, containerd, dan CNI bekerja persis seperti biasa. Kata menyamar sebagai runtime container standar di mata Kubernetes. Inilah yang membuat integrasi (episode 4) begitu mulus.

#Komponen Utama Kata Containers

#containerd-shim-kata-v2

containerd-shim-kata-v2 adalah implementasi shim v2 untuk containerd. Ia menggantikan dua proses yang dipakai arsitektur container lama (shim + runtime) dengan satu proses. Tugasnya: menerjemahkan permintaan CRI dari containerd menjadi instruksi yang dipahami Kata, dan menjaga koneksi antara containerd dengan microVM.

#kata-runtime dan kata-runtime-rs

kata-runtime adalah runtime OCI yang mengelola seluruh lifecycle microVM. Ia bisa digunakan mandiri (standalone) dengan containerd + CRI plugin, atau lewat shim v2. Di versi modern, kata-runtime-rs — versi Rust — adalah runtime utama dan menjadi default sejak Kata 4.0.0. Keduanya menyediakan subcommand seperti check, list, dan exec yang akan sering kalian pakai.

#kata-agent

kata-agent adalah proses yang berjalan di dalam guest. Ia mirip peran containerd di host, tapi terbatas di dalam microVM: menerima permintaan dari shim untuk membuat container, mengelola mount, eksekusi proses, signal, dan lifecycle container di dalam guest. Karena ia satu-satunya pintu masuk ke guest, keamanannya menjadi kritis (episode 13).

#kata-deploy dan Hypervisor Plugins

kata-deploy adalah tooling yang mengotomatiskan instalasi Kata ke cluster Kubernetes. Ia bekerja sebagai DaemonSet atau Helm chart dan menangani binary runtime, shim, hypervisor, serta guest kernel di setiap node. VMM sendiri adalah plugin yang dipilih lewat konfigurasi: QEMU, Cloud Hypervisor, Firecracker, atau Dragonball.

#Bagaimana Host dan Guest Berkomunikasi

MicroVM tidak bisa berbagi memori dengan host begitu saja. Komunikasi antara shim (di host) dan Kata agent (di guest) berjalan lewat vsock — mekanisme komunikasi virtual socket yang disediakan hypervisor, tanpa melalui jaringan fisik. Melalui vsock ini, shim mengirim permintaan membuat container, dan agent merespons status eksekusi.

Untuk perangkat I/O, Kata memakai dua mekanisme utama:

virtio: standar paravirtualisasi di mana guest tahu bahwa ia sedang divirtualisasi dan bekerja sama dengan VMM. Virtio-blk untuk disk, virtio-net untuk jaringan, virtio-fs untuk filesystem sharing.
VFIO: passthrough perangkat fisik dari host ke guest — GPU atau NIC yang dilepas dari host dan diakses guest secara langsung. Ini dibahas mendalam di episode 8 dan 10.

Bayangkan virtio sebagai karyawan paravirtual yang tahu tugasnya dikurangi perangkat virtual; VFIO adalah menyerahkan perangkat fisik asli kepada guest.

#Arsitektur Berdasarkan Platform

Kata Containers didesain lintas arsitektur:

x86_64: paling umum, didukung penuh dengan KVM (VT-x).
aarch64: ARM64 dengan ARM Virtualization Extensions, dipakai di edge dan server ARM.
ppc64le dan s390x: IBM POWER dan IBM Z, untuk environment enterprise.

Setiap platform punya dukungan hypervisor yang berbeda-beda — s390x misalnya memakai KVM dengan karakteristik berbeda dari x86. Selalu periksa dokumentasi rilis untuk matriks dukungan per arsitektur.

#Memverifikasi Komponen yang Ada

Sebelum lanjut, pastikan komponen-komponen berikut terpasang di node:

Cek komponen Kata

which containerd-shim-kata-v2
which kata-runtime
kata-runtime version

which containerd-shim-kata-v2 dan which kata-runtime memastikan binary berada di PATH. Di instalasi tarball, keduanya biasanya berada di /usr/local/bin. Jika belum ada, episode 3 akan menginstall semuanya.

Tip

Kunci memahami arsitektur Kata adalah mengingat satu kalimat: host tidak menjalankan aplikasi, ia menjalankan microVM. Semua keputusan arsitektur — dari vsock sampai Kata agent — mengalir dari prinsip itu.

#Penutup

Inti yang harus dibawa pulang:

Alur lengkap: containerd shimv2 → Kata runtime → VMM → guest kernel → Kata agent.
containerd-shim-kata-v2 menggantikan peran shim + runtime klasik.
kata-runtime (dan kata-runtime-rs versi Rust) mengelola lifecycle microVM.
kata-agent berjalan di dalam guest dan mengelola container dari dalam.
Host dan guest berkomunikasi lewat vsock; I/O lewat virtio atau VFIO.
Arsitektur didukung di x86_64, aarch64, ppc64le, dan s390x.

Di episode 3 selanjutnya kita akan melakukan instalasi & setup Kata Containers — mengunduh release tarball, menjalankan kata-deploy via Helm chart, membangun dari source, lalu memverifikasi instalasi dengan kata-runtime check dan kata-runtime kata-check. Semua arsitektur yang barusan kita pelajari akan mulai hidup di node kalian.