Skip to content
This repository has been archived by the owner on Sep 28, 2021. It is now read-only.

Latest commit

 

History

History
45 lines (38 loc) · 2.87 KB

gameserver_spec.md

File metadata and controls

45 lines (38 loc) · 2.87 KB

GameServer Specification

Like any other Kubernetes resource you describe a GameServer's desired state via a specification written in YAML or JSON to the Kubernetes API. The Agones controller will then change the actual state to the desired state.

A full GameServer specification is available below and in the example folder for reference :

apiVersion: "stable.agones.dev/v1alpha1"
kind: GameServer
metadata:
  name: "gds-example"
spec:
  container: example-server
  portPolicy: "static"
  containerPort: 7654
  hostPort: 7777
  protocol: UDP
  health:
    disabled: false
    initialDelaySeconds: 5
    periodSeconds: 5
    failureThreshold: 3
  template:
    metadata:
      labels:
        myspeciallabel: myspecialvalue
    spec:
      containers:
      - name: example-server
        image: gcr.io/agones/test-server:0.1
        imagePullPolicy: Always

Since Agones defines a new Custom Resources Definition (CRD) we can define a new resource using the kind GameServer with the custom group stable.agones.dev and API version v1alpha1.

You can use the metadata field to target a specific namespaces but also attach specific annotations and labels to your ressource. This is a very common pattern in the Kubernetes ecosystem.

The spec field is the actual GameServer specification and it is composed as follow:

  • container is the name of container running the GameServer in case you have more than one container defined in the pod. If you do, this is a mandatory field. For instance this is useful if you want to run a sidecar to ship logs.
  • portPolicy has two options dynamic (default) the system allocates a free hostPort for the gameserver, for game clients to connect to. And static, user defines the hostPort that the game client will connect to. Then onus is on the user to ensure that the port is available. When static is the policy specified, hostPort is required to be populated.
  • containerPort the port that is being opened on the game server process, this is a required field.
  • protocol the protocol being used. Defaults to UDP. TCP is the only other option.
  • health to track the overall healthy state of the GameServer, more information available in the health check documentation.
  • template the pod spec template to run your GameServer containers, see for more information.