Docker vs. Kubernetes: Mô hình tư duy 'Quản lý khách sạn'

TL;DR

Docker đóng gói ứng dụng cùng toàn bộ thư viện thành một container độc lập (phòng khách sạn tiêu chuẩn), giải quyết bài toán “chạy được trên máy tôi”. Kubernetes là hệ thống điều phối cụm server (ông quản lý khách sạn), tự động cấp phát tài nguyên, cân bằng tải, tự hồi phục khi container gặp sự cố, và scale hàng nghìn instance mà không cần can thiệp thủ công.

“Mình có cần dùng Kubernetes không?”

Đây là câu hỏi mình nhận được nhiều nhất từ các CTO startup. Họ đã chạy Docker ngon lành trên máy cá nhân. Họ nghĩ Kubernetes chỉ là “Docker phiên bản mạnh hơn” (Docker on steroids).

Hoàn toàn sai lầm.

So sánh Docker với Kubernetes giống như so sánh một Viên gạch với một Ông cai thầu xây dựng. Một cái là vật liệu; cái kia là một hệ thống phức tạp chuyên đi quát tháo khi có người đi trễ.

Đây là Hướng dẫn chuyên sâu về Hệ sinh thái Container. Chúng ta sẽ bắt đầu từ mô hình tư duy, các lệnh debug, và cái lỗi ám ảnh mang tên “CrashLoopBackOff”.

Phần 1: Nền tảng (Mô hình tư duy)

Kỷ nguyên Nguyên thủy: Ngôi nhà

Ngày xưa, chúng ta xây Nhà (Máy chủ vật lý).

Muốn nấu ăn, xây Bếp.
Muốn ngủ, xây Phòng ngủ.
Vấn đề: Nếu Bếp cháy, Phòng ngủ cũng cháy theo. (App A làm sập App B).

Kỷ nguyên VM: Chung cư

Sau đó có Máy ảo (Virtual Machine). Trên một miếng đất to (Server), ta xây nhiều căn hộ khép kín.

Mỗi căn hộ có điện nước, tường bao riêng nhờ Hypervisor.
Vấn đề: Nặng nề. Căn nào cũng phải tự lo nồi niêu xoong chảo riêng. (Khởi động cả hệ điều hành mất cả phút).

Kỷ nguyên Docker: Phòng khách sạn (Container)

Docker nhận ra ta không cần cả một căn hộ. Ta chỉ cần một Căn phòng.

Container: Phòng tiêu chuẩn. Nội thất giống hệt nhau (Dependencies).
Dùng chung: Các phòng dùng chung điện nước của tòa nhà (Host OS Kernel).
Lợi ích: Bạn có thể “hô biến” ra 1,000 căn phòng trong vài giây.

Kỷ nguyên Kubernetes: Ông Quản lý khách sạn

Giờ bạn có 1,000 căn phòng. Ai dọn dẹp? Ai xếp phòng cho khách? Toilet hỏng thì ai sửa?

Kubernetes (K8s) chính là Ông Quản lý.

Bạn: “Tôi cần 3 phòng View Biển (Front-end) và 2 phòng có Két sắt (Database).”
Quản lý (K8s): “Xong.”
Thực tế: Một phòng bị ngập nước.
Quản lý (K8s): “Tôi thấy phòng 203 bị ‘tèo’ rồi. Tôi vừa tạo ngay một phòng y hệt, phòng 405. Khách còn chưa kịp nhận ra.”

Docker chạy cái app. Kubernetes chạy cái Docker.

Markdy animation

Phần 2: Điều tra (Debug như chuyên gia)

1. Soi Container (Docker thuần)

Khi container dở chứng trên máy local:

# "Sao mày chết?"
docker logs my-app

# "Mày thực chất là cái gì?"
docker inspect my-app | grep "IPAddress"

2. Soi Pod (Kubernetes)

Khi một Pod (cái vỏ bọc của K8s cho container) bị chết:

# "Alo Quản lý, chuyện gì xảy ra với phòng này?"
kubectl describe pod my-app-xyz

# "Cho tôi đọc nhật ký của khách trong phòng"
kubectl logs my-app-xyz --previous

Lệnh “Describe” là bạn thân nhất của bạn. Nó nói cho bạn biết chính xác tại sao Ông Quản lý lại giết cái phòng đó (ví dụ “OOMKilled” - do khách ăn tốn RAM quá).

Phần 3: Chẩn đoán (Giải mã Error Codes)

Lỗi của Kubernetes thường khá khó hiểu. Đây là từ điển giải mã.

Trạng thái	Ý nghĩa	Ông Quản lý nói…	Cách sửa
Pending	Hết phòng.	“Khách sạn full rồi. Không còn server nào đủ RAM cho anh cả.”	Mua thêm server (node) hoặc giảm resource request.
CrashLoopBackOff	Chết đi sống lại.	“Cứ mở cửa phòng là nó nổ tung. Tôi tạm thời không mở nữa.”	Check code (`kubectl logs`). Thường do lỗi config hoặc không kết nối được DB.
OOMKilled	Hết bộ nhớ (Out of Memory).	“Thằng khách này ăn hết cả cái buffet. Tôi đuổi nó rồi.”	Tăng `resources.limits.memory` lên.
ImagePullBackOff	Không tìm thấy Image.	“Anh đòi nội thất kiểu ‘V2’, nhưng trong kho không có.”	Kiểm tra tên image/tag hoặc quyền truy cập registry.

Phần 4: Giải pháp (Yamls & Dockerfiles)

1. Bản thiết kế (Dockerfile)

Giữ cho nó nhẹ thôi. Đừng mang cả đội thợ xây vào nếu bạn chỉ cần cái búa.

# Dở: Cài nguyên cái OS ubuntu nặng trịch
FROM ubuntu:latest

# Tốt: Chỉ cài môi trường Python tối giản
FROM python:3.9-slim

WORKDIR /app
COPY . .
RUN pip install -r requirements.txt
CMD ["python", "app.py"]

2. Sổ tay hướng dẫn (K8s Deployment)

Ra lệnh cho Ông Quản lý. Ông ấy sẽ tự lo phần còn lại.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3                    # "Tôi muốn 3 phòng y hệt nhau"
  template:
    spec:
      containers:
      - name: my-app
        image: my-app:v1
        resources:
          limits:
            memory: "128Mi"      # "Đừng để nó ăn quá 128Mb RAM"

Lời khuyên cuối (Final Take)

Khía cạnh kiến trúc	Docker thuần (Single Host / Compose)	Kubernetes Cluster (Orchestration)
Mục đích cốt lõi	Đóng gói và chạy container đơn lẻ	Quản lý, điều phối hàng trăm server và container
Độ phức tạp vận hành	Rất thấp (cài Docker Desktop là chạy)	Rất cao (yêu cầu hiểu Control Plane, etcd, CNI, Ingress)
Khả năng tự phục hồi	Cơ bản (`restart: always` trên 1 server)	Tự động lập lịch lại pod sang node khác khi phần cứng chết
Tự động mở rộng (Auto-scaling)	Không hỗ trợ mặc định	Hỗ trợ HPA (Horizontal Pod Autoscaler) theo CPU/RAM/Custom Metrics
Chi phí hạ tầng	1 VPS nhỏ ($5 - $20 / tháng)	Tối thiểu 3 nodes production ($100+ / tháng)

Docker là viên gạch, Kubernetes là tổng thầu xây dựng.
Nếu bạn có dưới 3 server và lượng truy cập ổn định, hãy dùng Docker Compose và dành thời gian cải thiện tính năng cho sản phẩm.
Chỉ bước sang Kubernetes khi bạn thực sự cần tự động mở rộng theo tải, triển khai zero-downtime rolling update liên tục, và có kỹ sư chuyên trách vận hành hạ tầng.

Thử thách thực hành (Student First Assignment)

Tự tay mô phỏng vòng đời tự phục hồi của Container trong 10 phút:

Tạo một container Nginx bằng Docker: docker run -d --name test-nginx -p 8080:80 --restart=always nginx:alpine.
Kiểm tra trạng thái đang chạy bằng docker ps, sau đó mở trình duyệt truy cập http://localhost:8080.
Giả lập sự cố bằng lệnh giết tiến trình: docker kill test-nginx.
Chờ 3 giây và chạy lại docker ps để tận mắt chứng kiến cờ --restart=always tự động hồi sinh container với thời gian uptime mới.