Tìm kiếm Docker vs Kubernetes gợi ý bạn phải chọn một, nhưng việc đóng khung đó gây ra nhiều nhầm lẫn. It is a little like comparing a shipping container with the port that organizes thousands of them. Chúng hoạt động ở các cấp độ khác nhau và thường được sử dụng cạnh nhau.

Hướng dẫn này giải thích chức năng của từng ứng dụng, hiển thị cùng một ứng dụng nhỏ trong cả hai và kết thúc bằng cách đưa ra quyết định thực tế. Các lệnh và tệp ở đây là các ví dụ tiêu chuẩn mà chúng tôi không thực thi cho bài viết này, vì vậy hãy kiểm tra chúng với các phiên bản bạn cài đặt.

Câu trả lời ngắn gọn

Docker là một nền tảng để đóng gói một ứng dụng và các phần phụ thuộc của nó vào một hình ảnh, sau đó chạy hình ảnh đó dưới dạng vùng chứa. Nó trả lời câu hỏi “làm cách nào để ứng dụng này chạy giống nhau ở mọi nơi?”

Kubernetes, thường được viết là K8, là một trình điều phối vùng chứa. Nó quyết định nơi các container chạy trên nhiều máy, khởi động lại chúng khi chúng bị lỗi và mở rộng quy mô theo nhu cầu. Nó trả lời câu hỏi “làm cách nào để giữ cho hàng trăm container hoạt động ổn định?”

Docker vs Kubernetes cạnh nhau

Docker làm gì

Trước khi có container, “nó hoạt động trên máy của tôi” là một vấn đề hàng ngày, bởi vì mỗi máy chủ đều có các phiên bản khác nhau của mọi thứ. Docker gói mã, thời gian chạy và thư viện của bạn thành một hình ảnh. Bản sao đang chạy của hình ảnh đó là một container và nó chia sẻ kernel của máy chủ, do đó nó khởi động nhanh hơn và sử dụng ít bộ nhớ hơn so với một máy ảo đầy đủ.

Quy trình làm việc có ba bước:

1. Xây dựng: a Dockerfile mô tả cách tạo hình ảnh.
2. Gửi: Đẩy hình ảnh vào sổ đăng ký, chẳng hạn như Docker Hub.
3. Chạy: khởi động vùng chứa từ hình ảnh đó trên bất kỳ máy tương thích nào.

Để thực hành, hãy bắt đầu với Hướng dẫn về Docker dành cho người mới bắt đầu của chúng tôi, sau đó đọc các phương pháp hay nhất về Dockerfile của chúng tôi.

Kubernetes làm gì

Docker trên một máy chủ hoạt động tốt cho đến khi máy chủ đó bị lỗi, lưu lượng truy cập tăng nhanh hoặc bạn có hàng tá dịch vụ cần phối hợp. Kubernetes đảm nhiệm các công việc vận hành sau:

• Lên kế hoạch: đặt các thùng chứa trên các máy có đủ dung lượng trống.
• Tự phục hồi: thay thế các vùng chứa bị lỗi và di chuyển công việc ra khỏi các nút bị lỗi.
• Chia tỷ lệ: thêm hoặc xóa bản sao theo cách thủ công hoặc dựa trên số liệu.
• Khám phá dịch vụ: đặt tên ổn định cho một nhóm vùng chứa đang thay đổi.
• Cập nhật luân phiên: phát hành dần dần các phiên bản mới với thao tác khôi phục đơn giản.
• Cấu hình: quản lý cài đặt và bí mật riêng biệt với hình ảnh.

Ý tưởng cốt lõi là trạng thái mong muốn. Bạn tuyên bố rằng ba bản sao sẽ tồn tại và người kiểm soát tiếp tục so sánh điều đó với thực tế và sửa bất kỳ sự khác biệt nào. Hướng dẫn Kubernetes dành cho người mới bắt đầu của chúng tôi sẽ hướng dẫn vấn đề này trên một cụm cục bộ.

Cách Docker và Kubernetes phối hợp với nhau

Lộ trình điển hình từ máy tính xách tay của nhà phát triển đến sản xuất trông như thế này:

1. Nhà phát triển viết Dockerfile và kiểm tra vùng chứa cục bộ.
2. Quy trình CI/CD xây dựng hình ảnh và chạy thử nghiệm.
3. Đường ống đẩy hình ảnh được phiên bản vào sổ đăng ký.
4. Tệp kê khai Kubernetes được cập nhật để sử dụng phiên bản hình ảnh đó.
5. Kubernetes kéo hình ảnh và cuộn nó ra khắp cụm.

Vì vậy công việc của Docker phần lớn đã hoàn thành trước khi Kubernetes bắt đầu. Hình ảnh là điểm chuyển giao giữa chúng.

Một ứng dụng, cả hai cách

Đây là một dịch vụ web nhỏ. Hình ảnh được xây dựng giống như cách bất kỳ công cụ nào chạy nó:

# Dockerfile
FROM python:3.13-slim
WORKDIR /app
COPY . .
RUN pip install -r requirements.txt
CMD ["python", "app.py"]

Chạy nó với Docker

docker build -t shop-api:1.0 .
docker run -d --name shop -p 8080:8000 --restart unless-stopped shop-api:1.0

Hai lệnh và nó đang chạy. Điều này đơn giản và phù hợp cho nhiều dự án nhỏ. Nhưng chỉ có một bản sao trên một máy và nếu máy chết, dịch vụ sẽ đi kèm với nó.

Chạy nó với Kubernetes

# shop.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: shop
spec:
  replicas: 3
  selector:
    matchLabels:
      app: shop
  template:
    metadata:
      labels:
        app: shop
    spec:
      containers:
        - name: api
          image: registry.example.com/shop-api:1.0
          ports:
            - containerPort: 8000
---
apiVersion: v1
kind: Service
metadata:
  name: shop
spec:
  selector:
    app: shop
  ports:
    - port: 80
      targetPort: 8000

kubectl apply -f shop.yaml
kubectl get pods -l app=shop

Còn nhiều thứ để viết và bạn cần một cụm để chạy nó. Đổi lại, bạn nhận được ba bản sao, một địa chỉ nội bộ ổn định và tự động thay thế. Sự đánh đổi đó là toàn bộ quyết định thu nhỏ: phức tạp hơn để đổi lấy khả năng phục hồi tốt hơn.

Điều gì xảy ra khi một container bị hỏng?

Sự nhầm lẫn dockershim

Bạn có thể đã đọc “Kubernetes bỏ Docker”. Điều này đúng theo nghĩa hẹp và nó khiến nhiều người sợ hãi một cách không cần thiết. Kubernetes chạy các container thông qua một tiêu chuẩn gọi là Giao diện thời gian chạy container. Docker Engine không triển khai nó trực tiếp nên Kubernetes đã bao gồm một bộ chuyển đổi có tên dockershim. Bộ điều hợp đó đã bị xóa trong phiên bản 1.24.

Các cụm hiện nay thường sử dụng thời gian chạy như containerd hoặc CRI-O. Hình ảnh bạn xây dựng bằng Docker vẫn hoạt động vì chúng tuân theo tiêu chuẩn hình ảnh Sáng kiến ​​vùng chứa mở (OCI). Vì vậy, bạn có thể tiếp tục xây dựng bằng Docker và cụm của bạn sẽ chạy kết quả với thời gian chạy khác.

Docker Compose vs Swarm vs Kubernetes

Sự so sánh có ý nghĩa hơn là giữa các công cụ điều phối các thùng chứa:

Docker Compose khởi động một số vùng chứa liên quan từ một tệp và nó rất tuyệt vời cho một ứng dụng web cộng với cơ sở dữ liệu trên máy tính xách tay. Swarm được tích hợp vào Docker và dễ học hơn nhiều so với Kubernetes, nhưng nó có hệ sinh thái nhỏ hơn nhiều. Kubernetes có cộng đồng và công cụ lớn nhất, đó là lý do quan trọng khiến nó trở thành mặc định cho các triển khai lớn.

Bạn cần cái nào?

Chỉ riêng Docker thường là đủ khi:

• Bạn đang phát triển cục bộ hoặc chạy một ứng dụng nhỏ trên một máy chủ.
• Bạn có một nhóm nhỏ và không có nhân viên vận hành chuyên dụng.
• Thời gian ngừng hoạt động ngắn thường xuyên có thể chấp nhận được.

Kubernetes bắt đầu có ý nghĩa khi:

• Bạn chạy nhiều dịch vụ mà các nhóm khác nhau tự triển khai.
• Bạn cần tính sẵn sàng cao trên nhiều máy hoặc vùng.
• Lưu lượng truy cập thay đổi đủ để tự động chia tỷ lệ giúp tiết kiệm tiền thật.
• Bạn có kỹ năng hoặc ngân sách để vận hành nó.

Ngoài ra còn có một nền tảng trung gian. Các nền tảng bộ chứa được quản lý, chẳng hạn như AWS Fargate, Google Cloud Run hoặc PaaS, chạy hình ảnh Docker của bạn mà không cần duy trì cụm. Đối với nhiều công ty đang phát triển, đó là bước tiếp theo đúng đắn thay vì nhảy thẳng vào Kubernetes.

Nếu bạn muốn học cả hai vì lý do nghề nghiệp, thì thứ tự rất rõ ràng: Docker trước, sau đó là Kubernetes. Bạn không thể gỡ lỗi Pod một cách thoải mái nếu không hiểu rõ về hình ảnh, cổng và nhật ký vùng chứa.

Những lỗi thường gặp

• Việc áp dụng Kubernetes quá sớm. Việc sao chép kiến ​​trúc của một công ty khổng lồ có thể chôn vùi công việc vận hành của một nhóm nhỏ.
• Sử dụng thẻ latest trong sản xuất. Bạn không thể biết cái gì đang chạy hoặc quay lui một cách đáng tin cậy. Sử dụng thẻ phiên bản cụ thể.
• Lưu trữ dữ liệu bên trong vùng chứa. Vùng chứa chỉ dùng một lần nên hãy sử dụng khối lượng hoặc cơ sở dữ liệu được quản lý.
• Bỏ qua kiểm tra tình trạng. Nếu không có thăm dò mức độ sẵn sàng và hoạt động, Kubernetes không thể đưa ra quyết định đúng đắn về ứng dụng của bạn.
• Quên giới hạn tài nguyên. Một vùng chứa tham lam có thể bỏ đói mọi thứ khác trên một nút.

Lời kết

Docker đóng gói phần mềm của bạn và Kubernetes chạy phần mềm đó trên quy mô lớn. Thay vì hỏi cái nào tốt hơn, hãy hỏi hôm nay bạn gặp vấn đề gì. Nếu đó là “ứng dụng của tôi khó cài đặt”, hãy sử dụng Docker. Nếu đó là “40 dịch vụ của tôi cần để tồn tại khi máy chủ gặp sự cố”, hãy xem Kubernetes. Bắt đầu với công cụ đơn giản nhất có thể giải quyết vấn đề thực tế của bạn và tiến lên khi bạn thấy cần thiết.

Câu hỏi thường gặp

Tiếp tục học hỏi