Những điểm nổi bật
- Managed Kubernetes (VKS) phân chia trách nhiệm rõ ràng: nhà cung cấp lo control plane với SLA 99,99%, đội ngũ chỉ cần lo worker node, nhờ vậy team nhỏ không có DevOps vẫn chạy production được.
- Đội ngũ vẫn phải tự viết Helm chart, cấu hình resource, quản lý secrets, và thiết lập giám sát, đồng thời không nên chạy database trong cluster.
- Một startup sáu người đã đưa bốn microservice lên production trên VKS chỉ trong một ngày nhờ kết hợp Helm và ArgoCD theo mô hình GitOps.
Nếu bạn đang là CTO của một startup 5–8 người và đang nghĩ đến Kubernetes, khả năng cao bạn đang gặp một trong hai tình huống này:
Một là, app đang chạy trên Docker Compose hoặc vài VM rời — mọi thứ vẫn ổn, nhưng bạn đang deploy thủ công, rollback là cơn ác mộng, và cứ mỗi lần traffic tăng đột biến là phải thức đêm.
Hai là, bạn đã nghe đủ về Kubernetes, biết đây là hướng cần đi, nhưng đọc qua documentation thấy ngay rằng để setup K8s đúng cách cần một người chuyên về infra — mà team bạn chưa có.
Bài này dành cho cả hai trường hợp. Với managed Kubernetes như VKS GreenNode, ngưỡng kỹ thuật để chạy K8s production đã thấp hơn nhiều so với ba năm trước — đủ để một team không có DevOps dedicated vẫn làm được, nếu biết chọn đúng stack.
1. Startup muốn dùng K8s nhưng không có DevOps
Kubernetes giải quyết những vấn đề thực tế mà startup gặp phải khi scale: deploy không downtime, auto-scaling khi traffic tăng, tự restart khi container crash, và CI/CD pipeline gọn gàng cho nhiều service. Những thứ này không phải nice-to-have khi bạn có khách hàng trả tiền — chúng là yêu cầu cơ bản.
Vấn đề là K8s truyền thống đi kèm một danh sách ops work đáng sợ:
- Setup control plane HA với etcd cluster, cài CNI plugin, ingress controller, cert-manager
- Upgrade version 3 lần/năm, rotate certificate hàng năm (nếu quên thì cluster chết)
- Backup etcd định kỳ, patch OS cho worker nodes
- Khi có incident lúc 2 giờ sáng — đó là bạn phải xử lý
Với team 5–8 người mà backend engineer kiêm luôn mọi thứ, danh sách đó là không khả thi. Phần lớn startup ở giai đoạn này kết thúc bằng một trong ba hướng: tiếp tục dùng Docker Compose và chấp nhận giới hạn, thuê freelance DevOps để setup rồi không có ai maintain, hoặc dùng K8s của cloud nước ngoài nhưng gặp vấn đề về latency và compliance.
2. Managed K8s giải quyết bài toán này thế nào?
Managed Kubernetes không phải "K8s dễ hơn" nó là sự phân chia trách nhiệm rõ ràng giữa provider và bạn.
Kubernetes có hai phần chính: Control plane bộ não của cluster, gồm API server, etcd, scheduler, controller manager. Đây là phần phức tạp nhất, hay gặp incident nhất, và cần người có kinh nghiệm để maintain. Worker nodes nơi app của bạn thực sự chạy. Đây là phần mà developer hiểu và kiểm soát được thông qua manifest và Helm chart.
Managed K8s như VKS GreenNode lấy đi toàn bộ control plane khỏi tay bạn. Provider chịu trách nhiệm setup, maintain, upgrade và incident response. Bạn chỉ làm việc với worker nodes và workload đúng phần mà developer giỏi hơn ops engineer.
Đây không phải "K8s cho người lười" mà là phân công đúng chuyên môn: provider làm phần infra phức tạp, team bạn làm phần product và deployment.
Nếu bạn muốn tìm hiểu thêm về lý do managed Kubernetes phù hợp với startup ở giai đoạn này, xem thêm bài Managed Kubernetes cho startup: Khi nào là đúng thời điểm?
3. Những thứ VKS tự xử lý: control plane, etcd, upgrades, monitoring
Danh sách cụ thể những gì VKS GreenNode đảm nhận — và bạn không cần nghĩ đến:
3.1 Control plane fully managed và Multi-AZ
API server, etcd cluster, scheduler, controller manager — tất cả được GreenNode vận hành trên Multi-AZ infrastructure với SLA 99.99%. Nếu một availability zone gặp sự cố, control plane vẫn hoạt động. Control plane được cung cấp miễn phí.
3.2 Automated cluster upgrades
Kubernetes release minor version khoảng 3 lần mỗi năm. Với self-managed cluster, mỗi lần upgrade là 4–8 giờ engineering time. VKS xử lý việc này với zero downtime — bạn chọn version (hiện hỗ trợ 1.29 và 1.30), phần còn lại là tự động.
3.3 Etcd backup và certificate rotation
etcd là nơi lưu toàn bộ state của cluster. VKS manage etcd backup tự động và rotate certificate trước khi hết hạn — tránh cluster chết đột ngột do certificate expired.
3.4 Cluster Autoscaler tích hợp
Tự động thêm worker node khi pod pending vì thiếu resource, và xóa node idle để tối ưu chi phí. Theo tài liệu Kubernetes, cluster autoscaler cần cấu hình cẩn thận — VKS tích hợp sẵn theo best practice.
3.5 IAM và private cluster
Kiểm soát access qua IAM policy, hỗ trợ fully private cluster không có public API endpoint, whitelist IP cho API server. Phù hợp yêu cầu của khách hàng B2B và fintech.
4. Những thứ bạn vẫn phải tự làm
Managed K8s xử lý control plane — nhưng có những thứ bạn vẫn phải chịu trách nhiệm. Biết trước điều này giúp bạn không bị bất ngờ sau khi đã deploy.
4.1 Viết và maintain Kubernetes manifest:
Deployment, Service, Ingress, ConfigMap, Secret — bạn vẫn phải tự viết. Cách đơn giản hóa: dùng Helm chart. Hầu hết app phổ biến đã có community Helm chart trên Artifact Hub. App nội bộ thì viết chart một lần và reuse.
4.2 Resource requests và limits
Nếu không set đúng, Cluster Autoscaler không scale đúng và pod có thể bị evict. Cần làm một lần đúng cách.
4.3 Quản lý secrets
Kubernetes Secret mặc định chỉ encode base64 — không phải encrypt. Cần Sealed Secrets hoặc external secret manager. Với startup giai đoạn đầu, Sealed Secrets đủ dùng.
4.4 Ingress và TLS
Ingress controller và cert-manager cần install một lần. Sau đó thêm domain mới chỉ cần vài dòng YAML.
4.5 Monitoring và logging
VKS không đi kèm monitoring stack — cần install Prometheus + Grafana hoặc dùng managed monitoring. Nên làm ngay từ đầu, không phải sau khi có incident đầu tiên.
4.6 Database không nên chạy trong cluster
Nhiều startup cố chạy PostgreSQL hoặc MySQL trong Kubernetes vì tiện. Không nên. Database có stateful requirement phức tạp không phù hợp với K8s pod lifecycle. Dùng managed database, tách database ra khỏi cluster giảm đáng kể complexity và rủi ro.
5. Stack đề xuất cho startup 3–10 người: VKS + Helm + ArgoCD
Stack tối giản nhưng production-ready cho startup không có DevOps dedicated. Mỗi thành phần giải quyết một vấn đề cụ thể và không overlap:
VKS GreenNode — managed Kubernetes, xử lý toàn bộ control plane ops. Đây là nền tảng, các thứ còn lại đặt trên đây.
Helm — package manager cho Kubernetes. App nội bộ thì viết chart một lần và reuse.
ArgoCD — GitOps controller. Workflow: push code → CI build image → update image tag trong Git → ArgoCD tự deploy. Không cần kubectl apply thủ công. Xem ArgoCD documentation để hiểu cách cài đặt.
cert-manager — auto-provision và renew TLS certificate từ Let's Encrypt. Cài một lần, sau đó mỗi Ingress chỉ cần thêm một annotation.
nginx-ingress — ingress controller để route traffic. Standard choice, nhiều tài liệu, community lớn.
Sealed Secrets (optional nhưng khuyến nghị) — encrypt Kubernetes secret trước khi commit vào Git. Phù hợp với GitOps workflow của ArgoCD.
6. Tại sao stack này phù hợp với team không có DevOps
Helm và ArgoCD cùng nhau tạo ra một workflow mà developer hiểu được: mọi thứ đều là code trong Git, deploy là kết quả của việc merge PR, rollback là revert commit. Không cần biết internals của Kubernetes để vận hành hàng ngày.
7. Case study: Deploy SaaS production trong 1 ngày trên VKS
Scenario tổng hợp dựa trên pattern phổ biến của startup B2B SaaS tại Việt Nam.
Bối cảnh
Startup 6 người, đang chạy 4 microservices (API, worker, scheduler, frontend) trên Docker Compose trên một VM duy nhất. CTO kiêm backend lead. Không có DevOps. Đang chuẩn bị onboard khách hàng enterprise đầu tiên và khách hàng hỏi về deployment architecture và uptime SLA.
Ngày 1 — Sáng: Provision VKS cluster
- Tạo VKS cluster với 3 worker node (2 AZ khác nhau)
- Setup kubeconfig trên local
- Install nginx-ingress và cert-manager có sẵn Helm chart, khoảng 30 phút bao gồm test
Ngày 1 — Chiều: Containerize và viết Helm chart
- 4 service đã có Dockerfile từ trước (Docker Compose environment)
- Viết Helm chart cho từng service với values file cho staging và production
- Chart cơ bản cho một service REST API mất khoảng 45 phút
Ngày 1 — Cuối ngày: Setup ArgoCD và deploy
- Cài ArgoCD vào cluster (Helm chart có sẵn)
- Tạo Application resource cho từng service, point về Git repo
- ArgoCD sync lần đầu — 4 service lên production
- Tạo Ingress với TLS — cert-manager tự lấy certificate từ Let's Encrypt
Kết quả sau 1 ngày setup
- 4 service chạy trên K8s với health check và auto-restart
- Rolling deploy không downtime
- Auto-scaling khi traffic tăng
- TLS trên tất cả endpoint
- Rollback bằng cách revert commit trong Git
Mỗi lần deploy sau đó: push code, CI build image, ArgoCD tự deploy trong 2–3 phút
8. Giới hạn thực tế cần biết trước
- Kubernetes vẫn có learning curve. Nếu team chưa ai từng dùng kubectl, cần vài ngày để làm quen với concepts cơ bản. Đây là investment một lần, không phải ongoing burden.
- Debugging vẫn cần hiểu K8s. Khi pod crash hoặc deploy fail, bạn cần đọc được kubectl describe pod và kubectl logs. Không khó, nhưng cần học.
- Stateful workload cần cẩn thận. Database không nên chạy trong cluster. Message queue, cache (Redis) có thể chạy nhưng cần hiểu rõ PersistentVolume và storage class.
- Chi phí tăng so với single VM. 3 worker node đắt hơn 1 VM. Đây là trade-off có chủ đích: bạn đang mua reliability và ops time, không chỉ mua compute.
Kết luận
Stack VKS + Helm + ArgoCD cho phép team 3–10 người không có DevOps dedicated vận hành Kubernetes production với workflow mà developer hiểu được: mọi thứ là Git, deploy là merge PR, rollback là revert commit.
Phần bạn vẫn cần đầu tư: hiểu K8s concepts cơ bản, viết Helm chart, và setup monitoring. Tổng cộng vài ngày làm việc sau đó là workflow hàng ngày đơn giản hơn Docker Compose trước kia.
