Platform Engineering 3 — GitOps với Argo CD & Flux

Trong Platform Engineering — Tổng quan, golden path cần một cơ chế triển khai vừa tự phục vụ vừa kiểm soát được. IaC với Terraform lo phần tạo hạ tầng. Nhưng khi cluster Kubernetes đã có, việc đưa ứng dụng và cấu hình lên cluster và giữ chúng đúng như thiết kế lại là một bài toán riêng — và câu trả lời hiện đại nhất là GitOps. Bài này đi sâu GitOps qua hai công cụ hàng đầu: Argo CD và Flux.

GitOps là gì

GitOps là mô hình vận hành trong đó trạng thái mong muốn của hệ thống được khai báo trong Git, và một agent tự động làm cho hệ thống thật khớp với Git. Thay vì kỹ sư chạy kubectl apply bằng tay hay để CI đẩy lệnh vào cluster, mọi thay đổi đi qua một commit Git, và phần mềm sẽ tự đồng bộ.

Tổ chức OpenGitOps (thuộc CNCF) chuẩn hóa GitOps thành 4 nguyên tắc:

1. Declarative (khai báo): toàn bộ trạng thái mong muốn được mô tả một cách khai báo — bạn nói "tôi muốn gì" (3 replica, image tag v2.4.1) chứ không phải "làm các bước gì". Kubernetes manifest, Helm chart, Kustomize overlay đều là khai báo.
2. Versioned & Immutable (có phiên bản, bất biến): trạng thái mong muốn được lưu bất biến, có phiên bản, giữ lịch sử đầy đủ. Git đáp ứng chính xác điều này: mỗi commit là một ảnh chụp bất biến, có tác giả và thời điểm.
3. Pulled automatically (tự động kéo): các agent phần mềm tự động kéo trạng thái mong muốn từ nguồn khai báo — không ai phải đẩy thủ công.
4. Continuously reconciled (đối soát liên tục): agent liên tục quan sát trạng thái thật, so với trạng thái mong muốn, và hành động để hội tụ hai bên. Đây là cơ chế tự chữa (self-healing): nếu ai đó sửa tay trên cluster (drift), agent phát hiện và kéo về đúng như Git.

Điểm mấu chốt: Git là nguồn sự thật duy nhất (single source of truth). Muốn biết prod đang chạy gì, đọc Git — không cần đăng nhập cluster. Muốn thay đổi, sửa Git. Muốn rollback, git revert.

Pull-based vs push-based — vì sao pull an toàn hơn

Trong mô hình push-based truyền thống, hệ thống CI/CD nằm ngoài cluster nhận lệnh và đẩy thay đổi vào (ví dụ kubectl apply hay helm upgrade chạy trong pipeline). Trong mô hình pull-based của GitOps, một agent chạy bên trong cluster tự kéo thay đổi từ Git về.

Pull an toàn hơn ở nhiều điểm:

• Không lộ credential cluster ra ngoài: với push, CI phải nắm kubeconfig/token có quyền admin cluster; nếu CI bị xâm nhập, kẻ tấn công có chìa khóa cluster. Với pull, credential chỉ cần đọc Git repo; agent trong cluster tự dùng ServiceAccount nội bộ, không có bí mật nào rời cluster.
• Chống drift chủ động: push chỉ đồng bộ khi có pipeline chạy; giữa các lần chạy, drift tồn tại âm thầm. Pull đối soát liên tục nên phát hiện và sửa drift gần như tức thời.
• Bề mặt tấn công nhỏ hơn: cluster không cần mở endpoint cho hệ thống ngoài gọi vào; nó chủ động gọi ra Git.

Nhược điểm của pull: cần cài agent trong mỗi cluster, và phản hồi lỗi (chẳng hạn sync thất bại) không hiển thị thẳng trong pipeline CI mà nằm ở công cụ GitOps — cần tích hợp thông báo thêm.

Argo CD và Flux

Hai công cụ GitOps phổ biến nhất, đều là dự án CNCF Graduated, đều pull-based, nhưng khác nhau về triết lý trải nghiệm.

Argo CD hướng ứng dụng, có UI web mạnh trực quan hóa cây tài nguyên, trạng thái sync và health. Đơn vị trung tâm là Application — một Custom Resource (CRD) mô tả "nguồn nào trong Git" ánh xạ tới "namespace/cluster đích nào". Argo CD định nghĩa rõ hai trục trạng thái:

• Sync status: Synced (khớp Git) hay OutOfSync (đã lệch).
• Health status: Healthy, Progressing, Degraded... đánh giá tài nguyên có thực sự hoạt động tốt không (ví dụ Deployment đủ replica sẵn sàng).

Argo CD hỗ trợ mẫu app-of-apps: một Application "cha" trỏ vào thư mục chứa nhiều Application "con", cho phép bootstrap toàn bộ cluster từ một điểm.

Flux (GitOps Toolkit) theo hướng module hóa: nhiều controller nhỏ chuyên biệt lắp ghép — source-controller (theo dõi Git/Helm/OCI repo), kustomize-controller (dựng Kustomize), helm-controller (quản lý Helm release), notification-controller (thông báo & webhook), image-automation để tự cập nhật image tag. Flux thiên về API Kubernetes thuần, hợp với ai muốn "tất cả là CRD" và tự dựng UI/quy trình riêng; nó cũng là nền tảng bên dưới nhiều sản phẩm thương mại.

Cả hai đều tốt; lựa chọn phụ thuộc đội ngũ thích UI tập trung (Argo CD) hay mô hình controller thuần Kubernetes (Flux).

Luồng GitOps end-to-end

Luồng làm việc điển hình biến mỗi thay đổi triển khai thành một pull request:

1. Developer sửa manifest / Helm values / Kustomize overlay trong Git repo (thường là repo cấu hình tách khỏi repo code).
2. Mở pull request; đồng nghiệp review, CI chạy kiểm tra (lint YAML, kustomize build, policy check).
3. Merge vào nhánh đích (ví dụ nhánh cho môi trường staging).
4. Argo CD/Flux phát hiện commit mới (qua polling định kỳ hoặc webhook) và tự sync trạng thái mới vào cluster Kubernetes.
5. Agent đối soát liên tục; nếu có drift, kéo về đúng Git. Trạng thái sync/health hiển thị trên UI/CLI.

Chi tiết vận hành cluster đích — namespace, rollout, probe, resource — xem Kubernetes — Production Operations.

Rollback cực kỳ đơn giản: vì trạng thái mong muốn nằm trong Git, quay lui chỉ là git revert commit lỗi rồi để agent tự đồng bộ về phiên bản trước. Không có bước thủ công, không "nhớ xem trước đó cấu hình thế nào" — lịch sử Git chính là lịch sử triển khai.

Kết hợp với IaC: phân tầng trách nhiệm

GitOps và IaC bổ sung nhau chứ không thay thế nhau. Ranh giới thực dụng:

• Terraform/OpenTofu lo hạ tầng nền: VPC, cluster Kubernetes, node pool, database, IAM, DNS, load balancer. Đây là những thứ ít thay đổi và nằm ngoài Kubernetes. Xem IaC với Terraform.
• GitOps lo ứng dụng và cấu hình trên cluster: Deployment, Service, Ingress, ConfigMap, Helm release, cả các add-on như cert-manager hay ingress-controller. Đây là những thứ thay đổi thường xuyên và diễn đạt tự nhiên bằng Kubernetes manifest.

Một mô hình lai phổ biến: Terraform tạo cluster rồi cài sẵn Argo CD (qua Helm provider), sau đó Argo CD tự "bootstrap" phần còn lại của cluster bằng app-of-apps. Ranh giới không tuyệt đối — có thể quản lý resource cloud qua Kubernetes bằng Crossplane để đưa cả hạ tầng vào GitOps — nhưng nguyên tắc "Terraform: hạ tầng, GitOps: workload" là điểm khởi đầu tốt.

Quản lý môi trường bằng thư mục và overlay

Dev/staging/prod thường được tổ chức bằng Kustomize overlay hoặc thư mục riêng, dùng chung một base:

apps/data-api/
  base/               # manifest gốc dùng chung
  overlays/dev/       # patch: 1 replica, tài nguyên nhỏ
  overlays/staging/   # patch: 2 replica
  overlays/prod/      # patch: 4 replica, HPA, anti-affinity

Mỗi môi trường là một Argo CD Application (hoặc Flux Kustomization) trỏ vào overlay tương ứng. Đề bạt (promote) một release qua các môi trường trở thành thao tác Git thuần túy — cập nhật image tag ở overlay staging, rồi ở overlay prod — hoàn toàn có vết kiểm toán.

Ví dụ Argo CD Application manifest

Manifest dưới đây minh họa một Application đồng bộ thư mục overlay prod của một dịch vụ dữ liệu:

# Minh họa — Argo CD Application (không phải SQL, không chạy trong sandbox)
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: data-api-prod
  namespace: argocd
spec:
  project: data-platform
  source:
    repoURL: https://git.ncb.internal/platform/deploy.git
    targetRevision: main
    path: apps/data-api/overlays/prod
  destination:
    server: https://kubernetes.default.svc
    namespace: data-api
  syncPolicy:
    automated:
      prune: true       # xóa tài nguyên không còn trong Git
      selfHeal: true    # kéo về đúng Git khi có drift
    syncOptions:
      - CreateNamespace=true

Ý nghĩa các trường then chốt: source chỉ cái gì trong Git (repo, nhánh, đường dẫn); destination chỉ đưa vào cluster/namespace nào; automated.selfHeal: true bật tự chữa drift; prune: true cho phép xóa tài nguyên đã gỡ khỏi Git. Khi commit mới vào main, Argo CD dựng manifest từ overlay prod, so sánh với live, rồi đồng bộ.

Progressive delivery

GitOps trả lời "triển khai cái gì"; progressive delivery trả lời "triển khai an toàn thế nào". Thay vì thay 100% pod cùng lúc, ta phát hành từ từ và tự động lùi nếu chỉ số xấu:

• Canary: định tuyến một phần nhỏ lưu lượng (ví dụ 5% → 25% → 50% → 100%) sang phiên bản mới, theo dõi metric (tỷ lệ lỗi, độ trễ) ở từng bước; nếu vượt ngưỡng thì tự rollback.
• Blue-green: dựng song song môi trường mới (green) bên cạnh cũ (blue), chuyển toàn bộ lưu lượng một nhát khi green sẵn sàng, giữ blue để lùi nhanh.

Với Argo CD, Argo Rollouts thay Deployment bằng CRD Rollout để điều phối canary/blue-green và phân tích metric tự động (analysis). Bên Flux, vai trò này do Flagger đảm nhiệm. Các bước phân tích thường tích hợp với pipeline CI để build/test/scan image trước khi manifest chạm Git — xem CI/CD Pipelines — và với hệ quan sát để lấy tín hiệu metric quyết định thăng/lùi.

Lợi ích và cạm bẫy

Lợi ích:

• Audit trọn vẹn: mọi thay đổi triển khai là một Git commit có tác giả, thời điểm, lý do (PR), người duyệt. Với ngân hàng, đây là bằng chứng tuân thủ và tách quyền (segregation of duties) sẵn có, không cần dựng riêng.
• Tái lập: dựng lại cluster từ Git; disaster recovery trở thành "cài Argo CD rồi trỏ vào repo".
• Tự chữa & chống drift: cấu hình lệch tay bị kéo về; hệ thống luôn hội tụ về thiết kế.
• Review trước khi chạm prod: thay đổi đi qua PR, có 4-eyes principle.

Cạm bẫy cần tránh:

• Secrets trong Git: tuyệt đối không commit mật khẩu/khóa dạng thô. Dùng Sealed Secrets (mã hóa để chỉ controller trong cluster giải được), External Secrets Operator (kéo bí mật từ Vault/cloud secret manager lúc runtime), hoặc SOPS. Chi tiết ở Secrets & Security.
• Drift ngoài GitOps: nếu vẫn còn người kubectl edit tay, selfHeal sẽ "đánh nhau" với họ. Cần kỷ luật: cluster prod chỉ đổi qua Git, khóa quyền ghi trực tiếp.
• Đồng bộ nhiều cluster: quản lý hàng chục cluster cần ApplicationSet (Argo CD) hoặc mẫu tương tự để sinh Application theo generator, tránh copy-paste và lệch cấu hình giữa cluster.
• Repo config phình to & sync chậm: monorepo cấu hình quá lớn làm reconcile chậm; cân nhắc tách repo theo domain, dùng webhook thay polling.
• Trôi lệch giữa cái Git nói và cái đang chạy khi CI cũng đẩy: tránh vừa dùng GitOps vừa để pipeline kubectl apply song song — chọn một nguồn sự thật.

Use case thực tế

Bối cảnh: Đội Data Platform của NCB vận hành nhiều dịch vụ dữ liệu trên Kubernetes: data-api (API tra cứu dữ liệu khách hàng cho các phòng nghiệp vụ), serving-layer (phục vụ đặc trưng cho mô hình chấm điểm tín dụng), và vài job đồng bộ. Trước đây triển khai bằng script kubectl chạy tay từ máy kỹ sư — không ai chắc prod đang chạy đúng phiên bản nào, và mỗi lần audit nội bộ hỏi "ai đổi cấu hình rate-limit hôm 12/6" là một cuộc điều tra.

Giải pháp GitOps (số liệu ước lượng, mang tính minh họa):

• Lập repo platform/deploy với cấu trúc base + overlay cho 3 môi trường (dev/staging/prod), quản lý bởi Argo CD cài sẵn trên cluster.
• Mỗi dịch vụ là một Argo CD Application; toàn bộ gom dưới một app-of-apps để bootstrap lại cả cluster từ Git khi cần.
• Secrets kéo từ Vault qua External Secrets Operator — không byte bí mật nào nằm trong Git.
• data-api bật Argo Rollouts canary: 10% → 50% → 100%, tự phân tích tỷ lệ lỗi HTTP 5xx trong 5 phút mỗi bước, tự rollback nếu vượt 1%.

Kết quả ước lượng:

Điểm giá trị nhất với ngân hàng là audit: khi kiểm toán nội bộ hoặc thanh tra hỏi về một thay đổi trên hệ thống phục vụ dữ liệu, đội chỉ cần mở lịch sử Git — mỗi thay đổi gắn với một PR có người đề xuất và người duyệt, đúng nguyên tắc tách quyền. Nhu cầu quản trị dữ liệu rộng hơn thuộc phạm vi Governance — Tổng quan, còn nền tảng ngân hàng tổng thể xem Banking Platform.

Ghi nhớ

• GitOps = 4 nguyên tắc OpenGitOps: khai báo, có phiên bản/bất biến, tự động kéo, đối soát liên tục. Git là nguồn sự thật duy nhất.
• Pull an toàn hơn push: credential cluster không rời cluster, chống drift chủ động, bề mặt tấn công nhỏ hơn.
• Argo CD hướng ứng dụng, UI mạnh, Application CRD, app-of-apps. Flux hướng toolkit, ghép controller, thuần Kubernetes API. Cả hai đều CNCF Graduated, pull-based.
• Luồng: sửa manifest → PR review → merge → agent tự sync → đối soát liên tục. Rollback = git revert.
• Phân tầng: Terraform lo hạ tầng, GitOps lo workload/cấu hình trên K8s; môi trường qua overlay/thư mục.
• Progressive delivery (Argo Rollouts / Flagger): canary, blue-green, tự phân tích metric và rollback.
• Cạm bẫy: đừng bao giờ commit secrets thô (dùng Sealed Secrets / External Secrets); cấm sửa tay gây drift; multi-cluster dùng ApplicationSet.
• Với ngân hàng, lợi ích lớn nhất là audit và tách quyền có sẵn nhờ mọi thay đổi đều là Git commit qua PR.

Nguồn tham khảo

• OpenGitOps — Principles v1.0.0 (dự án CNCF chuẩn hóa 4 nguyên tắc GitOps)
• Argo CD Documentation — Application CRD, sync/health status, app-of-apps, ApplicationSet
• Flux Documentation — GitOps Toolkit, source/kustomize/helm/notification controller
• Argo Rollouts Documentation — canary & blue-green, analysis
• Flagger Documentation — progressive delivery cho Flux
• External Secrets Operator và Sealed Secrets (Bitnami) — quản lý bí mật ngoài Git
• CNCF Landscape — App Definition & Image Build / GitOps (danh mục dự án Graduated)