Network & Automation

Choose an exposure model

Select ClusterIP, NodePort, or LoadBalancer based on where players connect and who controls the network edge. When you have no public IP or no control over the network edge, layer a relay tunnel over the Service.

Service Types Overview

• ClusterIP: Internal-only access within the cluster. Ideal for internal game servers, proxies, or testing.
• NodePort: Exposes the service on a static port on every node. Suitable for on-premises clusters or when you manage your own load balancing.
• LoadBalancer: Integrates with your cloud provider’s load balancer (or on-premises equivalent like MetalLB/Cilium). Requests a public or routable address, optionally from a named address pool.
• Relay tunnels (frp, Tailscale, playit): Not an exposure mode but a layer over the Service that routes player connections through an external relay when you lack a public IP, port-forwarding, or a LoadBalancer. See Server Networking & Tunnels for setup and provider comparison.

Restrict and verify connectivity

Treat every port override and CIDR allow-list as part of the server’s documented interface.

Port and CIDR Configuration

Game servers expose ports via the Kubernetes Service created for each GameServer. You control which ports to expose (and their protocols) through the GameTemplate:

• Port overrides: specify TCP and UDP ports that should be publicly accessible.
• Source ranges (CIDRs): restrict access by IP allow-lists. When using LoadBalancer, set spec.networking.sourceRanges to CIDR blocks (e.g., ["203.0.113.0/24"]). This maps to Kubernetes service.spec.loadBalancerSourceRanges.

Important: sourceRanges only take effect when expose mode is LoadBalancer. ClusterIP and NodePort servers do not filter by source CIDR at the Kubernetes level (use firewall rules instead for those modes).

Address Pools (LoadBalancer Only)

When expose mode is LoadBalancer, optionally request a specific address pool or IP address:

• spec.networking.addressPool: name of a load-balancer address pool (e.g., "public-servers" for MetalLB or Cilium).
• spec.networking.address: specific IP address (e.g., "203.0.113.50").

The operator translates these to your load-balancer flavor’s annotations or labels. See the Ingress, TLS & External Access guide for full details.

Automate routine operations

Schedules can run backups and maintenance while probes and restart policy handle unexpected failures.

A BackupSchedule CRD runs backups on a recurring cron schedule. Each scheduled backup job:

1. Saves the server state (config, world data, player data).
2. Stores it at the destination (S3, NAS, local cluster storage).
3. Applies retention policy (delete old backups).
4. Records the operation in the audit log.

Liveness probes and restart policy: GameServers also support Kubernetes-native readiness and liveness probes defined in the template. If a server fails its liveness probe, the kubelet restarts the failing container in place (the pod itself is not recreated). Combined with scheduled backups, this provides automatic recovery from transient failures.

Next guide: Backups and recovery