Learn Kata Containers - Kata in the Cloud: AKS, OpenShift, AWS EKS

#Introduction

So far we've installed Kata ourselves on our own clusters. Episode 18 covers a different world: Kata as a managed service feature. When teams use AKS, OpenShift, or EKS, they don't need to install Kata from scratch — the platform already provides it as a RuntimeClass option. This shifts your role from installer to enabler: knowing how to enable, limit, and operate sandboxing on a managed platform.

Episode 18 also answers a question that often comes up in the field: when to use Kata and when to use KubeVirt for workloads that need VMs.

#AKS Pod Sandboxing (Microsoft Azure)

#Feature and Concept

AKS Pod Sandboxing is an Azure Kubernetes Service feature that uses Kata Containers as its sandboxing mechanism. Pods marked as "sandboxed" run in microVMs, while regular pods keep using runc. The concept is the same as what you've learned: the RuntimeClass determines the runtime.

The activation flow in AKS in broad strokes:

1. Enable the Pod Sandboxing feature in the cluster (requires a new cluster or a new nodepool).
2. Use a dedicated RuntimeClass for sandboxed pods.
3. Workloads work as usual — isolation is provided by the platform.

Sandboxed pods use a RuntimeClass with an AKS-specific name:

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 is the RuntimeClass AKS provides for pods run in a microVM. Note: the AKS runtime name can differ from the standard kata — always check the platform documentation for valid names.

#Considerations

• Regional availability: the sandboxing feature isn't available in all regions and instance types.
• Capacity: microVMs hold their resources — plan a node pool with adequate size.
• Combination: mix regular and sandboxed pods in the cluster, with appropriate node pools.

#OpenShift Sandboxed Containers (Red Hat)

OpenShift Sandboxed Containers is the integration of Kata Containers into Red Hat OpenShift. The concept is similar: a RuntimeClass provides a sandbox runtime for untrusted workloads, while the control plane and regular workloads keep using runc.

The advantage in OpenShift: deep integration with SecurityContextConstraints (SCC), admission policy (episode 15), and OpenShift tooling. Operators familiar with OpenShift can enable sandboxing as a documented option, with Red Hat support — added value for enterprise environments that need SLAs.

The usage pattern is the same: pods use a sandboxed RuntimeClass, and operators control who may use it through RBAC and policy.

#AWS EKS on Bare-metal Nodes

#EKS Characteristics

Amazon EKS supports Kata Containers on bare-metal nodes — nodes running on EC2 bare metal, not VMs. Why is bare metal important? Because running Kata (which needs KVM for virtualization) on top of a VM instance requires nested virtualization, which isn't always available or allowed. Bare metal gives direct access to the virtualization hardware.

On bare-metal nodes, you can install Kata like an on-prem cluster (episode 3) — kata-deploy or release tarball — then use the kata RuntimeClass as usual.

#Steps in Broad Strokes

1. Provision a bare-metal node pool (for example, a bare metal instance family).
2. Confirm virtualization support on the nodes (/dev/kvm, episode 0).
3. Install Kata on the node pool (kata-deploy scoped to that node pool).
4. Use the RuntimeClass for sandbox workloads.

This approach gives full control with the flexibility of AWS managed Kubernetes. Watch the cost: bare metal is more expensive, but provides the hardware access you need.

#KubeVirt vs Kata for VM Workloads

#Two Ways to Run VMs in Kubernetes

A question that often arises: if you need a VM, why not just use KubeVirt? Both answer different needs:

• Kata Containers: runs containers with VM isolation. Its API is the container API — Kubernetes sees them as pods. Suitable for container workloads that need more isolation.
• KubeVirt: runs native VMs in Kubernetes. Its API is the VM API — workloads that genuinely need their own virtual OS (Windows, legacy apps) and can't be containerized.

A quick comparison:

#When to Choose

Choose Kata when your application is a container that needs microVM isolation — sandbox patterns, multi-tenant, untrusted workloads. Choose KubeVirt when you have legacy VMs that can't be containerized and want to manage them alongside Kubernetes.

There's also a hybrid pattern in the field: KubeVirt for legacy VMs, Kata for untrusted containers, in the same cluster.

#On-Prem Bare-Metal Deployment

On-prem, you have full control — and full responsibility. Recommended checklist:

1. Verify KVM on every node before installing (episode 0).
2. Choose a backend and lock it in as one default choice (episode 6).
3. Install Kata with kata-deploy or a custom node image.
4. Configure containerd for the Kata runtime (episode 3).
5. Create the RuntimeClass matching the backend (episode 4).
6. Apply policy: require the RuntimeClass for untrusted namespaces (episode 15).
7. Per-VM monitoring from day one (episode 16).

#Conclusion

What you should take away:

• AKS provides Kata-based Pod Sandboxing with a dedicated RuntimeClass.
• OpenShift Sandboxed Containers integrates Kata with SCC and Red Hat tooling.
• AWS EKS supports Kata on bare-metal nodes that have KVM access.
• KubeVirt for native VMs; Kata for isolated containers — two different needs.
• On-prem gives full control; follow the checklist from KVM to monitoring.
• On managed platforms, the key job is managing RuntimeClass usage boundaries.

In the next episode, episode 19, we'll cover AI & agent sandboxes — running LLM inference and untrusted agents in microVMs, GPU via VFIO, and per-agent/session sandbox patterns and CI/CD isolates. This is one of the hottest real-world use cases of Kata Containers.