Lab 20: Platform Engineering¶
| Field | Value |
|---|---|
| Tier | 4 — Advanced |
| Estimated Time | 90 minutes |
| Prerequisites | k3s cluster, Helm |
| Auto-Grade | Yes |
Scenario¶
Your company has 30 development teams, each deploying their own microservices. Every team reinvents the wheel: writing their own Kubernetes manifests, CI/CD pipelines, monitoring dashboards, and alerting rules. Deployments are inconsistent, half the teams have no health checks, and there is no standard way to create a new service.
The CTO has asked you to build an internal developer platform. The first deliverable is a "service template" — a Helm chart that any team can use to deploy a standard microservice with all the best practices baked in: deployment with resource limits, health checks, HPA, PDB, service, ingress, monitoring annotations, and network policies. Teams only need to provide a few values (image, port, replicas) and they get a production-ready deployment.
Objectives¶
- Create a Helm chart
service-templatein/tmp/lab-platform/charts/ - Chart deploys: Deployment, Service, HPA, PDB, and ServiceAccount
- Chart uses
values.yamlwith sensible defaults (image, replicas, resources, port) - Chart includes health check probes (configurable via values)
- Chart adds Prometheus scrape annotations when
metrics.enabled: true - Deploy two instances of the chart with different values (team-alpha, team-beta)
- Both instances are running in namespace
lab-platform
Setup¶
Creates the working directory and namespace.
Hints¶
Hint 1: Helm chart structure
Hint 2: Templating values
Use `{{ .Values.image.repository }}:{{ .Values.image.tag }}` in templates. Use `{{ .Release.Name }}` for resource names to support multiple instances.Hint 3: Conditional Prometheus annotations
Hint 4: Installing two instances
Hint 5: Default values
Good defaults make the chart usable without any custom values. Set image to `nginx:alpine`, replicas to 2, port to 80, memory limit to 128Mi.Grading¶
Solution¶
See the solution/ directory for the complete Helm chart.