# kubeinvaders lets you shoot pods to see what your cluster does next

> kubeinvaders is a chaos engineering tool that turns Kubernetes resilience testing into a Space Invaders game, where every alien is a pod or a node. The current version ships a simulated KWOK cluster so you can try it without touching anything real, and the same binary can be pointed at a real cluster with a service account token.

**lucky-sideburn/kubeinvaders** — Gamified Chaos Engineering Tool for Kubernetes

- Repository: https://github.com/lucky-sideburn/kubeinvaders
- Stars: 1,131 · Forks: 148
- Language: JavaScript
- License: Apache-2.0
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/lucky-sideburn-kubeinvaders

## The demo cluster means you can try it safely first

The quick start needs no cluster at all, which is the design decision that makes the tool easy to evaluate. The image embeds a demo Kubernetes cluster powered by KWOK, already connected to the game, and running it is a single container invocation:

```bash
podman run --rm -p 8080:8080 docker.io/luckysideburn/kubeinvaders:latest
# or
docker run --rm -p 8080:8080 docker.io/luckysideburn/kubeinvaders:latest
```

Open the port and start shooting. Nodes and pods are simulated and nothing real is deleted. The switch to a real cluster is available at any time from the Kubernetes Connection form in the web console, or by starting the container with `KWOK_ENABLED=false` and your cluster settings. The demo cluster also starts only when no cluster is configured, so passing a token or running inside a pod disables it automatically, and a slim image without KWOK can be built with the build argument `WITH_KWOK=false`. The details and the limitations are in a separate document on the demo cluster.

## Connecting to a real cluster takes RBAC and a token

The container talks to the cluster with a ServiceAccount token, and the setup is three steps. First the RBAC and the target namespaces are created, with the manifest requiring Kubernetes v1.24 or newer:

```bash
kubectl apply -f manifests/kubeinvaders-rbac.yaml
kubectl create namespace namespace1
kubectl create namespace namespace2
```

Then a token is obtained, either the one stored in a secret or a short-lived one created on demand:

```bash
TOKEN=$(kubectl get secret kinv-sa-token -n kubeinvaders -o go-template='{{.data.token | base64decode}}')
# or a short-lived one
TOKEN=$(kubectl create token kinv-sa -n kubeinvaders --duration=8h)
```

The short-lived form is the better default, because a token that expires in eight hours cannot be left lying around in a shell history. The last step is running the container with the connection details, either by filling in the web console form with the API endpoint, token, comma-separated namespaces and, for a self-signed cluster, the CA certificate, or by passing environment variables. If the token is missing, invalid or expired, the tool cannot call the Kubernetes API and the game actions fail, which is a sensible failure mode: it does nothing rather than acting on a half-configured cluster.

## The namespace list is the blast radius

Two environment variables define what the game is allowed to touch, and the second one is the one to think about. `NAMESPACE` takes a comma-separated list of namespaces, so `NAMESPACE=namespace1,namespace2` restricts the game to those two, and the manifest in the repository defines the permissions the ServiceAccount is bound to. The other variables are the API server address and port, `KUBERNETES_SERVICE_HOST` and `KUBERNETES_SERVICE_PORT_HTTPS`. There is also a `DISABLE_TLS=true` switch, and the documentation is clear about its cost: it skips the verification of the API server certificate, and the advice is to drop it if your cluster certificate is trusted. That is the right default in a lab, and the wrong default in production, and the variable name gives no hint of that, so it is worth reading before copying a command line.

## The v2 rewrite moved the game to a web console

The release history shows two distinct products. v2.0, released on 2026-03-16 with the tag naming web_console_access, is the current version, and it is a web application: the container serves the interface on port 8080 and you connect from a browser. The v1.9.7 line from 2024 has a separate documented path for running the legacy version with a different set of environment variables, including `APPLICATION_URL`, `INSECURE_ENDPOINT` and the same token, host, port and namespace variables, and the image reference is a local tag rather than the published one. The two versions are documented separately because the environment variable contract changed, and the legacy section spells out that you need to extract the service account token first with a differently ordered kubectl command. If you have scripts around the old version, the v2 variable names will not match.

## The container is a small server stack, not a single binary

The Dockerfile shows what the tool is actually made of, and it is more than a game loop. The base image is OpenResty on bookworm, which gives you nginx and Lua, and the package list adds wget, procps, jq, openssl, task-spooler, Python 3 with pip, Redis and the Python Kubernetes client. The Kubernetes client is what talks to the API server, Redis backs the game state and the URL monitoring, and task-spooler is there to run background jobs. There is a `kube-linter/` directory at the root and a copy of the kube-linter binary is downloaded at build time, plus a parser script for it, and the front end is copied in as static HTML. The JavaScript front end and the Python back end are separate, which is why the image needs both runtimes, and it is also why the repository has a `confs/` directory and an `nginx/` directory for the web server configuration.

## There is a metrics story and a documentation set

The documentation list is a good map of the actual capability. There is a usage document covering game controls, keyboard shortcuts and on-screen information, a features document that names chaos containers for nodes, URL monitoring during chaos sessions and persistence, a Prometheus metrics document that mentions a Grafana dashboard, the KWOK demo cluster document, a step-by-step example with Podman and MiniKube, and a troubleshooting document. The URL monitoring during chaos sessions is the part that pushes this beyond a toy: it lets you point a synthetic check at your service while you are killing pods, so you can watch whether the service degrades, recovers, or pages someone. The repository also has a `minikube-setup/` directory, a `manifests/` directory, an `entrypoint.sh`, and a `helm-charts/` directory holding a legacy chart, which the README notes can be a starting point even though an official Helm chart is not currently supported.

## A teaching tool with an enterprise backing

The project describes itself as recommended by the CNCF and listed in the CNCF landscape under Observability and Analysis, Chaos Engineering, and it is used for teaching Kubernetes, for resilience testing, and at tech conferences. It is backed by two organisations, Platform Engineering and GDT Garanti Del Talento, which the README says provide enterprise-grade features and SRE experts, and the project is recommended by the CNCF sandbox. The original concept was Space Invaders, and the stated idea is that every alien is a pod or a node, so you shoot it and watch how your cluster reacts under pressure. The licence is Apache 2.0. The community channels are a Twitter account and a YouTube channel, and the README collects a list of community blogs and talks including a Kubernetes.io post, an AdaCon Norway stream and a LILiS talk.

## Conclusion

Adopt kubeinvaders if you want a low-stakes way to teach your team how a Kubernetes cluster behaves when pods disappear, since the game makes the failure visible to people who would not otherwise sit through a chaos experiment. Do not adopt it as a substitute for a real chaos engineering programme, because shooting pods is a narrow action and the tool does not cover the rest of the failure surface. Verify first which cluster you are connected to before you start shooting, that the RBAC you apply grants no more than the namespaces you intend, and that the demo cluster is actually the one running, since the container starts a simulated cluster whenever no real one is configured.

## FAQ

### Can I try kubeinvaders without a Kubernetes cluster?

Yes. The image embeds a demo cluster powered by KWOK that is already connected to the game, so `docker run --rm -p 8080:8080 docker.io/luckysideburn/kubeinvaders:latest` gives you a playable game where nothing real is deleted.

### How do I connect kubeinvaders to a real cluster?

Apply the RBAC manifest and create your target namespaces, get a service account token, then run the container with `KWOK_ENABLED=false` and the connection details, either through the web console form or through environment variables including `K8S_TOKEN`, `KUBERNETES_SERVICE_HOST`, `KUBERNETES_SERVICE_PORT_HTTPS` and `NAMESPACE`.

### What does DISABLE_TLS do in kubeinvaders?

It skips the verification of the API server certificate. The documentation advises dropping it if your cluster certificate is trusted, so it is meant for lab clusters with self-signed certificates rather than for production.

### Which version of kubeinvaders is current?

Version 2.0, released on 2026-03-16, is the current one and serves the game through a web console on port 8080. The legacy version 1.9.7 from 2024 is still documented separately with its own set of environment variables.

### Does kubeinvaders expose Prometheus metrics?

Yes, there is a Prometheus metrics document in the documentation along with a Grafana dashboard, and the features documentation covers chaos containers for nodes, URL monitoring during chaos sessions and persistence of the game state.

## Sources

- [Issues](https://github.com/lucky-sideburn/kubeinvaders/issues)
- [License: Apache-2.0](https://github.com/lucky-sideburn/kubeinvaders/blob/master/LICENSE)
- [lucky-sideburn/kubeinvaders on GitHub](https://github.com/lucky-sideburn/kubeinvaders)
- [README](https://github.com/lucky-sideburn/kubeinvaders/blob/master/README.md)
- [Releases](https://github.com/lucky-sideburn/kubeinvaders/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/lucky-sideburn-kubeinvaders