Developing Kubernetes-Native Operations with Minecraft - Part 1: Overview, Domain Model, and First Controller
Minecraft servers are easy to start and surprisingly hard to operate well. The moment you need reproducible builds, safe plugins, and a proxy that can evolve toward policy-driven routing, the operational surface area grows fast. This series documents building mc-k8s-operator: a Kubernetes operator that manages Minecraft Java servers (MinecraftServer) and Velocity networks (MinecraftNetwork) as first-class resources.
This consolidated Part 1 covers the architecture, the v1beta1 CRD model, and the first controller loop. Part 2 now focuses on MinecraftNetwork reconciliation and the proxy pipeline, while Part 3 covers the proxy policy DSL and control-plane shape.
Why the scope expanded in 2026
- The project now ships a Helm-based
mc-platformstack: operator, console API, web UI, and a console agent backed by Postgres. - The CRDs serve both v1alpha1 and v1beta1, with v1beta1 as the storage version.
- Security hardening and addon workflows are first-class (checksum verification, update policy, and policy-driven restarts).
- The control plane uses a DB polling model today; a future mTLS WebSocket protocol is defined but not implemented.
Current architecture (mc-platform)
flowchart LR User[Operator or SRE] --> Console[Web Console] Console --> API[Console API] API --> DB[(Postgres)] Agent[Console Agent] --> DB API --> K8s[Kubernetes API] Operator --> K8s CRDs[MinecraftServer + MinecraftNetwork] --> Operator Addons[Addon artifacts + sha256] --> Operator mcctl[mcctl CLI] --> API K8s --> Workloads[Servers + Velocity Proxy]



