Technology decisions
Docker and Kubernetes operate at different layers. Use Docker to build and run the application image; use Kubernetes when cluster scheduling, service discovery and controlled rollouts solve requirements that justify its operational cost.
Decision guide for Docker Engine/Compose image workflows and Kubernetes workload orchestration. Exact runtime, storage and rollout behavior depends on versions and cluster configuration. Examples are illustrative and were not deployed.
Docker packages and runs containers; Kubernetes schedules and reconciles containerized workloads across a cluster. Kubernetes uses container images, so the tools are complementary. A Docker image alone does not provide cluster orchestration, and Kubernetes does not replace image build design.
Scroll sideways to compare all columns on a smaller screen.
| Criterion | Docker | Kubernetes | What changes the decision |
|---|---|---|---|
| Primary job | Builds images and runs containers; Compose defines and runs multi-container applications. | Reconciles declared workloads and services across a cluster. | They commonly fit together in build and runtime stages. |
| Scope | One container or a Compose-defined application environment. | Cluster resources, scheduling, controllers and service discovery. | Use the smallest scope that meets placement and rollout needs. |
| Scaling/placement | A host runs configured containers; multi-host orchestration is a separate layer. | Scheduler places Pods according to resource and policy constraints. | Capacity and availability still depend on cluster and dependency design. |
| Health and rollout | Container process and configured health behavior; Compose lifecycle commands. | Deployments roll replicas; probes and readiness affect traffic/restarts. | Application health semantics must be designed in either environment. |
| Networking | Docker networks connect containers and provide names within network scope. | Services provide stable endpoints for selected Pods. | Neither removes application-level timeouts or network policy needs. |
| Persistent data | Volumes persist outside a container writable layer; lifecycle/backup remain separate. | PersistentVolume/Claim abstractions bind storage provisioned for the cluster. | Storage portability and backup need explicit verification. |
| Operational cost | A host and container lifecycle need operation. | A cluster adds control plane, scheduling, configuration and incident surfaces. | Choose Kubernetes when its controls offset the ownership cost. |
Docker builds and runs container images; Kubernetes reconciles desired workloads across a cluster. A Kubernetes workload still needs a container image, so the tools commonly form one delivery path.
An image packages filesystem layers, configuration defaults and a process entrypoint. A Kubernetes Deployment declares a desired number and version of Pods; controllers work to converge actual state toward that declaration. Kubernetes also coordinates scheduling, service discovery and rollout policy.
Building an image does not provide multi-node reconciliation, and Kubernetes does not make the image’s process, health checks or data safe by itself. Choose the smallest operating layer that meets the availability and deployment requirements.
source -> Dockerfile/BuildKit -> image registry -> Kubernetes Deployment -> PodsIllustrative packaging and deployment shape; it was not run on a cluster.
Illustrative, not executed.
Docker produces an artifact the cluster can run; Kubernetes manages where and how declared workloads run. Their responsibilities overlap in workflow but are not substitutes.
Read the source: Dockerfile overview · Kubernetes Deployments
Keep the Dockerfile explicit, pin base-image policy, separate dependency steps from frequently changed source, and build from a controlled context.
Dockerfile instructions create image layers. Cache reuse depends on earlier inputs remaining unchanged; copying every source file before dependency installation can invalidate expensive later steps on each edit. A smaller context also reduces accidental inclusion of credentials or local build artifacts.
A successful build does not prove the image is minimal, secure or reproducible. Record build inputs and scan/update base images through the project’s normal release process.
FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY src/ ./src/
CMD ["python", "-m", "src"]Illustrative packaging and deployment shape; it was not run on a cluster.
Illustrative, not executed.
A source-only edit can reuse the dependency layer when its inputs are unchanged. Verify the build context and cache behavior rather than assuming a cached build is correct.
Read the source: Dockerfile overview · Docker build cache
Run the application as the main foreground process, handle termination signals, stop accepting work and close resources within a bounded grace period.
The container runtime manages a process, not an abstract application. Entrypoint and shell wrappers affect which process receives signals. A child process that is not reaped or a server that ignores termination can stall shutdown and rollout.
Use a non-root application user where the image and runtime permit it, expose only required ports, and make health/readiness behavior reflect actual ability to serve. Avoid embedding credentials in image layers.
ENTRYPOINT ["/app/server"]
# Application handles SIGTERM, stops accepting work, drains, then exits.Illustrative packaging and deployment shape; it was not run on a cluster.
Illustrative, not executed.
SIGTERM delivery, in-flight request policy, resource closure, exit deadline and the behavior after the deadline expires.
Read the source: Running containers · Dockerfile overview
The writable container layer is replaceable. Use an explicit volume or external service for data that must outlive a container, and a defined network for service communication.
Docker volumes have their own lifecycle and are not automatically backups. Bind mounts couple a container to host paths and permissions; named volumes are managed by Docker. Containers on a user-defined network can resolve peer names through Docker’s network DNS.
In Kubernetes, a Service gives a stable network abstraction over matching Pods, while persistent volumes bind storage to declared claims and cluster support. Neither abstraction makes application data durable without the storage and backup behavior being tested.
services:
web:
image: example/web:tag
networks: [app]
db:
image: postgres:16
volumes: [db-data:/var/lib/postgresql/data]
networks: [app]Both services must join the same declared network. This excerpt additionally requires top-level networks: {app: {}} and volumes: {db-data: {}}, a real web image and the PostgreSQL image’s initialization/authentication configuration. It is not a complete runnable Compose file. The volume mounts database data independently of the container lifecycle.
Illustrative, not executed.
A portable production storage contract. Host paths, ownership and lifecycle differ across developer machines and schedulers.
Read the source: Docker volumes · Docker networking · Kubernetes Services · Kubernetes persistent volumes
A Deployment declares the desired ReplicaSet/Pod state; controllers continually work toward that state. It does not guarantee the application is healthy or that every rollout will succeed.
The controller compares desired and observed state and creates or removes replicas according to the Deployment strategy. A rollout can stall when a new Pod cannot schedule, image-pull fails, readiness never succeeds or the application exits. Inspect events and conditions to identify which boundary failed.
Updating a manifest changes intent. It is not a direct command to a specific host, and controller reconciliation can repeat. Application startup and migrations must tolerate restarts and overlap where the strategy permits it.
spec:
replicas: 3
selector:
matchLabels: {app: web}
template:
metadata:
labels: {app: web}
spec:
containers:
- name: web
image: registry.example/web:tagIllustrative packaging and deployment shape; it was not run on a cluster.
Illustrative, not executed.
Check Deployment conditions, Pod events, scheduling, image pull, probe results, resource pressure and application logs in that order.
Read the source: Kubernetes Deployments · Kubernetes scheduler
Readiness controls whether a Pod is considered ready for traffic; liveness can trigger restart after repeated failure; startup probes protect slow initialization. Requests guide scheduling and limits constrain runtime resources.
A liveness check that depends on a temporary downstream outage can restart every replica and worsen the incident. A readiness check should represent whether this instance can serve; startup probes can defer liveness until boot completes. Resource requests influence placement and limits can cause throttling or termination depending on resource.
Set probes and budgets from startup behavior and measured resource needs. A manifest value is a policy input, not evidence that the service has capacity.
startupProbe:
httpGet: {path: /startup, port: 8080}
failureThreshold: 30
periodSeconds: 10
readinessProbe:
httpGet: {path: /ready, port: 8080}
resources:
requests: {cpu: 100m, memory: 128Mi}The startup probe delays the other probes until startup succeeds. Readiness then controls whether the pod receives Service traffic. The requests shown inform scheduling; no resource limits or liveness probe are defined in this excerpt.
Illustrative, not executed.
An overly high limit can allow a workload to consume enough memory to put pressure on its node before reaching its own limit; scheduling also depends on requests and actual capacity. An overly low limit can instead lead to out-of-memory termination under normal load. Measure the working set and headroom, then test both application behavior and node-level contention.
Read the source: Kubernetes probes · Kubernetes resource management
A Service selects Pods and provides a stable network endpoint while backend Pod addresses change. Readiness and selector correctness determine which Pods receive traffic.
A Deployment rollout replaces Pods over time; a Service abstracts the selected backends. A selector mismatch can leave no endpoints, while a readiness failure can keep a Pod out of service. External traffic routing and security policies are separate configuration layers.
Check endpoint membership, readiness transitions and rollout availability. Do not confuse a Service with an application-level retry or transaction guarantee.
Deployment labels: app=web
Service selector: app=web
Service -> ready matching PodsIllustrative packaging and deployment shape; it was not run on a cluster.
Illustrative, not executed.
Compare selector labels with Pod labels, then check Pod readiness and namespace/port configuration.
Read the source: Kubernetes Services · Kubernetes Deployments · Kubernetes probes
Use a Docker image and a simple runner or Compose when one-host lifecycle, restart and networking needs are sufficient. Add Kubernetes only when cluster-level placement, rollout or availability requirements repay its operational cost.
A small tool with a web process and a local dependency may be easier to deploy as a Compose project. Still define persistent data, image updates, health and backup separately. Compose can also be part of larger environments; the recommendation is about this workload’s current operating needs, not a capability ceiling.
Reverse the choice when a single host becomes a verified availability/capacity constraint or teams need a shared scheduler and declarative rollout path.
Docker image -> Compose services -> host runner
Observe logs, restart policy, volume lifecycle and backup independently.Illustrative packaging and deployment shape; it was not run on a cluster.
Illustrative, not executed.
A concrete need for multi-node placement, rollout controls, service discovery or resource governance plus an operator team able to own the cluster.
Read the source: Docker Compose · Running containers · Docker volumes
Use Kubernetes when cluster-level desired state, service discovery and rollout controls solve a real operating need; build the image through the same Docker workflow and test graceful drain.
Define readiness, resource requests, replica availability, Pod disruption behavior, observability and rollback. A Deployment manages replicas, but external database migrations and client compatibility still need an expand-and-contract plan.
Do not infer high availability from replicas alone: node/zone placement, storage, dependency capacity and cluster control-plane availability matter. Reverse toward a managed platform or simpler runner if the cluster’s workload does not justify its maintenance.
Docker build -> registry push -> Deployment image update
-> new Pods pass startup/readiness -> Service routes -> old Pods drainIllustrative packaging and deployment shape; it was not run on a cluster.
Illustrative, not executed.
Promote the same reviewed artifact through environments, record its immutable digest, and define rollback to a known compatible version.
Read the source: Kubernetes Deployments · Kubernetes Services · Kubernetes probes · Kubernetes resource management
Keep the image boundary and external service contracts stable, then translate one service at a time into Kubernetes resources. Treat storage, secrets, networking and observability as explicit migrations.
Compose and Kubernetes configuration models are not identical. Automated conversion can create a starting point but does not decide probes, resource budgets, ingress, storage class, secret handling or rollout compatibility. Keep stateful dependencies managed according to their own recovery plan rather than copying a local volume assumption into a cluster.
Pilot one stateless service and its real traffic path. Roll back by routing to the old deployment while data contracts remain compatible; do not run two writers without an idempotent or reconciliation strategy.
same image digest
Compose service -> Kubernetes Deployment + Service + ConfigMap/Secret references
volume contract -> explicitly selected persistent storage or external serviceIllustrative packaging and deployment shape; it was not run on a cluster.
Illustrative, not executed.
Parity on health, routing, secrets, shutdown, resource behavior, logs/metrics and rollback, plus a tested plan for any persistent state.
Read the source: Docker Compose · Kubernetes Deployments · Kubernetes Services · Kubernetes ConfigMaps · Kubernetes persistent volumes · Kubernetes StatefulSets
Salary context
These are Hacker News job posts that mention these technologies, not employee earnings or a measure of what a skill adds to pay. The amounts summarize annualized advertised minimums in approximate USD. Groups can overlap and differ in roles, locations and dates.
133 posts · 133 usable advertised salary amounts
2024-06-04 to 2026-10-10
$130,000
Median advertised minimum, approximate USD/year
Middle 50%: $100,854–$150,000
Explore Docker salaries → Browse matching job posts →Approximate USD using ECB daily reference rates as of 2026-10-09. Original currencies and offer ranges remain on the source listings. These figures cover posts tagged Docker, rather than every job in the broader technology family.
151 posts · 151 usable advertised salary amounts
2024-06-05 to 2026-10-10
$140,000
Median advertised minimum, approximate USD/year
Middle 50%: $115,000–$160,000
Explore Kubernetes salaries → Browse matching job posts →Approximate USD using ECB daily reference rates as of 2026-10-09. Original currencies and offer ranges remain on the source listings. These figures cover posts tagged Kubernetes, rather than every job in the broader technology family.
The band runs from the 25th to 75th percentile; the vertical marker is the median. Both rows use approximate USD per year.
61 posts mention both technologies. That is 45.9% of Docker posts and 40.4% of Kubernetes posts. A post can belong to both groups. This overlap does not show that employers prefer one technology, and the two salary groups are not independent samples.