From Compose to Kubernetes: A Mental Model

The plain-language idea

The orchestration-basics lesson in this track established why Kubernetes exists — a scheduler and self-healing across many machines, capabilities Compose structurally doesn't have. This lesson is narrower and more practical: given that you already know Compose, what's the fastest route to reading Kubernetes YAML without it feeling like a different language?

It isn't one. Three ideas you already reason about in a Compose file have a direct — though not identical — Kubernetes counterpart:

• A Compose service (an image, a replica count if you set one, a port) maps to a Deployment (the pod template plus desired replica count) fronted by a Service (a stable name and address, because unlike a long-lived Compose container, a Kubernetes pod is disposable and gets a new IP every time it's rescheduled).
• Compose volumes: maps to a PersistentVolumeClaim — a request for durable storage that survives a pod being deleted and recreated, the same way a Compose named volume survives a container being recreated.
• Compose environment: / .env maps to a ConfigMap (plain values) or Secret (sensitive values, base64-encoded at rest — not encrypted by default, a detail worth knowing before treating a Secret as sufficient on its own).

See it in a real thing: the same three ideas, two shapes

A Compose service — image, replica count, one host — maps to a Deployment fronted by a Service.

BackNext

# docker-compose.yml
services:
  api:
    image: myapp/api:1.4
    environment:
      - LOG_LEVEL=info
    volumes:
      - api-data:/data
volumes:
  api-data:

# kubernetes: Deployment + Service (abbreviated)
apiVersion: apps/v1
kind: Deployment
metadata: { name: api }
spec:
  replicas: 3
  template:
    spec:
      containers:
        - name: api
          image: myapp/api:1.4
          envFrom: [{ configMapRef: { name: api-config } }]
          volumeMounts: [{ name: api-data, mountPath: /data }]
      volumes:
        - name: api-data
          persistentVolumeClaim: { claimName: api-data-claim }
---
apiVersion: v1
kind: Service
metadata: { name: api }
spec:
  selector: { app: api }
  ports: [{ port: 80, targetPort: 8080 }]

Reading this top to bottom with the mapping in mind: replicas: 3 is Compose's implicit "one container" made explicit and pluralized. envFrom/configMapRef is environment: moved into its own reusable object instead of inlined. persistentVolumeClaim is the named volume, now requested rather than just declared. None of this is coincidence — Kubernetes didn't invent new problems, it made explicit and fleet-aware the same problems Compose already solved for one host.

What people usually miss

Watch out

• A Kubernetes Service is not "a container," despite the name. It's a stable virtual address and DNS name that routes to whichever pods currently match its label selector — the closer Compose analogy is the network, not any individual container, since pods themselves are treated as disposable.
• A PersistentVolumeClaim is a request, not the storage itself. The claim gets bound to an actual PersistentVolume (backed by cloud disk, NFS, or similar) separately — Compose's named volume collapses "I want storage" and "here is storage" into one declaration; Kubernetes deliberately splits them so the same claim can be satisfied by different backing storage per environment.
• A ConfigMap and a Secret are almost the same object with different intent, not different security guarantees by default. Base64 is an encoding, not encryption — a cluster needs encryption-at-rest and access control (RBAC) configured separately for a Secret to actually be more protected than a ConfigMap value.
• This mental model breaks down for anything Compose has no concept of at all — namespaces, RBAC, ingress controllers, custom resource definitions. The mapping gets you through the first 70% of a Deployment/Service/PVC-shaped manifest, not through a full cluster's configuration surface.

Why this matters in interviews

"You've used Docker Compose — walk me through how that translates to Kubernetes" is a common bridge question specifically for candidates without direct K8s production experience, and naming the concrete mapping (service→Deployment+Service, volumes→PVC, environment→ConfigMap/Secret) while explicitly flagging where the analogy breaks is a stronger answer than either claiming full Kubernetes fluency or disclaiming all knowledge of it.