What Is Kubernetes? A Beginner-Friendly Explanation

Kubernetes in simple terms

Think of a container as a box that holds your application and everything it needs to run. A container tool like Docker lets you build and run one of those boxes on a single machine. That is useful for development, but it does not solve the production problem.

In production, you might need fifty copies of your web server running simultaneously across multiple machines. Some of those machines will fail. Traffic will spike unpredictably. You will need to deploy a new version of your app without taking the whole thing offline. You need something watching over everything, making sure the right number of containers are running at all times, routing traffic only to healthy ones, and replacing broken ones automatically.

That is what Kubernetes does. If a container tool runs individual containers, Kubernetes keeps hundreds of containers running reliably across a whole fleet of machines, automatically scheduling, healing, and scaling them as needed.

What problem does Kubernetes solve?

Containers are a great way to package software consistently. A container that works on a developer’s laptop works the same way in a data centre. That consistency is genuinely valuable.

But consistency at packaging time does not solve the problems that appear at runtime. Once you move to production at any real scale, you run into a specific set of operational challenges:

• Keeping containers running. Containers crash. Machines fail. Something needs to detect failures and start replacements without waking you up at 3am.
• Scaling when traffic spikes. A single copy of your service will not survive a sudden traffic spike. Something needs to spin up more instances quickly and take them back down afterwards.
• Rolling out updates safely. Replacing all containers at once causes downtime. You need a way to swap in new versions gradually, and roll back immediately if something goes wrong.
• Routing traffic to healthy instances. As containers start and stop, their IP addresses change. Something needs to track which containers are healthy and route traffic only to those.
• Running many services consistently. As the number of services grows, managing them with custom scripts becomes unmanageable. You need a consistent, repeatable approach that works the same way for every service.

Before Kubernetes, teams built custom tooling for each of these problems. The tooling was fragile, hard to maintain, and did not transfer between organisations. Google had already solved this internally with a system called Borg. In June 2014, Google open-sourced a general-purpose version. That project became Kubernetes, and it is now governed by the Cloud Native Computing Foundation (CNCF).

How Kubernetes works, step by step

Here is what actually happens when you deploy an application with Kubernetes:

1. You package your app into a container image. Using Docker or another container tool, you build an image and push it to a registry such as Google Artifact Registry.

2. You describe what you want in a YAML file. You write a Deployment manifest that says something like: “Run three copies of this container image, and make sure three are always running.” You apply it with kubectl apply -f deployment.yaml.

3. The control plane schedules pods onto nodes. The Kubernetes scheduler reads your Deployment, works out which worker nodes have enough free CPU and memory, and assigns pods to those nodes. A pod is the smallest unit Kubernetes manages (it wraps one or more containers together).

4. A Service routes incoming traffic. Because pod IP addresses change every time a pod restarts, you create a Service in front of them. The Service gets a stable virtual IP and automatically load-balances traffic across all healthy pods. See Services in Kubernetes for the full breakdown.

5. The Deployment controller maintains desired state. If a pod crashes, the Deployment controller starts a replacement. If you update the container image, it replaces pods gradually, a few at a time, so the service stays available throughout. See Deployments in Kubernetes for how rolling updates work in practice.

6. Kubernetes self-heals and scales. If a worker node fails, every pod on that node is rescheduled onto other healthy nodes. If you have configured autoscaling, Kubernetes scales the number of pods up or down based on CPU usage, memory pressure, or custom metrics. See Horizontal Pod Autoscaling for how that is configured.

Core Kubernetes concepts

These seven concepts appear in almost every Kubernetes workflow. Understanding them before you start will save a lot of confusion.

Cluster#

A Kubernetes cluster is the fundamental unit of deployment. It consists of a control plane and one or more worker nodes. Everything you run in Kubernetes lives inside a cluster. When you use GKE, you are creating and working with clusters.

Control plane#

The control plane is the brain of the cluster. It makes global decisions (scheduling pods, replacing failures, rolling out updates) and runs the API server that every tool communicates with: kubectl, the Cloud Console, CI pipelines. In GKE, Google operates the control plane entirely. You never manage those machines.

Node#

A node is a worker machine that runs your containerised workloads. Each node runs an agent called the kubelet, which receives instructions from the control plane and ensures the right containers are running. In GKE Standard mode, nodes are Compute Engine VMs in your project. In GKE Autopilot mode, Google manages the nodes for you. See Node Pools Explained for how to configure them in Standard mode.

Pod#

A pod is the smallest deployable unit in Kubernetes. It wraps one or more containers that share a network namespace (they can reach each other over localhost) and can share storage volumes. In practice, most pods run a single container. Pods are ephemeral by design: they start, do their job, and may be replaced at any time. For a deep dive, see Kubernetes Pods Explained.

Deployment#

A Deployment describes a desired state: “I want three replicas of this container image running at all times.” The Deployment controller continuously reconciles the actual state of the cluster with that desired state. If a pod dies, it starts a replacement. If you change the image version, it replaces pods gradually using a rolling update strategy. Bare pods (pods created without a Deployment) have no self-healing. Always use Deployments for application workloads. See Deployments in Kubernetes.

Service#

A Service is a stable network endpoint that routes traffic to a set of pods. Because pod IP addresses change every time a pod restarts, you never send traffic directly to a pod. A Service selects the right pods by label and load-balances across them, providing a consistent address regardless of how many pods are running or where they are scheduled. See Services in Kubernetes.

Namespace#

Namespaces partition cluster resources between teams, environments, or applications. Two teams can each have a deployment named api as long as they are in different namespaces. GKE clusters include a few built-in namespaces: kube-system for cluster infrastructure, default for workloads that do not specify one. For most real projects, you will create your own namespaces to keep things organised.

Kubernetes vs Docker

This is one of the most common points of confusion for beginners. Docker and Kubernetes are complementary tools, not competing ones. They operate at completely different levels.

When Kubernetes makes sense

Kubernetes is the right choice when you have:

• Multiple services that need to scale independently. Kubernetes handles each service as a separate Deployment with its own scaling configuration.
• High availability requirements. Kubernetes automatically spreads workloads across nodes and zones, replacing failed pods without manual intervention.
• Rolling deployments with zero downtime. The Deployment controller makes progressive rollouts straightforward, with automatic rollback if health checks fail.
• A platform team managing workloads for many application teams. Kubernetes’ namespace model and RBAC system make it practical to run many teams’ workloads on shared infrastructure safely.
• Consistency across environments. The same Kubernetes manifests describe workloads in development, staging, and production. There is no environment-specific configuration layer to maintain separately.
• Workloads that need fine-grained scheduling control. Kubernetes lets you express constraints like “this pod must run on a GPU node” or “do not co-locate these two pods on the same machine”.

When Kubernetes may be overkill

Kubernetes is powerful, but it comes with genuine operational complexity. It is worth being honest about when it is not the right tool.

Consider something simpler if:

• You have a single service with modest traffic. A fully managed platform like Cloud Run will deploy your container, scale it to zero, and charge you only for what you use, with far less configuration than a Kubernetes cluster.
• Your team does not yet have Kubernetes experience. The learning curve is real. Introducing Kubernetes prematurely slows you down and introduces operational risk.
• You are building an internal tool with low traffic and no high availability requirement. The overhead of cluster management is hard to justify for a low-stakes workload.
• You need to move quickly. Setting up and maintaining a Kubernetes cluster takes time. For an early-stage product, that time is usually better spent building features.

The comparison between these options is covered in detail on the GKE vs Cloud Run page and the Kubernetes vs serverless page.

Kubernetes on Google Cloud: Google Kubernetes Engine

Running Kubernetes yourself is a significant operational undertaking. You need to provision and patch control plane VMs, configure etcd, manage TLS certificates, set up load balancers, and keep pace with Kubernetes release cycles before your first workload can even run.

Google Kubernetes Engine (GKE) removes that burden. Google operates and maintains the control plane: the API server, etcd, scheduler, and controller manager run on Google-owned infrastructure and are not visible as VMs in your project. You interact with your cluster using the same standard kubectl commands you would use with any Kubernetes cluster anywhere in the world.

What GKE manages for you:

• The entire Kubernetes control plane
• Control plane high availability across zones
• Kubernetes version upgrades (when enrolled in a release channel)
• Security patching of the control plane
• etcd backups

What you still manage:

• Your application workloads (pods, deployments, services)
• IAM permissions for cluster access
• Networking configuration (VPC, subnets, private cluster settings)
• Persistent storage configuration
• Worker nodes in Standard mode

To start using GKE, enable the Kubernetes Engine API in your GCP project:

gcloud services enable container.googleapis.com

GKE Autopilot is Google’s recommended default for most workloads. Google manages the worker nodes entirely (provisioning, scaling, patching, and securing them). You describe what you want to run and GKE provisions exactly the infrastructure needed. Billing is per pod based on CPU and memory requests, not per node.

GKE Standard gives you full control over the node infrastructure. You define node pools, choose machine types, and configure autoscaling parameters. Use Standard when you need specific hardware (GPUs, high-memory machines) or have compliance requirements that demand control over the underlying infrastructure.

Inside a Kubernetes cluster

Understanding what is actually running inside a cluster helps you reason about what is happening when things go wrong.

Control plane components (managed by Google on GKE)

• kube-apiserver: the front door of the cluster. Every interaction from kubectl, the Cloud Console, or a CI pipeline goes through the API server. It validates requests and persists cluster state.
• etcd: a distributed key-value store holding the entire state of the cluster: every pod, service, config map, and secret. GKE manages etcd automatically.
• kube-scheduler: watches for newly created pods that need a home, then picks the best node based on resource availability, affinity rules, and other constraints.
• kube-controller-manager: runs a set of controllers that each watch cluster state and work to bring reality in line with desired state. The Deployment controller and ReplicaSet controller are both included here.

Node components (running on each worker node)

• kubelet: an agent on every node that receives pod specifications from the API server and ensures the right containers are running. If a container exits unexpectedly, the kubelet restarts it.
• kube-proxy: maintains network rules that allow pods to communicate within the cluster and allow external traffic to reach Services. For the full picture, see GKE Networking Model.
• Container runtime: the software that actually runs containers. GKE uses containerd on Container-Optimized OS nodes.

Kubernetes vs the alternatives

Kubernetes vs Docker#

Docker builds and runs individual containers on a single machine. Kubernetes orchestrates many containers across many machines. They are complementary: Docker-built images run on Kubernetes clusters. The confusion arises because both involve containers, but they operate at entirely different levels. The comparison table in the Kubernetes vs Docker section above covers this in detail.

Kubernetes vs serverless#

Serverless platforms like Cloud Functions or Cloud Run manage the infrastructure entirely. You deploy code or a container and the platform handles everything else. Kubernetes gives you much more control: over scheduling, networking, resource limits, and cluster configuration. The tradeoff is complexity. Kubernetes is the better choice when you need that control; serverless is the better choice when you do not. See the Kubernetes vs serverless comparison for a detailed breakdown.

Kubernetes vs Cloud Run#

Cloud Run is Google’s fully managed container platform. It runs your containers, scales them to zero, and charges per request. Kubernetes (via GKE) gives you persistent workloads, complex scheduling, and full cluster control. Cloud Run is significantly simpler for stateless HTTP workloads. Kubernetes is the better choice for stateful workloads, batch jobs, internal services, or anything that does not fit the request-response model well. See the GKE vs Cloud Run comparison for guidance on choosing between them.