mirror of
https://github.com/kata-containers/kata-containers.git
synced 2026-07-10 15:56:47 +00:00
5321c9d122
kata-deploy installs the Kata runtime asynchronously (DaemonSet or per-node Jobs), labelling the node katacontainers.io/kata-runtime=true as its final step. On a freshly provisioned node, a pod that requests a Kata RuntimeClass can be scheduled before the runtime binaries exist and fail to start. There is currently no mechanism to gate scheduling on the runtime actually being ready. Add a STARTUP_TAINTS option (helm value: startupTaints) listing taints to remove once install completes and the node is labelled. Operators can provision nodes with a startup taint (e.g. a Karpenter NodePool startupTaints entry) that keeps Kata workloads off the node until kata-deploy removes it as the very last install action, strictly after artifacts are installed, the CRI runtime is configured and restarted, and the node is labelled kata-capable. Each entry is a bare key (any effect) or key:effect. Removal is best-effort and idempotent: an absent taint is skipped, and a failure to remove leaves the taint in place (workloads stay gated) rather than admitting them prematurely. The default is empty, so the behaviour is opt-in and a no-op for existing deployments. The taint is wired through the shared commonEnv helper, so both daemonset and job deployment modes honour it. No RBAC change is needed: kata-deploy already holds nodes [get, patch]. Fixes: #13283 Assisted-by: Claude <noreply@anthropic.com> Signed-off-by: Pankaj Walke <punkwalker@gmail.com>
Kata Containers Deploy – Helm Chart
The documentation for the helm chart can be found at https://kata-containers.github.io/kata-containers/installation/#helm-chart.