Khắc phục sự cố Terraform State trong môi trường Hybrid
Terraform state file là nguồn sự thật duy nhất về hạ tầng. Trong môi trường Hybrid (Proxmox + AWS), state file thường bị phân mảnh hoặc xung đột khi nhiều người cùng thao tác hoặc khi mất kết nối mạng giữa các node.
Xác định và giải quyết xung đột state bằng cách khóa file (locking) và kiểm tra trạng thái đồng bộ.
Trước tiên, kiểm tra xem state file hiện tại có bị khóa không (corrupted lock) trên backend S3 (AWS) hoặc file local.
terraform force-unlock -state=terraform.tfstate
Lệnh này buộc mở khóa state file. là ID của lock bị treo, bạn có thể tìm thấy trong log lỗi Terraform hoặc trong S3 bucket tại key tfstate/lock.
Thao tác này chỉ thực hiện khi chắc chắn không có quá trình Terraform nào đang chạy song song. Nếu có, hãy đợi hoặc kill process đó trước.
Để kiểm tra sự không đồng bộ giữa state file và thực tế (ví dụ: VM Proxmox bị xóa thủ công nhưng vẫn còn trong state), hãy chạy lệnh refresh.
terraform refresh -state=terraform.tfstate
Thao tác này cập nhật state file theo thực tế mà không thay đổi cấu hình (plan). Kết quả mong đợi là Terraform sẽ liệt kê các tài nguyên đã bị thay đổi hoặc mất đi so với state.
Để xác định chính xác tài nguyên nào bị lệch, hãy dùng lệnh plan với cờ out để xuất file kế hoạch.
terraform plan -out=tfplan -state=terraform.tfstate
File tfplan được tạo ra chứa chi tiết các hành động Terraform dự định thực hiện để đưa state về đồng bộ với config.
Kiểm tra file plan để đảm bảo không có hành động "destroy" không mong muốn.
terraform show tfplan
Kết quả mong đợi: Bạn thấy danh sách các tài nguyên sẽ được tạo, sửa hoặc xóa. Nếu thấy VM Proxmox hoặc EC2 AWS bị đánh dấu xóa trong khi vẫn đang chạy, hãy kiểm tra lại cấu hình hoặc restore từ backup.
Trong trường hợp state file bị hỏng nặng (corrupted) không thể sửa, cần phải tách tài nguyên ra khỏi state (dismove) hoặc xóa khỏi state.
terraform state rm module.aws_instance.main
Lệnh này xóa một tài nguyên cụ thể khỏi state file mà không xóa tài nguyên đó khỏi hạ tầng thực tế (Proxmox/AWS).
Chạy terraform refresh ngay sau đó để Terraform nhận diện lại tài nguyên đó và cập nhật lại state.
Verify kết quả bằng cách chạy terraform plan. Kết quả phải là "No changes. Infrastructure is up-to-date".
Debug lỗi kết nối Crossplane với Proxmox và AWS
Crossplane hoạt động dựa trên Provider (Controller) để giao tiếp với hạ tầng. Lỗi thường gặp là Controller không thể connect đến API Proxmox hoặc AWS do vấn đề mạng, xác thực (Auth), hoặc cấu hình Secret.
Kiểm tra trạng thái của Provider trong Kubernetes cluster.
kubectl get providers -A
Kết quả mong đợi: Trạng thái (STATE) phải là Healthy. Nếu thấy NotReady hoặc Failed, hãy tiến hành debug.
Xem log chi tiết của Pod chứa Provider (thường nằm trong namespace crossplane-system).
kubectl logs -l crossplane.io/provider=provider-aws -n crossplane-system --tail=50
Thay provider-aws bằng provider-proxmox nếu đang debug Proxmox. Log sẽ hiển thị lỗi kết nối, lỗi token, hoặc lỗi định dạng API.
Trong môi trường Hybrid, lỗi phổ biến là Proxmox API không thể truy cập từ trong Pod Kubernetes do firewall hoặc DNS.
Thử nghiệm kết nối trực tiếp từ Pod vào API Proxmox để kiểm tra mạng.
kubectl run -it --rm debug-pod --image=curlimages/curl --restart=Never -- curl -k https://:8006/api2/json/nodes
Thay -k bỏ qua lỗi chứng chỉ tự ký (self-signed) thường thấy ở Proxmox.
Kết quả mong đợi: Trả về JSON chứa danh sách node. Nếu lỗi Connection refused hoặc timeout, kiểm tra firewall (iptables/ufw) trên Proxmox và CNI của Kubernetes.
Kiểm tra tính hợp lệ của Secret chứa credential (AWS Access Key hoặc Proxmox API Token).
kubectl get secret aws-creds -n crossplane-system -o yaml
Đảm bảo key trong Secret (ví dụ: access-key-id, secret-access-key) khớp với cấu hình trong file YAML của ManagedProvider hoặc ProviderConfig.
Để debug sâu hơn, bật chế độ debug của Crossplane Controller.
kubectl patch deployment crossplane -n crossplane-system --patch '{"spec":{"template":{"spec":{"containers":[{"name":"crossplane","env":[{"name":"LOG_LEVEL","value":"debug"}]}}]}}}'
Thao tác này thêm biến môi trường LOG_LEVEL=debug vào container Crossplane. Sau khi áp dụng, Pod sẽ restart và log sẽ chi tiết hơn rất nhiều.
Verify kết quả: Chạy lại kubectl logs và quan sát log mới. Bạn sẽ thấy chi tiết quá trình handshake với API Proxmox/AWS.
Chiến lược tối ưu chi phí và hiệu năng cho Workload Hybrid
Môi trường Hybrid cho phép bạn đặt workload lên Proxmox (on-premise, chi phí thấp, hiệu năng cao) hoặc AWS (cloud, linh hoạt, chi phí cao). Tối ưu hóa là việc cân bằng tải và chi phí dựa trên đặc điểm workload.
Sử dụng Crossplane để định nghĩa "Placement Policy" hoặc "Scheduling Logic" thông qua Composite Resource (XRM). Đây là cách trừu tượng hóa việc chọn hạ tầng.
Tạo file config để định nghĩa một ManagedCluster có thể tự động chọn Proxmox cho workload tĩnh và AWS cho workload biến động.
cat > /etc/crossplane/hybrid-placement.yaml
File này định nghĩa logic: Workload "compute-intensive" (xử lý nặng) ưu tiên Proxmox để tiết kiệm chi phí cloud, trong khi "web-frontend" (biến động) dùng AWS để scale tự động.
Để tối ưu hiệu năng mạng giữa Proxmox và AWS, hãy sử dụng Direct Connect (AWS) hoặc IPsec VPN với đường dẫn ưu tiên.
Cấu hình Route Policy trong Proxmox để chuyển hướng lưu lượng qua đường truyền riêng.
cat > /etc/network/interfaces.d/proxmox-aws-route
Thao tác này thêm route tĩnh cho subnet AWS (10.0.0.0/16) qua gateway VPN. Metric 100 đảm bảo ưu tiên cao hơn route default nếu có.
Áp dụng cấu hình mạng.
systemctl restart networking
Kết quả mong đợi: Kiểm tra bảng định tuyến bằng ip route để thấy route mới được thêm vào.
Tối ưu chi phí AWS bằng cách sử dụng Spot Instances cho các workload không quan trọng (non-critical) và On-Demand cho workload quan trọng.
Cấu hình ManagedInstance trong Crossplane để chỉ định loại instance.
cat > /etc/crossplane/spot-instance.yaml
Tham số spotPrice cho phép Crossplane yêu cầu Spot Instance. Nếu giá thị trường vượt quá 0.08, instance sẽ bị AWS kill, do đó cần có cơ chế tự động restart hoặc failover sang On-Demand.
Verify kết quả bằng cách xem log của Crossplane hoặc kiểm tra AWS Console để thấy instance được tạo với loại Spot.
Best Practices và Hướng phát triển
Tổng hợp các quy tắc vàng để vận hành nền tảng Multi-Cloud Hybrid bền vững.
- State Management: Luôn sử dụng Remote Backend (S3 + DynamoDB) cho Terraform state để tránh xung đột. Không bao giờ lưu state file trên local disk trong CI/CD.
- Secret Rotation: Tự động hóa việc làm mới token API Proxmox và AWS Credentials hàng tháng bằng công cụ như Vault hoặc External Secrets Operator.
- Immutable Infrastructure: Không bao giờ sửa đổi cấu hình trên VM đang chạy. Luôn dùng Terraform hoặc Crossplane để tạo mới và thay thế.
- Drift Detection: Thiết lập job Cron để chạy
terraform plan hàng ngày và gửi cảnh báo nếu phát hiện drift (sai lệch) giữa state và thực tế.
Hướng phát triển tiếp theo cho nền tảng này bao gồm tích hợp AI/ML để dự báo scaling tự động và chuyển đổi sang GitOps hoàn toàn cho mọi thay đổi hạ tầng.
Để triển khai GitOps nâng cao, hãy cấu hình ArgoCD để tự động sync các Manifest từ Git repo vào Crossplane khi có commit mới.
cat > /etc/argocd/app-sync-policy.yaml
File này cấu hình ArgoCD để tự động phát hiện thay đổi trong thư mục crossplane-manifests và áp dụng ngay lập tức vào cluster.
Verify kết quả: Push một file YAML mới vào repo, sau đó xem dashboard ArgoCD. Trạng thái Application sẽ chuyển từ OutOfSync sang Synced và Healthy trong vài giây.
Điều hướng series:
Mục lục: Series: Series: Xây dựng nền tảng Multi-Cloud Hybrid với Terraform, Crossplane và GitOps trên hạ tầng Proxmox và AWS
« Phần 9: Giám sát, logging và cảnh báo cho môi trường Hybrid