mirror of
https://github.com/kata-containers/kata-containers.git
synced 2026-04-02 18:13:57 +00:00
4fad88499c
Rename all host-visible names of the nydus-snapshotter instance managed by kata-deploy from the generic "nydus-snapshotter" to "nydus-for-kata-tee". This covers the systemd service name, the containerd proxy plugin key, the runtime class snapshotter field, the data directory (/var/lib/nydus-for-kata-tee), the socket path (/run/nydus-for-kata-tee/), and the host install subdirectory. The rename makes it immediately clear that this nydus-snapshotter instance is the one deployed and managed by kata-deploy specifically for Kata TEE use cases, rather than any general-purpose nydus-snapshotter that might be present on the host. Because the old code operated under a completely separate set of paths (nydus-snapshotter.*), any previously deployed installation continues to run without interference during the transition to this new naming. CI pipelines and operators can upgrade kata-deploy on their own schedule without having to coordinate an atomic cutover: the old service keeps serving its existing workloads until it is explicitly replaced, and the new deployment lands cleanly alongside it. Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
Kata Containers packaging
Introduction
Kata Containers currently supports packages for many distributions. Tooling to aid in creating these packages are contained within this repository.
Build in a container
Kata build artifacts are available within a container image, created by a
Dockerfile. Reference DaemonSets are provided in
kata-deploy, which make installation of Kata Containers in a
running Kubernetes Cluster very straightforward.
Build static binaries
See the static build documentation.
Build Kata Containers Kernel
Build QEMU
Create a Kata Containers release
See the release documentation.
Packaging scripts
See the scripts documentation.
Credits
Kata Containers packaging uses packagecloud for package hosting.