Developing Kubernetes-Native Operations with Minecraft - Part 2: MinecraftNetwork Reconciliation and the Proxy Pipeline
This part focuses on the MinecraftNetwork controller. Its job is to turn a high-level network spec into a working proxy layer: generate Velocity configuration, assemble proxy addons, and reconcile the Kubernetes resources that serve player traffic. Think of it as the control plane for the proxy tier, similar to how a Deployment controller manages Pods but with domain‑specific knobs.
Responsibilities in one reconcile
At a high level, each reconcile does four deterministic steps:
- Resolve backends from
MinecraftServerresources or explicit lists. - Render Velocity config (
velocity.toml) and optional secrets. - Reconcile runtime objects: ConfigMap, Deployment, Service, and init logic for addons.
- Update status with condition and event signals so operators can reason about health.
This flow ensures that the proxy behaves like any other Kubernetes workload: declarative input, stable output, and idempotent reconciliation.
Owned resources
The controller owns a small, stable set of resources:
- ConfigMap: rendered
velocity.tomlplus auxiliary files. - Deployment: Velocity Pods (
itzg/mc-proxy) plus an init container to stage addons. - Service: exposes the proxy (LoadBalancer or NodePort).
- Secrets: forwarding secret material for modern IP forwarding.
This keeps the reconciliation surface predictable and easy to audit.
Velocity config rendering
Rendering is a pure function of the spec and backend resolution. A typical output looks like:




