Kubernetes for Developers: Pods, Deployments and Services

Kubernetes runs containers across a cluster of machines and keeps them in the state you describe. You don't say "start three containers"; you declare "there should always be three", and Kubernetes makes it so, even when machines fail.

Pod

The smallest unit: one or more containers that share a network address and storage. You rarely create Pods directly, because a Pod that dies isn't replaced on its own.

Deployment

Manages a set of identical Pods. It keeps the requested number running, replaces failed ones and rolls out new versions gradually.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  replicas: 3
  selector:
    matchLabels: { app: api }
  template:
    metadata:
      labels: { app: api }
    spec:
      containers:
        - name: api
          image: ghcr.io/acme/api:1.4.2
          ports:
            - containerPort: 3000

Service

Pods come and go and their IPs change. A Service gives a stable name and IP that load-balances across all Pods matching a label selector.

apiVersion: v1
kind: Service
metadata:
  name: api
spec:
  selector: { app: api }
  ports:
    - port: 80
      targetPort: 3000

Other Pods in the namespace can now call http://api.

The rest of the vocabulary

• Namespace - a folder for resources; often one per team or environment.
• Node - a machine (VM) that runs Pods.
• ConfigMap / Secret - configuration and credentials injected into Pods.
• Ingress / Gateway - routes outside HTTP traffic to Services.
• Labels - key/value tags that tie everything together through selectors.

The control loop

Everything in Kubernetes follows the same idea: you write the desired state, controllers compare it with the actual state, and they act to close the gap. Once that clicks, most of Kubernetes makes sense.