Kubernetes Cluster Management
License Required
Kubernetes support requires the Kubernetes Support license add-on. Without this license, Kubernetes cluster management will not be available.
BadgerPanel can deploy game servers to Kubernetes clusters as an alternative to traditional daemon-based nodes. Kubernetes deployments use an orchestrator component that runs inside the cluster and communicates with the panel.
Overview
- Orchestrator - a binary deployed as a pod in your Kubernetes cluster. It connects to the panel, receives deployment instructions, and manages game server pods, services, and persistent volume claims.
- Cluster - a Kubernetes cluster registered in the panel via its orchestrator. One orchestrator manages one cluster.
- Game Server Pod - each game server runs as an individual pod with resource requests, limits, and a persistent volume for data.
Adding an Orchestrator
- Navigate to Admin > Orchestrators and click Add Orchestrator.
- Enter a name and description.
- Click Create. The panel generates a one-line install script.
- Run the install script on a machine with
kubectlaccess to your cluster:
curl -sSL "https://panel.example.com/api/orchestrators/install/TOKEN" | bashThe script creates a namespace (badger-system), deploys the orchestrator as a Deployment with a ServiceAccount, ClusterRole, and ClusterRoleBinding, and configures the connection back to the panel.
- Once the orchestrator connects, a cluster record is created automatically. The cluster appears under Admin > Kubernetes.
Cluster Dashboard
The cluster detail page (Admin > Kubernetes > [cluster]) provides a multi-tab view:
| Tab | Description |
|---|---|
| Overview | Cluster status, node count, pod count, CPU/memory utilization, orchestrator uptime |
| Nodes | All Kubernetes nodes with status, roles, capacity, and current usage |
| Pods | Pods in the game server namespace, filterable by status. Shows per-pod resource consumption |
| Deployments | Active deployments and replica status |
| Events | Real-time Kubernetes events, filterable by type and namespace |
Resource Configuration
Cluster-level resource settings are configured on the cluster detail page under Settings:
| Setting | Description | Default |
|---|---|---|
| Storage Class | Kubernetes StorageClass used for game server PVCs | - |
| Default Storage Size | Default PVC size for new servers | 10Gi |
| NodePort Range | Port range for NodePort services | 30000-32767 |
| Memory Overhead | Extra memory allocated to pods beyond the server's limit (for JVM/runtime overhead) | 25% |
| Host Network | Use the host network namespace for game server pods | false |
| Connection Address | Static IP or hostname shown to end users for connecting | - |
| Service Type | NodePort or LoadBalancer | NodePort |
Namespace Management
Game servers are deployed to the badger-servers namespace by default. You can change this in cluster settings. System namespaces (kube-system, kube-public, kube-node-lease, badger-system) are automatically excluded from deployment targets.
You can restrict the orchestrator to specific namespaces by configuring the Allowed Namespaces list. If left empty, the orchestrator can operate in any non-system namespace.
Auto-Migration
When enabled, the orchestrator can automatically move game server pods between Kubernetes nodes based on resource pressure. If a node becomes overloaded, pods are rescheduled to nodes with available capacity. Configure from the cluster settings under Auto-Migration.
Removing a Cluster
Before removing a cluster, delete or transfer all servers deployed to it. Then navigate to the orchestrator detail page and click Delete.
Clean up the orchestrator deployment from your cluster:
kubectl delete namespace badger-systemNext Steps
- Server Management - creating and managing game servers
- Daemon Installation - traditional node-based deployment