<aside> 💡

Kubernetes deprecated Docker as a container runtime in version 1.20 (2020) and removed it in 1.24 (2022). Instead, it now uses Containerd or CRI-O.

✅ The reason: Kubernetes uses the Container Runtime Interface (CRI) to communicate with container runtimes.

🚨 Problem with Docker: Docker does not natively support CRI, so Kubernetes had to use an extra layer called dockershim, which was inefficient.

🔹 What Changed?

<aside> 💡

Docker itself relies on containerd internally for container execution. So, when Kubernetes removed support for Docker as a container runtime, it wasn't really removing containerd—it was just removing the extra Docker layer (dockershim) that Kubernetes had to use to communicate with it.

</aside>

Even though AKS no longer directly supports Docker as a runtime, Dockerfiles are still widely used for containerized applications. Here’s why:

1. Dockerfile is Just a Standard for Building Images (OCI-Compatible)

Example:

Your Dockerfile might look like this:

FROM node:18
WORKDIR /app
COPY . .
RUN npm install
CMD ["node", "server.js"]

After building it with docker build -t myapp:latest ., the image can be pushed to Azure Container Registry (ACR) or another registry, then deployed to AKS.


2. Kubernetes & AKS Still Use OCI Images (Which Docker Creates)

Kubernetes (and AKS) do not care how an image was built, only that it conforms to OCI standards.


3. Docker is Still the Most Popular Tool for Building Images