gameplane / docs
REFERENCE

CRD Catalog

Understand every gameplane.local/v1alpha1 resource, its scope, desired spec, observed status, and controller owner.

API & Referencev0.24 MIN

Every Gameplane custom resource lives in the gameplane.local/v1alpha1 API group. This catalog lists each one, its scope (namespaced or cluster-wide), short name for use with kubectl, and its purpose within the platform.

Workload and recovery resources

Kind Scope Short name Purpose
GameServer Namespaced gs Desired game workload and live status.
GameTemplate Cluster gtmpl Reusable game/runtime blueprint from a module.
Backup Namespaced bk One-shot snapshot of server data.
BackupSchedule Namespaced bks Cron policy, destination, and retention.

Platform resources

Kind Scope Short name Purpose
Restore Namespaced rs One-shot restore into new or existing server.
Module Cluster mod Installed immutable module bundle and template owner.
ModuleSource Cluster msrc Registry, Git, HTTP, local, or upload source.
Cluster Cluster cls Registered target-cluster identity and health.
Spec vs. status ownership

Clients write spec and metadata; controllers own phase, conditions, observedFields, timestamps, digests, and results. Changes always flow from spec → reconciler → status, never the reverse.

Understanding scope

Namespaced resources (GameServer, Backup, BackupSchedule, Restore) are tied to a Kubernetes namespace and represent per-server or per-player state. They exist within a tenant’s workspace.

Cluster-scoped resources (GameTemplate, Module, ModuleSource, Cluster) are fleet-wide and shared across all namespaces. They define reusable infrastructure: what games are available, where module bundles come from, and which remote clusters are registered.

Field reference

Each CRD’s full schema—all spec fields, status conditions, and behavioral annotations—is documented in the source repository:

NEXT GUIDEModule & Cluster CRDs