Belajar Cloud Hypervisor - Cloud Hypervisor sebagai Backend Kata Containers

#Pendahuluan

Inilah episode yang menjawab pertanyaan paling sering diajukan soal Cloud Hypervisor: untuk apa sebenarnya dipakai di dunia nyata? Jawabannya ada di Kata Containers. Kata Containers adalah runtime OCI yang membungkus setiap container ke dalam VM ringan — dan Cloud Hypervisor adalah salah satu backend utama runtime kata-clh.

Bayangkan sebuah apartemen (node Kubernetes) di mana tiap kamar (pod) dikelilingi dinding beton (VM) yang tidak bisa ditembus kamar lain — meski kamar tetangga sudah dibobol perampok (container yang dikompromi). Di episode 18 kita membangun itu: memasang Kata Containers dengan kata-clh, mendefinisikan RuntimeClass, dan memahami alur pod dari containerd sampai ke VM.

#Konsep Kata Containers

#Container dalam VM

Kata Containers menggabungkan keamanan VM dengan kelincahan container. Setiap pod dijalankan di dalam VM tersendiri yang ditenagai Cloud Hypervisor (atau QEMU untuk runtime kata-qemu). Hasilnya:

Isolasi kernel: pod tidak berbagi kernel host — satu pod yang dikompromi tidak bisa menyerang kernel host atau pod lain.
Isolasi network & resource: setiap pod punya NIC dan memory space sendiri.
Kontainer tetap ringan: image container dipakai langsung, tidak perlu image VM terpisah.

#Alur: containerd → VM → agent

Alur eksekusi pod memakai shim v2:

Alur pod dengan kata-clh

kubelet → containerd → shimv2 (kata) → Cloud Hypervisor (VM)
                                            ↓
                              guest kernel + rootfs pod
                                            ↓
                              agent di dalam VM → menjalankan container

kubelet meminta containerd menjalankan pod.
containerd mendeteksi RuntimeClass kata-clh dan memanggil shim v2 Kata.
Shim meluncurkan Cloud Hypervisor — sebuah VM dibuat khusus untuk pod itu.
Di dalam VM, guest kernel boot dan menjalankan agent Kata.
Agent menerima OCI spec dari shim, membangun container di dalam VM (menggunakan virtio-fs untuk rootfs dan volume), dan melaporkan status kembali ke shim.

Dari sudut pandang Kubernetes, ini transparan — pod berjalan seperti biasa; yang berbeda hanyalah runtime di belakangnya.

#Memasang Kata Containers dengan kata-deploy

#RuntimeClass kata-clh

Cara termudah menginstall adalah Helm chart kata-deploy yang menyebarkan daemonset Kata Containers ke seluruh node:

Tambah repository Helm kata-deploy

helm repo add kata-containers https://kata-containers.github.io/kata-containers
helm repo update

Install kata-deploy dengan backend kata-clh

helm install kata-deploy kata-containers/kata-containers \
  --namespace kube-system \
  --create-namespace \
  --set runtimeClass.create=true \
  --set runtimeClass.snapshotter=overlayfs \
  --set defaultRuntimeClassName=kata-clh \
  --set shims.v2.default=true \
  --set shims.v2.enableAllShims=false \
  --set kataImage.registry="ghcr.io/kata-containers/kata-deploy"

Kunci konfigurasi yang perlu dipahami:

shims.v2.default=true: shim v2 dipasang sebagai default, dan backend yang dipakai adalah kata-clh (Cloud Hypervisor).
runtimeClass.create=true: RuntimeClass kata-clh dibuat otomatis.
runtimeClass.snapshotter=overlayfs: memakai snapshotter overlayfs agar rootfs container bisa dipakai di dalam VM.

#Verifikasi Instalasi

Cek daemonset dan RuntimeClass

kubectl -n kube-system get ds kata-deploy
kubectl get runtimeclass kata-clh
kubectl get runtimeclass kata-clh -o jsonpath='{.handler}'

kubectl get runtimeclass kata-clh harus menampilkan RuntimeClass dengan handler kata-clh.

#Menjalankan Pod dengan Isolasi VM

#Schedule pod ke kata-clh

Setelah RuntimeClass tersedia, jalankan pod dengan runtimeClassName: kata-clh:

pod-kata.yaml

apiVersion: v1
kind: Pod
metadata:
  name: secure-app
spec:
  runtimeClassName: kata-clh
  containers:
    - name: app
      image: nginx:latest
      resources:
        requests:
          memory: "256Mi"
          cpu: "250m"

Terapkan dan cek pod

kubectl apply -f pod-kata.yaml
kubectl get pod secure-app -w

#Verifikasi Pod Benar-Benar di dalam VM

Cara membuktikan pod berjalan di dalam VM Cloud Hypervisor, bukan di host:

Cek kernel di dalam pod

kubectl exec secure-app -- uname -r

Versi kernel yang berbeda dari kernel host adalah bukti kuat bahwa pod berada di VM terpisah:

Bandingkan dengan kernel host

uname -r

Di node tempat pod berjalan, cek proses host:

Cek proses cloud-hypervisor di node

pgrep -af cloud-hypervisor

Harus ada satu proses cloud-hypervisor per pod kata — bukti isolasi VM yang aktif.

Warning

Pod di belakang kata-clh tidak berbagi kernel host — ini konsekuensi yang harus dipahami semua orang: kernel module yang dibutuhkan workload (misal yang memuat driver khusus) harus tersedia di dalam guest kernel Kata, bukan kernel host. Baca dokumentasi Kata Containers untuk daftar module yang disediakan.

#Alur Kerja dan Operasional

#Persistensi State

Container state dan filesystem di dalam VM disinkronkan ke host lewat virtio-fs dan shim. Crash pod = VM dihentikan, container di dalamnya ikut berhenti, dan kubelet menjadwalkan ulang. Tidak ada "VM yang menggantung" di balik pod — model operasionalnya tetap Kubernetes murni.

#Resource dan Performance

Resource pod (requests/limits) diterjemahkan menjadi memory dan CPU VM. Untuk workload yang butuh resource besar, set requests/limits yang wajar — VM dibuat sesuai ukuran itu. Ingat: 1 pod = 1 VM — boot VM menambah overhead start, sehingga pod kata-clh cocok untuk workload yang butuh keamanan tinggi dan berumur panjang, bukan fungsi ephemeral ultra-sering.

#Integrasi dengan Fitur yang Sudah Kita Pelajari

Semua yang kita pelajari berlaku di sini: guest memory memakai shared=on (snapshot/migration), virtio-fs untuk rootfs (episode 6), dan TAP per-VM untuk isolasi network (episode 13). Kata Containers mengotomatiskan konfigurasi itu — kalian memilihnya lewat RuntimeClass.

Tip

Untuk workload multi-tenant yang membutuhkan isolasi kuat di satu node bersama (misal menjalankan kode milik pengguna berbeda), kata-clh adalah jawaban yang jauh lebih aman daripada sandbox container biasa. Ini peran yang sama dengan serverless microVM — kini dengan kelincahan Kubernetes penuh.

#Pitfall Umum

RuntimeClass tidak ada: pastikan runtimeClass.create=true saat install helm.
Kernel host vs guest dibingungkan: workload yang bergantung fitur kernel host tidak akan jalan di VM.
Resource pod terlalu kecil: VM butuh memory minimum untuk boot guest kernel — jangan set requests terlalu kecil.
Snapshotter salah: rootfs tidak bisa di-mount di dalam VM; ikuti pengaturan snapshotter dari dokumentasi kata-deploy.
Nested virtualization: jika node sendiri sudah VM (cloud), butuh nested virtualization (episode 19) untuk KVM.

#Penutup

Inti yang harus dibawa pulang:

Kata Containers membungkus tiap pod ke dalam VM; Cloud Hypervisor adalah backend kata-clh.
Alur: containerd → shimv2 → Cloud Hypervisor → guest kernel → agent → container.
Install dengan Helm kata-deploy dan set shims.v2.default=true untuk kata-clh.
Jalankan pod dengan runtimeClassName: kata-clh.
uname -r di dalam pod membuktikan isolasi kernel dari host.
1 pod = 1 VM: kuat untuk keamanan multi-tenant, dengan trade-off overhead start.

Di episode 19 selanjutnya kita akan membahas nested virtualization & EC2 — AWS EC2 yang mendukung nested virtualization (C8i/M8i/R8i, Februari 2026) memungkinkan kalian menjalankan KVM dan Cloud Hypervisor di instance reguler, plus deployment di bare-metal dan edge nodes. Kubernetes microVM di cloud publik jadi nyata.