Belajar Kata Containers - Sejarah, Latar Belakang & Mengapa Membutuhkannya

#Pendahuluan

Selamat datang kembali di series Belajar Kata Containers! Di episode 0 kalian sudah menyiapkan node dengan KVM, containerd, dan tooling dasar. Sekarang kita mundur sejenak untuk memahami dari mana Kata Containers berasal dan masalah keamanan apa yang sebenarnya dia selesaikan. Tanpa konteks ini, semua perintah kata-runtime dan RuntimeClass di episode-episode berikutnya akan terasa seperti kotak hitam.

Episode 1 membahas tiga hal besar: sejarah lahirnya Kata dari merger dua proyek, filosofi "the speed of containers, the security of VMs", serta siapa saja yang sudah mengadopsinya di production. Mengapa penting? Karena keputusan memakai Kata Containers biasanya lahir dari pemahaman tentang batas keamanan container tradisional.

#Kelahiran Kata Containers: Merger Dua Dunia

#Clear Containers dan runV

Sebelum Kata ada, ada dua pendekatan berbeda untuk mengamankan container. Intel Clear Containers (dari Intel) berfokus pada menjalankan container di dalam virtual machine dengan teknologi KVM/QEMU. Hyper.sh runV (dari perusahaan Hyper.sh) melakukan hal serupa dengan pendekatan yang sedikit berbeda namun tujuan yang sama: container dengan isolasi VM.

Kedua proyek ini menyadari bahwa mereka sedang mengejar masalah yang sama. Pada Desember 2017, keduanya bergabung menjadi satu proyek bernama Kata Containers, diumumkan di KubeCon Austin. Kata berarti "kata-kata" — sebuah metafora bahwa proyek ini menyatukan dua bahasa yang berbeda menjadi satu yang dipahami semua pihak.

#OpenInfra Foundation

Kata Containers kemudian menjadi proyek di bawah OpenInfra Foundation — payung yang sama dengan OpenStack. Keanggotaan di foundation ini berarti pengembangan Kata tidak dikendalikan satu vendor: Intel, Hyper.sh, dan kemudian banyak perusahaan lain berkontribusi bersama. Inilah salah satu alasan Kata dipercaya untuk production — tidak ada satu pihak yang bisa menghentikan pengembangan secara sepihak.

#Evolusi ke Runtime Rust

Sejak seri 3.x, perubahan arsitektural paling signifikan mulai berjalan: runtime utama berpindah dari Go ke Rust, dengan implementasi bernama runtime-rs. Perpindahan ini membawa keunggulan keamanan memori Rust, kecepatan, dan konsumsi resource yang lebih rendah. Puncaknya terjadi di Kata Containers 4.0.0 yang dirilis 22 Juli 2026: runtime Rust menjadi default dengan arsitektur Rust-first. Detail lengkapnya kita bedah di episode 17.

#Mengapa Membutuhkan Kata Containers

#Batas Keamanan Container Tradisional

Container berbasis runc berbagi kernel host. Namespace dan cgroups memberikan isolasi, tapi batas itu adalah perangkat lunak — satu kernel, ribuan proses, dan satu celah kernel berarti semua tenant terdampak. Bayangkan gedung apartemen dengan satu pondasi yang sama: nyaman dan murah, tapi satu retakan di pondasi dirasakan semua penghuni.

Kata Containers membalik logikanya: setiap pod mendapat kernel sendiri di dalam microVM. Batas isolasi sekarang ada di hardware — hypervisor memisahkan guest kernel dari host kernel. Satu tenant yang kena exploit hanya bisa merusak VM-nya sendiri, bukan seluruh node.

#"The Speed of Containers, the Security of VMs"

Filosofi ini adalah jantung Kata. Container menang di kecepatan dan kemudahan; VM menang di keamanan dan isolasi. Kata merancang seluruh stack agar pod boot dalam 150-300 milidetik — mendekati kecepatan container biasa, tapi dengan isolasi penuh VM:

• Speed of containers: API OCI/CRI yang sama, waktu boot singkat, overhead kecil per pod.
• Security of VMs: kernel guest terpisah, isolasi hardware, dan kompatibilitas dengan confidential computing.

Ini bukan angka marketing. Arsitektur yang dibahas di episode 2 — dari shim sampai guest kernel — dirancang khusus untuk mencapai boot time sekecil itu, termasuk pengurangan yang dilakukan runtime Rust dan optimasi Dragonball.

#Integrasi Mulus dengan Kubernetes

Kata tidak memaksa kalian mengganti tooling. Karena ia mengikuti spesifikasi OCI dan bekerja lewat CRI, Kubernetes mengenalinya sebagai runtime biasa. Pod memakai Kata cukup dengan menetapkan spec.runtimeClassName — objek RuntimeClass yang sudah kalian kenal dari episode 0. Tidak ada perubahan pada Deployment, Service, atau NetworkPolicy.

Untuk mengecek versi runtime yang sedang aktif di node:

kata-runtime version

kata-runtime version menampilkan versi runtime, versi protocol OCI, dan commit build. Nantikan penggunaan penuh perintah ini di episode 3 dan 4.

#Siapa yang Mengadopsi Kata Containers

Adopsi production membuktikan bahwa Kata bukan sekadar riset:

• AKS Pod Sandboxing (Microsoft Azure): Kata Containers sebagai sandboxing bawaan untuk workload untrusted di Azure Kubernetes Service.
• OpenShift Sandboxed Containers (Red Hat): Kata sebagai runtime untuk sandboxed workload di OpenShift.
• AWS EKS: dukungan pada bare-metal nodes untuk workload yang butuh isolasi microVM.
• IBM Cloud dan Alibaba Cloud: penyedia cloud besar yang mengintegrasikan Kata di platform mereka.

Pola yang muncul dari semua adopsi ini sama: workload yang tidak dipercaya atau multi-tenant — sandbox untuk code dari luar, CI/CD yang menjalankan artefak pihak ketiga, dan AI agent yang mengeksekusi tool dari sumber tidak dikenal.

#Praktik: Memeriksa Kesiapan Environment

Cek dulu bahwa semua yang disiapkan di episode 0 masih utuh, karena episode 3 akan langsung memakai semuanya:

ls -l /dev/kvm
kubectl get nodes -o wide
kata-runtime version

ls -l /dev/kvm memastikan akselerasi hardware tersedia, kubectl get nodes -o wide memastikan cluster sehat, dan kata-runtime version memastikan binary runtime sudah terpasang. Jika binary belum ada, jangan khawatir — episode 3 akan menginstallnya secara lengkap.

#Kata vs Pendekatan Lain: Gambaran Awal

Sebagai gambaran, begini posisi Kata di antara pendekatan isolasi lain:

• runc: container biasa, kernel bersama, ringan, batas isolasi software.
• Kata Containers: container dengan microVM, kernel sendiri, isolasi hardware.
• gVisor: userspace kernel sebagai perantara syscall, tanpa hypervisor.
• Firecracker/Cloud Hypervisor: VMM (Virtual Machine Monitor) yang menjadi backend Kata.
• KubeVirt: menjalankan VM native di Kubernetes, bukan container.

Perbandingan mendalam, termasuk kapan memilih gVisor dibanding Kata, akan kita bahas di episode 22.

#Penutup

Inti yang harus dibawa pulang:

• Kata lahir Desember 2017 dari merger Intel Clear Containers dan Hyper.sh runV.
• Proyek dikelola di bawah OpenInfra Foundation, bukan vendor tunggal.
• "The speed of containers, the security of VMs": boot 150-300 ms dengan isolasi hardware.
• Setiap pod Kata punya kernel sendiri; batas isolasi di hardware, bukan software.
• Integrasi Kubernetes mulus lewat OCI, CRI, dan RuntimeClass.
• Diadopsi AKS, OpenShift, AWS EKS, IBM Cloud, dan Alibaba Cloud.

Di episode 2 selanjutnya kita akan membedah konsep dasar dan arsitektur utama Kata Containers — alur dari containerd shimv2 ke VMM ke guest kernel dan Kata agent, komponen seperti containerd-shim-kata-v2, kata-runtime, kata-runtime-rs, dan kata-agent, serta bagaimana virtio dan VFIO menghubungkan host dan guest. Ini adalah fondasi arsitektur yang akan dipakai di semua episode berikutnya.