Tôi đã xóa Kubernetes khỏi hệ thống: giảm gần nửa chi phí vận hành và doanh thu vẫn tăng

Xin chào các bác nhé. Tôi đang là DevOps Engineer tại một công ty SaaS vừa và nhỏ. Tôi từng tin rằng Kubernetes là lựa chọn đúng đắn cho mọi hệ thống cloud-native. Tôi từng mất ngủ nhiều đêm để migrate ứng dụng từ EC2 sang EKS, viết Helm chart, tối ưu HPA, rồi debug các lỗi lạ do kube-proxy. Nhưng sau 1 năm sống chung với nó, tôi đưa ra một quyết định mà nhiều đồng nghiệp cho là “rảnh hơi mua việc”: Tôi đã gỡ bỏ toàn bộ Kubernetes khỏi production và quay lại với Docker Compose + hệ thống giám sát thủ công.

Kết quả? Hệ thống ổn định hơn. Tốc độ phát triển nhanh hơn. Và đặc biệt: chi phí vận hành giảm 47% (chính xác là 47,6%) trong 2 tháng.

Vì sao tôi chọn Kubernetes lúc đầu?

Nói đến cái “rảnh hơi” chắc có bác hỏi như vậy. Công ty startup tôi đang làm là một nền tảng SaaS cung cấp dịch vụ quản lý tài liệu cho doanh nghiệp nhỏ. Chúng tôi có 4 service backend (user, billing, document, notification), 1 frontend React app và sử dụng PostgreSQL + Redis. Lúc đầu chạy trên EC2 với ansible script deploy thủ công.

Rồi mọi thứ bắt đầu “cảm thấy cũ kỹ”. CTO đọc blog của một công ty lớn về microservices, CI/CD, Kubernetes, và nói: “Chúng ta nên dùng K8s để scale.”

Tôi đồng ý. Vì lúc đó tôi cũng đang học về Helm, Prometheus, Kustomize… Có cơ hội áp dụng là một giấc mơ với tôi (bản thân tôi base là Sysadmin chưa có tới mức senior DevOps).

Triển khai thực tế: Đẹp ngoài, rối bên trong

Chúng tôi triển khai trên EKS (Amazon Kubernetes Service). Dùng ArgoCD để deploy, Prometheus + Grafana cho giám sát, Fluent Bit đẩy log về Loki.

Về mặt “trưng bày” thì hệ thống rất đẹp:

GitOps đầy đủ, mọi thứ lưu trong Git.
Service tách nhỏ, có autoscale.
Dashboard nhìn như Google.

Nhưng vận hành thì là ác mộng.

Alert “giả” từ Prometheus mỗi khi có GC spike ở Java app.
HPA auto scale sai lệch do config CPU limit không chính xác, dẫn đến scale-out rồi scale-in liên tục.
Debug một request 500 mất ít nhất 15 phút vì phải tìm Pod đúng, check log đúng container, rồi correlate với log các service khác.
Chi phí AWS tăng 2,3 lần, chủ yếu từ load balancer và control plane.

Chưa kể dev phải học Helm, hiểu Pod, PVC, Service, Deployment mới có thể tự deploy. Nhiều người lùi bước (Startup các bác làm thì hiểu mà).

Tôi quay lại nền tảng đơn giản hơn

Tôi quyết định thử một bản staging chạy bằng Docker Compose + Traefik + systemd. Monitoring đơn giản hóa: dùng Netdata + Sentry và log đẩy về Elastic Cloud (managed).

CI/CD vẫn dùng GitHub Actions, chỉ là build image xong rsync thẳng qua SSH và chạy docker-compose up -d.

Kết quả bất ngờ:

Deploy nhanh hơn 3 lần (không cần build Helm, chờ Argo sync).
Dev có thể debug local rồi deploy prod gần như giống nhau.
Chi phí AWS giảm hơn 47% sau 2 tháng.
Chúng tôi có thời gian tập trung build feature chứ không phải “gỡ lỗi config”.

Tôi không nói Kubernetes tệ

Kubernetes rất mạnh. Tôi tin rằng ở quy mô lớn, hoặc khi bác cần multi-tenant, zero-downtime deployment, policy enforcement, thì K8s là không thể thay thế.

Nhưng ở một công ty không nhiều engineer, dưới 1 triệu request/ngày, và ngân sách cloud giới hạn, Kubernetes là overkill.

Hệ thống nên phục vụ business, không phải làm business phục vụ hệ thống – Tôi tin như vậy.