SnowOps Labs is a Kubernetes platform-engineering simulator. One command
builds a production-shaped cluster on your laptop: real Prometheus, Grafana,
Loki, Tempo, Argo CD, Istio, Kafka and Vault, not mocks. Then it breaks that
cluster in ways you will meet on call, and grades how you fix it against the
live cluster.
Practise what production never lets you practise: finding why every pod is
Ready while a third of requests fail, draining a node under load without
breaking the SLO, or picking a service mesh with evidence instead of opinion.
It runs on macOS (Apple Silicon and Intel), Linux and Windows via WSL2, or in
your browser through GitHub Codespaces.
Try it
git clone --branch stable https://github.com/snowops-oss/snowopslabs.git
cd snowopslabs && ./install.sh
labctl init # cluster + platform, 5 to 10 minutes
labctl incident inject crashloop-bad-config --deploy-prereqs
labctl incident status # hints, and whether you fixed it
No Docker on this machine? Open it in GitHub Codespaces
and skip to Your first lab.
Status: stable releases ship on the stable branch, with every fault
checked against a live cluster each night. What comes next is on the
roadmap; bugs and ideas go in
issues.
The four loops
| Loop | What you do | Command |
|---|
| Build | Stand up a cluster and install a real platform stack from swappable providers | labctl init |
| Simulate | Activate a scenario with objectives and checks that grade your work | labctl scenario up <name> |
| Break | Inject a reversible fault while traffic flows and alerts fire | labctl incident inject <name> |
| Measure | Grade the outcome: checks passed, time to resolve, hints used | labctl scenario verify <name> |
Failures are injected into the real systems, so the signal you debug is the
signal you would see in production.
Who it is for
| You are | You use it to |
|---|
| An engineer learning Kubernetes operations | Work through a learning path, then debug each class of failure without help |
| A platform team choosing a tool | Swap a provider, run the same scenario on both, and compare the results |
| An SRE running a game day | Inject faults, unnamed if you like, and measure time to resolve across sessions |
| A lead assessing skills | Run timed challenges with the same faults, grading and par time for everyone |
What you can practise
Every scenario and fault below ships today and is graded by checks against
the live cluster.
13 scenarios (catalog):
| Area | Scenarios |
|---|
| Observability | observability-sre: wire traces through a collector, follow one request across logs, metrics and traces, fire an SLO alert |
| Scaling and cost | autoscaling-under-load (KEDA on Prometheus RPS) · cost-right-sizing (OpenCost, requests sized to measured peak) |
| Delivery | gitops-cicd (Argo CD against a repo you push to) · env-promotion (dev to staging to prod) · mesh-traffic-management (Istio canary, fault injection, mTLS) |
| Security | security-compliance (Kyverno audit to enforce, cert-manager) · secrets-management (Vault rotation through External Secrets) |
| Reliability | chaos-engineering (Chaos Mesh experiments with a hypothesis) |
| Data | event-driven-arch (a Kafka consumer group falling behind) |
| Day-2 operations | node-drain-drill · cluster-upgrade-drill · backup-restore-drill, each graded on live traffic |
12 faults (library), for example:
| Fault | What you walk into |
|---|
dns-egress-blocked | A security policy forgot port 53. Every pod is Ready, /health answers, and requests that call the upstream fail. |
stray-pod-behind-service | A steady fraction of requests fails. Every pod is Ready, and the app's own error panel is flat. |
cpu-throttling | p99 latency is in seconds, with no restarts, no errors and a nearly idle node. |
missing-secret-key | After a credential rotation, no pod starts and there are no logs to read. |
4 timed challenges (on-call-shift lands two unnamed faults at once) and
the kubernetes-foundations learning path tie these together into a
curriculum.
See it in action
Every asset below is real labctl output and the actual embedded UI.
Inspect a scenario before you run it. labctl scenario info shows what a
scenario installs: its stages, objectives, the checks that grade you, and
commands to explore with:
Drive it from a browser. labctl ui serves a web dashboard at
http://localhost:3939, built into the same binary:
More of the dashboard (click a thumbnail for full size):
| Fault library | Platform components | Operate hub |
|---|
| | |
Watch the setup. A video walkthrough on YouTube
explains what the lab is and sets it up on a Mac, following the same steps
as Install.
How it compares
| Option | What it leaves out |
|---|
| Browser-based labs | Small clusters with no observability stack and no realistic failures |
| Certification courses (CKA/CKAD) | They test what you know, not how you respond to an incident under time pressure |
| Internal game days | Setup costs so much that they happen once or twice a year |
This is the beginning of the README. Read the rest at the original. Read the full README ↗
