System Diagram

A pictoral overview of the Agones component relationships.

System Diagram

Agones Control Plane

The Agones Control Plane consists of 4 Deployments:

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 provides a gRPC/REST service that translates allocation requests into GameServerAllocations. See Allocator Service for more information.


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).


agones-extensions is the endpoint for:

  • Agones-installed Kubernetes webhooks, which handle defaulting and validation for Agones CRs,
  • and the GameServerAllocation APIService, which handles GameServer allocations (either from the Allocator Service or the Kubernetes API).

agones-ping (not pictured)

agones-ping is a simple ping service for latency testing from your game client - see Latency Testing.

Agones CRDs

See Create a Game Server, Create a Game Server for examples of Agones CRDs in action, or the API Reference for more detail.

All of the Agones CRDs are controlled and updated by agones-controller. GameServer is additionally updated by the SDK Sidecar and agones-extensions (moving a GameServer from Ready to Allocated

Game Server Pod

Also pictured is an example Pod owned by a GameServer. Game clients typically connect to the Dedicated Game Server directly, or via a proxy like Quilkin. The game server server interfaces with Agones using the Client SDK, which is a thin wrapper around the SDK gRPC protocol. The SDK connects to the SDK Sidecar (sdk-server) in the same Pod, which handles the SDK business logic for e.g. health checks, Counters and Lists, etc.

Last modified July 23, 2024: Graduate Passthrough Port Policy to Beta on Autopilot (#3916) (205e87e)