Kubernetes

Compare placement, networking, and file sharing when containers run in one Pod.

Containers in one Pod share networking and are assigned to the same node.

Shared volume mounts allow file access across containers. Containers also share a port space and cannot bind the same address and port simultaneously.

Use it to decide container grouping and understand Pod networking and storage.

Explore node components, resources, and recovery after node failure.

A Pod runs on one node; running elsewhere requires a replacement Pod.

Kubelet and the container runtime manage execution. Scheduling uses allocatable resources, and recovery can create new Pods rather than move existing ones.

Use it to distinguish node capacity from Pod placement and understand replacement identities.

Run work that ends after a required number of successful completions.

A Job tracks successful work rather than continuously running replicas.

Completions sets the success target; parallelism controls concurrency. Retries follow configured limits, and CronJobs add schedules.

Use it for batch processing, migrations, one-off tasks, and scheduled work.

Follow reconciliation when the actual Pod count differs from the declared count.

Controllers repeatedly compare desired and actual state and take corrective action.

The API server stores configuration, the scheduler chooses nodes, and kubelet manages execution. Missing replicas can be replaced after failure.

Use it to understand declarative configuration and the responsibilities involved in recovery.

Follow a rolling update that progressively creates new Pods and removes old ones.

Scale the new ReplicaSet up and the previous one down.

Availability and surge depend on update settings. Readiness gates replacement, and retained ReplicaSets support rollback.

Use it to understand availability during rollout and version rollback.

Follow HPA as it adjusts replicas using CPU utilization.

Calculate required replicas from the metric-to-target ratio and apply configured bounds.

Tolerance handles small deviations, and stabilization can delay downscaling. Pod scaling and node-capacity scaling are separate responsibilities.

Use it to plan metric targets, replica bounds, and protection against frequent scaling changes.

Compare how readiness, liveness, and startup probes affect traffic and restarts.

Readiness checks traffic eligibility; liveness checks whether a restart is needed.

Readiness failure alone does not terminate a container. Liveness can trigger restart, while startup probes allow initialization time.

Use it to distinguish traffic exclusion from container restart and choose health-check settings.

Use a Service to retain a connection name as Pods change or scale.

A Service provides a stable endpoint and selects matching Pods.

Label selectors can discover replacement Pods with new IPs. Readiness controls which endpoints receive traffic.

Use it to connect workloads without hard-coded Pod IPs and understand traffic during deployments.

Follow Ingress rules routing external HTTP requests to multiple Services.

Match the request host and path to select a backend Service.

An Ingress controller must apply the rules. This example shares one external endpoint and terminates TLS at the Ingress.

Use it to plan host/path routing and locate external access and certificate handling.

Pass environment-specific configuration separately from container images.

ConfigMap and Secret values can be injected as environment variables or mounted files.

Existing environment variables do not update automatically. Ordinary ConfigMap volume files can update, but applications must reread them. Secret encoding is not encryption.

Use it to separate environment settings and plan update behavior and sensitive-value access.

Compare data retention in writable layers, emptyDir, and persistent volumes.

EmptyDir follows the Pod lifetime; persistent storage can outlive Pod replacement.

Recreating a container resets its writable layer but preserves the same Pod emptyDir. Persistent volumes use PVC requests, access modes, and reclaim policies.

Use it to distinguish temporary data from data that must survive restarts and replacements.

Follow node selection using resource requests and placement constraints.

Scheduling evaluates declared requests rather than current measured usage.

Filter eligible nodes, then evaluate them with scoring policies. Limits bound runtime usage, and CPU and memory exceedance behave differently.

Use it to understand requests, Pending Pods, node selection, and resource shortages.