As more containerd shims are created to extend the behavior of containerd, there is a need for an operator to coordinate containerd shim lifecycle operations. For example, shims need to be able to be installed / updated / removed, registered in the containerd config as handlers, runtime classes applied / removed, node labels applied / removed to indicate to the Kubernetes scheduler that a node has a given shim version installed so the scheduler can selectively schedule workloads on a node. All of these tasks can be done manually, but they are error prone and easily automated. These types of operations are prime tasks for an operator to perform. Kwasm With the introduction of Kwasm, the community has enabled easy installation of deislabs/containerd-wasm-shims to enable cluster operators to extend the functionality of their Kubernetes clusters to run WebAssembly (Wasm) workloads. Kwasm has demonstrated that an operator is a convenient means of shim lifecycle management in comparison to other methods of preparing cluster nodes to run Wasm workloads. For example, in kubernetes-sigs/image-builder project which is used by Cluster API to produce Kubernetes node virutal machine images, the containerd-wasm-shims must be downloaded, installed, and containerd config mutated when the virtual machine image is built, which produces a static virtual machine image with a specific set of Wasm shim versions. Additionally, to mutate Wasm shims installed in a cluster, a new virtual machine image would need to be built, published, and rolled out to clusters replacing existing cluster nodes. Generic containerd shim lifecycle management To accomplish the goal of building a generic containerd shim livecycle manager, it will need to manage the following tasks: