Crossplane trên Kubernetes: Vượt xa Terraform với Control Plane theo mô hình GitOps

Sự chuyển dịch từ Terraform sang Control Plane

Terraform đã thống trị lĩnh vực Infrastructure as Code (IaC) trong suốt một thập kỷ qua. Nó là một công cụ đáng tin cậy, nhưng hoạt động theo mô hình “push-based”. Bạn chạy một bản plan, apply các thay đổi, và quá trình kết thúc. Vấn đề là gì? Nếu một thành viên trong nhóm chỉnh sửa thủ công một security group trên AWS Console vào lúc 2 giờ sáng, Terraform sẽ không nhận ra cho đến lần thực thi thủ công tiếp theo của bạn. Đây chính là định nghĩa của hiện tượng “configuration drift” (lệch cấu hình).

Crossplane thay đổi hoàn toàn mô hình này bằng cách biến cụm Kubernetes của bạn thành một control plane toàn năng. Thay vì quản lý các file state, bạn định nghĩa hạ tầng dưới dạng Kubernetes Custom Resources (CRDs). Một controller sau đó sẽ liên tục điều phối (reconcile) các tài nguyên cloud của bạn. Nếu có gì đó thay đổi ở môi trường thực tế, Crossplane sẽ đưa nó trở lại trạng thái ban đầu. Tôi đã triển khai giải pháp này trong các môi trường production với hơn 500 tài nguyên được quản lý, giúp giữ mã nguồn hạ tầng và ứng dụng trong một pipeline GitOps thống nhất duy nhất.

Bắt đầu nhanh: Triển khai S3 Bucket trong chưa đầy 5 phút

Bạn chỉ cần một cụm Kubernetes đang hoạt động và Helm để bắt đầu. Chúng ta sẽ cài đặt Crossplane và một AWS provider cụ thể để tạo một bucket.

1. Cài đặt Crossplane

kubectl create namespace crossplane-system

helm repo add crossplane-stable https://charts.crossplane.io/stable
helm repo update

helm install crossplane --namespace crossplane-system crossplane-stable/crossplane

2. Cài đặt AWS Provider

Crossplane hiện đại sử dụng “family providers” để duy trì sự gọn nhẹ. Thay vì cài đặt mọi dịch vụ AWS, chúng ta sẽ chỉ cài đặt controller cho S3. Điều này giúp bộ nhớ tiêu thụ của controller ở mức thấp, thường dưới 150MB so với mức hơn 2GB ở các phiên bản monolithic cũ.

cat <<EOF | kubectl apply -f -
apiVersion: pkg.crossplane.io/v1
kind: Provider
metadata:
  name: provider-aws-s3
spec:
  package: xpkg.upbound.io/upbound/provider-aws-s3:v0.47.0
EOF

3. Cấu hình thông tin xác thực

Crossplane cần quyền để giao tiếp với AWS. Hãy tạo một file creds.conf chứa các key AWS của bạn, sau đó tạo một Kubernetes secret:

kubectl create secret generic aws-secret -n crossplane-system --from-file=creds=./creds.conf

cat <<EOF | kubectl apply -f -
apiVersion: aws.upbound.io/v1beta1
kind: ProviderConfig
metadata:
  name: default
spec:
  credentials:
    source: Secret
    secretRef:
      namespace: crossplane-system
      name: aws-secret
      key: creds
EOF

4. Khởi tạo tài nguyên đầu tiên

Giờ chúng ta định nghĩa bucket bằng file YAML tiêu chuẩn. Nó trông hoàn toàn giống như một manifest của Deployment hoặc Service.

cat <<EOF | kubectl apply -f -
apiVersion: s3.aws.upbound.io/v1beta1
kind: Bucket
metadata:
  name: my-crossplane-test-bucket
spec:
  forProvider:
    region: us-east-1
  providerConfigRef:
    name: default
EOF

Kiểm tra tiến độ bằng lệnh kubectl get buckets. Khi cột READY hiển thị True, bucket vật lý của bạn đã tồn tại trên AWS.

Tại sao Kubernetes là công cụ hạ tầng tốt nhất

Điểm mấu chốt không nằm ở YAML; đó là Control Loop (Vòng lặp điều khiển). Crossplane không bao giờ ngừng theo dõi. Nếu một S3 bucket bị xóa qua AWS CLI, Crossplane sẽ phát hiện ra sự sai lệch trong lần đồng bộ tiếp theo và tự động tạo lại nó. Nó cung cấp một hạ tầng tự phục hồi (self-healing) mà Terraform đơn giản là không thể sánh được nếu thiếu các công cụ tự động hóa bên ngoài.

Hạ tầng dưới dạng dữ liệu (Infrastructure as Data)

Bằng cách coi hạ tầng như các đối tượng Kubernetes, bạn có thể sử dụng các công cụ mà mình đã yêu thích. Dùng kubectl để debug, k9s để trực quan hóa, và ArgoCD để triển khai. Theo kinh nghiệm của tôi, cầu nối này giúp các lập trình viên làm chủ được tài nguyên cloud của chính họ. Họ không còn cần phải học ngôn ngữ HCL hay chờ đợi kỹ sư DevOps chạy pipeline nữa.

Mô hình Composition

Compositions là tính năng mạnh mẽ nhất của Crossplane. Chúng cho phép bạn đóng gói các tài nguyên phức tạp thành một API tùy chỉnh duy nhất. Ví dụ, bạn có thể tạo một đối tượng StandardDatabase. Khi lập trình viên tạo đối tượng đó, Crossplane sẽ tự động khởi tạo một instance RDS, các security group cần thiết và một private subnet group ở phía sau.

Sử dụng nâng cao: Quy trình GitOps

Để tận dụng tối đa Crossplane, hãy kết hợp nó với ArgoCD. Thiết lập này tạo ra một môi trường tự vận hành, nơi Git là nguồn sự thật (source of truth) duy nhất. Cấu trúc kho lưu trữ (repository) của bạn nên trông giống như thế này:

• /infra/providers/: Định nghĩa các cloud provider cần cài đặt.
• /infra/definitions/: Các Composition tùy chỉnh (các bản thiết kế).
• /apps/production/resources/: Các yêu cầu tài nguyên thực tế (các instance).

Khi bạn merge một PR để cập nhật tag của bucket, ArgoCD sẽ đồng bộ thay đổi đó vào cụm. Crossplane sau đó ngay lập tức cập nhật tài nguyên cloud. Sẽ không có các file state cục bộ bị lỗi và không cần chạy các lệnh terraform plan thủ công.

Lời khuyên thực tiễn từ kinh nghiệm thực tế

Sau khi di chuyển nhiều môi trường quy mô lớn sang Crossplane, tôi đã rút ra một vài kinh nghiệm thực tế quan trọng.

1. Sử dụng các Provider chia nhỏ (Granular)

Tránh sử dụng provider-aws “tất cả trong một”. Nó cố gắng tải hàng nghìn CRD, điều này có thể làm chậm API server của cụm. Hãy sử dụng các family provider như provider-aws-rds hoặc provider-aws-ec2 để giữ cho cụm quản lý của bạn luôn nhanh nhạy và hiệu quả.

2. Bảo mật các Secret

Crossplane ghi các dữ liệu nhạy cảm, chẳng hạn như mật khẩu cơ sở dữ liệu, vào Kubernetes Secrets. Đừng để chúng ở dạng văn bản thuần túy trong repo. Hãy sử dụng External Secrets Operator để đồng bộ các giá trị này với một kho lưu trữ bảo mật như AWS Secrets Manager hoặc HashiCorp Vault.

3. Sử dụng chính sách xóa Orphan

Theo mặc định, việc xóa một file YAML trong Kubernetes sẽ xóa tài nguyên tương ứng trên AWS. Trong quá trình di chuyển, điều này rất nguy hiểm. Hãy thêm deletionPolicy: Orphan vào thông số tài nguyên của bạn. Điều này yêu cầu Crossplane ngừng quản lý tài nguyên mà không phá hủy phần cứng thực tế trên cloud nếu file YAML bị xóa.

4. Đừng di chuyển mọi thứ cùng một lúc

Bạn không cần phải xóa code Terraform ngay lập tức. Crossplane có thể cùng tồn tại hoàn hảo với các công cụ hiện có. Hãy bắt đầu bằng cách di chuyển các tài nguyên đơn giản như SQS queue hoặc S3 bucket. Hãy để Terraform xử lý phần hạ tầng mạng nền tảng (VPC và Subnet) trong khi Crossplane xử lý các tài nguyên ứng dụng có tần suất thay đổi cao.

Chuyển sang một control plane Kubernetes-native là một bước tiến lớn hướng tới Platform Engineering thực thụ. Nó thay thế các thao tác kích hoạt thủ công bằng một hệ thống tự phục hồi hoạt động 24/7 để giữ cho hạ tầng của bạn luôn ở đúng trạng thái mong muốn.