What Kubernetes Actually Does

Kubernetes is not magic, and it does not replace infrastructure knowledge. It gives you a control plane for describing how workloads should run, how they should recover, and how traffic should reach them.

Kubernetes Field Notes · Foundation Level · Estimated reading time: 6 minutes

The simple version

Kubernetes is a platform for running and managing containers across a group of machines.

At a basic level, Kubernetes answers a few operational questions:

• Where should this workload run?
• How many copies should be running?
• Is the workload healthy?
• How should traffic reach it?
• What configuration does it need?
• What should happen if it fails?
• How do we update it without taking everything down?

A single container can run on a single server without Kubernetes. The value of Kubernetes starts to show up when you need to manage many workloads across many nodes with repeatable deployment, health checks, scaling, networking, and recovery.

Desired state vs actual state

One of the most important Kubernetes concepts is desired state.

You tell Kubernetes what you want. Kubernetes compares that desired state against what is actually running. If something does not match, Kubernetes tries to correct it.

For example, you might define a Deployment that says:

Run three copies of this application.
Use this container image.
Expose this port.
Restart failed containers.
Roll out updates in a controlled way.

If one pod dies, Kubernetes tries to bring another one up. If a node fails, Kubernetes can reschedule workloads somewhere else, assuming the cluster has capacity and the workload can run on another node.

That does not mean Kubernetes fixes every problem. If the application is badly designed, the image is broken, DNS is wrong, storage is unavailable, or the network path is blocked, Kubernetes may keep trying to recover but still fail.

The core building blocks

Kubernetes has many objects, but the first few matter most when you are starting.

Pods

A Pod is the smallest deployable unit in Kubernetes. It usually contains one application container, although it can contain more than one when containers need to share the same network and storage context.

Deployments

A Deployment manages how pods are created, updated, scaled, and replaced. In normal application deployments, you usually create a Deployment rather than creating individual pods by hand.

Services

Pods are temporary. They can be destroyed and recreated. A Service gives those changing pods a stable network identity so other workloads can reach them.

Ingress

Ingress helps route external HTTP or HTTPS traffic into services inside the cluster. In real environments, this usually involves an ingress controller, DNS, certificates, firewall rules, and load balancer configuration.

ConfigMaps and Secrets

ConfigMaps and Secrets let you separate configuration from container images. ConfigMaps are for general configuration. Secrets are for sensitive values, although you still need to handle them carefully and understand how your cluster stores and exposes them.

Kubernetes does not remove infrastructure problems

Kubernetes gives you a common way to define and manage workloads, but the old problems still matter:

• DNS
• certificates
• firewall rules
• routing
• storage
• identity
• permissions
• logging
• monitoring
• patching
• backups

This is why Kubernetes can feel confusing at first. When something breaks, the issue might be inside Kubernetes, but it might also be below it or around it.

A failed application could be caused by a bad container image, missing environment variable, failed secret mount, blocked network path, DNS failure, expired certificate, unavailable storage volume, or insufficient CPU and memory.

A tiny example

This simple Deployment tells Kubernetes to run one copy of nginx:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-demo
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx-demo
  template:
    metadata:
      labels:
        app: nginx-demo
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80

This does not just start a container. It creates a desired state. Kubernetes will try to keep one matching pod running.

If you change the replica count from one to three, Kubernetes will try to run three copies:

replicas: 3

That simple idea is the foundation of Kubernetes: define the desired state, then let the control plane work to maintain it.

What Kubernetes is good at

Kubernetes is useful when you need repeatable workload deployment and management across infrastructure.

• Running containerized workloads
• Restarting failed workloads
• Scaling workloads up or down
• Rolling out application updates
• Rolling back failed changes
• Providing internal service discovery
• Managing configuration and secrets
• Standardizing deployment patterns

What Kubernetes is not

Kubernetes is not an automatic fix for poor application design or weak operations.

• It is not a security program by itself.
• It is not a replacement for backups.
• It is not a replacement for monitoring.
• It does not automatically make applications highly available.
• It does not eliminate the need for infrastructure knowledge.
• It does not make bad networking or DNS designs disappear.

Kubernetes can help make a good platform more consistent, but it can also make a messy environment harder to understand if the fundamentals are weak.

What to learn next

The next practical step is to understand the basic Kubernetes objects in more detail:

• Pods
• Deployments
• ReplicaSets
• Services
• ConfigMaps
• Secrets
• Namespaces
• Ingress

Once those objects make sense, the rest of Kubernetes becomes easier to reason about.