Belajar Kata Containers - Kata di Cloud: AKS, OpenShift, AWS EKS

#Pendahuluan

Sejauh ini kita menginstall Kata sendiri di cluster sendiri. Episode 18 membahas dunia yang berbeda: Kata sebagai fitur managed service. Ketika tim memakai AKS, OpenShift, atau EKS, mereka tidak perlu menginstall Kata dari nol — platform sudah menyediakannya sebagai opsi RuntimeClass. Ini mengubah peran kalian dari installer menjadi enabler: tahu cara mengaktifkan, membatasi, dan mengoperasikan sandboxing di platform managed.

Episode 18 juga menjawab pertanyaan yang sering muncul di lapangan: kapan memakai Kata dan kapan memakai KubeVirt untuk workload yang butuh VM.

#AKS Pod Sandboxing (Microsoft Azure)

#Fitur dan Konsep

AKS Pod Sandboxing adalah fitur Azure Kubernetes Service yang memakai Kata Containers sebagai mekanisme sandboxing. Pod yang ditandai sebagai "sandboxed" dijalankan dalam microVM, sementara pod biasa tetap memakai runc. Konsepnya sama dengan yang kalian pelajari: RuntimeClass menentukan runtime.

Alur pengaktifan di AKS secara garis besar:

1. Aktifkan fitur Pod Sandboxing di cluster (perlu cluster baru atau nodepool baru).
2. Gunakan RuntimeClass khusus untuk pod sandboxed.
3. Kerja workload seperti biasa — isolasi diberikan oleh platform.

Pod sandboxed memakai RuntimeClass dengan nama spesifik AKS:

apiVersion: v1
kind: Pod
metadata:
  name: sandboxed-app
spec:
  runtimeClassName: kata-mshv-vm-isolation
  containers:
    - name: app
      image: nginx:alpine

runtimeClassName: kata-mshv-vm-isolation adalah RuntimeClass yang disediakan AKS untuk pod yang dijalankan di microVM. Perhatikan: nama runtime AKS bisa berbeda dari standar kata — selalu cek dokumentasi platform untuk nama yang valid.

#Pertimbangan

• Ketersediaan regional: fitur sandboxing tidak tersedia di semua region dan tipe instance.
• Kapasitas: microVM menahan resource — rencanakan node pool dengan ukuran memadai.
• Kombinasi: campur pod biasa dan sandboxed di cluster, dengan node pool yang sesuai.

#OpenShift Sandboxed Containers (Red Hat)

OpenShift Sandboxed Containers adalah integrasi Kata Containers ke Red Hat OpenShift. Konsepnya serupa: RuntimeClass menyediakan runtime sandbox untuk workload yang tidak dipercaya, sementara kontrol plane dan workload biasa tetap memakai runc.

Keunggulan di OpenShift: integrasi mendalam dengan SecurityContextConstraints (SCC), policy admission (episode 15), dan tooling OpenShift. Operator yang terbiasa dengan OpenShift bisa mengaktifkan sandboxing sebagai opsi yang terdokumentasi, dengan dukungan Red Hat — nilai tambah untuk environment enterprise yang butuh SLAs.

Pola pemakaiannya sama: pod memakai RuntimeClass sandboxed, dan operator mengatur siapa yang boleh memakainya lewat RBAC dan policy.

#AWS EKS di Bare-metal Nodes

#Karakteristik EKS

Amazon EKS mendukung Kata Containers di bare-metal nodes — node yang berjalan di atas EC2 bare metal, bukan VM. Mengapa bare-metal penting? Karena menjalankan Kata (yang butuh KVM untuk virtualisasi) di atas instance VM membutuhkan nested virtualization yang tidak selalu tersedia atau diizinkan. Bare-metal memberi akses langsung ke hardware virtualisasi.

Di bare-metal nodes, kalian bisa menginstall Kata seperti cluster on-prem (episode 3) — kata-deploy atau release tarball — lalu memakai RuntimeClass kata seperti biasa.

#Langkah Garis Besar

1. Sediakan node pool bare-metal (contoh: keluarga instance bare metal).
2. Konfirmasi dukungan virtualisasi di node (/dev/kvm, episode 0).
3. Install Kata di node pool (kata-deploy terbatas ke node pool tersebut).
4. Gunakan RuntimeClass untuk workload sandbox.

Pendekatan ini memberi kendali penuh dengan fleksibilitas managed Kubernetes AWS. Perhatikan biaya: bare-metal lebih mahal, tapi memberi akses hardware yang dibutuhkan.

#KubeVirt vs Kata untuk Workload VM

#Dua Cara Menjalankan VM di Kubernetes

Pertanyaan yang sering muncul: kalau butuh VM, kenapa tidak langsung KubeVirt? Keduanya menjawab kebutuhan berbeda:

• Kata Containers: menjalankan container dengan isolasi VM. API-nya API container — Kubernetes melihatnya sebagai pod. Cocok untuk workload container yang butuh isolasi lebih.
• KubeVirt: menjalankan VM native di Kubernetes. API-nya API VM — workload yang benar-benar butuh OS virtual sendiri (Windows, legacy app) dan tidak bisa dikontainerisasi.

Perbandingan singkat:

#Kapan Memilih

Pilih Kata ketika aplikasi kalian adalah container dan butuh isolasi microVM — pattern sandbox, multi-tenant, untrusted workload. Pilih KubeVirt ketika kalian punya VM legacy yang tidak bisa dikontainerisasi dan ingin mengelolanya bersama Kubernetes.

Ada juga pola hybrid di lapangan: KubeVirt untuk VM legacy, Kata untuk container untrusted, dalam satu cluster yang sama.

#Deployment di Bare-metal On-Prem

Di on-prem, kalian punya kendali penuh — sekaligus tanggung jawab penuh. Checklist yang direkomendasikan:

1. Verifikasi KVM di setiap node sebelum install (episode 0).
2. Pilih backend dan kunci ke satu pilihan default (episode 6).
3. Install Kata dengan kata-deploy atau image node custom.
4. Konfigurasi containerd untuk runtime Kata (episode 3).
5. Buat RuntimeClass sesuai backend (episode 4).
6. Terapkan policy: wajibkan RuntimeClass untuk namespace untrusted (episode 15).
7. Monitoring per-VM sejak hari pertama (episode 16).

#Penutup

Inti yang harus dibawa pulang:

• AKS menyediakan Pod Sandboxing berbasis Kata dengan RuntimeClass khusus.
• OpenShift Sandboxed Containers mengintegrasikan Kata dengan SCC dan tooling Red Hat.
• AWS EKS mendukung Kata di bare-metal nodes yang punya akses KVM.
• KubeVirt untuk VM native; Kata untuk container terisolasi — dua kebutuhan berbeda.
• On-prem memberi kendali penuh; ikuti checklist dari KVM sampai monitoring.
• Di managed platform, kunci pekerjaan adalah mengatur batas pemakaian RuntimeClass.

Di episode 19 selanjutnya kita akan membahas AI & agent sandboxes — menjalankan LLM inference dan agent untrusted di microVM, GPU via VFIO, serta pola sandbox per agent/session dan CI/CD isolates. Inilah salah satu kasus penggunaan terpanas Kata Containers di dunia nyata.