Install the sandbox runtime

Agent code runs inside Kata Containers microVMs. Kata is a cluster prerequisite: you install it once per cluster, from the Kata project's own Helm chart, before you install the platform, and every deployment on the cluster shares it. The platform installs no part of it.

Audience: IT (the enabler)

Your nodes must already meet Cluster and node requirements, in particular nested virtualization. Nothing here checks: with the reference configuration the chart installs onto a node without /dev/kvm and reports success, and only sandbox runs fail. Confirm /dev/kvm on the node before you start.

Install

Save the values file

The authoritative, versioned reference configuration is maintained on GitHub: v3/kata-containers/kata-values.yaml (opens in a new tab). Save it as kata-values.yaml and use it as is. See What the pinned values do.

Install the chart

helm install kata-deploy \
  oci://ghcr.io/kata-containers/kata-deploy-charts/kata-deploy \
  --version 4.1.0 \
  --namespace kube-system \
  -f kata-values.yaml \
  --wait --timeout 25m

The install unpacks Kata onto every node and restarts containerd on each one, so run it in a maintenance window.

Verify

Both commands must return at least one object before you install the platform.

kubectl get runtimeclass kata-clh
kubectl get nodes -l katacontainers.io/kata-runtime=true

The label is applied only after a node's install has completed, so the second command is the one that tells you a node is genuinely ready.

The application expects a runtime class named kata-clh, which is what the reference configuration produces. Do not install Kata with env.multiInstallSuffix, which renames it.

Nothing checks this at install time. The platform may install without the sandbox runtime, but it will not operate correctly: agent runs fail, with sandbox pods that never leave Pending. Make sure both commands above pass before you install the platform.

To update an existing installation, follow Upgrading Kata or changing its configuration. The Operations reference also covers node reboots and sharing one runtime installation across deployments.

Cluster and node requirements AWS EKS