Docker vs Podman vs containerd 2026: Chọn Runtime Nào Cho Production?

Karify98 & Amy 🌸·
Cover Image for Docker vs Podman vs containerd 2026: Chọn Runtime Nào Cho Production?
#devops#docker#podman#containerd#kubernetes

Docker Không Còn Là Lựa Chọn Duy Nhất

Nếu bạn bắt đầu học container năm 2020, gần như mọi tutorial đều bắt đầu bằng docker run. Docker gần như đồng nghĩa với container. Nhưng đến 2026, bức tranh đã khác hẳn.

Theo CNCF 2026 Container Survey, 68% workload production đang chạy rootless — tăng từ 12% năm 2020. Và Docker không phải người dẫn đầu xu hướng này.

Có 3 runtime đáng cân nhắc: Docker, Podman, và containerd 2.0. Mỗi tool có thế mạnh riêng, và chọn sai có thể khiến bạn gặp rắc rối về security hoặc performance sau này.

Kiến Tạo: Docker, Podman, containerd Khác Nhau Thế Nào?

Trước khi so sánh, cần hiểu chúng khác nhau ở đâu.

Docker dùng kiến trúc client-server. Daemon dockerd chạy nền với quyền root, mọi lệnh CLI gửi request đến daemon này. Docker CE 29.x hiện tại vẫn giữ kiến trúc truyền thống, dù đã cải thiện nhiều về security.

Podman hoàn toàn daemonless. Mỗi container là child process của user gọi lệnh. Không có daemon trung tâm, không cần root. Podman 5.x chạy rootless mặc định.

containerd là container runtime thuần túy — không có CLI build image, không có compose. Nó sinh ra để làm runtime cho Kubernetes, không phải tool cho developer cá nhân.

Dùng phép so sánh quen thuộc: Docker như chiếc SUV đa dụng, Podman như xe điện an toàn, containerd như động cơ F1 — cực mạnh nhưng cần người biết dùng.

Security: Điểm Khác Biệt Lớn Nhất

Đây là lý do chính khiến nhiều team chuyển khỏi Docker.

Docker: Daemon Root Là Vấn Đề

Docker daemon (dockerd) chạy với quyền root. Nếu daemon bị compromise, attacker có toàn quyền trên host. Đây không phải lý thuyết — đã có nhiều CVE liên quan đến Docker daemon.

Docker đã cải thiện với rootless mode (từ Docker 20.10), nhưng nó là tùy chọn, không phải mặc định. Cấu hình rootless Docker cũng phức tạp hơn Podman.

Podman: Rootless Từ Gốc

Podman chạy rootless mặc định. Container nội bộ dùng UID 0 nhưng map sang unprivileged user trên host qua user namespace. Nếu container bị escape, attacker chỉ có quyền của user thường.

Điểm hay: Podman tích hợp sâu với systemd. Bạn có thể tạo systemd unit file cho container:

# Tạo container và generate systemd service
podman run -d --name my-nginx -p 8080:80 nginx:latest
podman generate systemd --name my-nginx > ~/.config/systemd/user/container-my-nginx.service

# Quản lý như service bình thường
systemctl --user enable container-my-nginx.service
systemctl --user start container-my-nginx.service

containerd: Minimal Attack Surface

containerd có attack surface nhỏ nhất vì nó chỉ là runtime. Không có build system, không có compose, không có REST API phức tạp. containerd 2.0 còn hardened hơn với sandbox API và improved plugin isolation.

Bảng So Sánh Nhanh

  • Docker daemon root: Attack surface lớn, single point of failure
  • Podman rootless: Daemonless, user namespace, an toàn nhất cho developer
  • containerd 2.0: Minimal surface, hardened architecture, ideal cho Kubernetes

Performance: containerd Dẫn Đầu

Về raw performance, containerd luôn dẫn đầu vì kiến trúc lightweight. Docker và Podman có overhead thêm từ layers abstraction.

Nhưng với hầu hết workload, sự khác biệt không đáng kể. Benchmark từ tech-insider.org cho thấy:

  • Build image: Docker và Podman gần như ngang nhau (Podman nhanh hơn ~5-8% với rootless)
  • Start container: containerd nhanh nhất (ít overhead), Docker và Podman tương đương
  • Network throughput: Docker rootful > Podman rootful > Podman rootless (slirp4netns có overhead)

Điểm quan trọng: Podman rootless dùng slirp4netns cho networking (user-mode networking stack), tạo ra overhead về latency. Với workload network-bound, đây là vấn đề. Podman Desktop v1.22 đã cho phép switch giữa rootless và rootful mode.

Kubernetes Compatibility: containerd Là Vua

Nếu bạn chạy Kubernetes, containerd là lựa chọn mặc định từ K8s 1.24 (dockershim bị loại bỏ). Kubernetes v1.36 vừa ra mắt (13/05/2026) với workload-aware scheduling cho AI/ML workloads, tiếp tục tối ưu cho containerd.

Docker vẫn hoạt động với Kubernetes qua cri-dockerd adapter, nhưng thêm một layer = thêm complexity và potential failure point.

Podman không trực tiếp làm Kubernetes runtime, nhưng podman generate kube rất hữu ích cho dev workflow — tạo Kubernetes YAML từ running container.

# Tạo K8s manifest từ container đang chạy
podman generate kube my-nginx > nginx-deployment.yaml

# Áp dụng lên cluster
kubectl apply -f nginx-deployment.yaml

Docker Compose vs Podman Compose

Nhiều team vẫn dùng Docker Compose cho local dev. Tin tốt: Podman đã hỗ trợ Docker Compose compatibility tốt hơn nhiều từ Podman 5.x.

# Podman chạy docker-compose trực tiếp
podman compose up -d

# Hoặc dùng podman-compose (Python-based)
pip install podman-compose
podman-compose up -d

Tuy nhiên, không phải mọi compose feature đều hoạt động mượt mà. Nếu stack của bạn dùng nhiều compose features phức tạp (depends_on với healthcheck, build context tricks), test kỹ trước khi chuyển đổi.

Khi Nào Chọn Gì?

Chọn Docker khi:

  • Team đã quen Docker, migration cost cao
  • Cần Docker Desktop (GUI trên macOS/Windows)
  • Stack phụ thuộc nhiều vào Docker Compose phức tạp
  • Không chạy production trên host (dùng cloud managed service)

Chọn Podman khi:

  • Security là ưu tiên (rootless mặc định)
  • Muốn daemonless architecture
  • Dev trên Linux, quen systemd
  • Cần Kubernetes YAML generation cho dev workflow

Chọn containerd khi:

  • Chạy Kubernetes production
  • Cần raw performance tối thiểu
  • Đã có platform team quản lý infrastructure
  • Dùng managed K8s (EKS, GKE, AKS) — runtime thường là containerd

Migration Tips: Docker Sang Podman

Nếu quyết định chuyển, đây là roadmap thực tế:

Bước 1: Cài Podman và alias docker

# Ubuntu/Debian
sudo apt install podman

# Alias docker → podman (thêm vào .zshrc/.bashrc)
alias docker=podman

Bước 2: Test compatibility

# Chạy lại docker-compose stack
podman compose up -d

# Kiểm tra networking
podman run --rm curlimages/curl curl http://localhost:8080

Bước 3: Fix edge cases

  • Rootless networking: dùng podman pod nếu cần container share network
  • Volume permissions: rootless container dùng user namespace, volume mount có thể cần adjust UID
  • Build context: podman build dùng Buildah backend, hầu hết Dockerfile hoạt động bình thường

Bước 4: Tạo systemd services cho production

podman generate systemd --new --name my-app --restart-policy=always

Kết Luận: Không Có "Best", Chỉ Có "Phù Hợp"

Docker vẫn là lựa chọn an toàn cho đa số team. Nhưng nếu bạn đang build production system trên Linux, Podman rootless đáng để thử. Nếu chạy Kubernetes, containerd đã là default — không cần nghĩ nhiều.

Quan trọng nhất: hiểu trade-offs. Docker daemon root không phải vấn đề nếu bạn tin tưởng host. Podman rootless không cần thiết nếu bạn chạy managed cloud. containerd quá minimal nếu bạn chỉ muốn docker compose up cho local dev.

Chọn tool phù hợp với context, không phải theo trend.

Tham khảo: