Guidance needed: Best practices for managing Sysbox configuration drift on Kubespray clusters

[SomeoneInTheInternet218]

Hi Sysbox team,

I'm looking for some guidance on the officially recommended approach for deploying Sysbox on a Kubernetes cluster provisioned by Kubespray.

Currently, I'm facing a configuration challenge when integrating the installation into a strict Infrastructure-as-Code (IaC) environment.

Specifically, installing Sysbox directly via the .deb package automatically mutates /etc/containerd/config.toml to register the sysbox-runc runtime. However, Kubespray strictly manages this configuration via Ansible templates. Any subsequent Kubespray playbook runs (e.g., adding a new node, upgrading cluster components) will overwrite config.toml, erasing the Sysbox runtime registration and immediately causing active Sysbox pods to fail.

My current workaround is to write a custom Ansible task to install the package and explicitly inject the sysbox-runc configuration into Kubespray's containerd_additional_runtimes variable, allowing Kubespray to render the config natively.

Is there a more official or recommended deployment pattern (such as a supported Ansible role) to seamlessly integrate Sysbox into standard Kubespray/GitOps workflows without causing configuration drift?

Thanks in advance for your time and insights!