Kubernetes Platform Sandbox
This sandbox isolates the platform layer: how services are packaged, routed, observed, scaled, and promoted when the application code is intentionally small.
The challenge
Complexity lives in the failure paths
Kubernetes concepts are easy to study in isolation but harder to connect into a working delivery path. The project needed comparable local and AWS models without suggesting that a learning cluster carries production guarantees.
System design
Boundaries before components
Key decisions
Tradeoffs made explicit
Keep local and cloud models comparable
k3d supports fast local iteration while EKS-specific charts and values exercise the same service, ingress, and monitoring boundaries in AWS.
Make deployment state declarative
Helm packages workloads and Argo CD ApplicationSets model promotion across environments instead of relying on undocumented manual commands.
Treat observability as platform behavior
ServiceMonitors, Prometheus, Grafana dashboards, health probes, and scaling rules sit beside the workloads they explain.
Evidence & validation
What can be inspected
- The repository contains containerized FastAPI services, a React client, reusable Helm charts, environment-specific values, and Kubernetes manifests.
- Local paths exercise k3d, ingress-nginx, MetalLB, horizontal pod autoscaling, and load generation.
- EKS paths include Argo CD applications, Nginx and ALB ingress alternatives, ServiceMonitors, Prometheus, and Grafana configuration.
Outcomes
- Creates an inspectable reference for tracing traffic from ingress through services and connecting workload behavior to platform metrics.
- Separates Kubernetes practice from the broader distributed-job system so deployment and operations decisions can be examined directly.
Honest limits
- This is a learning sandbox, not evidence of production scale, uptime, or a fully hardened multi-tenant platform.
- The repository is intentionally exploratory, and its documentation and environment coverage continue to evolve.