Skip to main content
Welcome to the first lesson in the Platform Architecture and Infrastructure module. This lesson focuses on the foundational decisions platform engineers make — decisions that determine whether a Kubernetes platform will scale or collapse. We’ll cover:
  • What a layered platform architecture looks like.
  • The difference between control plane and data plane components.
  • Trade-offs between single-cluster and multi-cluster topologies.
By the end you should be able to design intentional platform boundaries and choose cluster topologies that fit your organization.
A slide titled "Learning Objectives" with a blue left panel and three numbered items. The objectives are: (1) Describe a layered platform architecture, (2) Distinguish control plane from data plane components, and (3) Evaluate cluster topology trade-offs.
Why this matters Kubernetes is powerful and flexible — which is a double-edged sword. Without an intentional architecture, teams will implement different patterns, permissions will proliferate, and a single mistake can cascade into an outage. Consider this real-world scenario: a fast-growing startup with ~50 teams runs everything in one giant cluster with no structure. A junior developer’s heavy data job consumed all CPU overnight, starving the checkout service. The site went down and even security engineers couldn’t authenticate because the control plane was overloaded. This is the two a.m. incident nobody wants. Kubernetes gives you primitives, not a playbook. To scale from five teams to five hundred, you must design a platform — and a layered architecture is the most practical approach.
A diagram titled "Flexibility vs. Structure" showing a scalable platform (stacked servers) in the center, linking a small box of 5 teams on the left to a large box of 500 teams on the right. It visualizes infrastructure scaling to support many teams.
Common failure modes when architecture is missing
  1. Inconsistent configuration — teams create different solutions because there is no shared blueprint.
  2. Lack of boundaries — one team’s workload can negatively impact another.
  3. Security gaps — ad hoc permissions let people affect systems they shouldn’t.
These failure modes add technical debt, slow onboarding, and increase the likelihood of incidents. Platform engineering’s job is to convert Kubernetes’ flexibility into predictable, safe, and repeatable platform behavior.
A slide titled "Kubernetes Is Flexible by Design" showing Kubernetes icons and components (Pods, Services, Namespaces, RBAC) with a note that it's "NOT a blueprint." A circular graphic warns that without intentional architecture inconsistencies arise, every team solves problems differently, and lack of shared standardization makes scaling harder.
Layered platform architecture (recommended) A practical, opinionated way to organize a platform is to introduce clear layers with defined ownership and responsibilities. The four-layer model (bottom to top) is:
Design a Golden Path: provide teams with opinionated workflows, templates, and defaults for security, observability, and deployments. Good Golden Paths reduce accidental complexity and accelerate team delivery.
Benefits of layering
  • Clear ownership boundaries reduce coordination friction.
  • Reusable patterns accelerate new team onboarding.
  • Better scaling and reliability because teams consume platform services instead of rebuilding them.
Control plane vs. data plane Separating the control plane from the data plane is crucial for scalability, failure isolation, and security. Control plane — cluster brain
  • API Server: the front door for kubectl, controllers, and users.
  • etcd: the source of truth (requires high availability and backups).
  • Scheduler: assigns pods to nodes considering resources, affinity, taints/tolerations.
  • Controller Manager: runs reconciliation loops to converge actual state with desired state.
Data plane — where workloads run
  • Worker nodes with kubelet agents that execute control plane instructions.
  • Container runtimes (containerd, CRI-O) pull images and run containers.
  • Pods and containers: the runtime for application workloads.
A diagram of Kubernetes architecture highlighting the Control Plane — showing components like the API Server, etcd (state storage), Scheduler and Controller Manager — and the API server's interactions with kubectl commands, controller reconciliation loops, and admission webhooks.
Why the separation matters
  • Independent failures: API server outages block control operations (create/modify) but running pods continue; node failures trigger rescheduling if the control plane/etcd are healthy.
  • Independent scaling: you can scale control plane resources separately from worker node count.
  • Security boundaries: restrict who can access the control plane and define tighter RBAC for systems interacting with etcd/API Server.
A side-by-side diagram comparing the Kubernetes Control Plane (where management decisions happen) and the Data Plane (where workloads run). The Control Plane lists API Server, etcd, Scheduler and Controller Manager, while the Data Plane shows Worker Nodes, Kubelet, Container Runtime and Pods/Workloads.
Cluster topology: one cluster vs many clusters One of the most impactful platform decisions is topology: should you operate a single large cluster, or many smaller clusters? Single large cluster
  • Pros: simpler operations, fewer control planes to maintain, better aggregate resource utilization.
  • Cons: bigger blast radius for control plane/etcd failures and noisy neighbor problems.
A slide diagram titled "Cluster Topology: One vs Many" showing a single large Kubernetes cluster split into three colored team boxes (Team A, Team B, Team C). It lists advantages with green checkmarks (simpler operations, better resource utilization, single control plane) and disadvantages with red Xs (blast radius is entire org, control plane/etcd failure impacts all teams, noisy neighbor issues).
Multiple clusters
  • Pros: stronger isolation, independent lifecycles (upgrade dev/staging without risking prod), easier compliance or region-specific control.
  • Cons: higher operational cost and complexity: multiple control planes, cluster provisioning, and cross-cluster concerns.
A slide showing a multi-cluster topology with three separate Kubernetes clusters labeled Dev, Staging, and Prod. It notes pros (strong isolation, independent lifecycle) with checkmarks and cons (higher operational cost, cross-cluster complexity) with crosses.
Cluster topology summary Common partitioning patterns
  • By environment: dev, staging, prod (separation of risk).
  • By region: US, EU, APAC for latency or regulatory needs.
  • By team/business unit: per-team clusters for strict ownership.
  • Hybrid: shared non-production clusters and isolated production clusters.
There is no single correct answer — choose based on scale, compliance, operational capability, and risk tolerance. Key takeaways
  1. Design intentionally: Kubernetes provides primitives, not an architecture.
  2. Use layered platform architecture with clear owners and responsibilities.
  3. Understand control plane vs data plane — separation enables better isolation and scaling.
  4. Choose cluster topology (single vs multi) based on trade-offs for your organization.
Further reading and references Platform engineering is about making deliberate choices that scale. With this blueprint, subsequent lessons will dive into concrete patterns and implementation details that put these principles into practice.

Watch Video