Docker Kubernetes cho doanh nghiệp: khi nào là thừa

Đội kỹ thuật gửi bạn một tờ đề xuất: chuyển hệ thống sang Kubernetes, ngân sách hạ tầng tăng từ 4 triệu lên 20 triệu một tháng, chưa kể tuyển thêm một kỹ sư DevOps. Bạn là người ký. Bạn không biết Kubernetes là gì, nhưng bạn biết con số đó gấp năm lần con số cũ và bạn không thấy khách hàng nào của mình được lợi thêm.

Câu hỏi thật ở đây không phải "Kubernetes có tốt không". Nó tốt. Câu hỏi là hệ thống của bạn đã đủ lớn để cái tốt đó quy đổi ra tiền chưa. Đây là chỗ mà tư vấn về Docker Kubernetes cho doanh nghiệp hay bị lệch: người trình bày là người sẽ vận hành nó, còn người trả tiền lại không đủ vốn từ để hỏi lại. Kết quả là ngân sách được duyệt bằng niềm tin.

Dưới đây là cách chúng tôi tách hai thứ đó ra khi tư vấn hạ tầng: Docker giải bài toán gì, Kubernetes giải bài toán gì, và ngưỡng quy mô nào thì mỗi thứ bắt đầu có lãi. Không có phần nào yêu cầu bạn biết code.

Container là gì, giải thích bằng thùng hàng

Trước khi có container tiêu chuẩn, hàng hóa xuống cảng được bốc dỡ thủ công, mỗi loại hàng một kiểu, mỗi cảng một quy trình. Container 40 feet ra đời không làm hàng hóa tốt hơn. Nó chỉ làm cho mọi cần cẩu, mọi tàu, mọi xe đầu kéo đối xử với mọi loại hàng theo đúng một cách.

Container phần mềm y hệt. Phần mềm của bạn cần một hệ điều hành nhất định, một phiên bản PHP hoặc Node nhất định, vài thư viện, vài file cấu hình. Đóng gói cả cụm đó thành một thùng hàng chạy được ở bất kỳ đâu — đó là container. Máy chủ chỉ cần biết nâng thùng lên và đặt xuống, không cần biết bên trong có gì.

Từ đó ra hai vai trò rất khác nhau, và đây là chỗ nhiều người nhầm:

• Docker là công cụ đóng thùng và chạy thùng. Nó lo phần "làm ra container".
• Kubernetes (viết tắt K8s) là hệ thống điều phối cả cảng: quyết định thùng nào đặt lên tàu nào, thùng hỏng thì thay, cao điểm thì tự thêm thùng. Nó lo phần "quản lý hàng trăm container".

Một cái là hộp. Cái kia là ban điều hành cảng. Doanh nghiệp có ba thùng hàng không cần ban điều hành cảng.

Docker giải quyết vấn đề gì thật: "máy tôi chạy được"

Câu nói kinh điển trong ngành phần mềm là "máy tôi chạy được mà". Lập trình viên viết xong, chạy ngon trên laptop, đẩy lên máy chủ thì lỗi. Nguyên nhân gần như luôn giống nhau: máy chủ có phiên bản thư viện khác, thiếu một extension, biến môi trường sai một dòng.

Chi phí của vấn đề này không nằm ở tiền máy chủ mà nằm ở thời gian. Một tình huống chúng tôi gặp rất thường xuyên: doanh nghiệp có website bán hàng, mỗi lần cập nhật tính năng là mất nửa buổi tối để dựng lại môi trường, cứ vài lần lại có một lần hỏng phải khôi phục từ backup. Nhân với 20-30 lần cập nhật mỗi năm, đó là hàng chục giờ kỹ sư bị đốt vào việc không tạo ra giá trị.

Docker cắt đúng khoản đó. Môi trường được mô tả bằng một file, nằm chung kho mã nguồn, ai chạy cũng ra kết quả giống nhau. Ba lợi ích cụ thể bạn nhìn thấy được:

1. Triển khai lặp lại được. Bản chạy trên môi trường thử nghiệm và bản chạy thật là cùng một thùng hàng, không phải hai bản dựng khác nhau.
2. Quay lui nhanh. Bản mới lỗi thì đổi về thùng cũ, thường trong vài phút thay vì cài lại từ đầu.
3. Bàn giao không phụ thuộc người. Kỹ sư nghỉ việc không mang theo cái "bí kíp cấu hình máy chủ" nằm trong đầu anh ta.

Điểm quan trọng: Docker chạy tốt trên một VPS duy nhất. Bạn không cần cloud, không cần cụm máy chủ, không cần đổi nhà cung cấp. Với phần lớn doanh nghiệp SME, dừng lại đúng ở đây là hợp lý, và ngân sách hạ tầng gần như không đổi so với chi phí thuê VPS cho doanh nghiệp theo tải thật mà bạn đang trả.

Kubernetes sinh ra cho bài toán nào

Kubernetes được Google mở nguồn năm 2014, dựa trên hệ thống nội bộ họ dùng để chạy container ở quy mô rất lớn. Bài toán gốc của nó cụ thể: hàng nghìn dịch vụ nhỏ trên hàng chục nghìn máy chủ, hàng trăm kỹ sư triển khai song song, và không được phép có ai ngồi canh thủ công.

Những gì K8s làm giỏi:

• Tự khởi động lại dịch vụ chết mà không cần người trực.
• Tự co giãn số lượng bản chạy theo tải, tăng vào giờ cao điểm, giảm lúc vắng.
• Triển khai không gián đoạn — thay dần từng bản, lỗi thì tự dừng và quay lui.
• Chia tài nguyên giữa nhiều đội, nhiều dịch vụ trên cùng cụm máy chủ.
• Tự chữa lành khi một máy chủ vật lý chết, dồn khối lượng sang máy còn sống.

Đọc danh sách đó xong, hãy hỏi ngược lại một câu duy nhất: hệ thống của bạn có bao nhiêu dịch vụ độc lập đang chạy? Nếu câu trả lời là "một website và một API", thì bốn trong năm gạch đầu dòng trên không có việc để làm. Tự co giãn khi chỉ có một dịch vụ thì tương đương với việc nâng cấp gói VPS. Chia tài nguyên giữa nhiều đội khi chỉ có một đội thì không chia gì cả.

K8s không làm hệ thống nhỏ chạy nhanh hơn. Nó làm hệ thống lớn quản lý được. Đó là hai lời hứa hoàn toàn khác nhau, và chỉ một trong hai liên quan tới bạn.

Nếu điều bạn thực sự cần là hệ thống ít sập hơn và có nơi đặt dữ liệu đàng hoàng hơn, bài toán đó nằm ở tầng lựa chọn hạ tầng chứ không phải tầng điều phối container — chọn VPS, hosting hay cloud theo giai đoạn của website sẽ trả lời trực tiếp hơn nhiều.

Chi phí thật của Kubernetes không nằm ở license

Kubernetes miễn phí. Đây là câu đầu tiên mọi đề xuất đều nhắc tới, và nó đúng. Nó cũng gây hiểu nhầm nhiều nhất, vì tiền không đi vào license — tiền đi vào máy chủ tối thiểu và vào người.

Một cụm K8s dùng được cho môi trường thật cần tối thiểu ba node cho tầng điều khiển nếu tự dựng, cộng các node chạy ứng dụng. Nghĩa là bạn trả tiền cho ít nhất bốn đến năm máy chủ trước khi ứng dụng đầu tiên chạy. Trên nền quản lý sẵn của cloud, bạn tiết kiệm được công vận hành tầng điều khiển nhưng trả thêm phí cân bằng tải, phí lưu trữ động, phí truyền dữ liệu ra ngoài.

Bảng dưới là khoảng tham khảo thị trường tại thời điểm viết (08/2026), chưa gồm VAT, cho một hệ thống cỡ trung bình của SME:

Nhìn dòng cuối. Khoản chênh không đến từ phần mềm mà đến từ dòng nhân sự vận hành. Kubernetes là một hệ thống phân tán đầy đủ: mạng riêng, cơ chế lưu trữ riêng, mô hình bảo mật riêng, lịch nâng cấp phiên bản riêng vài tháng một lần. Ai đó phải hiểu tất cả những thứ đó, và người như vậy trên thị trường Việt Nam hiện không rẻ.

Còn một khoản hiếm khi được ghi vào đề xuất: rủi ro một người. Doanh nghiệp dựng K8s bằng đúng một kỹ sư giỏi rồi kỹ sư đó nghỉ việc là tình huống chúng tôi được gọi vào xử lý nhiều hơn bạn nghĩ. Hệ thống vẫn chạy, nhưng không ai dám chạm vào, và mọi thay đổi nhỏ đều biến thành dự án.

Khung quyết định theo quy mô hệ thống và đội ngũ

Đây là khung chúng tôi dùng khi được hỏi có nên triển khai Docker Kubernetes cho doanh nghiệp hay không. Đọc theo hàng, lấy hàng nào mô tả đúng bạn nhất.

Ba ngưỡng đáng nhớ, nói thẳng:

• Dưới 5 kỹ sư và dưới 5 dịch vụ độc lập: Kubernetes là thừa. Không phải "chưa cần", mà là thừa — bạn sẽ trả chi phí vận hành của hệ thống lớn để nhận lại lợi ích của hệ thống nhỏ.
• Không có ít nhất một người chịu trách nhiệm hạ tầng toàn thời gian: đừng tự dựng K8s. Nếu vẫn muốn container hóa mạnh, đi đường managed và chấp nhận phí cao hơn.
• Chưa đo được hệ thống hiện tại đang nghẽn ở đâu: chưa phải lúc bàn về công cụ. Rất nhiều trường hợp "cần K8s để chịu tải" hóa ra là một truy vấn cơ sở dữ liệu thiếu index.

Đường tiến hóa hợp lý: VPS, rồi Docker, rồi K8s khi có nhu cầu thật

Hạ tầng nên lớn lên theo hệ thống, không lớn lên theo hội thảo công nghệ. Lộ trình bốn bước dưới đây là thứ chúng tôi khuyến nghị cho hầu hết doanh nghiệp SME, mỗi bước chỉ bước khi có tín hiệu thật.

1. VPS đơn, cấu hình thủ công có tài liệu. Đủ dùng tới khi bạn triển khai dưới một lần mỗi tháng. Việc cần làm cho đàng hoàng ở bước này là backup và giám sát, không phải container.
2. Docker hóa ứng dụng, chạy bằng Compose trên cùng VPS đó. Tín hiệu để bước sang: mỗi lần triển khai đều hồi hộp, hoặc môi trường thử nghiệm và môi trường thật đã lệch nhau. Thường mất một đến hai tuần, ngân sách hạ tầng gần như không đổi.
3. Tách tầng: một máy chủ ứng dụng, một máy chủ cơ sở dữ liệu, thêm bản dự phòng. Tín hiệu: một sự cố làm sập toàn bộ, hoặc cơ sở dữ liệu và ứng dụng tranh RAM của nhau. Đây cũng là điểm nhiều doanh nghiệp bắt đầu tính tới việc chuyển hệ thống lên cloud mà không gián đoạn kinh doanh.
4. Điều phối container thật sự, K8s hoặc tương đương. Tín hiệu: trên 10 dịch vụ độc lập, nhiều đội triển khai song song trong ngày, tải dao động mạnh tới mức co giãn thủ công không kịp.

Bỏ qua bước 2 và 3 để nhảy thẳng lên bước 4 là cách nhanh nhất để có một hệ thống mà không ai trong công ty bạn hiểu trọn vẹn. Chúng tôi làm hạ tầng doanh nghiệp từ 2015, qua hơn 500 dự án, và hệ thống phải làm lại vì chọn công cụ quá tầm luôn nhiều hơn hệ thống phải làm lại vì chọn công cụ quá đơn giản. Công cụ đơn giản khi chật thì nâng cấp được. Công cụ quá tầm khi hỏng thì phải gọi người ngoài.

Ba dấu hiệu bạn đang bị bán thừa

Khi nhận một đề xuất hạ tầng, ba dấu hiệu sau đáng để hỏi lại trước khi ký:

• Đề xuất nói về công nghệ trước, nói về vấn đề sau. Nếu phần hiện trạng đang đau ở đâu, đo bằng số nào lại ngắn hơn phần mô tả kiến trúc, thứ tự đã ngược.
• Không có phương án B rẻ hơn để so sánh. Một đề xuất nghiêm túc luôn kèm ít nhất một lựa chọn tiết kiệm hơn và lý do không chọn nó.
• Không có dòng nào về chi phí vận hành 12 tháng tới và ai sẽ trực khi cụm gặp sự cố lúc 2 giờ sáng.

Ngược lại, có lúc đội kỹ thuật của bạn đúng và bạn nên duyệt: khi họ đưa ra được số lần triển khai mỗi tháng, số sự cố do lệch môi trường, thời gian trung bình để khôi phục, và chỉ ra công cụ mới cắt được khoản nào trong đó. Số liệu là thứ phân biệt nhu cầu thật với trend.

Nếu bạn đang cầm một đề xuất chuyển sang Kubernetes và không chắc nên duyệt hay hoãn, gửi nó cho chúng tôi đọc cùng. Đội kỹ sư của chúng tôi có chứng chỉ AWS, GCP, CEH, OSCP và đã dựng cả hai loại hệ thống — loại cần K8s và loại được khuyên đừng dùng. Gọi 0919 788 815 hoặc để lại thông tin trên microads.vn, buổi tư vấn đầu tiên không tính phí kể cả khi kết luận là bạn chưa cần đổi gì. Cấu hình và bảng giá cụ thể xem tại dịch vụ máy chủ của Microads.