Thảm họa Sai lệch lúc 2 giờ sáng
Máy nhắn tin của tôi réo vang lúc 2:14 sáng. Một dịch vụ production quan trọng đang báo lỗi 503. Sau khi kiểm tra cụm (cluster), tôi đã tìm ra thủ phạm: cấu hình deployment không khớp với repository của chúng tôi. Một kỹ sư có ý định tốt, dưới áp lực phải sửa lỗi định tuyến, đã sử dụng kubectl edit để bỏ qua quy trình CI/CD. Họ đã giải quyết được vấn đề tức thời nhưng lại quên commit thay đổi đó ngược lại mã nguồn.
Cụm của bạn sẽ trở thành một ‘snowflake’ (độc bản và khó tái tạo) ngay thời điểm nó bị sai lệch so với mã nguồn. Trong thế giới thủ công hoặc dựa trên cơ chế đẩy (push-based), repository của bạn chỉ mang tính chất gợi ý chứ không phải là nguồn sự thật (source of truth). Chuyển hạ tầng sang GitOps đã thay đổi mọi thứ. Nó giúp đội ngũ của tôi chuyển trọng tâm từ việc đi ‘chữa cháy’ các lỗi thủ công sang sự ổn định được bình duyệt (peer-reviewed), đảm bảo chúng tôi thực sự có thể ngủ ngon giấc suốt đêm.
Tại sao FluxCD chiến thắng trong cuộc tranh luận ‘Push vs. Pull’
Jenkins và GitHub Actions thường sử dụng mô hình ‘Push’. Chúng chạy một kịch bản, thực thi kubectl apply, và hy vọng mạng không bị ngắt. Nếu cụm cluster không thể truy cập trong mười giây, lệnh đẩy sẽ thất bại và môi trường của bạn sẽ không còn đồng bộ. FluxCD đảo ngược logic này. Nó nằm bên trong cụm của bạn dưới dạng một tập hợp các controller thực hiện việc ‘kéo’ (pull) các cấu hình từ Git.
Flux giám sát repository của bạn mỗi phút. Nếu phát hiện sự sai lệch—như việc chỉnh sửa thủ công lúc 2 giờ sáng đó—nó sẽ ngay lập tức ghi đè trạng thái cụm để khớp với mã nguồn. Nó không xin phép; nó áp đặt sự thật.
Thiết lập Flux Control Plane
Để bắt đầu, bạn sẽ cần Flux CLI và một cụm Kubernetes. Dù bạn đang chạy trên GKE, EKS hay một cụm Kind cục bộ, quy trình đều giống hệt nhau. Flux CLI là công cụ tốt nhất ở đây vì nó xử lý quá trình bootstrap phức tạp, bao gồm tạo khóa SSH và triển khai controller, chỉ trong một bước duy nhất.
1. Cài đặt Flux CLI
Đối với Linux hoặc macOS, hãy sử dụng script nhanh này để lấy file thực thi:
curl -s https://fluxcd.io/install.sh | sudo bash
# Xác nhận file thực thi đã nằm trong đường dẫn path
flux --version2. Kiểm tra trước khi chạy (Pre-flight Check)
Không phải cụm nào cũng sẵn sàng cho GitOps ngay lập tức. Hãy chạy lệnh kiểm tra này để xác minh phiên bản Kubernetes và quyền RBAC của bạn:
flux check --preBootstrapping: Cung cấp “Bộ nào” cho Cụm cluster
Lệnh bootstrap là nền tảng cho thiết lập GitOps của bạn. Nó tạo một repository riêng tư (nếu chưa tồn tại), cấu hình các khóa triển khai (deployment keys) và cài đặt các Flux controller vào namespace flux-system. Đây là nơi Flux trở nên tự quản lý. Nếu bạn muốn nâng cấp chính Flux sau này, bạn chỉ cần thay đổi số phiên bản trong Git.
Xuất (Export) thông tin xác thực của bạn
Tạo một Personal Access Token (PAT) với quyền repo trên GitHub và xuất nó ra biến môi trường:
export GITHUB_TOKEN=token_cua_ban_tai_day
export GITHUB_USER=ten_dang_nhap_cua_banThực thi Bootstrap
flux bootstrap github \
--owner=$GITHUB_USER \
--repository=fleet-infra \
--branch=main \
--path=./clusters/my-cluster \
--personalSau khoảng 90 giây, bạn sẽ thấy một repo fleet-infra mới trong tài khoản của mình. Repository này giờ đây chính là bộ não của cụm cluster.
Xác định Nguồn Sự Thật của bạn
Khi bộ máy đã chạy, chúng ta cần trỏ nó tới mã nguồn ứng dụng. Flux sử dụng hai tài nguyên chính: một GitRepository (nơi chứa mã nguồn) và một Kustomization (cách áp dụng nó).
1. Kết nối Repository Ứng dụng của bạn
Yêu cầu Flux kiểm tra các thay đổi trong repo webapp-config của bạn sau mỗi 30 giây:
flux create source git webapp-repo \
--url=https://github.com/my-org/webapp-config \
--branch=main \
--interval=30s \
--export > ./clusters/my-cluster/webapp-source.yaml2. Thiết lập Chiến lược Triển khai
Tài nguyên Kustomization chính là tập hợp các chỉ dẫn thực tế. Hãy luôn sử dụng cờ --prune=true một cách triệt để. Nó đảm bảo rằng nếu bạn xóa một file YAML trong Git, Flux sẽ gỡ bỏ tài nguyên đó khỏi cụm trong vòng 5 phút. Nếu không có tính năng dọn dẹp (pruning), cụm của bạn sẽ trở thành một ‘nghĩa địa’ chứa các dịch vụ cũ và mồ côi.
flux create kustomization webapp-deploy \
--target-namespace=production \
--source=webapp-repo \
--path="./deploy/prod" \
--prune=true \
--wait=true \
--interval=5m \
--export > ./clusters/my-cluster/webapp-kustomization.yamlCommit các file này vào fleet-infra. Trong vòng vài giây, Flux sẽ kéo các chỉ dẫn mới và bắt đầu quá trình triển khai.
Kiểm tra Khả năng Thực thi
Tin tưởng nhưng phải xác minh. Tôi luôn chạy một bài ‘Chaos Test’ để chứng minh hệ thống hoạt động. Hãy tăng quy mô (scale) deployment của bạn lên 10 bản sao (replicas) theo cách thủ công bằng CLI:
kubectl scale deployment my-webapp --replicas=10 -n productionBây giờ, hãy theo dõi log của Flux hoặc đợi đến khoảng thời gian đối soát (reconciliation interval). Bạn sẽ thấy Flux phát hiện ra trạng thái cụm (10 replicas) vi phạm trạng thái trong Git (3 replicas). Nó sẽ tự động scale các pod xuống mức cũ. Đó là khoảnh khắc bạn nhận ra mình cuối cùng đã có thể tin tưởng vào hạ tầng của mình.
Cảnh báo: Phát hiện Lỗi sớm
GitOps trong môi trường production yêu cầu tính minh bạch. Bạn không cần phải liên tục kiểm tra CLI để xem việc đồng bộ có thất bại hay không. Flux tích hợp với Slack hoặc Microsoft Teams để cảnh báo cho bạn ngay khi một lập trình viên push một file YAML bị lỗi.
flux create alert-provider slack-notifier \
--type=slack \
--channel=ops-alerts \
--address=https://hooks.slack.com/services/XXXXX \
--export > ./clusters/my-cluster/slack-provider.yamlGiờ đây chúng tôi phát hiện các ‘Trạng thái Git lỗi’ ngay trong giờ làm việc. Nếu một manifest không hợp lệ, đội ngũ sẽ nhận được thông báo Slack trong vòng 15 giây sau khi merge, rất lâu trước khi nó trở thành một tình huống khẩn cấp lúc 2 giờ sáng.
Lời kết
GitOps với FluxCD biến cụm cluster của bạn thành một tấm gương phản chiếu mã nguồn. Nó loại bỏ ‘yếu tố con người’ khỏi giai đoạn triển khai, buộc mọi thay đổi phải thông qua một Pull Request được ghi chép và bình duyệt. Ban đầu có thể cảm thấy cứng nhắc. Tuy nhiên, sự nhất quán cấu hình 99,9% và khả năng kiểm tra mọi thay đổi hạ tầng khiến nó trở thành một tiêu chuẩn không thể thiếu cho các đội ngũ DevOps hiện đại.
