gameplane / docs
REFERENCE

API and CRD reference

Automate Gameplane through Kubernetes resources and scoped identities while keeping desired state, observed status, and audit history aligned.

API & Referencev0.218 MIN
Write spec, read status

Controllers own conditions and observed fields; automation should never patch them as desired state.

Core resources

GameServer, GameTemplate, Module, ModuleSource, Backup, BackupSchedule, Cluster, and Restore encode the platform’s declarative contracts. These eight resources form the core API surface.

Coming in v0.3.0

NetworkCapture, the ninth core CRD (packet capture), ships in v0.3.0 and is not available in beta.8.

Use installed CRD versionsUse apiVersion and kind from the installed CRDs, not copied state examples.
Separate names and UIDsTreat names and UIDs separately when correlating resources across restores.
Leverage labels and ownershipUse labels and owner references for automation and cleanup.

Status, phases, and conditions

Observed generation, phase, reason, message, and conditions explain whether the controller has applied the latest intent. Every resource tracks its current state via .status fields that the controller populates.

Wait for observedGenerationWait for observedGeneration before treating status as current.
Use condition metadataUse condition type, status, reason, and timestamp in runbooks.
Watch Kubernetes eventsWatch events when a phase alone cannot explain a blocked reconciliation.

kubectl and API access

Use Kubernetes RBAC for CRD workflows and scoped Gameplane service accounts for product APIs and integrations. The declarative loop below shows the most common workflow.

DECLARATIVE LOOP

01   kubectl apply -f gameserver.yaml
02   kubectl get gameserver <name> -o yaml
03   kubectl describe gameserver <name> # conditions + events

API and integration references