VPS chạy Docker đã ổn, vì sao chúng ta vẫn nghĩ đến Kubernet

Serial S05 · S05E01

Chúng ta chưa cài thêm thứ gì vào máy chủ. Việc đầu tiên là ngăn một quyết định hấp dẫn biến thành một cuộc di chuyển không có đường lui.

Đây là tập mở đầu của dự án.

Trả lời ngắn: khi nào nên dùng Kubernetes

Kết quả của chặng này không phải là một cluster mới, mà là một quyết định có thể giải thích được bằng dữ liệu. Trong phạm vi bài này, chúng ta chỉ thay đổi phần liên quan đến inventory mục tiêu và giới hạn của dự án; mọi thành phần khác được giữ nguyên để dễ rollback.

Góc thực chiến của tập này: Dùng cùng một ứng dụng web nhỏ làm sợi chỉ đỏ: web stateless, database, upload và worker. So sánh Compose với K3s bằng tiêu chí rollout, self-healing, secret, storage và chi phí; không biến Kubernetes thành mặc định đúng cho mọi workload.

Điểm xuất phát và giả định

Case study dùng một VPS Ubuntu và workload Docker Compose đã chạy ổn định. Các lệnh bên dưới là khung kiểm tra cho lab; hãy thay <placeholder>, pin phiên bản sau khi đọc tài liệu hiện hành và chụp lại output trước khi áp dụng. Ubuntu VPS; Docker Compose baseline; K3s version phải pin và kiểm tra lại tại thời điểm triển khai.

Giả định cần kiểm chứng: Dùng cùng một ứng dụng web nhỏ làm sợi chỉ đỏ: web stateless, database, upload và worker. So sánh Compose với K3s bằng tiêu chí rollout, self-healing, secret, storage và chi phí; không biến Kubernetes thành mặc định đúng cho mọi workload.

Chúng ta thực hiện theo thứ tự nào?

Chụp lại trạng thái hiện tại trước khi thay đổi.
Tách mục tiêu học Kubernetes khỏi yêu cầu vận hành website.
Đặt giới hạn CPU, RAM, disk, downtime và thời gian rollback.

Khung lệnh kiểm tra

docker compose config
docker compose ps
docker system df
free -h
df -h
ip -br addr
ss -lntup

Không nên dán cả khối lệnh mà không đọc output. Bất kỳ lệnh nào có thể thay đổi cluster nên chạy dry-run, review manifest hoặc thực hiện trong cửa sổ thay đổi đã ghi trước.

Đọc kết quả thay vì chỉ nhìn trạng thái xanh

Lưu output vào một file baseline có timestamp; không dùng cảm giác “máy đang ổn” làm tiêu chí duy nhất.

Artefact của tập này là Lệnh kiểm tra, file cấu hình, YAML, checklist, log hoặc runbook tương ứng với tập.. Hãy lưu nó trong repository hoặc thư mục runbook kèm timestamp, phiên bản và người thực hiện. Đây là phần giúp tập sau có dữ liệu thật để kế thừa.

Trade-off và lỗi dễ gặp

Sai lầm phổ biến là cài K3s trước rồi mới tìm cách đặt domain, firewall và backup. Trong serial này, DNS, dữ liệu và đường quay lui được chốt trước.

Nếu Compose đã đáp ứng quy mô và đội ngũ chưa có nhu cầu scheduling, self-healing hay chuẩn hóa deployment, giữ nguyên Compose cũng là kết luận hợp lệ.

Checklist sau khi hoàn tất

Đã ghi lại trạng thái trước và sau thay đổi.
Đã biết lệnh kiểm tra và log cần đọc khi lỗi.
Đã xác định đường rollback hoặc giới hạn blast radius.
Đã cập nhật artefact của serial, không chỉ sửa thủ công trên máy.

Trạng thái dự án sau tập này

Dự án case study liên tục: VPS Ubuntu + Docker Compose tiến dần tới K3s production nhỏ; tập này kế thừa trạng thái từ tập trước. Kết quả cần chốt trong nhật ký là: inventory mục tiêu và giới hạn của dự án đã được xử lý đến mức nào, điều gì còn chưa kiểm chứng và ai có thể lặp lại thao tác.

Vấn đề còn mở cho tập sau

Nếu các kiểm tra đạt, ở tập sau chúng ta sẽ chuyển sang Chốt bài toán: hệ thống nào được đưa vào K3s và hệ thống nào ở lại?.