Một Docker image chạy được trên laptop không có nghĩa là nó sẵn sàng cho production. Series 6 phần này đi từ câu hỏi đó đến một lab thật — MQTT broker chạy trên Kubernetes, release tự động qua GitLab CI/CD — để trả lời: điều gì thực sự xảy ra giữa một dòng code và một hệ thống đang chạy ổn định, tự scale và tự phục hồi.

Vì sao series này tồn tại

Container giải quyết bài toán đóng gói: đóng gói ứng dụng cùng dependency, chạy nhất quán giữa các môi trường. Nhưng "chạy được" và "vận hành được" là hai chuyện khác nhau. Khi một Docker image được đẩy lên production, còn rất nhiều câu hỏi mà bản thân image không trả lời được:

• Ai chạy test trước khi release?
• Image nào tương ứng với commit nào?
• Nếu một Pod chết, ai tạo lại?
• Khi nào cần scale, và scale dựa trên cái gì?
• Rollback mất bao lâu, và có mất dữ liệu không?

CI/CD trả lời nhóm câu hỏi đầu — đưa một thay đổi đi một cách có kiểm soát. Kubernetes trả lời nhóm câu hỏi sau — giữ hệ thống ở trạng thái mong muốn, bất kể điều gì xảy ra bên dưới. Hai công cụ này thường được học riêng lẻ, nhưng trong thực tế chúng là hai nửa của cùng một vòng đời: một chuỗi duy nhất từ commit đến workload đang phục vụ traffic thật.

Series này dựng một lab cụ thể để không phải nói suông: một MQTT broker cho hệ thống IoT, release qua GitLab CI, chạy trên Kubernetes, autoscale theo số kết nối thật, và có thể tự phục hồi khi một Pod biến mất. Sáu bài viết được chia thành ba cặp, đi từ khái niệm đến thực hành.

Phần 1-2: CI/CD overview — hiểu pipeline trước khi tin nó

Phần 1/2: Vấn đề, khái niệm và các khối tạo nên pipeline

Docker image chạy được, nhưng ai dám chắc đó là bản đã test? Bài mở đầu đi từ vấn đề thực tế đến các khái niệm nền tảng: phân biệt Continuous Integration, Continuous Delivery và Continuous Deployment — ba thuật ngữ hay bị dùng lẫn lộn — rồi tháo rời một pipeline thành các khối cấu thành: stage, job, runner, artifact, container registry, environment.

Phần 2/2: Từ pipeline MQTT broker đến release process hoàn chỉnh

Lý thuyết đã có, giờ đọc một pipeline thật. Bài này theo một dòng code từ commit đến production qua pipeline MQTT broker trong lab, cho thấy image bất biến, quyền tối thiểu và khả năng rollback không phải là việc làm thêm sau cùng — mà là một phần thiết kế của release process. Kết thúc bằng các chiến lược deploy (rolling, blue-green, canary) và cách đo lường hiệu quả CI/CD bằng những con số cụ thể, không phải cảm tính.

Phần 3-4: Kubernetes overview — bên trong cỗ máy tự điều phối

Phần 1/2: Object model, kiến trúc cluster và workload resource

Kubernetes không "tự động" theo cách nhiều người tưởng tượng — nó chỉ liên tục so sánh trạng thái mong muốn với trạng thái thực tế, rồi sửa sai. Bài này mở bản đồ bên trong một cluster: API Server, etcd, Scheduler, kubelet đóng vai trò gì; và khi nào nên dùng Pod, Deployment, StatefulSet, DaemonSet hay Job — mỗi loại giải quyết một bài toán vòng đời khác nhau.

Phần 2/2: Networking, self-healing, rollout và autoscaling

Xoá một Pod và nó tự sống lại ở chỗ khác — phép màu hay cơ chế? Bài này giải mã self-healing bằng chính định nghĩa của nó: một controller phát hiện chênh lệch và sửa nó, không hơn không kém. Đi kèm là cách traffic thật tìm đường tới Pod qua Service, rolling update/rollback hoạt động ra sao dưới một dòng lệnh kubectl, và các lớp autoscaling (HPA, VPA, Node autoscaler) khác nhau ở điểm nào. Một bộ lệnh kubectl chỉ đọc được đính kèm để bất kỳ ai cũng có thể tự quan sát cluster một cách an toàn.

Phần 5-6: Thực hành — đẩy lý thuyết đến giới hạn thật

Phần 1/2: Release, fixed capacity và overload

Tới lúc bắt tay vào làm. Bài thực hành đầu tiên release một phiên bản MQTT broker bằng semantic Git tag thật, theo dõi pipeline test → package → deploy chạy trên GitLab CI, rồi đẩy hệ thống tới giới hạn: so sánh fixed capacity 300 kết nối ổn định với một kịch bản overload ở 240 — để thấy rõ ranh giới giữa "chạy được" và "chạy đúng cách".

Phần 2/2: Autoscaling, self-healing và rollback

800 connections cùng lúc dội vào 3 Pod ban đầu — chuyện gì xảy ra? Bài cuối cùng quan sát trực tiếp HPA scale từ 3 lên tối đa 10 Pod dưới tải thật, mô phỏng một Pod đột ngột biến mất để xem controller phản ứng ra sao, và rollback một bản release có vấn đề về baseline đã biết trước. Mỗi bước được đọc như một thí nghiệm: có giả thuyết, có biến điều khiển, có tiêu chí đạt rõ ràng — không phải "thử xem sao".

Đọc theo thứ tự nào?

Series được thiết kế để đọc tuần tự từ Phần 1 đến Phần 6, vì mỗi bài thực hành đều dựa trên khái niệm đã giới thiệu ở hai cặp bài trước. Tuy nhiên, nếu đã quen CI/CD hoặc Kubernetes, có thể bắt đầu thẳng từ cặp bài còn thiếu:

• Đã quen CI/CD → bắt đầu từ Kubernetes overview (Phần 1/2).
• Đã quen Kubernetes → bắt đầu từ CI/CD overview (Phần 1/2).
• Đã quen cả hai, chỉ muốn xem lab → bắt đầu từ Thực hành (Phần 1/2).

Đón đọc 6 phần của series ngay sau đây 👇