Kubernetes Foundations: Pods, Workloads, and Declarative State

The API stores intent

Kubernetes exposes an API of objects describing desired state and reported status. When you apply a Deployment, you are not issuing an imperative "start these exact processes forever" command. You are storing a specification that controllers repeatedly compare with observed cluster state. If a managed Pod disappears, a controller can create a replacement to restore the requested replica count.

The specification and status can disagree temporarily. Reconciliation takes time, and missing capacity, image pull errors, or admission policy can prevent convergence. A successful apply means the API accepted the object; it does not prove that the workload is serving traffic. Inspect rollout status, events, and Pod conditions to distinguish acceptance from readiness.

Pods are replaceable units

A Pod groups containers that share scheduling placement and certain networking/storage resources. Containers in the same Pod can communicate over localhost. Containers in different Pods should use a service discovery contract, not assume a particular Pod IP remains stable.

A container restart can occur within an existing Pod. A replacement Pod has a new identity and may run on another node. Data written only to a container filesystem is not a durable storage strategy. Choose persistent volumes or an external durable service when data must outlive a replacement. Even a persistent volume does not automatically create backups or multi-writer safety.

Choose a workload controller

Use a Deployment for interchangeable application replicas. A StatefulSet provides stable identities and ordered behavior useful for some stateful applications, but it does not implement database replication for you. A Job runs work toward completion; a CronJob schedules Jobs and needs a deliberate overlap and missed-schedule policy. A DaemonSet runs a Pod on eligible nodes, commonly for node agents.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: catalog
spec:
  replicas: 2
  selector:
    matchLabels:
      app: catalog
  template:
    metadata:
      labels:
        app: catalog
    spec:
      containers:
        - name: api
          image: example.invalid/catalog@sha256:REPLACE_WITH_VERIFIED_DIGEST
          ports:
            - containerPort: 8080

The image reference is illustrative and not deployable. Pin a real verified artifact before use. The selector matches the Pod template labels; changing labels casually can disconnect an operational relationship. Declaring a container port documents intent but does not publish a Service or configure an application to listen on that port.

Debug the ownership chain

Start with the Deployment, inspect its ReplicaSet, then inspect its Pods and events. If no Pod was created, application logs cannot explain the failure. If the Pod cannot be scheduled, check requests, taints, affinity, and available nodes. If the image cannot be pulled, check the image reference and registry access. Only after the process starts should application-level diagnostics become the primary investigation.

Practice by deleting one Pod in a disposable environment and watching the controller replace it. Confirm that the replacement has a different name and that traffic does not rely on that name. This experiment makes declarative ownership concrete without changing a production cluster.