Kubernetes vs Docker

Key Takeaways

• Docker and Kubernetes solve different problems: Docker tooling builds and runs containers; Kubernetes orchestrates containerized workloads.
• Kubernetes doesn't require Docker Engine. Nodes that run Pods need a supported CRI-compatible runtime, such as containerd or CRI-O.
• A Pod is Kubernetes' smallest deployable unit and can contain multiple cooperating containers.
• Choose Kubernetes for its scheduling, desired-state management, and deployment controls—not simply because your application uses containers.

Kubernetes vs Docker isn't usually an either-or choice. Docker commonly handles building container images and running containers during development; Kubernetes manages deployed workloads through declarative configuration. You can build an image with Docker and run it on Kubernetes without installing Docker Engine on the cluster's nodes.

What is Docker?

Docker provides tools for packaging applications into container images and running containers from those images. An image is the packaged artifact; a container is a running instance of it. Our introduction to what Docker is covers that foundation.

The word “Docker” often bundles together three different things:

• Image-building tooling: Docker's build workflow uses BuildKit to turn application files and build instructions into images.
• Docker Engine: the container platform you use to create, run, and manage containers on a host.
• Docker Swarm: Docker Engine's clustering and orchestration mode—the component that actually overlaps with Kubernetes.

Keeping those names separate resolves much of the confusion in this comparison. Building an image, executing a container, and coordinating workloads across machines are different responsibilities.

For Linux containers, isolation relies on host-kernel features: namespaces separate views of system resources, while control groups account for and limit resource usage. Containers share a kernel rather than each booting a separate one, so don't assume they provide the same isolation as separate virtual machines. Security also depends on permissions, mounts, capabilities, and host hardening.

What is Kubernetes?

Kubernetes is an open-source platform for managing containerized workloads. Its central idea is desired state: you describe what should exist, and controllers repeatedly work to bring the actual system into line with that declaration. This ongoing correction is called reconciliation.

For example, a Deployment can declare that three application replicas should run. If a managed Pod disappears, the associated ReplicaSet works to create a replacement. That is different from issuing a one-time command to start three containers.

Kubernetes exposes specific mechanisms rather than handling every operational concern automatically:

• Deployments: manage replicated applications and controlled updates.
• Services: provide network access to changing sets of application instances.
• Jobs: manage tasks intended to run to completion.
• ConfigMaps: separate non-confidential configuration from application images.

These mechanisms are useful building blocks, not a complete application platform. Kubernetes doesn't build your application images or supply a complete monitoring, logging, and alerting stack. You choose and operate those integrations.

Basics of Docker and Kubernetes

A Kubernetes cluster has a control plane that manages cluster state and node components that execute workloads. The scheduler assigns Pods to suitable nodes; each node's agent, the kubelet, works with a container runtime to run their containers.

A Pod is Kubernetes' smallest deployable unit. It contains one or more tightly cooperating containers scheduled together on the same node, with shared networking and access to shared storage resources. A Pod isn't necessarily a single container, and it shouldn't become a bucket for unrelated services.

Source code -> Docker/BuildKit -> Image -> Registry
                                            |
                                            | image pull
                                            v
Control plane -> kubelet -> CRI -> Node runtime -> Containers in a Pod

The diagram separates the image's journey from Kubernetes' management path. The runtime pulls the image and executes containers; the control plane doesn't act as the application container runtime. A control-plane machine can also host node components, so these roles can coexist on one machine. Kubernetes can run as a one-node cluster—the defining difference is orchestration and reconciliation, not a minimum host count.

For the component-level picture, see our guides to what Kubernetes is and how Kubernetes works.

What is the Difference Between Kubernetes and Docker?

Kubernetes and Docker solve different problems. The useful comparison separates image creation, host-level execution, and orchestration:

Docker Engine and Kubernetes aren't equivalent deployment systems. Kubernetes vs Docker Swarm is the direct orchestration comparison.

Do you need Docker for Kubernetes?

No. Nodes that run Kubernetes Pods need a supported runtime implementing the Container Runtime Interface (CRI), the interface through which the kubelet requests container and image operations. CRI is an interface, not a runtime you install by itself. Check compatibility with your Kubernetes release, operating system, and distribution.

Kubernetes removed its built-in dockershim adapter in v1.24. Docker Engine doesn't implement CRI directly, so it isn't a Kubernetes node runtime by itself. Where Docker Engine is required, an external adapter such as cri-dockerd supplies that integration.

This change didn't invalidate Docker-built images. Supported runtimes such as containerd and CRI-O can run Docker-built images, including OCI-compatible images. OCI—the Open Container Initiative—defines standards for container images and execution. Image portability still requires a compatible operating system and CPU architecture. Registry access is needed when fetching or verifying images remotely; properly preloaded images can run without it using an appropriate imagePullPolicy of IfNotPresent or Never.

Kubernetes without Docker

The practical runtime choices have different roles:

• containerd: a general-purpose container runtime. Its CRI integration handles Kubernetes requests for images and container lifecycles.
• CRI-O: a runtime implementation designed specifically to provide Kubernetes' CRI integration with OCI-compatible container execution.
• Docker Engine with an adapter: an option when an environment needs Docker Engine, provided the adapter and runtime combination meets that environment's requirements.

Start with your cluster distribution's supported configuration and the Kubernetes container runtime documentation. For containerd, confirm that CRI support is enabled. Don't infer a universal performance advantage from the runtime's name; evaluate support, required features, configuration, and your own workloads.

A Concrete Desired-State Example

This example uses the public NGINX image to keep the focus on execution and orchestration. With Docker Engine available locally, run one container and publish its HTTP port on your machine's loopback address:

docker run --rm --publish 127.0.0.1:8080:80 nginx:stable

The --rm flag removes the container after it exits. Stop this local container before reusing port 8080 below.

For Kubernetes, save this as web.yaml. You need a test cluster with Linux nodes, access to the image registry, a configured kubectl client, and permission to create Deployments and Services.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: nginx:stable
          ports:
            - containerPort: 80
          readinessProbe:
            httpGet:
              path: /
              port: 80
---
apiVersion: v1
kind: Service
metadata:
  name: web
spec:
  type: ClusterIP
  selector:
    app: web
  ports:
    - port: 80
      targetPort: 80

The Deployment requests three replicas. Its selector matches the Pod template's labels, and the Service selects those same Pods. The readiness probe checks HTTP availability before a container is considered ready.

kubectl apply -f web.yaml
kubectl rollout status deployment/web
kubectl port-forward service/web 8080:80

These commands apply the resources, wait for the Deployment rollout, and forward local port 8080 to a Pod selected through the Service. Port forwarding is a development access path, not a production load balancer. Delete the demo resources when you're finished.

The ClusterIP Service provides an internal endpoint; it doesn't create an external load balancer. External exposure needs an appropriate implementation or provider integration. Your own Docker-built application follows the same deployment pattern once its image is published to a registry the nodes can access.

Which is Better? Kubernetes vs Docker Swarm

Docker Swarm remains available as Docker Engine's orchestration mode. It provides desired-state services, multi-host networking, service discovery, and rolling updates through Docker's tooling. Those capabilities aren't exclusive to Kubernetes.

Consider Swarm when its integrated Docker workflow matches your team's skills and your deployment requirements. Consider Kubernetes when you need its workload APIs, extension mechanisms, or integrations supported by your hosting environment. Kubernetes' monitoring and logging ecosystem is an integration choice—not a complete suite built into the cluster.

Neither “Swarm for small deployments” nor “Kubernetes for large deployments” is a sufficient decision rule. Evaluate availability requirements, storage and networking needs, existing operational expertise, hosting support, and the extensions you actually need.

When is Kubernetes Worth the Complexity?

For local development or a straightforward deployment where a single host is acceptable, start with a single-host container workflow. Docker Compose can define and run a multi-container application without requiring you to adopt a Kubernetes cluster.

Consider Kubernetes when several requirements justify a shared orchestration platform:

• Scheduling applications across nodes and replacing failed workload instances.
• Keeping deployments aligned with reviewed, declarative configuration.
• Providing service discovery and controlled application rollouts.
• Integrating multiple workloads with a consistent platform and operational tooling.

Scaling still needs configuration. A HorizontalPodAutoscaler needs a metrics source; resource metrics commonly come from Metrics Server. CPU-utilization-based scaling also depends on CPU requests being configured. Merely creating a Deployment doesn't enable demand-based autoscaling.

Budget for cluster upgrades, runtime maintenance, networking, access control, observability, and workload configuration. Managed Kubernetes can transfer some infrastructure responsibilities to a provider, but it doesn't remove application-level operational work.

Finally, replicas aren't an availability guarantee. Application design, spare capacity, failure-domain placement, storage behavior, and control-plane availability all matter. Three replicas on one failing machine don't solve a host-level outage.

FAQ

Do you need Docker to run Kubernetes?

No. Nodes that run Pods need a supported CRI-compatible container runtime, such as containerd or CRI-O. Docker Engine is optional and requires a CRI adapter if you use it as the node runtime.

Can Kubernetes run images built with Docker?

Yes. Supported Kubernetes runtimes can run Docker-built images without Docker Engine on the nodes. The image must be compatible with the execution platform's operating system and CPU architecture; registry access is needed when fetching or verifying images remotely, but properly preloaded images can run without it using an appropriate imagePullPolicy of IfNotPresent or Never.

What replaced dockershim in Kubernetes?

Kubernetes removed its built-in dockershim adapter in v1.24; it didn't replace it with one mandatory runtime. Nodes can use a supported CRI-compatible runtime, or integrate Docker Engine through an external adapter such as cri-dockerd.

What is the difference between Docker Engine and Docker Swarm?

Docker Engine runs and manages containers on a host. Swarm mode adds clustering and orchestration across Docker hosts, including desired-state services, service discovery, and rolling updates.

When is Kubernetes worth the operational complexity?

Consider Kubernetes when multi-node scheduling, declarative reconciliation, service discovery, rollout controls, and required integrations justify its operating cost. Containerization alone isn't a reason to adopt it; a single-host workflow may meet your requirements.

Further Reading

• Docker overview — images, containers, and Docker's architecture.
• Docker BuildKit — the image-building component.
• Kubernetes container runtimes — runtime requirements and integration configuration.
• Dockershim removal FAQ — Docker Engine integration and image compatibility.
• Kubernetes Deployments — replica management and application rollouts.
• Kubernetes Services — internal endpoints and external exposure options.
• Horizontal Pod Autoscaling — metrics, resource requests, and scaling configuration.
• Docker Swarm mode — Docker's integrated orchestration features.