mirror of https://github.com/kata-containers/kata-containers.git synced 2026-07-01 14:38:33 +00:00

Files

Fabiano Fidêncio aebadb1ab2 docs: document kata-deploy job deployment mode

Document the new opt-in deploymentMode: job alongside the default
DaemonSet model in the maintained docs (not just the chart README):

  - helm-configuration.md: add a "Deployment Modes (DaemonSet vs Job)"
    section covering the dispatcher-driven staged install/cleanup
    pipelines, why a dispatcher is used instead of Helm-rendered per-node
    Jobs (O(1) release, guaranteed coverage, paced rollout, explicit
    privilege split), the "re-run helm upgrade to cover newly added
    nodes" model (no always-on reconcile component), and the
    node-selection precedence (job.nodes > job.nodeSelector +
    job.nodeSelectorExpressions) that defaults to worker nodes.
  - installation.md: note that the DaemonSet is the default but no longer
    the only model, linking to the section above.

Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
Assisted-by: Cursor <cursoragent@cursor.com>

2026-06-12 18:58:33 +02:00

2.6 KiB

Raw Blame History

Installation

Helm Chart

helm can be used to install templated kubernetes manifests.

Prerequisites

Kubernetes ≥ v1.22 – v1.22 is the first release where the CRI v1 API became the default and RuntimeClass left alpha. The chart depends on those stable interfaces; earlier clusters need feature‑gates or CRI shims that are out of scope.
Kata Release 3.12 - v3.12.0 introduced publishing the helm-chart on the release page for easier consumption, since v3.8.0 we shipped the helm-chart via source code in the kata-containers GitHub repository.
CRI‑compatible runtime (containerd or CRI‑O). If one wants to use the multiInstallSuffix feature one needs at least containerd-2.0 which supports drop-in config files
Nodes must allow loading kernel modules and installing Kata artifacts (the chart runs privileged containers to do so)

`helm install`

# Install directly from the official ghcr.io OCI registry
# update the VERSION X.YY.Z to your needs or just use the latest

export VERSION=$(curl -sSL https://api.github.com/repos/kata-containers/kata-containers/releases/latest | jq .tag_name | tr -d '"')
export CHART="oci://ghcr.io/kata-containers/kata-deploy-charts/kata-deploy"

$ helm install kata-deploy "${CHART}" --version "${VERSION}"

# See everything you can configure
$ helm show values "${CHART}" --version "${VERSION}"

This installs the kata-deploy DaemonSet and the default Kata RuntimeClass resources on your cluster.

Note: the DaemonSet is the default install model, but it is no longer the only one. You can instead install Kata via short-lived, staged per-node Jobs (no always-on component on the node) by setting deploymentMode: job. See Deployment Modes (DaemonSet vs Job) for details and node-selection options.

To see what versions of the chart are available:

$ helm show chart oci://ghcr.io/kata-containers/kata-deploy-charts/kata-deploy

`helm uninstall`

$ helm uninstall kata-deploy -n kube-system

During uninstall, Helm will report that some resources were kept due to the resource policy (ServiceAccount, ClusterRole, ClusterRoleBinding). This is normal. A post-delete hook Job runs after uninstall and removes those resources so no cluster-wide RBAC is left behind.

Pre-Built Release

Kata can also be installed using the pre-built releases: https://github.com/kata-containers/kata-containers/releases

This method does not have any facilities for artifact lifecycle management.

2.6 KiB Raw Blame History Unescape Escape