کontainerها انقلاب DevOps بودند: deploy سریع، density بالا، CI/CD ساده. اما همان kernel مشترک که سرعت را ممکن کرد، بزرگ‌ترین سطح حمله را هم باز گذاشت. escape از container، exploit در runc، دسترسی به socket host، یا neighbor noisy در cluster مشترک — همه از همین مدل می‌آیند.

Kata Containers پاسخ Open Source جامعه به این trade-off است:

The speed of containers, the security of VMs.

یعنی از بیرون مثل container رفتار می‌کند (OCI، Docker، Kubernetes CRI)، اما هر workload داخل microVM سبک با kernel اختصاصی اجرا می‌شود. نه nested VM سنگین، نه container ناامن — یک لایه میانی production-grade.

مشکل container کلاسیک (runc)

در runtime معمولی (runc، crun):

Host Kernel (یکی برای همه)
├── namespace + cgroup → Container A
├── namespace + cgroup → Container B
└── namespace + cgroup → Container C

مزیت: startup میلی‌ثانیه، overhead ناچیز، density عالی.

ریسک:

برای dev/staging و workloadهای trusted، runc عالی است. برای multi-tenant SaaS، fintech، healthcare، AI inference مشترک، یا اجرای کد کاربر (serverless/functions) — kernel مشترک liability است.

Kata Containers چیست؟

Kata Containers یک container runtime متن‌باز است که:

• با OCI runtime spec سازگار است
• از Kubernetes CRI (containerd، CRI-O) استفاده می‌کند
• هر Pod/sandbox را داخل lightweight VM اجرا می‌کند
• توسط OpenInfra Foundation (همان اکوسystem OpenStack) نگه‌داری می‌شود
• از ادغام Intel Clear Containers + Hyper.sh RunV (۲۰۱۷) تا امروز scale شده

پشتیبانی معماری: AMD64، ARM، IBM Power، IBM Z (s390x)

Hypervisorها: QEMU، Cloud Hypervisor، Firecracker، Dragonball (built-in پیش‌فرض Kata 4.0)

معماری: چطور کار می‌کند؟

نمای کلی

Kubernetes / containerd
        ↓ CRI + shim v2
containerd-shim-kata-v2 (runtime-rs)
        ↓
   ┌────┴────┐
   │  VMM    │  ← Dragonball (built-in) یا QEMU/CLH/FC (external)
   └────┬────┘
   Guest microVM
   └── kata-agent
       └── container(s) داخل VM

نکات کلیدی:

1. یک VM per Pod (sandbox) — نه یک VM per container درون همان Pod؛ containerهای یک Pod در یک microVM shared می‌مانند (مثل مدل Kubernetes).
2. kata-agent داخل guest — معادل container runtime در VM؛ با host از طریق vsock/hybrid-vsock صحبت می‌کند.
3. shim v2 — یک binary واحد per pod با containerd integrate می‌شود؛ lifecycle VM و container را مدیریت می‌کند.

Kata 4.0 و runtime-rs

از نسخه 4.0، runtime-rs (Rust، async با Tokio) پیش‌فرض است:

دو حالت VMM:

در حالت Dragonball، shim مستقیماً VMM را صدا می‌زند — بدون fork process جدا + RPC — startup سریع‌تر و مصرف RAM کمتر.

Go runtime قدیمی (kata-qemu) هنوز ship می‌شود ولی deprecated است؛ migration به runtime-rs توصیه می‌شود.

مقایسه: runc vs gVisor vs Kata vs VM کامل

gVisor برای sandbox syscall عالی است ولی بعضی workloadها (eBPF، برخی io_uring، driver خاص) مشکل دارند.

Kata وقتی برنده می‌شود که بخواهید Linux واقعی + isolation سخت‌افزاری بدون مدیریت VM دستی.

چرا باید از Kata استفاده کنیم؟

۱. امنیت و multi-tenancy

• هر tenant در kernel جدا — escape یک container به host neighbor را بسیار سخت‌تر می‌کند
• مناسب SaaS که کد مشتری اجرا می‌کند (Function Computing، serverless containers)
• Baidu در production از Kata برای Function Computing، Cloud Container Instances و Edge استفاده می‌کند

۲. compliance و سیاست سازمانی

صنایع regulated (بانک، بیمه، health) اغلب «VM-level isolation» می‌خواهند ولی team فقط Kubernetes بلد است. Kata همان API را نگه می‌دارد.

۳. اجرای workloadهای نامطمئن

• CI runner که PR ناشناس build می‌کند
• sandbox برای AI Agent / code execution
• Jupyter یا notebook shared cluster

۴. Confidential Computing

Kata از پیکربندی‌های Intel TDX، AMD SEV/SEV-SNP و CoCo (Confidential Containers) پشتیبانی می‌کند — encryption in-use برای دادهٔ حساس در cloud عمومی.

۵. سازگاری ecosystem

• OCI image — همان Docker imageها
• Kubernetes RuntimeClass — انتخاب per-namespace یا per-Pod
• containerd 2.x، CRI-O، Docker 26+ (با QEMU)
• Helm chart از Kata 3.12+

۶. Performance قابل قبول

Kata Containers ادعا می‌کند performance consistent با Linux container با isolation بیشتر — نه tax یک VM سنتی. Dragonball و runtime-rs دقیقاً برای کاهش این gap ساخته شده‌اند.

ویژگی‌های اصلی (از katacontainers.io)

Kubernetes: RuntimeClass عملی

پیش‌نیاز: Kubernetes ≥ 1.22، containerd ≥ 2.0 (توصیه 2.1+)

نصب با kata-deploy / Helm

# مثال: Helm (Kata ≥ 3.12)
helm install kata-deploy kata-containers/kata-deploy \
  --namespace kube-system

Helm برای هر shim یک RuntimeClass می‌سازد، مثلاً:

• kata-dragonball — built-in VMM (runtime-rs)
• kata-qemu-runtime-rs — QEMU + runtime-rs
• kata-qemu — Go runtime (deprecated)

استفاده در Pod

apiVersion: v1
kind: Pod
metadata:
  name: secure-workload
spec:
  runtimeClassName: kata-dragonball
  containers:
    - name: app
      image: nginx:alpine

Namespace-level policy

apiVersion: v1
kind: LimitRange
metadata:
  name: kata-default
  namespace: untrusted-tenants
spec:
  limits:
    - default:
        runtimeClassName: kata-dragonball
      type: Container

نصب روی سرور (Linux)

روش 1: release tarball + kata-deploy

مستندات رسمی: Installation Guide

# دانلود آخرین release از GitHub kata-containers/kata-containers
# نصب binaryها در /opt/kata
# پیکربندی containerd

روش 2: containerd config

در /etc/containerd/config.toml:

[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.kata-dragonball]
  runtime_type = "io.containerd.kata.v2"
  [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.kata-dragonball.options]
    ConfigPath = "/opt/kata/share/defaults/kata-containers/configuration-dragonball.toml"

سپس:

systemctl restart containerd
kubectl apply -f runtimeclass-kata.yaml

Docker 26+ (مستقیم)

Docker می‌تواند Kata shim را register کند؛ تست رسمی با QEMU. برای runtime-rs باید ConfigPath مناسب set شود.

tuning و best practices

RAM و density

• هر microVM memory footprint دارد — برای cluster کوچک capacity planning کنید
• Dragonball برای density بهتر از QEMU external
• از virtio-fs / nydus برای rootfs سریع‌تر استفاده کنید (در config Kata)

چه Podهایی را Kata بگذاریم؟

Observability

• metrics از containerd + kubelet مثل قبل
• debug: kata-runtime kata-env، log shim در /var/log/
• برای مشکل startup: hypervisor config (configuration-dragonball.toml)

چه زمانی Kata نباید اولین انتخاب باشد؟

1. Cluster تک‌tenant داخلی با imageهای signed — runc ساده‌تر و ارزان‌تر است
2. Latency ultra-p low (HFT، realtime gaming server) — overhead VM ممکن است حس شود
3. Edge با RAM بسیار کم — microVM هنوز بیشتر از container خالی می‌خواهد
4. Team بدون ops experience — Kata نیاز به containerd/K8s tuning دارد

Kata لایه امنیتی اضافه است، نه جایگزین همه containerها.

سناریوهای واقعی

Function Computing (الگوی Baidu)

Request → scheduler → microVM جدید یا warm pool → اجرای function → destroy. Isolation per invocation بدون VM دستی.

AI / ML shared cluster

مدل inference برای چند مشتری: جلوگیری از دسترسی یک job به memory GPU/host neighbor از مسیر kernel.

GitLab Runner / CI

# .gitlab-ci.yml — runner با Kata runtime
tags: [kata, secure]
script:
  - untrusted-build.sh

Edge node

Kata در edge برای workloadهایی که device فیزیکی shared است ولی tenant logic جدا — مثلاً retail POS + analytics.

Kata در کنار stack مدرن

                    ┌─────────────────┐
                    │   Kubernetes    │
                    └────────┬────────┘
                             │ RuntimeClass
              ┌──────────────┼──────────────┐
              ▼              ▼              ▼
           runc          Kata          gVisor
         (default)    (secure pods)   (syscall sandbox)
              │              │
              ▼              ▼
         containerd      microVM + kata-agent

در practice: 80٪ runc + 20٪ Kata برای namespaceهای حساس — الگوی رایج enterprise.

Roadmap و جامعه

• Repo: github.com/kata-containers/kata-containers
• License: Apache 2.0
• Steward: OpenInfra Foundation
• جلسات architecture هفتگی — mailing list و Slack community
• Kata 4.0: runtime-rs، Dragonball، پشتیبانی Wasm/Linux container experimental

جمع‌بندی: چرا Kata؟

اگر cluster شما multi-tenant، regulated، یا untrusted code اجرا می‌کند، Kata Containers یکی از matureترین گزینه‌های Open Source برای «container ergonomics + VM security» است — با ecosystem واقعی production (از جمله Baidu) و evolution فعال در runtime-rs / Dragonball.

قدم بعدی

1. Latest release را روی staging cluster نصب کنید
2. یک RuntimeClass با kata-dragonball بسازید
3. یک namespace test با Pod نمونه deploy کنید
4. startup time و RAM را با workload واقعی benchmark بگیرید
5. policy namespace production را تعریف کنید

منابع:

• Kata Containers — Official Site
• Installation Documentation
• Architecture 4.0 (runtime-rs)
• GitHub — kata-containers/kata-containers
• OpenInfra Foundation

منتشر شده در P30Light — بخش زیرساخت سرور و Cloud Native.