Vấn đề Khi Quản lý Nhiều Kubernetes Cluster Thủ công
Nếu bạn từng quản lý hơn hai Kubernetes cluster — chẳng hạn một cho môi trường development, một cho staging, và một cho production — bạn hẳn đã biết mọi thứ có thể trở nên lộn xộn nhanh như thế nào. Mỗi cluster được tạo ra theo một cách hơi khác nhau. Việc nâng cấp diễn ra theo các lịch trình khác nhau. Có người thủ công khởi tạo node trên AWS bằng eksctl, trong khi team khác dùng Terraform trên GCP, và cụm bare-metal thì là một mớ Ansible playbook mà chẳng ai còn hiểu rõ nữa.
Kết quả là bạn có một đội “hoa tuyết” — các cluster trông giống nhau bề ngoài nhưng lại không nhất quán bên trong. Triển khai nâng cấp phiên bản Kubernetes trở thành một dự án kéo dài cả tuần thay vì chỉ mất một buổi chiều. Thêm một cluster mới cho một region mới đòi hỏi phải sao chép và chỉnh sửa các script vốn không được thiết kế để tái sử dụng.
Cluster API (CAPI) ra đời chính xác để giải quyết vấn đề này. Nó mang cách quản lý khai báo theo kiểu Kubernetes-native đến với chính các cluster — cùng phương pháp thân thiện với GitOps, vòng lặp reconciliation mà bạn đã dùng cho workload, giờ được áp dụng cho chính hạ tầng chạy những workload đó.
Các Khái niệm Cốt lõi Bạn Cần Biết Trước
Management Cluster vs. Workload Cluster
CAPI giới thiệu mô hình hai tầng:
- Management Cluster: Một Kubernetes cluster chuyên dụng chạy các CAPI controller. Đây là control plane cho toàn bộ đội cluster của bạn. Nó theo dõi
Cluster,MachineDeploymentvà các CAPI custom resource khác, sau đó đồng bộ hạ tầng thực tế để khớp với trạng thái mong muốn. - Workload Cluster: Các cluster mà ứng dụng của bạn thực sự chạy trên đó. Chúng được tạo, nâng cấp và xóa bởi management cluster dựa trên các YAML manifest bạn apply.
Hãy hình dung management cluster như một nhà máy tạo cluster. Bạn mô tả những gì bạn muốn, và nó sẽ xây dựng cho bạn.
Infrastructure Provider
CAPI không phụ thuộc vào provider cụ thể. Mỗi cloud hay nền tảng có provider riêng để chuyển đổi CAPI resource thành các lệnh gọi hạ tầng thực tế:
- CAPA — Cluster API Provider AWS
- CAPG — Cluster API Provider GCP
- CAPM3 — Cluster API Provider Metal3 (bare-metal qua BMC/IPMI)
Các CAPI controller cốt lõi xử lý logic vòng đời chung (kiểm tra sức khỏe máy, rolling upgrade, scaling), trong khi infrastructure provider thực hiện các lệnh gọi API thực tế để tạo VM, load balancer và mạng.
Các Loại Resource Quan trọng
Khi tạo workload cluster với CAPI, bạn định nghĩa các resource này trong YAML:
Cluster— Object cấp cao nhất tham chiếu đến hạ tầng và control planeAWSCluster/GCPCluster— Cấu hình mạng và VPC dành riêng cho providerKubeadmControlPlane— Quản lý các control plane node (etcd + API server + scheduler)MachineDeployment— Quản lý các nhóm worker node (giống Deployment, nhưng dành cho máy)AWSMachineTemplate/GCPMachineTemplate— Định nghĩa thông số máy (loại instance, image, disk)
Thực hành: Thiết lập CAPI và Khởi tạo Cluster Đầu tiên
Bước 1: Cài đặt clusterctl
clusterctl là công cụ CLI để khởi tạo provider và tạo cluster manifest.
# Cài đặt clusterctl (Linux/macOS)
curl -L https://github.com/kubernetes-sigs/cluster-api/releases/download/v1.7.3/clusterctl-linux-amd64 -o clusterctl
chmod +x clusterctl
sudo mv clusterctl /usr/local/bin/
# Kiểm tra
clusterctl versionBước 2: Chuẩn bị Management Cluster
Dùng bất kỳ Kubernetes cluster nào đang có (thậm chí cluster kind cục bộ cũng hoạt động để test). Bạn cần ít nhất Kubernetes 1.26.
# Tạo management cluster cục bộ với kind (để test)
kind create cluster --name capi-management
export KUBECONFIG=$(kind get kubeconfig --name capi-management)Bước 3: Khởi tạo AWS Provider (CAPA)
Đầu tiên thiết lập AWS credentials dưới dạng biến môi trường, sau đó chạy clusterctl init để cài đặt các controller:
export AWS_REGION=ap-northeast-1
export AWS_ACCESS_KEY_ID=<your-key-id>
export AWS_SECRET_ACCESS_KEY=<your-secret>
# Cài đặt clusterawsadm để bootstrap IAM resource
clusterawsadm bootstrap iam create-cloudformation-stack
# Xuất credentials dưới dạng base64 cho controller
export AWS_B64ENCODED_CREDENTIALS=$(clusterawsadm bootstrap credentials encode-as-profile)
# Khởi tạo CAPA trên management cluster
clusterctl init --infrastructure awsVới GCP, lệnh tương đương là:
export GCP_B64ENCODED_CREDENTIALS=$(cat sa-key.json | base64 | tr -d '\n')
clusterctl init --infrastructure gcpBước 4: Tạo Cluster Manifest
Thay vì viết YAML từ đầu, clusterctl generate cluster tạo ra manifest sẵn dùng dựa trên template từ provider:
export AWS_SSH_KEY_NAME=my-key-pair
export AWS_CONTROL_PLANE_MACHINE_TYPE=t3.medium
export AWS_NODE_MACHINE_TYPE=t3.medium
clusterctl generate cluster dev-cluster \
--infrastructure aws \
--kubernetes-version v1.30.0 \
--control-plane-machine-count 1 \
--worker-machine-count 2 \
> dev-cluster.yamlMở dev-cluster.yaml và kiểm tra nó. Bạn sẽ thấy tất cả các loại resource đã đề cập ở trên. File duy nhất này mô tả toàn bộ cluster của bạn — control plane node, worker node, cài đặt VPC và phiên bản Kubernetes.
Bước 5: Apply và Theo dõi Cluster Khởi động
kubectl apply -f dev-cluster.yaml
# Theo dõi trạng thái khởi tạo
clusterctl describe cluster dev-clusterCAPI sẽ gọi AWS API để tạo VPC, subnet, security group và EC2 instance. Toàn bộ quá trình thường mất 8–12 phút. Khi sẵn sàng, lấy kubeconfig cho workload cluster mới của bạn:
clusterctl get kubeconfig dev-cluster > dev-cluster.kubeconfig
export KUBECONFIG=dev-cluster.kubeconfig
kubectl get nodesBước 6: Nâng cấp Phiên bản Kubernetes
Đây là điểm CAPI thực sự tỏa sáng. Nâng cấp cluster chỉ là thay đổi một trường trong YAML — không cần SSH, không cần quy trình thủ công nào.
# Chỉnh sửa resource KubeadmControlPlane
kubectl patch kcp dev-cluster-control-plane \
--type merge \
-p '{"spec":{"version":"v1.31.0"}}'CAPI triển khai các control plane node mới chạy 1.31.0 từng cái một, chờ từng cái trở nên healthy, rồi mới terminate các node cũ. Worker node cũng theo cùng chiến lược rolling thông qua MachineDeployment. Tôi đã áp dụng cách tiếp cận này trong môi trường production và kết quả luôn ổn định — thậm chí qua các phiên bản minor lớn, CAPI xử lý đúng thứ tự mà không cần can thiệp thủ công.
Để nâng cấp worker:
kubectl patch machinedeployment dev-cluster-md-0 \
--type merge \
-p '{"spec":{"template":{"spec":{"version":"v1.31.0"}}}}'Bước 7: Scale Worker Node
Scale chỉ là thay đổi trường replicas trên một MachineDeployment:
# Mở rộng lên 5 worker
kubectl scale machinedeployment dev-cluster-md-0 --replicas=5
# Hoặc patch theo cách khai báo
kubectl patch machinedeployment dev-cluster-md-0 \
--type merge \
-p '{"spec":{"replicas":5}}'Bước 8: Xóa Cluster
Việc xóa cũng sạch sẽ không kém. CAPI xử lý việc teardown theo đúng thứ tự — worker trước, rồi control plane, sau đó mới đến hạ tầng:
kubectl delete cluster dev-clusterĐiều này kích hoạt provider xóa tất cả AWS resource liên quan đến cluster, bao gồm EC2 instance, load balancer và VPC (nếu CAPI đã tạo). Không có resource mồ côi nào bị bỏ lại.
Dùng Cùng Quy trình Trên Bare-Metal (Metal3)
Provider bare-metal (CAPM3) hoạt động với các object BareMetalHost đại diện cho máy vật lý được đăng ký qua BMC (Baseboard Management Controller) của chúng. Khi host đã được đăng ký, quy trình hoàn toàn giống nhau — bạn viết manifest Cluster tham chiếu Metal3Cluster và Metal3MachineTemplate, apply nó, và CAPI khởi tạo cluster bằng PXE boot và cloud-init:
# Khởi tạo Metal3 provider
clusterctl init --infrastructure metal3
# Tạo cluster manifest cho bare-metal
clusterctl generate cluster prod-baremetal \
--infrastructure metal3 \
--kubernetes-version v1.30.0 \
--control-plane-machine-count 3 \
--worker-machine-count 6 \
> prod-baremetal.yamlKết hợp Lại: Một Fleet Thân thiện với GitOps
Sức mạnh thực sự của CAPI đến khi bạn lưu trữ cluster manifest trong Git và dùng công cụ như Flux hay ArgoCD để đồng bộ chúng với management cluster. Toàn bộ đội cluster — dev trên AWS, staging trên GCP, và production trên bare-metal — trở thành một tập hợp file YAML trong repository. Tạo môi trường mới chỉ là một git commit. Nâng cấp 10 cluster chỉ là thay đổi version trong Kustomize overlay. Ngừng hoạt động một cluster chỉ là xóa một file.
Pattern này loại bỏ vấn đề kiến thức chỉ nằm trong đầu một vài người. Bất kỳ kỹ sư nào trong team cũng có thể đọc repository và hiểu chính xác những cluster nào đang tồn tại, chạy phiên bản nào, và có bao nhiêu node. Management cluster liên tục thực thi trạng thái mong muốn, vì vậy configuration drift trở nên khó tích lũy hơn nhiều.
Tiếp theo Sau Đây
Bắt đầu nhỏ: khởi động một management cluster kind cục bộ và tạo một workload cluster để test bằng Docker infrastructure provider (CAPD) — không cần cloud credentials. Khi bạn đã hiểu mô hình resource, chuyển sang AWS hay GCP với máy thực. Sau đó thêm Machine Health Check để tự động thay thế node không healthy, và thiết lập ClusterClass (một tính năng CAPI mới hơn) để tạo cluster template có thể tái sử dụng, giúp các team tự phục vụ mà không cần viết YAML thô mỗi lần.
Đường cong học tập của CAPI dốc hơn so với eksctl hay GKE Autopilot, nhưng phần thưởng là một cách tiếp cận nhất quán, có thể kiểm tra và tự động hóa để quản lý hạ tầng cluster — có khả năng mở rộng cùng với đội cluster của bạn.
