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 values below 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

Write this to kata-values.yaml and use it as is. The clh shim, the --xattr flag, and disable_guest_empty_dir are required by the platform; the rest narrows a general-purpose chart to what a deployment needs. See What the pinned values do.

kata-values.yaml

# Only the Go Cloud Hypervisor shim. This produces RuntimeClass/kata-clh.
shims:
  disableAll: true
  clh:
    enabled: true
    supportedArches:
      - amd64
    allowedHypervisorAnnotations: []
    containerd:
      snapshotter: ""
    dropIn: |
      [hypervisor.clh]
      virtio_fs_extra_args = ["--thread-pool-size=1", "--announce-submounts", "--xattr"]
      kernel_params = "cgroup_no_v1=all systemd.unified_cgroup_hierarchy=1"
      enable_annotations = []
 
      [runtime]
      disable_guest_empty_dir = true
 
defaultShim:
  amd64: clh
 
# Images come from your cluster's ordinary snapshotter.
snapshotter:
  setup: []
 
runtimeClasses:
  enabled: true
  createDefault: false
  overheadEnabled: false
 
monitor:
  enabled: false
 
node-feature-discovery:
  enabled: false
 
priorityClassName: system-node-critical
 
# Pinned and pull-if-absent, so a mirrored or air-gapped registry works.
imagePullPolicy: IfNotPresent
kubectlImage:
  tag: "v1.36.4"

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 values above produce. 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.

Day-2 behavior — upgrading Kata, the short self-healing window after an in-place node reboot, and running several deployments on one cluster — is covered in the Operations reference.

What this article will cover

Air-gapped installation from a mirrored registry
Gating node scheduling on Kata readiness with startup taints

Cluster and node requirements AWS EKS