Hands-on experiment building microservices and cloud native applications

Running with Kubernetes


Starting game services locally

  1. Obtain the source for the root project (gameontext/gameon)
  2. Change to the gameon directory

    $ cd gameon
  3. Setup your environment (one time, see below).

    $ ./ choose       # choose Docker Compose
    $ eval $(./ env)  # set script aliases
    $ alias go-run               # confirm `docker/`
  4. Set up core game services (repeatable):

    $ go-run setup

    This will ensure you have the right versions of applications we use, prompt to use helm or not, and create a certificate for signing JWTs.

    If your cluster IP changes (or you have made changes to some templated files and want to start over), use:

    $ go-run reset

    All script commands in the following steps will show the command (kubectl or helm) being invoked, so you can follow along, or invoke on your own.

  5. Start core game services:

    $ go-run up

    This step will also create a gameon-system name space and a generic kubernetes secret containing that certificate.

  6. Wait for the system warm up

    $ go-run wait

    or, to watch the action, visit the kubernetes dashboard. For example, with minikube, try:

    $ minikube dashboard
  7. Carry on with building your room!
  8. Clean up

    $ go-run down

Files supporting Kubernetes

The kubernetes subdirectory of the root project contains the following:

  • chart/gameon-system (directory) defines a helm chart for deploying core game services
  • kubectl (directory) defines individual YAML files to create Kubernetes artifacts (config maps, services, and deployments)
  • .template.configmap.yaml, .template.ingress.yaml, and .template.values.yaml are copied into the kubectl and chart directories by the setup script once the cluster IP address is known.
  • helps with starting, stopping, and cleaning up Game On! core services.
  • k8s-functions contains most of the functions working directly with kubectl or helm.


When Game On! runs in the cloud, it uses etcd to obtain its configuration. When running locally it expects all this to be fed to it via the environment.

With Kubernetes, configuration is injected via ConfigMap objects: * When using kubectl alone, configuration attributes are provided by kubectl/configmap.yaml. * When using helm, configuration attributes are provided by chart/gameon-system/values.yaml

As referenced earlier, these files won’t exist until the setup script has run at least once.

Rebuilding Core Game services with Kubernetes