Kubernetes is an open-source system that automates deploying, scaling, and operating containerised applications. It keeps a cluster in the state you declared, rescheduling work when nodes fail and adjusting capacity when load moves. This guide covers its architecture, its rollout and scaling mechanics, and what actually gets hard once you run it at enterprise scale.
Quick Overview
What you’ll learn:
- What Pods, Services and Deployments do, and why the distinction matters operationally
- How a cluster is put together — control plane, worker nodes, and who talks to whom
- Which rollout strategies Kubernetes gives you natively, and which need extra tooling
- How HPA, VPA and the Cluster Autoscaler differ, including their default timings
- What observability looks like when workloads move between nodes on their own
- The operational costs that show up only at enterprise scale
Who this article is for:
- Developers moving an application from a single server to a cluster
- Sysadmins and DevOps engineers taking over a Kubernetes environment
- Architects deciding whether orchestration is worth its operating cost for a given system
Reading time: 12 minutes
What Kubernetes Actually Does — and Why It Took Over
Kubernetes, often shortened to K8s, automates deployment, scaling and management of applications running in containers. The useful mental model is not “a tool that starts containers” but a control loop: you declare the state you want — this many replicas, this image, this much CPU — and a set of controllers works continuously to make the observed state match it. When a node dies, nothing has to page a human to restore capacity; the loop notices the gap and refills it.
That model is why adoption tracked the move to distributed architectures rather than preceding it. A monolith on three servers does not need it. A system of forty services, each with its own release cadence, dependencies and failure modes, cannot be operated by hand — the number of things that must be true at once exceeds what a runbook can carry. Kubernetes absorbs the repetitive parts of that work: rolling out new versions, restarting failed instances, spreading workloads across nodes, and adjusting replica counts to load.
The trade is explicit and worth naming early. You get uniformity — every service is deployed, scaled and observed the same way, regardless of language or team — in exchange for a platform that is itself a system to be operated, upgraded and secured. Teams that treat Kubernetes as infrastructure they “just install” tend to discover the operating cost about six months in, usually during an upgrade.
The Building Blocks: Pod, Service, Deployment
Three objects carry most of the day-to-day work, and understanding how they relate is the difference between using Kubernetes and fighting it.
A Pod is the smallest unit that Kubernetes schedules. It holds one container, or several tightly coupled ones that share a network namespace — the same IP address — and can share volumes. Two containers belong in the same Pod when they must live and die together and talk to each other over localhost: an application and its log shipper, say. Two containers that merely call each other over the network do not.
Pods are deliberately disposable. They get created, destroyed and replaced during scaling, node maintenance or failure, and their IP addresses change every time. That is exactly why the second object exists. A Service gives a group of Pods performing the same function one stable name and one stable virtual IP, and load-balances across whichever Pods currently exist. Callers address the Service; they never learn Pod addresses. This indirection is what makes Pod disposability safe rather than chaotic.
A Deployment manages the lifecycle of a Pod group. It declares how many identical replicas should be running and from which image, then works to keep that true — creating replacements for failed Pods, and orchestrating controlled version changes. In practice you rarely create Pods directly; you create Deployments, and the Deployment creates Pods through an intermediate ReplicaSet. That indirection is what makes rollbacks possible: the previous ReplicaSet still exists, so reverting is a matter of shifting replicas back to it rather than redeploying an old artefact.
Once you have more than a handful of these definitions, keeping them consistent across environments becomes its own problem — which is where templating and packaging come in. Our guide to managing deployments with Helm charts covers that step for teams that have outgrown hand-maintained YAML.
Inside a Cluster: Control Plane and Worker Nodes
A cluster splits into a control plane, which decides, and worker nodes, which run the workloads.
The control plane’s entry point is the API server. Everything — kubectl, CI systems, controllers, the nodes themselves — talks to the cluster through it, which makes it both the integration point and the place where authentication and authorisation are enforced. Cluster state lives in etcd, a distributed key-value store; it is the only stateful component in the control plane, and consequently the one whose backup strategy matters most. The scheduler decides which node each new Pod lands on, weighing resource requests, node capacity, affinity rules and taints. The controller manager runs the reconciliation loops themselves — the processes that notice a Deployment has four Pods when it should have five and act on it.
Worker nodes run three things. The kubelet is the agent that takes Pod specifications from the API server, tells the container runtime to start them, and reports health back. Kube-proxy implements the network rules that make Services work, routing traffic to healthy Pods. And a container runtime — containerd or CRI-O in most current clusters — does the actual work of running containers. If you are weighing runtime options for a new cluster, our Docker vs Podman vs containerd comparison sets out the practical differences.
The reason this split is worth memorising is diagnostic. Almost every cluster problem localises to one side of it: workloads that will not schedule point at the scheduler, capacity or constraints; workloads that schedule but will not start point at the kubelet, the runtime, or image pulls; workloads that start but are unreachable point at Services, kube-proxy or network policy.
Rollout Strategies: Rolling Update, Recreate, Blue/Green, Canary
Kubernetes supports two rollout strategies natively, through the Deployment object, and provides the foundation for two more that need additional tooling.
Rolling update is the default. Old Pods are replaced with new ones incrementally, with parameters — maxUnavailable and maxSurge — controlling how aggressively. Because a minimum number of Pods stays available throughout, the Service keeps serving. The catch is that both versions run simultaneously during the window, so the new version must tolerate the old one’s data and vice versa. Schema changes are where this assumption usually breaks.
Recreate stops every old Pod before starting any new ones. It causes downtime by design, and it exists for the case where two versions genuinely cannot coexist — a database migration that rewrites a table in place, for example.
Blue/green keeps two complete environments and switches traffic between them once the new one has been verified. Canary exposes the new version to a small share of traffic first and watches its behaviour before widening. Neither is a native Deployment strategy; both are built on top, using ingress controllers, a service mesh, or a progressive delivery controller. Reaching for them before you have solid metrics is a common mistake — a canary you cannot measure is just a slower rollout.
For the wider picture of getting a cluster to a state where any of this is safe to run, see our complete guide to a production Kubernetes cluster rollout.
Autoscaling: HPA, VPA and the Cluster Autoscaler
Three mechanisms scale at three different levels, and confusing them is a reliable source of surprise bills.
The Horizontal Pod Autoscaler (HPA) changes the number of replicas. It reads metrics — CPU and memory by default, custom or external metrics with extra plumbing — and adjusts the replica count to hold a target utilisation. Two defaults are worth knowing before you tune anything. The controller re-evaluates on a fixed interval set by --horizontal-pod-autoscaler-sync-period, which defaults to 15 seconds. And scale-down is deliberately damped: the stabilisation window set by --horizontal-pod-autoscaler-downscale-stabilization defaults to 5 minutes, so the HPA will not shrink a Deployment the moment a traffic spike passes. Both figures are documented in the Kubernetes horizontal pod autoscaling guide. Teams that experience “the HPA is not reacting” are usually looking at one of these two intervals rather than a broken configuration.
The Vertical Pod Autoscaler (VPA) changes the resources given to each Pod rather than the number of Pods. It suits workloads that cannot be parallelised — a single-writer process, a job with expensive per-instance startup. The operational cost is that applying new limits generally requires recreating the Pod, so vertical scaling and continuous availability pull against each other. Running HPA and VPA on the same CPU metric for the same workload is a known conflict, not a clever combination.
The Cluster Autoscaler works one level up, on nodes. When Pods cannot be scheduled because no node has room, it asks the infrastructure provider for more nodes; when nodes sit underused, it drains and removes them. It is the mechanism that turns pod-level elasticity into an actual change in the bill — and the one where node draining, disruption budgets and stateful workloads interact in ways that need thinking through in advance. Our article on what Kubernetes autoscaling with HPA and VPA really costs works through that arithmetic on real numbers.
Observability: Metrics, Logs and Traces
Running an application on a cluster changes what monitoring has to answer. Workloads move between nodes without being asked, Pods are replaced rather than repaired, and “which server is it on” stops being a meaningful question. Monitoring built around named hosts degrades quietly in this environment: the dashboards still render, they just stop describing anything.
Three data types carry the load. Metrics are numeric time series describing cluster components and applications — node resource usage, request rates, error rates, latency percentiles. Prometheus and Grafana are the default pairing in this ecosystem, and the reason is structural: Prometheus’s label model matches Kubernetes’ label model, so a query can address “all Pods of this Deployment in this namespace” without a separate inventory.
Centralised logging matters because container logs vanish with the container. Aggregating them — with an EFK stack, or Promtail and Loki — is what makes it possible to investigate an incident after the Pod that caused it has already been replaced.
Distributed tracing follows a single request across services, showing where the time went. In a system of a few services it is a nice-to-have; past a dozen, it is the only practical way to answer “why is this endpoint slow” without guessing. Jaeger and Tempo are the common implementations.
The team-level point underneath all three: observability in Kubernetes is not a tool you install once but a set of conventions — label naming, log structure, trace propagation — that every service has to follow. The tooling is the easy half. If your team is standing this up, the Prometheus and Grafana: Kubernetes and cloud-native monitoring course covers both halves.
Kubernetes and CI/CD: Where DevOps Practice Meets the Platform
Kubernetes fits CI/CD well because its interface is an API and its unit of change is a declarative manifest. A pipeline can build an image, run tests against an ephemeral namespace created for the purpose, then apply a manifest change — and the cluster’s reconciliation loop does the rest.
That pattern has consolidated into GitOps: the desired state lives in a Git repository, a controller in the cluster watches it, and deployment becomes a merge rather than a pipeline step with cluster credentials. The practical benefit is auditability — the repository is the record of what was deployed and when — and the practical cost is that drift between repository and cluster becomes its own class of incident to detect.
Secrets are where this gets uncomfortable. Kubernetes Secrets are base64-encoded, not encrypted, in their default configuration, and a manifest in Git must not contain them in plain text. The workable answers are external secret stores with an operator that injects values at runtime, or encrypted-at-rest manifests with a sealing controller. Choosing one before the first production deployment is considerably cheaper than retrofitting it afterwards.
What Gets Hard at Enterprise Scale
The problems that dominate a large Kubernetes estate are mostly not the ones a first cluster teaches you.
Version lifecycle is the most underestimated. The Kubernetes project maintains release branches for the most recent three minor releases, and patch release series are supported for roughly fourteen months. Practically, that means an enterprise cluster is never finished: an upgrade cadence has to be a standing commitment, not a project, and every controller, CNI plugin and operator in the cluster has to keep pace with it. Estates that skip upgrades do not stay still — they accumulate a migration that gets more expensive every quarter.
Security stops being a checklist and becomes a set of enforced defaults. Kubernetes defines three Pod Security Standards — Privileged, Baseline and Restricted — as progressively tighter profiles, and they are the sensible starting point precisely because they are shared vocabulary rather than a bespoke policy nobody else can review. Around them sit RBAC, network segmentation, image provenance and runtime detection. Network policy in particular tends to be deferred and then discovered: a cluster with no policies is a flat network. Our guide to Kubernetes NetworkPolicy fundamentals and team responsibilities covers who owns which part of that, which is usually the harder question. For the runtime and policy-enforcement side, the Cloud-native security: Kubernetes security with Falco and OPA course goes into the tooling in depth.
Multi-environment consistency is a discipline problem wearing a technical costume. Development, staging and production diverge unless something forces them not to, and the thing that forces them is infrastructure-as-code plus a single source of manifests parameterised per environment.
Cost is where cluster elasticity meets a cloud bill. Over-requested resources are the usual culprit: requests set generously “to be safe” reserve capacity the scheduler cannot give to anything else, so a cluster can report itself full while much of the capacity it reserved sits idle.
Stateful workloads remain the sharp edge. StatefulSets, PersistentVolumes and storage classes make databases on Kubernetes possible; they do not make them simple. The honest position for most organisations is that a managed database service is the better default, and running your own on the cluster is a decision that needs a specific reason behind it.
Build Your Skills
The gap between “we have a cluster” and “we operate a cluster” is mostly the material above — architecture you can reason about under pressure, rollout mechanics you have practised, and an upgrade and security posture decided before you need it. The Advanced Container Orchestration Practices with Kubernetes course works through exactly that, with hands-on exercises rather than slides. Check the programme and sign up to build your skills with EITT’s experts.
Frequently Asked Questions (FAQ)
How long does it take to get productive with Kubernetes?
Core concepts — Pods, Services, Deployments and basic troubleshooting — take a few weeks of focused work. Operating production clusters competently, including upgrades, security and incident response, generally takes six to twelve months of hands-on experience supported by structured training. The second interval is the one that gets underestimated in planning.
Is Kubernetes worth it for a small team?
Often not. For a handful of services with predictable load, the platform’s operating cost outweighs its benefits, and a managed container service or plain Docker Compose is the better answer. Kubernetes starts paying off when you have enough services and enough deployment frequency that manual coordination has become the bottleneck — and a managed offering removes most of the control-plane burden even then.
What is the difference between running stateless and stateful applications?
Stateless workloads — API servers, web front ends — are straightforward: every replica is interchangeable and can be created or destroyed freely. Stateful workloads need stable network identity and durable storage, which is what StatefulSets and PersistentVolumes provide. The added complexity is real, and it is why managed data services remain the default recommendation for most teams.
Do I have to upgrade Kubernetes constantly?
Effectively yes. Release branches are maintained for the three most recent minor releases and patch support runs roughly fourteen months, so a cluster left alone drifts out of support within about a year. Treating upgrades as a scheduled, routine operation is considerably cheaper than treating them as a project that gets deferred until something forces it.
Where should security work start on a new cluster?
With the Pod Security Standards — adopting Baseline as a floor and Restricted where workloads allow it — plus RBAC scoped to actual need rather than convenience. Network policies come next, because a cluster without them is a flat network in which any compromised Pod can reach any other. Image scanning and runtime detection follow, but they are less valuable on a cluster whose basic isolation is not in place.