Belajar Kata Containers - RuntimeClass & Workload di Kubernetes

#Pendahuluan

Di episode 3 kalian sudah menginstall Kata dan menyiapkan RuntimeClass kata. Episode 4 adalah momen yang paling memuaskan: menjalankan pod pertama dengan isolasi microVM. Tapi sebelum itu, kita perlu memahami RuntimeClass secara utuh — karena di cluster production, kalian akan berhadapan dengan beberapa RuntimeClass sekaligus, masing-masing untuk backend hypervisor yang berbeda.

Kalian juga akan melihat sendiri bukti paling meyakinkan bahwa isolasi benar-benar terjadi: proses aplikasi tidak terlihat di host, melainkan di dalam microVM. Setelah episode ini, konsep "the speed of containers, the security of VMs" bukan lagi slogan, melainkan sesuatu yang kalian buktikan dengan perintah ps.

#Memahami RuntimeClass Kata

#Nama-Nama RuntimeClass Standar

Kata menyediakan beberapa RuntimeClass yang umum dipakai, masing-masing menunjuk ke backend VMM berbeda:

• kata: backend QEMU — default, kompatibilitas terluas.
• kata-clh: backend Cloud Hypervisor — modern dan cepat untuk workload umum.
• kata-fc: backend Firecracker — minimalis, cocok untuk sandbox ringan.
• kata-qemu-coco-dev: backend QEMU dengan dukungan confidential containers (TDX/SEV-SNP), dipakai untuk workload yang butuh attestation.

Nama-nama ini bukan magic — masing-masing adalah entri RuntimeClass yang handler-nya menunjuk ke konfigurasi containerd. Lihat apa yang sudah terdaftar di cluster kalian:

kubectl get runtimeclass
kubectl get runtimeclass kata -o yaml

kubectl get runtimeclass menampilkan daftar RuntimeClass yang dikenal cluster. kubectl get runtimeclass kata -o yaml menampilkan detail — termasuk handler: kata yang harus cocok dengan nama runtime di containerd.

#Bagaimana Kubernetes Memilih Runtime

Alur pemilihan runtime mengikuti rantai yang sudah dibangun di episode 2 dan 3:

1. Pod menyebut spec.runtimeClassName: kata.
2. kubelet memvalidasi bahwa RuntimeClass tersebut ada.
3. kubelet meneruskan handler ke containerd saat membuat sandbox.
4. containerd mencocokkan handler dengan blok runtimes di config.toml.
5. containerd memanggil containerd-shim-kata-v2, dan microVM lahir.

Jika handler tidak ditemukan, Kubernetes menolak pod dengan error failed to find runtime handler. Inilah mengapa konfigurasi containerd (episode 3) dan nama handler harus konsisten.

#Menjalankan Pod Pertama dengan Kata

#Manifes Sederhana

Pod dengan Kata terlihat seperti pod biasa, dengan satu perbedaan: spec.runtimeClassName. Buat file pod-kata.yaml:

apiVersion: v1
kind: Pod
metadata:
  name: kata-demo
  labels:
    app: kata-demo
spec:
  runtimeClassName: kata
  containers:
    - name: app
      image: nginx:alpine
      ports:
        - containerPort: 80

spec.runtimeClassName: kata adalah satu-satunya perbedaan dari pod biasa. Terapkan dan tunggu pod menjadi Running:

kubectl apply -f pod-kata.yaml
kubectl get pod kata-demo -w

kubectl get pod kata-demo -w menampilkan status pod secara real-time. Yang menarik: pod Kata biasanya menampilkan status ContainerCreating lebih lama sesaat — karena microVM sedang di-boot — tapi secara keseluruhan tetap cepat, sesuai klaim boot 150-300 ms.

#Pod Sandbox dan App Container dalam Satu MicroVM

Satu detail arsitektur yang penting: pod sandbox dan app container berbagi satu microVM. Di Kata, sebuah pod adalah satu microVM, dan container-container di dalam pod adalah container-container di dalam guest. Sandbox (pause container) dan app container lahir di guest yang sama, dikelola oleh Kata agent.

Untuk melihat hubungan ini, periksa container dan sandbox dari sisi containerd:

crictl pods
crictl ps

crictl pods menampilkan sandbox pod, dan crictl ps menampilkan container yang berjalan. Keduanya harus menampilkan pod kata-demo dalam kondisi normal — dari perspektif CRI, semuanya tampak seperti runtime container biasa.

#Membuktikan Isolasi: Proses di Host vs di Guest

#Di Host: Hanya VMM

Ini momen pembuktian yang paling menarik. Cari proses aplikasi di host:

ps aux | grep nginx
pgrep -f nginx

ps aux | grep nginx di host harus tidak menemukan proses nginx. Yang ada di host hanyalah proses VMM — satu proses per microVM. Lihatlah:

ps aux | grep -E "(qemu|cloud-hypervisor|firecracker)"

ps aux | grep -E "(qemu|cloud-hypervisor|firecracker)" menampilkan satu proses VMM yang membungkus seluruh microVM pod kata-demo. Proses nginx tidak terlihat di host karena ia lahir di dalam guest kernel.

#Di Guest: Proses Terlihat

Untuk melihat proses di dalam guest, kita perlu masuk ke guest. Kata menyediakan kata-runtime exec untuk menjalankan perintah di dalam microVM. Ambil ID sandbox dari kata-runtime list:

kata-runtime list
sudo kata-runtime exec <sandbox-id> ps aux

kata-runtime list menampilkan sandbox yang sedang berjalan beserta ID-nya. kata-runtime exec <sandbox-id> ps aux menjalankan ps di dalam guest — di sinilah kalian akan melihat proses nginx, bersama dengan proses Kata agent dan proses sistem guest.

#Common Pitfalls

Beberapa masalah yang paling sering ditemui saat menjalankan pod Kata pertama:

• Handler tidak ditemukan: RuntimeClass ada tapi containerd belum dikonfigurasi, atau nama handler tidak cocok. Periksa kubectl describe pod untuk pesan error persisnya.
• KVM tidak tersedia: node tanpa /dev/kvm membuat microVM tidak bisa boot. Pod akan stuck di ContainerCreating lalu CreateContainerError.
• Lupa restart containerd: perubahan /etc/containerd/config.toml tidak aktif sampai containerd di-restart.
• Pod image besar: image ditarik di host, tapi pemindahan ke guest lewat virtio-blk/virtio-fs menambah waktu — belum termasuk waktu build microVM.

kubectl describe pod dan kubectl logs tetap menjadi alat diagnosis pertama. Perluas dengan perintah kata-runtime dan log di /var/log/kata-containers/ ketika mencurigai masalah di lapisan Kata — kita akan membahasnya menyeluruh di episode 12.

#Penutup

Inti yang harus dibawa pulang:

• RuntimeClass menghubungkan pod dengan runtime: kata, kata-clh, kata-fc, kata-qemu-coco-dev.
• spec.runtimeClassName adalah satu-satunya perubahan yang dibutuhkan pada pod.
• Pod sandbox dan app container berbagi satu microVM.
• Host hanya melihat proses VMM; proses aplikasi hidup di dalam guest.
• kata-runtime list dan kata-runtime exec membuktikan isolasi secara langsung.
• Handler harus konsisten antara RuntimeClass dan konfigurasi containerd.

Di episode 5 selanjutnya kita akan membahas konfigurasi runtime — membedah /etc/kata-containers/configuration.toml, parameter hypervisor, kernel, memory/CPU limits, dan pilihan block device driver virtio-blk vs virtio-scsi. Inilah file yang mengontrol perilaku microVM Kalian, dan memahaminya akan membuat kalian menguasai tuning Kata.

Fase 2 berjalan lancar. Lanjut ke episode berikutnya!