Kubernetes Internals (Part 1): What Kubernetes Is#

One-line summary: Kubernetes is a control plane that reconciles desired state into running workloads across a fleet of machines.

Goal#

• Explain what Kubernetes is in operational terms, not marketing terms.
• Introduce the control plane/data plane split and why reconciliation matters.
• Define the core objects you will see in every cluster.

What Kubernetes is (and isn’t)#

Kubernetes manages the resources of nodes grouped into a cluster through a single API. That single control surface is what makes consistent placement, networking, and storage policy possible across many machines. In practice, this means you describe what should run and Kubernetes continuously drives the cluster toward that state.

flowchart LR
  API[API Server]
  subgraph Cluster[Cluster Nodes]
    N1[Node 1]
    N2[Node 2]
    N3[Node 3]
  end

  API --> N1
  API --> N2
  API --> N3

The big picture: control plane vs data plane#

flowchart LR
  subgraph ControlPlane[Control Plane]
    API[API Server]
    ETCD[etcd]
    CM[Controller Manager]
    SCH[Scheduler]
  end
  subgraph DataPlane[Data Plane]
    Kubelet[Kubelet]
    Runtime[Container Runtime]
    CNI[CNI Plugin]
    KubeProxy[kube-proxy]
  end

  API --> ETCD
  API --> CM
  API --> SCH
  SCH --> API
  CM --> API
  API --> Kubelet
  Kubelet --> Runtime
  Kubelet --> CNI
  KubeProxy --> API

Control plane components#

• API Server: the front door for all requests and state changes.
• etcd: the authoritative state store.
• Scheduler: assigns Pods to nodes.
• Controller Manager: reconciliation loops for Deployments, Nodes, Jobs, etc.

Data plane components#

• Kubelet: the node agent that creates and manages Pods and reports status.
• Container runtime: the CRI implementation that runs containers.
• CNI plugin: pod networking.
• kube-proxy: Service VIP and load-balancing rules.

API server request flow (authn -> authz -> admission)

etcd consistency and performance (quick notes)

Kubernetes is the control plane; the data plane is where your workloads actually run.

The reconciliation loop#

Kubernetes is eventually consistent. Controllers watch objects, compare actual vs desired state, and apply changes until they match. This is why systems converge instead of relying on one-time orchestration.

flowchart LR
  Desired[Desired State] --> API[API Server]
  API --> Controllers[Controllers]
  Controllers --> Scheduler[Scheduler]
  Scheduler --> Kubelet[Kubelet]
  Kubelet --> Actual[Actual State]
  Actual --> Status[Status Update]
  Status --> API

Typical flow:

1. You submit a desired state (e.g., a Deployment with 3 replicas).
2. Controllers create/adjust ReplicaSets and Pods.
3. The scheduler binds Pods to nodes.
4. Kubelet runs them and reports status back.

Failed Pods return because controllers keep reconciling until actual matches desired.

This loop is always on, which is why failure recovery is mostly automatic.

Controller pattern (scan)

Core objects you should know#

• Pod: the smallest runnable unit; a sandbox that shares network and volumes (e.g., a web container + sidecar).
• Deployment: declares how many replicas should run and manages rollouts (e.g., blue/green or canary-style updates).
• Service: provides a stable IP/DNS and load-balances across Pods (e.g., fronting a Deployment).
• Namespace: partitions resources and policy boundaries (e.g., dev vs prod isolation).
• ConfigMap/Secret: injects configuration and credentials (e.g., app config vs API keys).
• Job/CronJob: run-to-completion and scheduled workloads (e.g., nightly batch tasks).

These are the objects that form the daily language of Kubernetes operations.

When Kubernetes shines (and when it doesn’t)#

Shines when:

• You need automated placement and re-placement across failure domains.
• You rely on declarative rollouts, health-gated updates, and fast rollback.
• You want consistent service discovery and load balancing across nodes.
• You need uniform config/secret distribution and lifecycle controls.

Not ideal when:

• You only run a handful of services on a single node.
• Operational overhead outweighs the benefits for a small fleet.
• You need ultra-low-latency single-node control with no orchestration.

A quick command tour#

kubectl get nodes
kubectl get ns
kubectl get pods -A
kubectl

Notes:

• Confirm all nodes are Ready to validate cluster health.
• Check namespaces and system Pods to see the control plane footprint.
• Use kubectl describe to understand why a Pod is Pending or restarting.

These commands show the cluster health and the most common workload types.

Wrap-up#

Kubernetes is a reconciliation engine for distributed systems: a control plane that turns desired state into running reality. The rest of this series goes deeper into how each part works.

Next up: Part 2 — Linux Control Primitives.

Series: Kubernetes Internals: How the Cluster Actually Works