A custom resource definition (CRD) extends the Kubernetes API with a new resource type. Kubernetes has built-in primitives such as Deployments, Services, and ConfigMaps, but no built-in application object. A CRD lets a platform define a top-level resource that can be configured and handled like a native Kubernetes object. section 8.1
Applying a CRD registers its schema with the cluster; applying a custom resource (CR) creates an instance of that type. The CRD alone does not make the resource do anything. An operator, running as a controller in the cluster, interprets the CR and reconciles it into work such as deployments, networking, updates, or restarts. section 8.1
Figure 8.2 How a Wasm operator fits into Kubernetes: the user deploys a Wasm app by submitting a CR to the Kubernetes API server. This resource is defined by a Wasm-specific CRD, which is handled behind the scenes by a Wasm operator.
A Wasm-specific CRD defines the submitted custom resource, while a Wasm operator receives it through the Kubernetes API and performs the underlying deployment work. section 8.1
CRDs make Kubernetes usable as an orchestration API for resources beyond containers:
- Model infrastructure objects such as databases or storage buckets, as Crossplane does. section 8.1
- Model virtual machines, as KubeVirt does. section 8.1
- Model Wasm workloads so they can be deployed and managed through Kubernetes-native patterns. section 8.5
SpinKube: installing and using CRDs
A SpinKube cluster needs a Wasm RuntimeClass, SpinKube CRDs, and the Spin operator. The CRDs register Spin-specific resource types; the operator orchestrates them. Secure admission webhooks may validate a submitted Spin app or apply defaults, with cert-manager supplying TLS certificates for that communication. kubectl apply -f spin-operator.crds.yaml helm install spin-operator --namespace spin-operator --create-namespace --version 0.5.0 --wait oci://ghcr.io/spinframework/charts/spin-operator The resulting custom resources express the desired application state, while the operator creates and manages the Kubernetes work needed to run it. section 8.2.1 section 8.2.1
wasmCloud application CR
wasmCloud installs CRDs including WasmCloudHostConfig, which defines a running wasmCloud host, and Application, which represents a wasmCloud app. After applying an Application CR, Kubernetes recognizes its type, so familiar commands can inspect it: kubectl apply -f wadm.yaml kubectl get app kubectl describe app rust-hello-world The application specification can declare components, image locations, scaling traits, and links. `wash app status` provides a more detailed view of deployed parts and connections. section 8.3.1 section 8.3.2
CRDs and Helm both reduce the amount of raw Kubernetes YAML a user must manage, but they work at different layers. Helm generates and bundles manifests on the client side; a CRD extends the Kubernetes API itself. The operator pattern is what gives a custom resource runtime behavior after it reaches the cluster. section 8.2 section 8.1
For Wasm, the model differs by platform. SpinKube runs each Wasm binary in its own pod and supports Kubernetes-oriented deployment, debugging, and monitoring. wasmCloud runs components inside wasmCloud hosts and uses NATS and wadm for application management, while its CRDs expose host and application resources to Kubernetes. section 8.3.2 section 8.5
