what is kubernetes-troubleshooting-lab fr?

This repository is a hands on training lab for troubleshooting Kubernetes, aimed at engineers who want to practice the kind of diagnostic work expected from a mid level or senior DevOps or platform engineer. It contains fifteen realistic failure scenarios, each one runnable on Minikube, Kind, or Amazon EKS, and each modeled on incidents that actually happen in production clusters. Every scenario follows the same structure: an overview of what is failing and why it matters, the exact symptoms an operator would see through kubectl commands, the root cause, a step by step diagnosis path, several possible fixes with their tradeoffs, best practices to prevent the issue from happening again, and production tips drawn from experienced platform engineers. The scenarios are grouped by the layer of the system they touch. Workload level problems include CrashLoopBackOff, ImagePullBackOff, out of memory kills, and CPU throttling. Scheduling and capacity problems include pods stuck in a pending state, nodes that are not ready, and autoscaling issues with Karpenter. Networking problems cover CoreDNS failures, broken ingress routing, and network policies blocking traffic. There is a storage scenario about persistent volume claims stuck pending, and control plane scenarios covering RBAC permissions, etcd, and the Kubernetes API server itself. The README also teaches a general five question triage method: what is failing, where it is failing, why it is failing, since when, and how far the blast radius reaches. This method is meant to build a repeatable way of thinking rather than memorized commands, so it should transfer to problems the lab does not explicitly cover. Each scenario lives in its own folder with a Kubernetes manifest that reproduces the failure, plus any supporting service or configuration files needed. The project is licensed under MIT and welcomes contributions, with a roadmap for adding more scenarios over time. No specific programming language is listed for the repository, since it is built almost entirely from YAML manifests and Markdown documentation rather than application code.