Minecraft Server - Part 3: Running on Kubernetes

In the third part of this series, the focus shifts to running a Minecraft server on a Kubernetes cluster. The previous parts covered running the server in Docker containers with persistence and automatic restarts. This article aims to bring the same server into a Kubernetes cluster, offering managed storage via PersistentVolumeClaim, isolation via Namespace, and the flexibility to run on any available node in the cluster.

The Bedrock edition of Minecraft is used as an example. The first step is creating a Namespace named minecraft-br to isolate the Minecraft Bedrock resources from the rest of the cluster. Next, a PersistentVolumeClaim of 10Gi is defined in the same namespace, ensuring the server's saved world remains intact even if pods restart or recreate.

A Deployment is then created with a single replica, as running multiple instances of the same Minecraft world isn't supported due to the game not being designed for multiple instances accessing the same save simultaneously. The Deployment uses the itzg/minecraft-bedrock-server:latest image and exposes port 19132 for UDP traffic. Environment variables are set to enable EULA, set the game mode to survival, limit the maximum players to 10, and display a custom message of the day.

The server's data is mounted as a volume using a PersistentVolumeClaim. Finally, a Service of type LoadBalancer is created to expose the server outside the cluster on UDP port 19132. However, note that on on-premise clusters, the LoadBalancer type may not automatically provision an IP, requiring a controller like MetalLB for the Service to receive a usable external IP. Without this, the external IP will remain pending indefinitely.