Docker hay Kubernetes cho self-hosted app: đâu là lựa chọn thực tế hơn?
Tự host ứng dụng đang trở thành lựa chọn hấp dẫn với nhiều cá nhân, startup nhỏ và đội ngũ kỹ thuật muốn kiểm soát dữ liệu, chi phí và hạ tầng. Nhưng ngay khi bắt đầu, một câu hỏi gần như luôn xuất hiện: nên dùng Docker hay Kubernetes?
Vấn đề là hai cái tên này thường bị đặt cạnh nhau như thể chúng là hai “đối thủ” ngang hàng. Thực tế không hẳn vậy. Docker chủ yếu giải quyết bài toán đóng gói và chạy ứng dụng trong container. Kubernetes lại là nền tảng điều phối container ở quy mô lớn hơn. Vì thế, câu hỏi đúng hơn không phải là “cái nào mạnh hơn”, mà là: với self-hosted app của bạn, đâu là lựa chọn thực tế hơn, đáng công vận hành hơn, và ít làm bạn mất ngủ hơn?
Câu trả lời ngắn gọn: đa số trường hợp self-hosted nên bắt đầu với Docker, còn Kubernetes chỉ thực sự hợp lý khi độ phức tạp và quy mô đã vượt qua ngưỡng nhất định. Nhưng để kết luận này có giá trị, ta cần đi sâu hơn.
Hiểu đúng: Docker và Kubernetes đang giải quyết hai bài toán khác nhau
Docker phù hợp để chạy ứng dụng gọn, nhanh, dễ kiểm soát
Docker giúp bạn:
– Đóng gói app cùng toàn bộ dependency
– Chạy app nhất quán từ máy dev đến server
– Tách biệt môi trường giữa các dịch vụ
– Dễ triển khai bằng docker run hoặc docker compose
Nếu bạn đang self-host:
– một blog Ghost hoặc WordPress,
– một app Node.js/Python nhỏ,
– một stack gồm app + database + reverse proxy,
– một vài dịch vụ như Plausible, Nextcloud, Vaultwarden, Gitea,
thì Docker gần như đã đủ cho phần lớn nhu cầu ban đầu.
Điểm mạnh lớn nhất của Docker trong self-hosted không phải là “siêu công nghệ”, mà là sự đơn giản có thể quản lý được. Bạn nhìn thấy container nào đang chạy, port nào đang mở, volume nào chứa dữ liệu, biến môi trường nào được dùng. Khi có lỗi, bạn thường lần ra khá nhanh.
Kubernetes sinh ra cho điều phối ở mức hệ thống
Kubernetes làm tốt các việc mà Docker đơn lẻ hoặc Docker Compose bắt đầu đuối sức:
– Quản lý nhiều node
– Tự động reschedule container khi node lỗi
– Rolling update
– Auto-scaling
– Service discovery nội bộ
– Quản lý secret, config, health check bài bản
– Tách lớp networking, ingress, policy rõ ràng
Nghe rất hấp dẫn. Nhưng cần nhớ: mọi tính năng mạnh mẽ đều kéo theo chi phí vận hành. Với Kubernetes, chi phí đó không chỉ là tiền máy chủ mà còn là:
– thời gian học,
– công sức cấu hình,
– độ khó debug,
– overhead bảo trì cluster.
Với self-hosted app, đây là điểm phân biệt quan trọng nhất.
Khi nào Docker là lựa chọn thực tế hơn?
1. Khi bạn vận hành một hoặc vài ứng dụng trên ít máy chủ
Đây là kịch bản phổ biến nhất. Một VPS, một mini PC ở nhà, hoặc vài máy cloud nhỏ. Bạn cần app chạy ổn định, backup dễ, khôi phục nhanh, update không quá đau đầu.
Trong bối cảnh này, Docker thắng rõ vì:
– Cài nhanh
– Cấu hình dễ hiểu
– Tài liệu cộng đồng phong phú
– Hầu hết ứng dụng self-hosted đều có sẵn docker-compose.yml
– Việc backup volume và file cấu hình khá trực quan
Một ví dụ thực tế: bạn tự host Nginx Proxy Manager + app web + PostgreSQL + Redis. Với Docker Compose, toàn bộ stack có thể gói trong một thư mục, có file .env, volume rõ ràng, và quy trình deploy chỉ là docker compose up -d. Với nhiều người, đó là mức tối ưu giữa tiện lợi và kiểm soát.
2. Khi bạn là solo operator hoặc team rất nhỏ
Self-hosted thường không có cả đội SRE đứng sau. Người setup hạ tầng đôi khi cũng là người viết app, sửa bug, monitor server, backup dữ liệu và trả lời người dùng.
Trong hoàn cảnh đó, điều quan trọng không phải là nền tảng “xịn” nhất, mà là nền tảng có tỷ lệ lợi ích/độ phức tạp tốt nhất.
Docker phù hợp vì:
– Dễ onboarding cho người mới
– Dễ viết tài liệu nội bộ
– Dễ khôi phục khi có sự cố
– Dễ chuyển máy nếu cần migrate
Ngược lại, Kubernetes có thể biến một hệ thống nhỏ thành thứ khó hiểu quá mức cần thiết. Chỉ riêng việc nắm các khái niệm như Pod, Deployment, Service, Ingress, ConfigMap, Secret, PersistentVolume, StorageClass… đã đủ khiến nhiều người mất nhiều ngày hoặc nhiều tuần để thực sự vận hành tự tin.
3. Khi tài nguyên phần cứng hạn chế
Kubernetes không nhất thiết “nặng khủng khiếp”, nhất là với các bản nhẹ như K3s. Nhưng dù vậy, nó vẫn có overhead vận hành cao hơn Docker Compose.
Nếu bạn đang chạy trên:
– VPS 1-2 GB RAM,
– homelab mini PC,
– NAS tự host nhiều dịch vụ,
thì Docker thường tiết kiệm tài nguyên và công sức hơn. Đặc biệt nếu app của bạn không cần scale ngang hoặc phân tán nhiều node, Kubernetes sẽ mang lại cảm giác “dùng xe tải để chở một thùng hàng nhỏ”.
Khi nào Kubernetes bắt đầu đáng cân nhắc?
1. Khi bạn có nhiều dịch vụ và cần chuẩn hóa vận hành
Nếu bạn không còn chạy 2-3 container nữa mà đã có:
– nhiều microservice,
– nhiều môi trường dev/staging/prod,
– nhu cầu deploy lặp lại thường xuyên,
– yêu cầu health check, rollback, zero-downtime update,
thì Kubernetes bắt đầu có lý do tồn tại.
Lúc này, giá trị của Kubernetes nằm ở khả năng chuẩn hóa hệ thống. Bạn không còn quản lý dịch vụ kiểu “mỗi con một file compose hơi khác nhau”, mà có thể đưa mọi thứ vào một mô hình triển khai nhất quán hơn.
2. Khi uptime và tự phục hồi là ưu tiên thật sự
Docker Compose có thể restart container khi lỗi, nhưng Kubernetes làm tốt hơn ở mức điều phối:
– Pod chết thì được tạo lại
– Node lỗi thì workload được dời sang node khác
– Rolling update và rollback có quy trình rõ
– Readiness/Liveness probe giúp tránh route traffic vào app chưa sẵn sàng
Nếu bạn self-host một ứng dụng phục vụ nội bộ quan trọng, có người dùng thật, và downtime kéo dài gây thiệt hại rõ rệt, Kubernetes có thể xứng đáng với phần phức tạp bổ sung.
3. Khi bạn thật sự cần multi-node
Đây là điểm then chốt. Nếu bạn chỉ có một máy chủ, Kubernetes thường khó biện minh trừ khi mục tiêu của bạn là học tập hoặc chuẩn bị cho tương lai.
Nhưng nếu bạn có nhiều node và muốn:
– phân phối workload,
– tăng khả năng chịu lỗi,
– tách compute và storage,
– mở rộng có kiểm soát,
thì Kubernetes bước vào “đúng sân”.
Nói cách khác, Kubernetes mạnh nhất khi hạ tầng bắt đầu là một cụm, không còn là một server đơn.
Những cái giá thường bị đánh giá thấp khi chọn Kubernetes
Nhiều người chọn Kubernetes quá sớm vì bị hấp dẫn bởi hình ảnh “production-ready”. Nhưng với self-hosted, có vài chi phí ẩn cần nhìn thẳng.
Độ khó debug tăng lên đáng kể
Với Docker, bạn thường kiểm tra:
– log container,
– port mapping,
– volume,
– network bridge.
Với Kubernetes, một lỗi có thể nằm ở nhiều lớp:
– Pod không schedule được
– Service chọn sai label
– Ingress route lỗi
– PVC không bind
– DNS nội bộ trục trặc
– CNI gặp vấn đề
– TLS hoặc cert-manager cấu hình sai
Điều này không xấu nếu hệ thống đủ lớn để xứng đáng. Nhưng với self-host app nhỏ, đây là gánh nặng có thật.
Backup và storage không còn đơn giản như trước
Self-host không chỉ là “chạy được”, mà còn là khôi phục được khi hỏng.
Docker volume thường dễ backup theo cách thủ công hoặc script định kỳ. Kubernetes thì liên quan đến PersistentVolume, CSI, snapshot, storage backend. Nếu không thiết kế ngay từ đầu, bạn có thể có một cluster trông rất hiện đại nhưng khôi phục dữ liệu lại khá chật vật.
Bảo mật và cập nhật cũng nhiều lớp hơn
Kubernetes không tự động an toàn chỉ vì nó là Kubernetes. Bạn vẫn cần nghĩ đến:
– RBAC
– Secret management
– Network policy
– Ingress bảo mật
– Cập nhật control plane và worker node
– Quản lý chart, manifest, CRD
Với self-host quy mô nhỏ, số lớp cần chăm sóc đôi khi vượt xa giá trị thực nhận được.
Một cách chọn thực tế hơn thay vì chọn theo “độ ngầu”
Nếu mục tiêu của bạn là chạy app ổn định với ít công bảo trì nhất, hãy tự hỏi:
– Bạn có bao nhiêu ứng dụng?
– Có bao nhiêu máy chủ?
– Có cần scale ngang thật không?
– Downtime 5-10 phút có chấp nhận được không?
– Bạn có muốn dành cuối tuần để debug cluster không?
Trong phần lớn trường hợp, câu trả lời dẫn đến Docker.
Một lộ trình hợp lý cho self-hosted thường là:
1. Bắt đầu với Docker Compose
2. Chuẩn hóa biến môi trường, volume, reverse proxy, backup
3. Theo dõi khi nào hệ thống bắt đầu đau vì giới hạn của mô hình hiện tại
4. Chỉ chuyển sang Kubernetes khi có nhu cầu rõ ràng, không phải vì xu hướng
Đây là cách tiếp cận tiết kiệm thời gian, giảm rủi ro và vẫn giữ được khả năng mở rộng về sau.
Kết luận: với self-hosted app, Docker thường là lựa chọn thực tế hơn
Nếu phải đưa ra một lời khuyên ngắn gọn: Docker là lựa chọn hợp lý mặc định cho hầu hết self-hosted app; Kubernetes là lựa chọn nâng cao khi bạn đã thật sự cần orchestration ở quy mô lớn hơn.
Docker thắng ở sự đơn giản, dễ học, dễ vận hành, dễ backup và phù hợp với phần lớn nhu cầu thực tế của cá nhân hoặc team nhỏ. Kubernetes không hề “thừa” hay “quá mức” trong mọi trường hợp, nhưng nó chỉ phát huy hết giá trị khi bạn có nhiều dịch vụ, nhiều node, yêu cầu uptime cao và sẵn sàng trả chi phí vận hành tương ứng.
Cuối cùng, hạ tầng tốt không phải là hạ tầng dùng công nghệ phức tạp nhất. Hạ tầng tốt là hạ tầng bạn hiểu rõ, sửa được khi hỏng, và duy trì được lâu dài. Với self-hosted app, đó thường là lý do Docker chiến thắng.