Skip to main content
This lesson explains how to design a Kubernetes cluster for different use cases (learning, development, testing, production). Start by answering the questions below — they directly affect decisions about node sizing, storage, networking, availability, and tooling.
  • What is the purpose of the cluster — learning, development, testing, or production?
  • Do you want a managed cloud service or a self-hosted solution?
  • What workloads will run on the cluster (web apps, analytics, batch jobs)?
  • How many applications will you host — few or many?
  • What are the resource requirements of those applications (CPU, memory, disk I/O)?
  • What kind of network traffic do the applications expect — steady, bursty, or spiky?
Answering these will guide choices such as node types, storage classes, CNI plugin selection, and how you plan for upgrades and monitoring. Choose tooling and topology based on your use case. The table below summarizes recommended approaches for common deployment scenarios. For cloud-managed clusters, providers often handle control plane HA, etcd, and upgrades for you. For self-managed clusters, kubeadm and kops give flexibility but require more operational effort.

​
Capacity guidance

Kubernetes supports large clusters. Reference limits (subject to change by Kubernetes or cloud provider):
  • Example maximums often cited: up to ~5,000 nodes, ~150,000 pods, and ~300,000 containers.
  • Typical defaults include ~110 pods per node (can be tuned).
Always consult canonical sources — Kubernetes docs and your cloud provider — for current, exact limits. Use these numbers as a starting point for on-prem capacity planning.
A presentation slide titled "Hosting Production Applications" listing deployment guidelines and capacity limits (high-availability multi-node clusters, kubeadm/GCP/Kops, up to 5,000 nodes, 150,000 PODs, 300,000 containers, etc.). Below is a table mapping node count ranges to recommended GCP and AWS instance types with vCPU and memory sizes.
If you’re on-prem, use the above as a baseline for hardware sizing. Cloud providers usually provide instance size recommendations and may auto-select instances for managed services.

​
Storage considerations

Pick storage based on workload I/O, durability, and sharing requirements:
  • High-performance workloads: prefer SSD-backed storage for low latency and high IOPS.
  • Concurrent access: use NAS or distributed block storage that supports multi-attach when many clients need simultaneous read/write.
  • Shared volumes: use PersistentVolumes (PV) and PersistentVolumeClaims (PVC) and define StorageClasses for different performance tiers.
  • Node labeling for disks: label nodes by disk capability (for example, fast-ssd) and use node selectors / node affinity to schedule workloads to those nodes.
  • Use taints and tolerations to keep general workloads off specialized nodes unless explicitly allowed.
A presentation slide titled "Storage" with five numbered panels that list storage features: high-performance SSD-backed storage, network-based concurrent connections, persistent shared volumes for multiple PODs, labeling nodes by disk type, and using node selectors to assign apps to specific disks.

​
Nodes, control plane, and topology

Key topology and node design points:
  • Nodes can be physical machines or VMs (cloud instances). For small setups, VirtualBox VMs or small cloud VMs are common.
  • A minimal production-ready cluster typically has multiple control plane nodes (to provide HA) and multiple workers. A common small configuration is 3 control-plane nodes and 2+ worker nodes.
  • Control plane components include: etcd, kube-apiserver, kube-controller-manager, and kube-scheduler.
  • In larger clusters, consider isolating etcd on dedicated nodes to reduce contention for I/O and memory.
  • kubeadm taints control-plane/master nodes by default to prevent scheduling regular workloads; keeping masters dedicated is best practice. Only use taints/tolerations to run workloads on masters if you understand the operational trade-offs.
For production, dedicate control plane nodes to control plane components only. Use taints and tolerations deliberately if you must run workloads on master nodes.

​
Other practical considerations

  • Operating system: use a supported 64-bit Linux distribution for control plane and most worker nodes. Windows worker nodes are supported for Windows containers (control plane remains Linux).
  • Networking: choose a CNI plugin that matches your needs for performance, policy, and cloud integration (Calico, Cilium, Flannel, etc.).
  • Monitoring and logging: include cluster-level monitoring (Prometheus, metrics-server), alerting, and centralized logging (e.g., Fluentd/Fluent Bit + ELK/EFK) from the start.
  • Upgrades and lifecycle: plan and test upgrades in non-production first. Managed services reduce upgrade complexity; self-managed clusters require a documented upgrade process.

​
References and certification notes

For authoritative details, consult:
Exam tip: Know the concepts and trade-offs (HA control plane, storage classes, node sizing). Rely on official docs for exact capacity numbers rather than memorizing them.

​
Control plane illustration

Below is a simple depiction of master nodes showing typical control plane components (etcd, API server, controller-manager, scheduler).
A diagram titled "Master Nodes" showing two identical master node boxes. Each box depicts etcd at the top and the API Server, Controller‑Manager, and Scheduler components arranged below (Kubernetes master architecture).

​
Next steps

Provision a small cluster (cloud or local) and apply these design ideas: choose appropriate storage classes, label nodes for workload placement, select a CNI, and instrument monitoring and logging. Practice upgrades and failure scenarios to validate your design.

Watch Video