Docker và Kubernetes: Triển khai ứng dụng Container

Không phải vì nó là "trend". Khi bạn quản lý 20, 50, hay 200 server, bạn sẽ nhận ra rằng SSH vào từng cái để cài dependencies là cách tự tìm đến chết. Netflix từng mất hàng triệu đô trong một sự cố vì environment không đồng nhất giữa các server. Ngày nay, 73% các công ty lớn sử dụng container (theo CNCF survey 2024).

Nhưng có một điều quan trọng mà ít người nói: Docker không phải là giải pháp cho tất cả vấn đề. Nó giải quyết 30% vấn đề deployment. Phần còn lại? Đó là orchestration, scaling, networking, storage - những thứ mà Kubernetes bước vào.

Kubernetes: Khi Docker không đủ

Hình dung bạn có 100 container chạy trên 10 server. Một server bị down - bạn cần phân phối lại 10 container đó. Một app bạn cần scale từ 5 lên 50 instances trong 2 phút vì traffic spike. Một container crash, bạn cần restart nó tự động. Làm bằng tay? Hãy quên đi, bạn sẽ điên.

Kubernetes (K8s) làm việc này - nó tự động quản lý vòng đời của các container. Nó:

• Phân phối container tự động dựa trên tài nguyên
• Scale lên/xuống theo demand (auto-scaling)
• Health check và tự restart container bị lỗi
• Update zero-downtime (rolling update)
• Manage network giữa các container

Điều khó nhất về Kubernetes không phải là syntax hay command. Là mental model - hiểu được nó tư duy như thế nào. K8s không quan tâm đến "server cụ thể nào", nó chỉ quan tâm đến "tôi cần 10 instance của app này, mỗi cái cần 2GB RAM".

Con đường từ Docker đến Kubernetes

Nếu bạn mới vào ngành, đừng vội nhảy vào Kubernetes. Học Docker trước - hiểu image, container, volume, network. Chạy một vài project trên Docker Compose để cảm nhận việc quản lý nhiều service.

Dấu hiệu bạn cần Kubernetes:

• Production của bạn có >5 server
• Bạn cần scale tự động
• Downtime không chịu được
• Team của bạn đủ người để maintain nó (K8s không trivial)

Ngược lại, nếu bạn chỉ có một vài server hoặc ứng dụng nhỏ, Docker + Docker Swarm hay thậm chí quản lý thủ công cũng đủ.

Những bẫy thực tế mà documentation không nói

Resource request/limit: Nhiều người set 16GB limit cho một app không cần quá 2GB. K8s sẽ không cho nó chạy nếu node không có 16GB free. Kết quả? Pod pending mãi mãi. Bạn phải hiểu workload của bạn.

Image size: Image 2GB sẽ khiến cluster bạn cực kỳ chậm. Tôi từng thấy một startup deploy image 5GB, pull xuống 10 lần/ngày, network bị nghẽn. Use multi-stage build, bỏ những thứ không cần.

Persistent data: Container là stateless. Nếu bạn lưu data vào container, khi container restart, data mất. Bạn cần external storage (database, S3, PVC). Nhiều người bỏ quên điểm này.

Logging: Nếu không setup centralized logging, khi 100 container chạy, bạn không biết cái nào bị lỗi. ELK stack, Datadog, hay các tool khác là bắt buộc.

Thực hành: Từ zero đến production

Bước 1: Viết Dockerfile đúng cách - sử dụng base image nhỏ (Alpine, Distroless), multi-stage build.

Bước 2: Test trên máy local với Docker.

Bước 3: Nếu chỉ có 1-2 app, dùng Docker Compose trên server duy nhất.

Bước 4: Khi phức tạp, dùng managed Kubernetes (EKS, GKE, AKS) thay vì tự setup - tiết kiệm thời gian vàng.

Ở Việt Nam, một số công ty như Grab, Tiki đã dùng K8s từ lâu. Nhưng nhiều startup vẫn chưa, có thể vì hosting cost hoặc team nhỏ.

Kết luận

Docker và Kubernetes không phải buzz words - chúng là tools thực tế để giải quyết bài toán mở rộng. Docker giải quyết vấn đề "nó chạy trên máy tôi sao không chạy trên server?" Kubernetes giải quyết "làm sao tôi scale được nếu có 1000 user đột ngột?". Bạn chọn dùng hay không tùy vào bài toán của bạn, nhưng hiểu được chúng là kỹ năng cần thiết cho bất kỳ engineer nào muốn sống sót trong thế giới cloud-native.

Nếu bạn cần tư vấn kỹ lưỡng hơn, đội của Idflow Technology có kinh nghiệm lâu dài trong lĩnh vực này.