kata-deploy ignores k8sDistribution=k3s when the systemd unit has a custom name

Description

kata-deploy 3.29.0 does not consistently honor the Helm value k8sDistribution: k3s.

The chart uses that value to mount the K3s containerd configuration directory at /etc/containerd, but the installer still determines the runtime independently by probing the host for active k3s-agent or k3s systemd units. If K3s is managed by a differently named unit, the installer falls back to the runtime-version prefix (containerd) even when the Kubernetes node reports a K3s-suffixed containerd version.

The result is a partially generic-containerd installation on a K3s node:

• runtime is logged as containerd rather than k3s-agent;
• the runtime fragment is written to /opt/kata/containerd/config.d/kata-deploy.toml instead of K3s's versioned drop-in directory;
• the rendered K3s config.toml is edited directly and the change is lost when K3s regenerates it;
• the installer attempts to restart containerd.service, which may not exist.

This is related to #10809 and #10914, but those issues do not cover the mismatch between the chart's explicit distribution setting and the installer's service-name-based runtime detection.

Reproduction

1. Install K3s with its agent managed by a nonstandard systemd unit name, while retaining the normal K3s paths and a node runtime version such as containerd://2.x.y-k3sN.

2. Install the 3.29.0 Helm chart with:

   yaml复制

   k8sDistribution: k3s
   deploymentMode: daemonset

3. Observe the installer log:

   复制

   Detected container runtime: containerd
   Creating drop-in file at: /host/opt/kata/containerd/config.d/kata-deploy.toml
   About to restart runtime: containerd
   Restarting containerd service

Without a local compatibility alias, the restart fails. With such an alias, installation can finish, but the runtime fragment still requires an out-of-tree link into K3s's versioned drop-in directory to survive K3s configuration regeneration.

Expected behavior

When k8sDistribution: k3s is explicitly configured, kata-deploy should use the K3s containerd paths and lifecycle regardless of the host systemd unit name. The chart should either:

1. pass the selected distribution into the installer as an authoritative runtime hint, with an optional service-name override; or
2. have the installer recognize the -k3s runtime-version suffix and provide a configurable K3s service name.

This would also remove the need for a cluster-specific privileged init-container workaround.

Version

• Kata Containers / kata-deploy: 3.29.0
• Source commit: 8dccf4cf37aeea4b6c2caacf3e61510d6eef2f71
• Deployment: upstream kata-deploy Helm chart with k8sDistribution: k3s