Kubernetes Basics: Pods, Deployments, Services, and Why the Abstractions Exist

Kubernetes manages containerized workloads by representing desired state as objects and continuously working toward that state across a cluster. A useful engineering habit is to state the mechanism first and the tool second; tools change, but the problem usually stays recognizably similar.

The core idea

Running one container is easy. Running many replicas across changing machines, replacing failed instances, exposing stable network endpoints, and rolling out new versions is operationally harder. Kubernetes addresses that coordination problem through declarative objects and controllers.

How it works

A Pod is the basic execution unit for containers that share a network namespace and certain other resources. Most application workloads are not managed as standalone Pods; higher-level controllers create and replace them.

A Deployment describes a desired set of replicas and manages rollout and replacement of Pods. A Service provides a stable network abstraction for reaching a changing set of Pods selected by labels.

Kubernetes controllers continuously compare desired state with observed state. If a Pod disappears, the controller can create another one. This is the core reconciliation model.

A concrete example

A campus API can run three replicas behind a Service. If one Pod fails, the Deployment controller creates a replacement. The client continues using the Service address rather than tracking individual Pod IP addresses.

Common mistakes

• Treating Kubernetes YAML as magic configuration without understanding the controller model.
• Running Kubernetes for a project that does not need its operational complexity.
• Assuming a Service automatically solves authentication, data consistency, or application-level retries.

A student project that makes it stick

Apply the concept to a project you already have. Keep the scope narrow, document assumptions, and make the result reproducible by another student on another machine. This is where a conceptual idea becomes an engineering artifact.

Where it connects

The surrounding systems—version control, containers, CI, networking, databases, security, and observability—share the same engineering pattern: define desired behavior, make state visible, automate repeatable work, and leave enough evidence to debug failures.

What to remember

1. Learn the abstraction before the command sequence.
2. Prefer reproducible workflows over tribal knowledge.
3. Make important state and dependencies visible.
4. Treat operational behavior as part of the software design.
5. Keep the system smaller than your ability to explain it.

Limitations

Tooling and deployment details vary by operating system, provider, project age, and team conventions. The primary documentation linked below is the appropriate reference when a real deployment depends on version-specific behavior.

Related Observatory reads

• docker containers and what they actually isolate
• ci cd as a repeatable software pipeline
• observability logs metrics and traces

Primary sources

• Kubernetes Documentation — Concepts
• Kubernetes Documentation — Deployments