Day 28's four-layer architecture ended with "Infrastructure Foundation" as the bottom layer — the part nobody sees, that everything else gets built on. For most organizations doing platform engineering today, that foundation is Kubernetes. But there's a real gap between "we run Kubernetes" and "we've built a platform on Kubernetes," and it's the same gap this whole series has been drawing since Day 19: one is infrastructure, the other is a product built on top of it.
Kubernetes on its own gives you workload scheduling, service discovery, and self-healing — genuinely valuable primitives. What it doesn't give you is a developer portal, golden paths, or a self-service catalog. Those get built on Kubernetes, using its primitives as the foundation, which is exactly why Day 28 put "Infrastructure Foundation" at the bottom of the stack rather than treating it as the whole platform.
Note
"We run Kubernetes" and "we have a platform" are not the same claim. A team can operate a technically excellent Kubernetes cluster and still leave every application team to independently figure out CI/CD, observability, and secrets management on top of it — which is precisely the "ten teams solving the same problem" failure mode from Day 20, just relocated one layer down.
The same four layers, now concrete
SELF-SERVICE EXPERIENCE → Developer Portal, Service Catalog, Docs, APIs, ChatOps
PLATFORM SERVICES → CI/CD (GitOps/ArgoCD), Observability (Prometheus),
Security (Policies/Vault), Secrets Management,
Backup & DR
KUBERNETES CAPABILITIES → Workloads (Deploy/StatefulSet), Networking
(Services/Ingress), Storage (PV/PVC/CSI),
Config (ConfigMaps), Autoscaling (HPA/VPA)
INFRASTRUCTURE FOUNDATION → Compute, Network, Storage, Cloud/HybridReading this bottom-up: Kubernetes exposes reliable, abstracted primitives over raw infrastructure. Platform services are built as reusable capabilities on top of those primitives — the platform team runs Argo CD once, centrally, rather than every application team hand-rolling their own deployment pipeline against the Kubernetes API directly. And the self-service layer is what makes all of it discoverable and usable without a developer needing to understand any of the three layers underneath.
What actually changes when Kubernetes becomes "the platform"
| Without a platform on Kubernetes | With Kubernetes as the platform |
|---|---|
| Each team writes its own manifests, from scratch | Golden path templates generate correct manifests |
| Each team wires up its own CI/CD against the cluster | CI/CD as a service, centrally operated |
| Observability is whatever each team remembers to add | Every workload gets dashboards and tracing by default |
| Kubernetes expertise is a prerequisite for shipping | Kubernetes is invisible to most developers |
That last row is the real measure of success. "Kubernetes + Platform Engineering = Developer Velocity at Scale" only holds if most developers never need to think about Kubernetes at all — they request an environment, and Kubernetes is simply the thing making that request real underneath, the same way most developers don't think about the Linux kernel scheduling their process.
A concrete before/after
Before: each team builds its own way
Team A → hand-rolled Helm charts → own CI/CD → own dashboards
Team B → raw kubectl apply → own CI/CD → no dashboards
Team C → Kustomize, differently → own CI/CD → different dashboards
Result: same goals, 10x the chaos, nobody can support anyone else's setup
After: platform on Kubernetes
Team A, B, C → golden path template → shared CI/CD → shared observability
Result: same teams, same goals, dramatically less chaosReal tools, real stack
Argo CD for GitOps (Day 29's mechanism, now placed concretely in the stack), Helm and Kustomize for templating, Prometheus and Grafana for observability, Vault for secrets, Istio or Linkerd for service mesh where it's warranted — none of this is exotic. Most platform teams running Kubernetes seriously are assembling some real subset of exactly this list, in the shape Day 28's four layers describe.
Why this is the right foundation to build on
The payoff — faster delivery, consistency and standards across every app, scalability without a linear increase in operational chaos, cost efficiency, centralized visibility and control — comes from Kubernetes doing what it's actually good at (scheduling, healing, abstracting infrastructure) while the platform team's own work goes into the layers above it, not into re-solving problems Kubernetes already solved. Kubernetes is the engine. Platform engineering, as this series put it back on Day 19, is what makes that engine something a developer never has to open the hood on.
Tomorrow's article moves up one layer: platform APIs, the actual contract between developers and everything Kubernetes and the platform services layer provide underneath.
