A demo application that turns a Kubernetes cluster into a Whack a Mole game, where the moles are pods.
OTHER License
This is a demo that can be used to show how resilient services running on Kubernetes can be. Main app shows a giant sign that flashes in various random colors. Those colors come a Kubernetes powered microservice. If the service goes down, the sign turns red. Your goal is to try and knock the service down by killing the Kubernetes pods that run the service. You can do that by whacking the pods wich are respresented as moles.
There is also a less busy verison of the game available at /next.html. This version has an advanced mode that allows someone to do a more visual explanation of the mechanics.
The advanced version allows you to track the pod that is serving the color service and to simulate creating and destroying nodes.
The current directions assume you are using Google Cloud Platform to take advantage of Container Engine to build a manage your Kubernetes cluster. There is nothing preventing this app from running on a Kubernetes cluster hosted elsewhere, but the directions for setup assume Container Engine. If there is significant interest in these directions, I'll be happy to publish them (or better yet, accept a pull request.)
/Samples.properties
, renamed to /Makefile.properties
PROJECT
to your project idZONE
and REGION
if you want to run this demo in a particular area.CLUSTER
if you want to call your cluster something other thanwhack-a-pod
.INGRESSNAME
if you need to use something other than the default.DOCKERREPO
if you need to use something other Google Container Registry./
.make config
to create your ingress file.I use this application to show off Google Cloud Platform, so I tend set it up multiple times, once per region or datacenter. Therefore, I rename the
INGRESSNAME
andCLUSTER
a bunch. If you only have one cluster, you don't have to fiddle with these.
/infrastructure/
.make build
.make build
will do the following:
If you get the error
ResponseError: code=503, message=Project projectname is not fully initialized with the default service accounts. Please try again later.
You need to navigfate to Compute Engine in Google Cloud console to activate Compute Engine service.
make build
make deploy
gcloud compute addresses describe #INGRESSNAME# --global
There are two skins to the game.
The advanced version of the game is a great demo for teaching some of the fundamentals of Kubernetes. It allows you to cordon and uncordon nodes of the Kubernetes cluster to simulate Node failure. In addition it shows which Pod of the Replica Set is actually answering calls for the service.
/
.make clean
/infrastructure/
.make clean
Whack a Pod can run on Minikube. Its performance isn't stellar, but the game versions of it run just as well a it does on a flaky conference wifi.
minikube addons enable ingress
You can use the Container Registry based commands in the Makefiles to build and host your Docker images.
make build
This still requires a Google Cloud Platform Project. If you would like to build
them some other way, you can, nothing restricts you from doing so. Just make
sure you set $(DOCKERREPO)
to the right value in Makefile.properties.
Alternatively, to host your images on DockerHub,
Makefile.properties
, change the value of PROJECT
so that it equals your image repository slugMakefile.properties
, change the value of DOCKERREPO
so that it looks like yourusername/$(PROJECT)
make build.dockerhub
Your repository should have three new images with the tags:
For example, if your username is username
and your repository name is wap
, your images will be pushed to:
minikube start --vm-driver=xhyve
make deploy.minikube
minikube ip
to get the IP address of the Minikube deployment.minikube.wap
.minikube start
make deploy.minikube.dockerhub
"minikube.wap"
stringsudo vim /etc/hosts
, append the last line to the /etc/hosts
and save the file.kubectl get ing --watch
and wait till the ADDRESS
column has a value)make clean.minikube
minikube stop
This method is for generic usage and can be run on any Kubernetes installation. There are few differences:
DOCKERREPO
defined in Makefile.propertiesNodePort
type for ingress servicemake build.generic
OR skip building by setting DOCKERREPO
to cloudowski and use prebuilt images availabe on dockerhubmake deploy.generic
whackapod.example.com
in your /etc/hosts
pointing to IP address of your load balancer in front of ingress controller or one of nodes IP (when using NodePort
)make clean.generic
There are three Kubernetes services that make up the whole application:
"This is not an official Google Project."