Advanced on Agones

System Diagram

Thu, 18 Apr 2024 00:00:00 +0000

Agones Control Plane

The Agones Control Plane consists of 4 Deployments:

NAME                READY   UP-TO-DATE   AVAILABLE   AGE
agones-allocator    3/3     3            3           40d
agones-controller   2/2     2            2           40d
agones-extensions   2/2     2            2           40d
agones-ping         2/2     2            2           40d

`agones-allocator`

agones-allocator provides a gRPC/REST service that translates allocation requests into GameServerAllocations. See Allocator Service for more information.

`agones-controller`

agones-controller maintains various control loops for all Agones CRDs (GameServer, Fleet, etc.). A single leader-elected Pod of the Deployment is active at any given time (see High Availability).

Scheduling and Autoscaling

Thu, 03 Jan 2019 05:45:05 +0000

Cluster Autoscaler

Kubernetes has a cluster node autoscaler that works with a wide variety of cloud providers.

The default scheduling strategy (Packed) is designed to work with the Kubernetes autoscaler out of the box.

The autoscaler will automatically add Nodes to the cluster when GameServers don’t have room to be scheduled on the clusters, and then scale down when there are empty Nodes with no GameServers running on them.

This means that scaling Fleets up and down can be used to control the size of the cluster, as the cluster autoscaler will adjust the size of the cluster to match the resource needs of one or more Fleets running on it.

High Availability Agones

Tue, 28 Feb 2023 00:00:00 +0000

High Availability for Agones Controller

The agones-controller responsibility is split up into agones-controller, which enacts the Agones control loop, and agones-extensions, which acts as a service endpoint for webhooks and the allocation extension API. Splitting these responsibilities allows the agones-extensions pod to be horizontally scaled, making the Agones control plane highly available and more resilient to disruption.

Multiple agones-controller pods enabled, with a primary controller selected via leader election. Having multiple agones-controller minimizes downtime of the service from pod disruptions such as deployment updates, autoscaler evictions, and crashes.

Controlling Disruption

Tue, 24 Jan 2023 20:15:26 +0000

Disruption in Kubernetes

A Pod in Kubernetes may be disrupted for involuntary reasons, e.g. hardware failure, or voluntary reasons, such as when nodes are drained for upgrades.

By default, Agones assumes your game server should never be disrupted voluntarily and configures the Pod appropriately - but this isn’t always the ideal setting. Here we discuss how Agones allows you to control the two most significant sources of voluntary Pod evictions, node upgrades and Cluster Autoscaler, using the eviction API on the GameServer object.

Limiting CPU & Memory

Thu, 03 Jan 2019 05:45:15 +0000

As a short description:

CPU Requests are limits that are applied when there is CPU congestion, and as such can burst above their set limits.
CPU Limits are hard limits on how much CPU time the particular container gets access to.

This is useful for game servers, not just as a mechanism to distribute compute resources evenly, but also as a way to advice the Kubernetes scheduler how many game server processes it is able to fit into a given node in the cluster.

Out of Cluster Dev Server

Tue, 15 Aug 2023 07:00:00 +0000

This section builds upon the topics discussed in local SDK Server, Local Game Server, and GameServer allocation (discussed here, here, and here). Having a firm understanding of those concepts will be necessary for running an “out of cluster” local server.

Running an “out of cluster” dev server combines the best parts of local debugging and being a part of a cluster. A developer will be able to run a custom server binary on their local machine, even within an IDE with breakpoints. The server would also be allocatable within a cluster, allowing integration with the project’s full stack for handling game server lifetime.

Allocator Service

Fri, 25 Oct 2019 05:45:05 +0000

To allocate a game server, Agones provides a gRPC and REST service with mTLS authentication, called agones-allocator that can be used instead of GameServerAllocations .

Both gRPC and REST are accessible through a Kubernetes service that can be externalized using a load balancer. By default, gRPC and REST are served from the same port. However, either service can be disabled or the services can be served from separate ports using the helm configuration.

Multi-cluster Allocation

Fri, 25 Oct 2019 05:45:05 +0000

This implementation of multi-cluster allocation was written before managed and open source multi-cluster Service Meshes such as Istio and Linkerd, were available and so widely utilised.

We now recommend implementing a Service Mesh in each of your Agones clusters and backend services cluster to provide a multi-cluster allocation endpoint that points to each Agones cluster’s Allocation Service.

Service Mesh specific projects provide far more powerful features, easier configuration and maintenance, and we expect that they will be something that you will likely be installing in your multi-cluster architecture anyway.

GameServer Pod Service Accounts

Mon, 01 Apr 2019 00:00:00 +0000

Default Settings

By default, Agones sets up service accounts and sets them appropriately for the Pods that are created for GameServers.

Since Agones provides GameServer Pods with a sidecar container that needs access to Agones Custom Resource Definitions, Pods are configured with a service account with extra RBAC permissions to ensure that it can read and modify the resources it needs.

Since service accounts apply to all containers in a Pod, Agones will automatically overwrite the mounted key for the service account in the container that is running the dedicated game server in the backing Pod. This is done since game server containers are exposed publicly, and generally don’t require the extra permissions to access aspects of the Kubernetes API.