Vấn Đề Khi Dùng Chung Một Kubernetes Cluster
Nếu bạn đã từng làm việc trong team mà mọi người dùng chung một Kubernetes cluster để phát triển, chắc bạn hiểu cái cảm giác đau đầu đó. Ai đó vô tình xóa mất namespace của người khác. Một resource quota cấu hình sai làm hỏng deployment của developer khác. Một junior dev apply một ClusterRole lỗi và đột nhiên cả nửa team không thể deploy được gì nữa.
Giải pháp kinh điển thường là “dùng cluster riêng biệt” hoặc “cô lập theo namespace.” Cả hai đều có chi phí thực sự — và không cái nào phù hợp hoàn toàn với mọi team.
So Sánh Ba Phương Pháp
1. Cluster Riêng Biệt Hoàn Toàn (Mỗi Developer Một Cluster)
Mỗi developer có cluster riêng — có thể là local (kind, minikube) hoặc được cấp phát trên cloud.
- Cô lập hoàn toàn: không ai có thể gây ảnh hưởng đến người khác
- Toàn quyền tự do: cài bất kỳ CRD nào, thay đổi bất kỳ cấu hình cluster nào
- Tốn kém: cluster trên cloud mất tiền thật; ngay cả cluster local cũng có thể ngốn 4–8GB RAM của laptop
- Khởi động chậm: cấp phát một cluster thật mất vài phút, không phải vài giây
2. Cô Lập Theo Namespace (Tất Cả Dùng Chung Một Cluster)
Mỗi developer (hoặc team, hoặc môi trường) có namespace riêng với RBAC giới hạn quyền truy cập.
- Tiết kiệm tài nguyên: một control plane dùng chung cho tất cả
- Nhanh: namespace được tạo trong vài giây
- Cô lập kém: các tài nguyên cấp cluster (CRD, ClusterRole, node) vẫn dùng chung
- RBAC phức tạp: thiết lập quyền đúng mà không cấp dư là việc thực sự khó
- Dev không có cluster-admin: không thể cài Helm chart cần CRD hoặc ClusterRole
3. Virtual Cluster với vcluster
vcluster chạy một Kubernetes API server đầy đủ chức năng bên trong một namespace của host cluster. Developer thấy một cluster thật với quyền admin đầy đủ. Host cluster chỉ thấy một vài pod nằm trong một namespace.
- Nhẹ: mỗi vcluster dùng ít tài nguyên hơn nhiều so với cluster thật
- Nhanh: một virtual cluster mới sẵn sàng trong dưới 60 giây
- Cô lập hoàn toàn: mỗi vcluster có API server, etcd (hoặc SQLite) và control plane riêng
- Quyền cluster-admin: dev có thể cài CRD, tạo ClusterRole, làm bất cứ điều gì — mà không ảnh hưởng đến host
- Workload chạy trên host: các pod thực tế vẫn chạy trên node của host cluster (vcluster đồng bộ xuống)
Ưu và Nhược Điểm của vcluster
vcluster Làm Tốt Điều Gì
- Dev sandbox: Dựng môi trường cô lập trong vài giây, xóa đi khi xong. Không tốn công dọn dẹp cho team platform.
- CI/CD pipeline: Mỗi lần chạy pipeline có cluster riêng để chạy integration test. Không rò rỉ trạng thái giữa các lần chạy.
- SaaS multi-tenant: Cấp cho khách hàng virtual cluster riêng mà không tốn chi phí cấp phát cluster thật.
- Môi trường đào tạo: Cho học viên thử nghiệm cấu hình cấp cluster mà không gây rủi ro cho hạ tầng của bạn.
- Kiểm thử operator và CRD: Cài và gỡ CRD thoải mái — thay đổi không bao giờ ảnh hưởng đến host.
Hạn Chế của vcluster
- Truy cập cấp node: Nếu ứng dụng cần DaemonSet chạy trên mọi node thật, cơ chế đồng bộ của vcluster có thể trở nên phức tạp.
- Host networking: Dịch vụ LoadBalancer và NodePort cần cấu hình thêm để expose traffic từ vcluster ra bên ngoài.
- Storage: PersistentVolume được đồng bộ lên host, hoạt động ổn — nhưng phụ thuộc vào StorageClass mà host hỗ trợ.
- Overhead tài nguyên: Mỗi vcluster thêm một lượng nhỏ overhead cho control plane (~100–200MB RAM). Ổn với 10 cluster. Từ 100+ cluster trở lên, bạn cần lên kế hoạch capacity cẩn thận hơn.
Chuẩn Bị Trước Khi Bắt Đầu
Bạn cần một host Kubernetes cluster. Để phát triển local, kind hoặc k3d đều rất phù hợp. Để hosting vcluster ở môi trường production, bất kỳ managed cluster nào (EKS, GKE, AKS) đều dùng được.
Bạn cũng cần:
kubectlđã cấu hình để kết nối với host clusterhelmv3+ (vcluster dùng Helm bên dưới)- CLI
vcluster(chúng ta sẽ cài bên dưới)
Một gợi ý đáng chú ý: dùng k3s làm virtual control plane (mặc định của vcluster cho các setup nhẹ) và SQLite thay vì etcd. Với mục đích dev sandbox, sự kết hợp này là quá đủ — và giúp giảm khoảng 40% bộ nhớ so với chạy etcd đầy đủ.
Hướng Dẫn Triển Khai
Bước 1: Cài vcluster CLI
# Linux / macOS
curl -L -o vcluster "https://github.com/loft-sh/vcluster/releases/latest/download/vcluster-linux-amd64"
chmod +x vcluster
sudo mv vcluster /usr/local/bin/
# Kiểm tra cài đặt
vcluster versionBước 2: Tạo Virtual Cluster Đầu Tiên
# Tạo vcluster tên "dev-sandbox" trong namespace "vcluster-dev"
vcluster create dev-sandbox --namespace vcluster-dev
# Lệnh này sẽ:
# 1. Tạo namespace nếu chưa tồn tại
# 2. Deploy vcluster control plane (API server + syncer)
# 3. Chờ đến khi vcluster sẵn sàng
# 4. Tự động chuyển kubectl context sang vcluster mớiSau khi lệnh hoàn tất, bạn đã kết nối vào virtual cluster. Chạy kubectl get nodes và bạn sẽ thấy một node — đó là node đại diện tổng hợp của vcluster.
kubectl get nodes
# NAME STATUS ROLES AGE VERSION
# vcluster-dev-sandbox Ready <none> 30s v1.28.0Bước 3: Deploy Thứ Gì Đó Bên Trong vcluster
# Deploy nginx bên trong virtual cluster
kubectl create deployment nginx --image=nginx:alpine
kubectl expose deployment nginx --port=80 --type=ClusterIP
# Kiểm tra xem đã chạy chưa
kubectl get pods
kubectl get svcBây giờ chuyển lại host cluster và xem vcluster thực sự tạo ra gì ở đó:
# Chuyển lại context của host cluster
vcluster disconnect
# Kiểm tra namespace vcluster trên host
kubectl get pods -n vcluster-dev
# Bạn sẽ thấy: pod control plane của vcluster + pod nginx (đồng bộ từ vcluster)Workload khai báo bên trong vcluster sẽ được đồng bộ xuống host dưới dạng pod thật. API server của vcluster trình bày chúng cho developer như tài nguyên native — nhưng thực tế chúng được lên lịch chạy trên node của host. Đó chính là toàn bộ bí quyết.
Bước 4: Cấp Quyền Truy Cập vcluster cho Developer
# Xuất kubeconfig cho vcluster
vcluster connect dev-sandbox --namespace vcluster-dev --print > dev-sandbox-kubeconfig.yaml
# Chia sẻ file này cho developer
# Họ dùng như bất kỳ kubeconfig nào khác:
export KUBECONFIG=./dev-sandbox-kubeconfig.yaml
kubectl get podsBước 5: Tạo Nhiều vCluster cho Các Môi Trường Khác Nhau
# Mỗi developer một cluster
vcluster create dev-alice --namespace vcluster-alice
vcluster create dev-bob --namespace vcluster-bob
# Hoặc mỗi giai đoạn môi trường một cluster
vcluster create staging --namespace vcluster-staging
vcluster create qa --namespace vcluster-qa
# Liệt kê tất cả vcluster đang chạy
vcluster list
# NAME NAMESPACE STATUS CONNECTED
# dev-alice vcluster-alice Running
# dev-bob vcluster-bob Running
# staging vcluster-staging RunningBước 6: Tùy Chỉnh vcluster với values.yaml
Khi cần vượt ngoài cấu hình mặc định, dùng file Helm values:
# vcluster-values.yaml
controlPlane:
distro:
k3s:
enabled: true
statefulSet:
resources:
requests:
memory: 128Mi
cpu: 50m
limits:
memory: 512Mi
cpu: 500m
syncer:
extraArgs:
- "--sync-all-nodes" # đồng bộ label/taint của node vào vcluster# Áp dụng values tùy chỉnh khi tạo
vcluster create dev-sandbox \
--namespace vcluster-dev \
--values vcluster-values.yamlBước 7: Xóa vcluster Khi Không Dùng Nữa
# Xóa vcluster và dọn sạch namespace
vcluster delete dev-sandbox --namespace vcluster-devMọi thứ biến mất hoàn toàn — không còn CRD nào sót lại trên host, không có ClusterRole nào thừa. Hãy so sánh với cách cô lập theo namespace, nơi việc dọn dẹp thường có nghĩa là phải đi tìm các tài nguyên cấp cluster được tạo ngoài ranh giới namespace.
Kết Quả Thực Tế
Trong môi trường production, tôi đã dùng pattern này cụ thể cho môi trường integration test của CI/CD. Mỗi pipeline job tạo một vcluster, chạy toàn bộ test suite (bao gồm cả Helm chart cài CRD), rồi xóa cluster khi hoàn tất. Sau nhiều tháng và hàng nghìn lần chạy pipeline, chưa có một lần nào xảy ra rò rỉ tài nguyên liên quan đến test trên host.
Chạy 8 vcluster đồng thời với k3s + SQLite tiêu tốn khoảng 1.2GB RAM tổng cộng cho tất cả control plane. Control plane của một cluster thật trên hầu hết các managed provider đã dùng nhiều hơn thế rồi.
Tham Khảo Nhanh
# Các lệnh thường dùng nhất
vcluster create <tên> --namespace <ns> # Tạo và kết nối
vcluster list # Liệt kê tất cả vcluster
vcluster connect <tên> --namespace <ns> # Kết nối lại vcluster đã có
vcluster disconnect # Chuyển về host cluster
vcluster delete <tên> --namespace <ns> # Xóa vĩnh viễnNếu team bạn đang vật lộn với sự hỗn loạn của shared cluster, vcluster xứng đáng để thử một buổi chiều. Bạn có được sự cô lập thật sự mà không phải trả tiền cho cluster thật — và sự đánh đổi đó hoạt động tốt cho cả dev sandbox, test pipeline lẫn các kịch bản multi-tenant.
