What Kubernetes Is and Why It Exists

Summary

Kubernetes is an open-source platform that runs and manages containerized workloads across a pool of machines using a desired-state control model.
Insight: You do not tell Kubernetes how to run something step by step. You declare what you want, and controllers continuously drive reality toward that target.
Key Concepts: the API server as the single source of truth, the control loop (observe, compare, act), containers as the unit of packaging, and Pods as the unit of scheduling.
When to Use: many services, frequent deploys, a need for self-healing, horizontal scaling, and portability across clouds or on-prem.
Limitations/Trade-offs: real operational complexity, a steep learning curve, and overkill for a single small app that a managed platform could run.
Related Topics: declarative configuration, reconciliation, and the control-plane component layout.

Foundations

Containers solved packaging. One image bundles your app, its runtime, and its dependencies, and it runs the same on a laptop and in production.

Containers did not solve operations. A container that crashes stays dead. A node that fails takes its containers with it.

At scale you have hundreds of containers across dozens of machines. Something must decide where each one runs, restart the failed ones, and reroute traffic away from broken nodes.

That job is orchestration, and Kubernetes is the orchestrator that won the market.

The core idea is simple to state. You write down the state you want, and the system works continuously to make the actual state match it.

This is different from a script. A script runs once, top to bottom, and if a step fails halfway, you are left in an unknown state.

Kubernetes instead treats your intent as data stored in the cluster. Controllers watch that data and act until reality agrees with it.

Mechanics & Interactions

Everything in Kubernetes flows through the API server. Clients like kubectl, CI pipelines, and controllers all talk to it over HTTP.

The API server validates requests and persists accepted objects into etcd, a consistent key-value store that holds the entire desired state of the cluster.

A Pod is the smallest deployable unit. It wraps one or more containers that share a network namespace and storage, and it is what the scheduler places onto a node.

You rarely create bare Pods. You create higher-level objects like a Deployment, and its controller creates and manages the Pods for you.

Here is a minimal desired-state declaration.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: ghcr.io/acme/web:1.4.2

When you submit this, the API server stores it. The Deployment controller notices there should be three Pods and creates them.

The scheduler assigns each unscheduled Pod to a node with enough capacity. On that node, the kubelet talks to the container runtime through the CRI to actually start the containers.

That runtime is containerd, not Docker Engine. Docker builds your images and runs them locally, but the in-cluster runtime on nodes is containerd via the CRI. The old dockershim path was removed years ago.

If a Pod dies, the controller sees a gap between desired (3) and actual (2) and creates a replacement. If a node dies, its Pods are rescheduled elsewhere. This is self-healing, and it is just the control loop running.

Advanced Considerations & Applications

The reconciliation model is the reason Kubernetes is extensible. Custom Resource Definitions (CRDs) let you add your own object types, and a custom controller or operator reconciles them exactly like built-in objects do.

This is how databases, certificate managers, and service meshes ship as Kubernetes-native software. They are just new desired-state APIs with controllers behind them.

The trade-off is complexity. You now operate a distributed system with a control plane, a network fabric, storage plugins, and RBAC, all of which need patching and monitoring.

Use managed control planes (EKS, GKE, AKS) unless you have a strong reason to self-host. They remove most of the etcd and API-server operational burden.

For a single small service with predictable load, a serverless platform or a PaaS is often the better call. Kubernetes earns its keep when you have many services, frequent releases, and a platform team to run it.

The payoff is a uniform, declarative substrate. Deployments, scaling, secrets, networking, and rollouts all use the same submit-and-reconcile model, which is what makes GitOps and automation practical.

Common Misconceptions

"Kubernetes runs my containers with Docker." No. Docker is a build and local-dev tool. Nodes run containers with containerd through the CRI.

"Kubernetes makes my app scalable automatically." It gives you the mechanism, but you still set replica counts, resource requests, and autoscalers. A single-threaded app will not scale just because it is in a Pod.

"kubectl apply runs my changes like a script." It records desired state. Controllers apply it asynchronously, and the change may take time or fail quietly in a controller.

"Kubernetes replaces my CI/CD." It is the deployment target, not the pipeline. You still need CI to build and push images and something to submit manifests.

"Bigger clusters are always better." Very large clusters strain etcd and the scheduler. Many teams run multiple smaller clusters instead.

FAQs

Do I need Kubernetes for a small project? Usually not. A managed PaaS or a couple of VMs is simpler until you have many services or real scaling needs.

Is Kubernetes the same as Docker? No. Docker packages and builds containers. Kubernetes schedules and manages them across machines using containerd as the node runtime.

What is the single most important concept? Desired state and reconciliation. Almost every other feature is an application of that one control loop.

Where is my cluster's state stored? In etcd, behind the API server. Everything you submit becomes an object there, and controllers act on it.

Can I run Kubernetes on my laptop? Yes, with kind, minikube, or k3d for learning and testing. Production clusters are typically managed cloud offerings.

Why is it called K8s? It is a numeronym: K, then eight letters, then s.

Stack versions: This page was written for Kubernetes 1.36.2, Docker Engine 29.6.1 (BuildKit default), containerd (CRI runtime on nodes), Helm 3, Compose v2, Argo CD (latest - verify at build), and Gateway API (GA - verify controller support at build).

What Kubernetes Is and Why It Exists

Summary

Kubernetes is an open-source platform that runs and manages containerized workloads across a pool of machines using a desired-state control model.
Insight: You do not tell Kubernetes how to run something step by step. You declare what you want, and controllers continuously drive reality toward that target.
Key Concepts: the API server as the single source of truth, the control loop (observe, compare, act), containers as the unit of packaging, and Pods as the unit of scheduling.
When to Use: many services, frequent deploys, a need for self-healing, horizontal scaling, and portability across clouds or on-prem.
Limitations/Trade-offs: real operational complexity, a steep learning curve, and overkill for a single small app that a managed platform could run.
Related Topics: declarative configuration, reconciliation, and the control-plane component layout.

Foundations

Containers solved packaging. One image bundles your app, its runtime, and its dependencies, and it runs the same on a laptop and in production.

Containers did not solve operations. A container that crashes stays dead. A node that fails takes its containers with it.

At scale you have hundreds of containers across dozens of machines. Something must decide where each one runs, restart the failed ones, and reroute traffic away from broken nodes.

That job is orchestration, and Kubernetes is the orchestrator that won the market.

The core idea is simple to state. You write down the state you want, and the system works continuously to make the actual state match it.

This is different from a script. A script runs once, top to bottom, and if a step fails halfway, you are left in an unknown state.

Kubernetes instead treats your intent as data stored in the cluster. Controllers watch that data and act until reality agrees with it.

Mechanics & Interactions

Everything in Kubernetes flows through the API server. Clients like kubectl, CI pipelines, and controllers all talk to it over HTTP.

The API server validates requests and persists accepted objects into etcd, a consistent key-value store that holds the entire desired state of the cluster.

A Pod is the smallest deployable unit. It wraps one or more containers that share a network namespace and storage, and it is what the scheduler places onto a node.

You rarely create bare Pods. You create higher-level objects like a Deployment, and its controller creates and manages the Pods for you.

Here is a minimal desired-state declaration.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: ghcr.io/acme/web:1.4.2

When you submit this, the API server stores it. The Deployment controller notices there should be three Pods and creates them.

The scheduler assigns each unscheduled Pod to a node with enough capacity. On that node, the kubelet talks to the container runtime through the CRI to actually start the containers.

Advanced Considerations & Applications

This is how databases, certificate managers, and service meshes ship as Kubernetes-native software. They are just new desired-state APIs with controllers behind them.

The trade-off is complexity. You now operate a distributed system with a control plane, a network fabric, storage plugins, and RBAC, all of which need patching and monitoring.

Use managed control planes (EKS, GKE, AKS) unless you have a strong reason to self-host. They remove most of the etcd and API-server operational burden.

Common Misconceptions

"Kubernetes runs my containers with Docker." No. Docker is a build and local-dev tool. Nodes run containers with containerd through the CRI.

"kubectl apply runs my changes like a script." It records desired state. Controllers apply it asynchronously, and the change may take time or fail quietly in a controller.

"Kubernetes replaces my CI/CD." It is the deployment target, not the pipeline. You still need CI to build and push images and something to submit manifests.

"Bigger clusters are always better." Very large clusters strain etcd and the scheduler. Many teams run multiple smaller clusters instead.

FAQs

Do I need Kubernetes for a small project? Usually not. A managed PaaS or a couple of VMs is simpler until you have many services or real scaling needs.

Is Kubernetes the same as Docker? No. Docker packages and builds containers. Kubernetes schedules and manages them across machines using containerd as the node runtime.

What is the single most important concept? Desired state and reconciliation. Almost every other feature is an application of that one control loop.

Where is my cluster's state stored? In etcd, behind the API server. Everything you submit becomes an object there, and controllers act on it.

Can I run Kubernetes on my laptop? Yes, with kind, minikube, or k3d for learning and testing. Production clusters are typically managed cloud offerings.

Why is it called K8s? It is a numeronym: K, then eight letters, then s.

Stack versions: This page was written for Kubernetes 1.36.2, Docker Engine 29.6.1 (BuildKit default), containerd (CRI runtime on nodes), Helm 3, Compose v2, Argo CD (latest - verify at build), and Gateway API (GA - verify controller support at build).

What Kubernetes Is and Why It Exists

Buscar en la documentación

What Kubernetes Is and Why It Exists