In this tutorial, we are going to show you how to install Agones on your OVHcloud Managed Kubernetes Service. Agones is an open-source, multiplayer, dedicated game-server hosting built on Kubernetes.
Additionally, to test your install, you will install a Xonotic game server and play some old school death matches…
Before you begin
This tutorial assumes that you already have a working OVHcloud Managed Kubernetes cluster, and some basic knowledge of how to operate it. If you want to learn more about these topics, please look at the deploying a Hello World application article.
You also need to have Helm installed on your workstation and your cluster, please refer to the How to Install Helm on OVHcloud Managed Kubernetes Service tutorial.
What is Agones?
One of the key advantages to using Kubernetes is the formidable ecosystem around it. From Rancher to Istio, from Rook to Fission, from gVisor to KubeDB, the Kubernetes ecosystem is rich, vibrant and ever-growing. We are getting to the point where, for most deployment needs, we can say there is a K8s-based open-source project for that.
One of the latest additions to this ecosystem is the Agones project, an open-source, multiplayer, dedicated game-server hosting platform built on Kubernetes and developed by Google in collaboration with Ubisoft.
Agones, derived from the Greek word agōn (contests held during public festivals or more generally “contest” or “competition at games”), aims to replace the usual proprietary solutions to deploy, scale, and manage game servers.
Agones enriches Kubernetes with a Custom Controller and a Custom Resource Definition. With these tools, you can standardize Kubernetes tooling and APIs to create, scale, and manage game server clusters.
What kind of game servers?
Agones’s main focus is online multiplayer games such as FPSs and MOBAs - fast-paced games requiring dedicated, low-latency game servers that synchronize the state of the game between players and serve as a source of truth for gaming situations.
These kinds of games ask for relatively ephemeral dedicated gaming servers, with every match running on a server instance. The servers need to be stateful (they must keep the game status), with the state usually held in memory for the duration of the match.
Latency is a key concern, as the competitive real-time aspects of the games ask for quick responses from the server. That means that the connection from the player device to the game server should be the most direct possible, ideally bypassing any intermediate server such as a load-balancer.
Connecting players to the right server
Every game publisher used to have their own proprietary solutions, but most of them follow a similar flow, with a matchmaking service that groups players into a match, deals with a cluster manager to provision a dedicated instance of a game server, and sends the players its IP address and port to allow them to directly connect to the server and play the game.
Agones, as well as its Custom Controller and Custom Resource Definition, replaces the complex cluster management infrastructure with a standardized, Kubernetes-based tooling and APIs. The matchmaker services interact with these APIs to spawn new game server pods and get their IP addresses and ports to the concerned players.
The cherry on top
Using Kubernetes for these tasks also gives some nice additional bonuses like being able to deploy the full gaming infrastructure in a developer environment like minikube, or easily cloning it to deploy it in a new data center or cloud region, but also offering a whole platform to host all the additional services needed to build a game: account management, leaderboards, inventory…
And of course, the simplicity of operating Kubernetes-based platforms, especially when they dynamic, heterogeneous and distributed, as most online gaming platforms.
Deploying Agones on OVHcloud Managed Kubernetes
There are several ways to install Agones in a Kubernetes cluster. For our test, we chose the easiest one: installing with Helm.
Enabling creation of RBAC resources
The first step to install Agones is to set up a service account with enough permissions to create some special RBAC resource types.
kubectl create clusterrolebinding cluster-admin-binding --clusterrole=cluster-admin --serviceaccount=kube-system:default
Now we have the Cluster Role Binding needed for the installation:
$ kubectl create clusterrolebinding cluster-admin-binding --clusterrole=cluster-admin --serviceaccount=kube-system:default clusterrolebinding.rbac.authorization.k8s.io/cluster-admin-binding created
Installing the Agones chart
Now let’s continue by adding Agones repository to Helm’s repository list.
helm repo add agones https://agones.dev/chart/stable
Then, install the stable Agones chart:
helm install my-agones --namespace agones-system --create-namespace agones/agones
After a few moments, Agones should be installed:
$ helm repo add agones https://agones.dev/chart/stable "agones" has been added to your repositories $ helm install my-agones --namespace agones-system --create-namespace agones/agones NAME: my-agones LAST DEPLOYED: Fri Dec 9 09:35:16 2022 NAMESPACE: agones-system STATUS: deployed REVISION: 1 TEST SUITE: None NOTES: The Agones components have been installed in the namespace agones-system. You can get their status by running: kubectl --namespace agones-system get pods -o wide Once ready you can create your first GameServer using our examples https://agones.dev/site/docs/getting-started/create-gameserver/ . Finally don't forget to explore our documentation and usage guides on how to develop and host dedicated game servers on top of Agones: - Create a Game Server (https://agones.dev/site/docs/getting-started/create-gameserver/) - Integrating the Game Server SDK (https://agones.dev/site/docs/guides/client-sdks/) - GameServer Health Checking (https://agones.dev/site/docs/guides/health-checking/) - Accessing Agones via the Kubernetes API (https://agones.dev/site/docs/guides/access-api/)
Warning: The installation we have just done isn’t suited for production since the official installation instructions recommend running Agones and the game servers in separate, dedicated pools of nodes. But for the needs of our test, the basic setup is enough.
Confirming Agones started successfully
To verify that Agones is running on our Kubernetes cluster, we can look at the pods in the
kubectl get --namespace agones-system pods
If everything is okay, you should see an
agones-controller pod with a
$ kubectl get --namespace agones-system pods NAME READY STATUS RESTARTS AGE agones-allocator-6db787b757-4vd7r 1/1 Running 0 95s agones-allocator-6db787b757-kvdkz 1/1 Running 0 95s agones-allocator-6db787b757-w9mjw 1/1 Running 0 95s agones-controller-fc95bcbd7-8zv4q 1/1 Running 0 95s agones-ping-6fd4dd9b48-r49qq 1/1 Running 0 95s agones-ping-6fd4dd9b48-w6pzd 1/1 Running 0 95s
You can also see more details using:
kubectl describe --namespace agones-system pods
Looking at the
agones-controller description. You should see something like:
$ kubectl describe --namespace agones-system pods Name: agones-controller-fc95bcbd7-8zv4q Namespace: agones-system [...] Conditions: Type Status Initialized True Ready True ContainersReady True PodScheduled True
Here all the
Conditions should have the status
Deploying a game server
The Agones Hello world is rather boring, a simple Xonotic game server.
Xonotic is an open-source multi-player FPS, and a rather good one, with lots of interesting game modes, maps, weapons, and customization options.
Deploying a Xonotic game server over Agones is rather easy:
kubectl create -f https://raw.githubusercontent.com/googleforgames/agones/release-1.27.0/examples/xonotic/gameserver.yaml
This command installs Xonotic:
$ kubectl create -f https://raw.githubusercontent.com/googleforgames/agones/release-1.27.0/examples/xonotic/gameserver.yaml gameserver.agones.dev/xonotic created
The game server deployment can take a few moments, so we need to wait until its status is
Unhealthy before using it. We can fetch the status with:
kubectl get gameserver
We will wait until the fetch gives a
Unhealthy status on our game server:
$ kubectl get gameserver NAME STATE ADDRESS PORT NODE AGE xonotic Ready 51.83.xxx.yyy 7410 nodepool-f636da5d-3d0d-481d-aa-node-f4d042 24s
When the game server is ready, we also get the address and the port we should use to connect to our death match game (in my example,
It’s frag time
So now that you have a server, let’s test it!
Download the Xonotic client (for Windows, Linux, or MacOS), and launch it:
Then go to the Multiplayer menu and enter the address and port of our game server:
And you are ready to play!
And on the server side?
On the server side, you can spy on how things are going for your game server, using
kubectl logs. Let’s begin by finding the pod running the game:
kubectl get pods
You will see that your game server is running in a pod called
$ kubectl get pods NAME READY STATUS RESTARTS AGE xonotic 2/2 Running 0 2m28s
You can then use
kubectl logs on it. In the pod there are two containers - the main
xonotic one and an Agones sidecar - so we must specify that we want the logs of the
$ kubectl logs xonotic xonotic >>> Connecting to Agones with the SDK >>> Starting health checking >>> Starting wrapper for Xonotic! >>> Path to Xonotic server script: /home/xonotic/Xonotic/server_linux.sh  Game is Xonotic using base gamedir data gamename for server filtering: Xonotic Xonotic Linux 20:37:34 Jun 27 2022 - release Current nice level is below the soft limit - cannot use niceness Skeletal animation uses SSE code path execing quake.rc [...] >>> Found 'listening' statement: 2 Server using port 26000 Server listening on address 0.0.0.0:26000 Server listening on address [0:0:0:0:0:0:0:0]:26000 execing server.cfg maxplayers can not be changed while a server is running. It will be changed on next server startup ("map" command). "maxplayers" set to "8" Game type successfully switched to dm Maplist contains no usable maps! Resetting it to default map list. Switching to map silentsiege menu: unknown program name Server using port 26000 >>> Found 'listening' statement: 3 Server listening on address 0.0.0.0:26000 >>> Found 'listening' statement: 4 >>> Moving to READY: Server listening on address [0:0:0:0:0:0:0:0]:26000 Server listening on address [0:0:0:0:0:0:0:0]:26000
Add some friends
The next step is the best one - ask some friends to connect to the server and do a true death match like in the Quake 2 times.
Uninstall Xonotic game server:
kubectl delete gameserver
To uninstall Agones, you can use the
helm uninstall command in order to delete the Agones Helm chart:
helm uninstall my-agones -n agones-system
Remove installed Cluster Role Binding:
kubectl delete clusterrolebinding cluster-admin-binding