liveBook · Manning

Kubernetes operator

As explained in Server-Side WebAssembly

A Spin operator is a Kubernetes controller that manages the deployment and execution of Spin applications.

A Kubernetes operator is a controller that makes a custom resource do useful work. A CRD defines a new resource type; the operator watches its custom resources and interprets their desired state. For a Wasm application, that can mean creating a deployment, wiring networking, and handling updates or restarts. This lets an application be managed through Kubernetes-native, declarative patterns rather than as a collection of manually coordinated objects. 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 resource submitted to the Kubernetes API server; the operator handles that resource behind the scenes. section 8.1

The Spin operator is installed alongside SpinKube CRDs and a runtime configuration. Before it can orchestrate Spin workloads, the cluster needs a RuntimeClass that identifies the Spin runtime and cert-manager to secure the operator’s admission webhooks. Those webhooks can validate a submitted Spin application configuration or apply defaults before Kubernetes accepts it. section 8.2.1 section 8.2.1

A practical Spin deployment pipeline is:

  • Build the Spin application and push it to a container registry as an OCI image. section 8.2.2
  • Use the Spin kube plugin to scaffold a SpinApp manifest that references the image, executor, and desired replica count. section 8.2.2
  • Apply the manifest to create the custom resource; the operator reconciles it into runnable application resources. section 8.1 section 8.2.2
  • Check SpinApp readiness, then reach the generated service through port forwarding to test the application. section 8.2.2

Deploying hello-world-spin

A SpinApp named hello-world-spin specifies an OCI image, the containerd-shim-spin executor, and two replicas. After the manifest is created, kubectl reports two ready replicas. Port-forwarding the hello-world-spin service and requesting its root route returns “Hello World from Spin in Kubernetes!” section 8.2.2

Operators allow Kubernetes to manage noncontainer workloads, including Wasm applications, with familiar orchestration and scaling patterns. SpinKube supplies the CRDs and operator for Spin, while the Spin kube plugin reduces manifest authoring when moving an application from local development toward production. Kubernetes HPA can also scale Spin application replicas from CPU and memory load. section 8.5

How Server-Side WebAssembly covers it

How deep it goes
Explains CRD-to-operator flow and walks through installation, manifest generation, deployment, and verification.
Examples
Uses a two-replica hello-world SpinApp, an OCI registry image, generated manifest, readiness check, and port-forwarded HTTP response.
What it assumes
Introduces Kubernetes terms in context while requiring a configured local cluster, Spin application, registry access, and Rust 1.85.0 or later.
What you can do after
Operate/configure it by installing SpinKube components and deploying a scaffolded SpinApp manifest.
How it connects
Connects CRDs, custom resources, RuntimeClass, admission webhooks, Kubernetes Services, HPA, and SpinApp manifests.

Also explained in

Compare how 7 books explain Kubernetes operator →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Server-Side WebAssembly. The section links point to the parts of the book it draws on.