A pod is Kubernetes’ smallest deployable unit. It packages a workload for scheduling on a node; in this setup, a pod typically runs one container or one Wasm module. Kubernetes places pods across available nodes according to resources. section 8.2.1
Pods are designed to be replaceable. A Deployment manages groups of identical pods for scaling, updates, and recovery, while a Service gives changing pods a stable network address and load balancing. section 8.1
For Spin-based Wasm workloads, pod execution depends on cluster preparation:
- Create nodes with a containerd-shim-spin-enabled cluster image so Kubernetes can run Spin workloads. section 8.2.1
- Define a RuntimeClass that selects the Spin handler instead of the node’s default container runtime. section 8.2.1
- Install SpinKube CRDs and its operator, which orchestrate submitted Spin application resources. section 8.1 section 8.2.1
Two-node local cluster
Create a local cluster with two agent nodes and expose its load balancer on port 8081. Later deployments can package Spin applications into pods and schedule them across those nodes. section 8.2.1
Figure 8.1 Kubernetes architecture showing the control plane (API server, scheduler, controller manager) and data plane (nodes with pods). The control plane manages cluster state and makes scheduling decisions, while the data plane runs the actual workloads. Users interact with the cluster through the API server, typically using kubectl commands or YAML manifests.
View how the control plane schedules and manages pods on data-plane nodes, with users submitting desired state through the API server. section 8.1
