Kubernetes foundations

A container packages a process and its dependencies. It does not, by itself, decide where three copies should run or replace a copy lost with a machine. Doing that manually means repeatedly checking machines, starting processes, and coordinating changes.

Kubernetes lets you describe a target and delegates recurring decisions to cooperating components. A cluster is a group of machines, called nodes, managed together. Our example is a small stateless web application: any replica can answer a request without relying on private local session data.

An API object is a stored record, such as a Deployment named foundations-web. Its spec describes the requested configuration. For this Deployment, spec.replicas: 3 asks for three replicas. Its status reports what Kubernetes components have observed, including replica counts and progress conditions.

Updating spec changes the target. It does not immediately change reality. Status can temporarily lag behind events, so a difference between the two is a reason to investigate, not automatic proof of a fault. A manifest is a file describing objects; kubectl submits requests to the Kubernetes API on your behalf.

The control plane coordinates the cluster. Worker nodes provide the environment where application containers run. These are roles; a small learning cluster may place both on one machine.

A Pod is the unit Kubernetes schedules: one or more closely related containers sharing networking and, when configured, storage. Our application uses one container per Pod.

A Deployment manages the application’s rollout through ReplicaSets. A ReplicaSet maintains its requested count of active Pods, meaning Pods that have not completed and are not being deleted. Active does not mean ready. In a simple steady state, our Deployment manages one active ReplicaSet, which owns three Pods. During an update, multiple ReplicaSets can participate.

The ownerReferences field records this ownership chain: Deployment → ReplicaSet → Pod.

Before running the “Create a Pod” architecture scenario, predict what exists immediately after the API accepts a Deployment. Which component creates the Pod object, which chooses its node, and which starts its container? Advance one step at a time to check your answers.

A created Pod exists in the API. A scheduled Pod has a node assignment. Pending is a Pod phase that can include waiting for scheduling or container setup, so Pending alone does not identify the cause.

Running is a lifecycle phase, not a guarantee that the application is healthy. Ready is a condition indicating readiness to serve traffic. A readiness probe can test an application-specific endpoint; a running process may still fail that check. Without a meaningful readiness check, readiness may tell you less than you expect.

For a typical Service, Pods that are not ready do not receive normal application traffic. Readiness and network reachability still do not prove that every business operation works.

Reconciliation means observing state and taking steps toward the target again when needed. If a container exits, kubelet may restart that container according to its restart policy, within the same Pod. If a managed Pod is deleted, its controller can create a different Pod with a new unique identifier (UID).

A Pod does not move intact to another node. Replacement is a new object that must be scheduled and started. Detecting a failed node and replacing affected workloads takes time; policies and available capacity affect recovery.

Controllers cannot invent CPU capacity, repair an invalid image reference, or fix broken application code. Repeated attempts may remain blocked until you resolve the underlying constraint.

Suppose the ReplicaSet owns three active Pods, but only two fit on eligible nodes. Two may become ready while the third stays Pending with no node assignment. The desired count is three, the active Pod count is three, and the ready count is two.

The ReplicaSet does not keep creating extra Pods simply because one is unready. The scheduling problem belongs at the placement stage. The scheduler considers resource requests and constraints, not only a machine’s currently idle CPU.

Start with the gap between the target and the observation. If three replicas were requested, determine whether three Pod objects exist, whether they have nodes, and whether their containers are ready. Each answer narrows the investigation.

• Fewer Pods than requested: inspect Deployment and ReplicaSet conditions and events for creation failures, such as quota restrictions.
• Pod exists without a node: inspect scheduling events and the requested resources or placement constraints.
• Pod has a node but containers have not started: inspect container waiting reasons and events for image, storage, or setup problems.
• Container starts but restarts or stays unready: inspect its state, restart history, application logs, and configured probes.

Kubernetes can be useful when a team needs consistent workload placement, controlled rollouts, and recovery across multiple machines and services. Those benefits come with responsibility for access, networking, upgrades, monitoring, capacity, and the applications themselves.

A small service may be easier to operate on a virtual machine, a managed application platform, or a managed container service. A local development stack may only need a container composition tool. Choose from actual availability, deployment, scaling, and team requirements.