Kubernetes for Developers, Part 1: The Basics That Actually Matter

Kubernetes can feel abstract until the core pieces click. This guide explains Pods, Deployments, Services, nodes, and the control plane in plain English so developers can build a real mental model from the start.

Kubernetes gets introduced with big phrases.

Container orchestration. Cluster management. Cloud native infrastructure.

None of those phrases help much when you are just trying to answer a simple question:

What is Kubernetes actually doing for my application?

That is the right place to start.

Kubernetes is a system for running applications across a group of machines in a predictable way. It helps you deploy services, replace failed instances, expose them on the network, scale them, and keep the actual running state aligned with the state you declared.

If that sounds broad, it is. Kubernetes is not one tool that does one job. It is a platform made of several ideas that work together. That is also why it feels difficult at first. Newcomers often try to memorize object names before they understand the model underneath them.

This article is about that model.

By the end, you should understand:

why Kubernetes exists
what problem it solves beyond just "running containers"
how a cluster is structured
what Pods, Deployments, and Services are really for
why Kubernetes is called declarative
what mental model will make the rest of Kubernetes easier to learn

This is Part 1 of a three-part series. Here we will focus on the foundations. Part 2 will move into the day-to-day mechanics of running applications on Kubernetes. Part 3 will cover the production and operational realities that show up once the basics are no longer the hard part.

Why Kubernetes Exists

Before Kubernetes, many teams had one of two problems.

The first problem was inconsistency. An application worked on one server but failed on another because of missing packages, different runtime versions, or subtle configuration drift.

The second problem was operational fragility. Even if the application ran correctly, deploying it, scaling it, restarting it, or moving it to another machine involved manual work and too much hope.

Containers improved the first problem.

A container lets you package an application with the environment it expects. That gave teams a more consistent unit of deployment. If the container works in one place, it is much more likely to work in another.

But containers alone do not solve the second problem.

If you have one container running on one laptop, life is simple. If you have dozens of services, multiple environments, rolling deployments, traffic routing, machine failures, and a need to scale during peak load, you need more than docker run.

You need a system that can answer questions like these:

Where should this application run?
What if the process crashes?
What if the machine dies?
How many copies should be running?
How should traffic reach them?
How do I update the application without dropping requests?
How do I keep actual state aligned with intended state?

That system is Kubernetes.

At a high level, Kubernetes gives you a control loop for application infrastructure.

You describe the state you want. Kubernetes keeps comparing that desired state with the real state of the cluster and keeps trying to close the gap.

That idea is the center of everything else.

Kubernetes Is About Desired State

One of the biggest mental shifts in Kubernetes is moving from imperative thinking to declarative thinking.

Imperative thinking says:

start this container
stop that one
restart this process
create three copies of the app

Declarative thinking says:

this application should have three healthy replicas
they should use this image
they should expose this port
they should be reachable through this service

You define the end state. Kubernetes works toward it.

That is why people often say Kubernetes is declarative. You are not issuing a stream of machine-level instructions every time something changes. You are describing what the world should look like, and controllers keep reconciling the real world to that description.

This is easier to understand with a simple example.

Imagine you want three copies of your API running.

In a more manual system, you might start three processes and then watch them yourself. If one dies, you notice the problem and restart it.

In Kubernetes, you declare that three replicas should exist. If one disappears because a container crashes or a node fails, Kubernetes notices the mismatch and creates another one.

The important part is not just automation. It is continuous reconciliation.

Kubernetes is not a one-time deployment command. It is a system that keeps checking whether reality still matches the configuration you declared.

flowchart TD
    A[Desired state in manifest] --> B[Kubernetes API]
    B --> C[Controllers observe desired state]
    C --> D[Compare with actual cluster state]
    D --> E[Create or replace resources]
    E --> F[Cluster moves closer to desired state]
    F --> D

Once this clicks, many Kubernetes objects start making more sense.

The Cluster: The Big Picture First

Kubernetes usually runs across a cluster, which is a group of machines working together.

Those machines are not all doing the same job.

At a high level, the cluster has two sides:

the control plane
the worker nodes

The control plane makes decisions about the cluster.

The worker nodes run your application workloads.

If you remember only one sentence from this section, remember this:

The control plane decides what should happen. Worker nodes do the actual running.

The control plane

The control plane is the management brain of the cluster. It stores cluster state, exposes the Kubernetes API, schedules workloads, and runs the controllers that keep reconciling desired state.

You do not usually SSH into the control plane and manage workloads by hand. You interact with Kubernetes through its API, often using kubectl, and the control plane handles the coordination.

Key control plane responsibilities include:

storing configuration and cluster state
deciding where workloads should run
monitoring object state
triggering reconciliation when state drifts

Worker nodes

Worker nodes are the machines where your containers actually run.

Each worker node has software that lets Kubernetes start and manage workloads on it. When Kubernetes schedules a Pod onto a node, that node becomes responsible for running the containers inside it.

Worker nodes provide the compute resources your applications consume:

CPU
memory
local networking
sometimes local storage

If the control plane is the part that decides, worker nodes are the part that executes.

flowchart LR
    A[Developer applies manifest] --> B[API server]
    B --> C[Control plane]
    C --> D[Scheduler chooses node]
    D --> E[Worker node 1]
    D --> F[Worker node 2]
    D --> G[Worker node 3]
    E --> H[Pods running containers]
    F --> H
    G --> H

Why this separation matters

This split is not just architecture trivia.

It explains why Kubernetes can treat your application as a workload that can move, restart, scale, and recover without you managing each machine manually.

You are not deploying to "server 12" anymore. You are declaring a workload to the cluster. The cluster decides where it should live.

That is a major shift.

Nodes: The Machines Kubernetes Schedules Onto

A node is a machine in the cluster. It can be a virtual machine or a physical server.

For a beginner, the most useful way to think about a node is this:

A node is a place where Kubernetes can run Pods.

Nodes have finite resources. They only have so much CPU and memory. Because of that, Kubernetes cannot place workloads arbitrarily. It has to schedule them onto nodes that have enough capacity and satisfy the workload's constraints.

This matters because Kubernetes is solving placement problems continuously.

If you ask for five replicas of a service, Kubernetes does not just create them in the abstract. It has to decide which nodes can host them.

Later in the series, this becomes more important when we talk about resource requests, limits, affinity, and scheduling behavior. For now, the key point is simpler:

Applications do not run directly on the cluster as a vague concept. They run on specific nodes chosen by Kubernetes.

Pods: The Smallest Unit You Actually Run

If you are new to Kubernetes, this is the first object that usually feels a little strange.

You might assume Kubernetes runs containers directly.

It does not.

Kubernetes runs Pods, and Pods contain one or more containers.

So what is a Pod?

A Pod is the smallest deployable unit in Kubernetes.

In practice, a Pod usually contains one main application container, and sometimes one or more supporting containers that need to live alongside it.

Containers in the same Pod share:

the same network namespace
the same IP address
the ability to talk to each other over localhost
some storage volumes, if configured

That shared environment is the reason a Pod exists as a wrapper around containers.

Why not just run containers directly?

Because Kubernetes needs a unit that represents a tightly related group of containers that should be scheduled, started, stopped, and replaced together.

For many applications, that group has exactly one container. Even then, Kubernetes still wraps it in a Pod because Pods are the scheduling and networking unit.

A simple way to think about Pods

Think of a Pod as a temporary running instance of your application.

Not your application as a whole. Not your deployment strategy. Not your stable service endpoint.

Just one running instance.

That distinction matters a lot.

Pods are meant to be replaceable. They are not pets. They are not long-lived machines you log into and manually fix. If a Pod dies, Kubernetes usually creates another one.

That is why storing important application state inside a Pod's local filesystem is usually the wrong idea. Pods can disappear and be recreated.

Example Pod manifest

apiVersion: v1
kind: Pod
metadata:
  name: demo-api
spec:
  containers:
    - name: api
      image: myorg/demo-api:1.0.0
      ports:
        - containerPort: 3000

This example is intentionally simple, but it already shows the basic shape of Kubernetes configuration:

apiVersion tells Kubernetes which API version this object belongs to
kind says what type of object it is
metadata identifies the object
spec describes the desired state

The important beginner mistake to avoid

Do not think of Pods as permanent application instances.

Think of them as disposable runtime units.

That mindset will save you confusion later when Pods get recreated during updates, crashes, rescheduling, or scaling events.

Deployments: Managing Pods the Way You Actually Need To

If Pods are the smallest runnable unit, why do most real applications use Deployments instead of creating Pods directly?

Because a Pod alone is too low-level for most application management.

A raw Pod definition says, in effect, "run this Pod."

That is not enough for real systems.

You usually want more than that:

a certain number of replicas
self-healing when a Pod dies
controlled rollout when a new image is deployed
an easy way to update the desired state later

That is what a Deployment gives you.

What a Deployment really does

A Deployment manages a set of Pods and keeps them aligned with the desired state you declared.

If a Pod crashes, the Deployment will ensure another one appears.

If you change the container image from version 1.0.0 to 1.1.0, the Deployment can roll out the new version gradually.

If you want three replicas instead of two, the Deployment works toward that target.

This is one of the clearest examples of the Kubernetes model: you describe the state, and controllers keep trying to make reality match it.

Example Deployment manifest

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-api
spec:
  replicas: 3
  selector:
    matchLabels:
      app: demo-api
  template:
    metadata:
      labels:
        app: demo-api
    spec:
      containers:
        - name: api
          image: myorg/demo-api:1.0.0
          ports:
            - containerPort: 3000

The template section describes the Pods the Deployment should create.

That is worth noticing carefully.

The Deployment is not the process that handles requests. The Pods created from the template are the actual running instances. The Deployment is the higher-level controller that manages them.

Why Deployments matter so much

When people say they "deployed an app to Kubernetes," they often mean they created or updated a Deployment.

That is because Deployments are the standard way to run stateless applications such as:

APIs
web frontends
background workers that do not require stable identity

If you remember the role split clearly, Kubernetes gets less fuzzy:

Pod: one running instance
Deployment: manager of many Pods and their updates

flowchart TD
    A[Deployment] --> B[ReplicaSet]
    B --> C[Pod 1]
    B --> D[Pod 2]
    B --> E[Pod 3]

You do not need to understand ReplicaSets deeply yet. Just know that Deployments use lower-level machinery under the hood to maintain the desired number of Pods.

Services: Stable Networking for Unstable Pods

By now, we have a problem.

Pods are replaceable. They come and go. Their IP addresses are not meant to be stable forever.

So how do other parts of the system talk to them reliably?

That is where Services come in.

A Service gives a stable way to reach a set of Pods.

Why Services exist

Imagine you have three Pods for your API, all managed by a Deployment.

Those Pods may be recreated during a rollout. One may crash and be replaced. Another may get scheduled onto a different node.

If clients had to know the exact IP address of each Pod, everything would break constantly.

Instead, a Service selects a group of Pods, usually by label, and gives them a stable network identity.

Clients talk to the Service. The Service routes traffic to matching Pods.

Example Service manifest

apiVersion: v1
kind: Service
metadata:
  name: demo-api
spec:
  selector:
    app: demo-api
  ports:
    - port: 80
      targetPort: 3000

In this example:

the Service listens on port 80
it forwards traffic to port 3000 on matching Pods
it selects Pods with the label app: demo-api

The selector is crucial. It is how the Service knows which Pods belong behind it.

The most useful mental model for Services

Do not think of a Service as "the app itself."

Think of it as a stable network front door for a changing set of Pods.

That one sentence explains why Services are so central to Kubernetes networking.

flowchart LR
    A[Client] --> B[Service]
    B --> C[Pod 1]
    B --> D[Pod 2]
    B --> E[Pod 3]

Why this is a big deal

Kubernetes separates concerns in a useful way:

Deployments manage lifecycle and replica count
Pods are the actual running units
Services provide stable network access

That separation is one of the reasons Kubernetes scales conceptually once you stop treating every object as a random piece of YAML.

Each object has a distinct job.

Labels: The Glue Between Objects

There is one small Kubernetes concept that quietly makes many other concepts work: labels.

Labels are key-value pairs attached to objects.

They look simple because they are simple.

But they are also how Kubernetes groups things together.

For example:

a Deployment uses labels in its Pod template
a Service uses a selector to find Pods with matching labels
teams use labels to organize environments, versions, and application roles

Example labels:

labels:
  app: demo-api
  tier: backend
  env: production

Without labels, many Kubernetes objects would have no clean way to relate to each other.

That is why label consistency matters.

If your Service expects Pods labeled app: demo-api, but your Deployment creates Pods labeled app: api, the Service will not route traffic to them. The YAML may look fine at a glance, but the system will not connect the pieces.

This is an early example of a broader Kubernetes truth:

Small configuration mismatches often create large behavioral problems.

What kubectl Is Actually Doing

You cannot learn Kubernetes seriously without seeing kubectl, so it helps to place it correctly in the model.

kubectl is a command-line client for the Kubernetes API.

It is not Kubernetes itself. It is a way to talk to Kubernetes.

When you run a command like this:

kubectl apply -f deployment.yaml

you are sending a resource definition to the Kubernetes API. From there, the control plane stores the desired state and the relevant controllers begin reconciling toward it.

Similarly, when you run commands like these:

kubectl get pods
kubectl get deployments
kubectl get services

you are asking the API for current state.

This may sound obvious, but it matters because beginners sometimes treat kubectl as if it were a deployment engine doing everything directly. It is better to think of it as your interface to the control plane.

A Simple End-to-End Example

Let us connect the pieces.

Suppose you want to run a small API in Kubernetes.

At a high level, the flow looks like this:

You create a Deployment that says you want three replicas of your API.
Kubernetes creates Pods based on the Pod template in that Deployment.
The scheduler places those Pods onto worker nodes.
A Service selects those Pods by label and gives them a stable way to receive traffic.
If one Pod dies, Kubernetes creates another to restore the desired replica count.

That is the beginner version of what Kubernetes is doing for you every day.

Here is the overall shape:

flowchart TD
    A[Deployment with 3 replicas] --> B[Pods created]
    B --> C[Scheduler places Pods on nodes]
    C --> D[Service selects Pods by label]
    D --> E[Clients send traffic to Service]
    B --> F[If Pod dies, controller creates replacement]

Notice what you did not need to manage by hand:

which exact machine each instance runs on
how to keep the replica count stable
how to give unstable Pods a stable network identity

That is the operational value Kubernetes is providing.

Why Kubernetes Feels Hard At First

At this point, the basic pieces might seem reasonable. So why does Kubernetes still feel overwhelming to so many developers?

There are a few honest reasons.

1. It introduces many objects quickly

Pods, Deployments, Services, ConfigMaps, Secrets, Ingress, StatefulSets, Jobs, volumes, probes, namespaces, and more.

If you encounter all of them before building a mental model, they blur together.

2. The YAML creates false confidence

Kubernetes manifests often look readable before they are understandable.

A beginner can look at a Deployment file and recognize fields without understanding the lifecycle behavior behind them. That creates a subtle trap where the syntax looks easier than the system really is.

3. The abstractions are operational abstractions

Many developers are comfortable reading application code. Kubernetes asks you to reason about scheduling, service discovery, lifecycle management, and distributed systems behavior. That is a different layer of thinking.

4. Many tutorials focus on commands before models

It is easy to find content that says "run this command" or "paste this manifest." It is harder to find explanations of why the pieces exist and how they fit together.

That is why your first goal should not be memorization.

Your first goal should be a stable mental model.

Once the model is clear, the commands and resource types become much easier to organize.

The Mental Model That Makes Kubernetes Easier

If you want a compact way to carry Kubernetes in your head, use this model:

1. The cluster is a pool of machines

Your applications are no longer tied to one named server.

2. Kubernetes is continuously reconciling desired state

You declare what should exist. Kubernetes keeps trying to make it true.

3. Pods are disposable runtime units

They run your containers, but they are not stable long-term identities.

4. Deployments manage the lifecycle of stateless app replicas

They keep the right number of Pods running and help roll out updates.

5. Services give stable network access to changing Pods

They let clients reach workloads without depending on specific Pod IPs.

If those five points feel solid, you are already past the point where Kubernetes is just a pile of nouns.

What We Deliberately Did Not Cover Yet

Part of learning Kubernetes well is learning it in the right order.

So in this first article, we intentionally did not go deep on:

ConfigMaps and Secrets
health checks
rolling updates in detail
autoscaling
persistent storage
namespaces
Ingress
resource requests and limits
debugging broken workloads
security and RBAC

Those topics matter a lot.

But they make much more sense once you already understand the foundation: Kubernetes is a declarative system that schedules and manages Pods across a cluster, usually through higher-level objects like Deployments and Services.

That foundation is the real prerequisite.

Final Takeaways

Kubernetes is easier to approach once you stop asking, "What does this YAML field do?" and start asking, "What role does this object play in the system?"

At the beginner level, the most important roles are these:

Node: a machine that can run workloads
Pod: the smallest runnable unit, usually wrapping one application container
Deployment: the controller that manages replicated Pods and updates them safely
Service: the stable network endpoint for a changing set of Pods
Control plane: the management side that stores state, schedules workloads, and runs reconciliation loops

If you understand those roles and the idea of desired state, Kubernetes stops looking like random ceremony.

It starts looking like a system with clear responsibilities.

That is the point where learning becomes faster.

In Part 2, we will move from core concepts to the things developers actually touch when running applications on Kubernetes: configuration, health checks, rollouts, scaling, storage, namespaces, and the first layer of debugging.