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.

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#

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