GitOps — Mô hình vận hành khai báo dựa trên Git

1. Tổng quan

Định nghĩa: GitOps là mô hình vận hành trong đó trạng thái mong muốn (desired state) của hệ thống được mô tả một cách khai báo trong kho Git, và agent liên tục điều chỉnh (reconcile) để môi trường vận hành thực tế khớp với khai báo đó. Git đóng vai trò nguồn sự thật duy nhất (Single Source of Truth) của triển khai · cấu hình, đồng thời là cửa ngõ của mọi thay đổi.

Triển khai truyền thống là cách tiếp cận thủ tục, trong đó người vận hành đẩy (push) lệnh như kubectl apply, terraform apply từ pipeline CI hoặc shell. Với cách này, "ai đã chạy gì, khi nào, theo thứ tự nào" nằm rải rác trong log pipeline, và ngay khi người vận hành trực tiếp can thiệp trên console, trôi cấu hình (configuration drift) phát sinh — mã trong kho và trạng thái cluster thực tế lệch nhau. Khi số cluster tăng lên hàng chục và microservice lên hàng trăm, sẽ đến lúc không ai có thể trả lời chính xác "thứ đang thực sự chạy trên môi trường vận hành hiện giờ là phiên bản · cấu hình nào".

GitOps giải quyết vấn đề này bằng sự chuyển đổi góc nhìn. Nó định nghĩa lại triển khai không phải là "hành vi thực thi lệnh" mà là "quá trình hội tụ thu hẹp khoảng cách giữa trạng thái mục tiêu mô tả trong kho và trạng thái thực tế". Người vận hành không trực tiếp chạm vào cluster mà chỉ thực hiện thay đổi trên Git (Pull Request và merge), còn agent chạy bên trong cluster phát hiện thay đổi đó và tự điều chỉnh trạng thái thực tế theo mục tiêu. Kết quả là lịch sử commit Git chính là lịch sử triển khai đầy đủ và bằng chứng kiểm toán, còn việc quay lui (rollback) được quy về git revert sang commit trước.

Từ góc độ bài làm Kỹ sư chuyên nghiệp (Professional Engineer), GitOps không nên được mô tả như "một công cụ CI/CD" đơn thuần mà là mô hình vận hành kết hợp tính khai báo của IaC (hạ tầng dưới dạng mã), văn hóa quản lý phiên bản · review và phản hồi vòng kín của lý thuyết điều khiển (closed-loop control).

1.1 Bối cảnh xuất hiện và sự cần thiết

Thứ nhất, API khai báo của Kubernetes đã tạo tiền đề cho GitOps. Kubernetes vốn đã tích hợp vòng điều chỉnh (reconciliation loop) theo nguyên tắc "mô tả trạng thái mong muốn thì controller sẽ đưa trạng thái hiện tại về đúng như vậy". Có thể coi GitOps là việc ngoại hóa đầu vào (trạng thái mong muốn) của vòng điều chỉnh này ra Git, nên nó định hình một cách tự nhiên trong hệ sinh thái Kubernetes.

Thứ hai là vấn đề trôi cấu hình và không thể tái lập. Nếu con người vá khẩn cấp trên console mà không để lại ghi chép, khi khôi phục thảm họa hoặc dựng lại cluster sẽ không thể tái lập trạng thái đó. Trong GitOps, mọi thay đổi đều đi qua Git, nên chỉ cần có kho là có thể tái dựng toàn bộ cluster một cách tất định.

Thứ ba là yêu cầu bảo mật · quản trị. Cách push cấp quyền ghi rộng trên cluster vận hành cho máy chủ CI hoặc nhiều lập trình viên có bề mặt tấn công lớn. Cách pull của GitOps do agent bên trong cluster kéo (pull) kho về, nên không cần giữ thông tin xác thực cluster ở bên ngoài, phù hợp với nguyên tắc đặc quyền tối thiểu.

2. Bốn nguyên tắc của GitOps và vòng điều chỉnh

Bốn nguyên tắc của GitOps do Weaveworks đề xuất và cộng đồng OpenGitOps (CNCF) hệ thống hóa đã cô đọng bản chất của mô hình này. Không nên chỉ liệt kê nguyên tắc mà phải hiểu bằng cách liên kết xem mỗi nguyên tắc giải quyết các vấn đề trôi cấu hình · tái lập · bảo mật nêu trên như thế nào.

graph LR
  DEV["Lập trình viên"] -->|"Pull Request / merge"| GIT["Kho Git (desired state)"]
  GIT -->|"Phát hiện thay đổi (pull)"| AGENT["Agent GitOps (bộ điều chỉnh)"]
  AGENT -->|"apply / sync"| CLUSTER["Cluster vận hành (actual state)"]
  CLUSTER -->|"Quan sát trạng thái hiện tại"| AGENT
  AGENT -->|"Cảnh báo/tự phục hồi khi phát hiện drift"| GIT

Điểm cốt lõi trong hình trên là hướng mũi tên agent kéo kho về và vòng kín đọc lại trạng thái cluster để so sánh với mục tiêu. Hai đặc tính này là khác biệt mang tính quyết định giữa CI/CD kiểu push và GitOps.

Thứ nhất, khai báo (Declarative). Trạng thái mong muốn của hệ thống được mô tả dưới dạng kết quả "phải là gì" chứ không phải thủ tục "tạo ra như thế nào". Tiêu biểu là manifest YAML, Helm chart, overlay Kustomize; khác với script thủ tục, chúng bảo đảm tính lũy đẳng (idempotency) — áp dụng bao nhiêu lần cũng cho cùng kết quả.

Thứ hai, quản lý phiên bản · bất biến (Versioned and Immutable). Trạng thái mong muốn được lưu trong Git nên mọi thay đổi đều được ghi thành commit, và mỗi phiên bản được bảo toàn bất biến. Vì vậy "ai, khi nào, vì sao thay đổi" được ghi lại trong thông điệp commit · review PR, bảo đảm khả năng kiểm toán, và việc khôi phục về một thời điểm cụ thể được quy về checkout commit.

Thứ ba, tự động kéo về (Pulled Automatically). Agent định kỳ thăm dò (polling) kho hoặc phát hiện qua webhook để tự lấy thay đổi về. Vì hệ thống bên ngoài không đẩy vào cluster nên thông tin xác thực cluster không cần lộ ra bên ngoài.

Thứ tư, liên tục điều chỉnh (Continuously Reconciled). Agent lặp lại việc quan sát trạng thái thực tế để phát hiện khác biệt với mục tiêu, và ngay cả khi con người thay đổi thủ công trên console gây ra trôi cấu hình, nó vẫn phát hiện để cảnh báo hoặc tự động phục hồi về trạng thái mục tiêu. Đặc tính tự phục hồi (self-healing) này kìm hãm tận gốc vấn đề trôi cấu hình.

3. Kiến trúc và chiến lược triển khai

Kiến trúc GitOps thường tách kho mã nguồn ứng dụng và kho cấu hình (manifest). CI của kho mã nguồn build · kiểm thử image container, đẩy lên registry và cập nhật tag, rồi phản ánh tag image đó vào manifest của kho cấu hình (commit tự động). Sau đó agent phụ trách triển khai phát hiện thay đổi của kho cấu hình và phản ánh lên cluster. Như vậy, tách CI (build · kiểm chứng) và CD (triển khai · điều chỉnh) theo ranh giới kho là cấu trúc điển hình của GitOps.

flowchart TD
  subgraph CI["Vùng CI (push)"]
    SRC["Kho mã nguồn ứng dụng"] --> BUILD["Build · kiểm thử"]
    BUILD --> IMG["Registry image container"]
    IMG --> UPD["Cập nhật tag image (commit tự động)"]
  end
  subgraph CD["Vùng CD (pull)"]
    UPD --> CFG["Kho manifest cấu hình"]
    CFG --> ARGO["Agent điều chỉnh (ArgoCD · Flux)"]
    ARGO --> K8S["Cluster vận hành"]
    K8S -.->|"So sánh trạng thái · phát hiện drift"| ARGO
  end

Các công cụ tiêu biểu là Argo CD và Flux, cả hai đều là dự án đã tốt nghiệp (Graduated) của CNCF. Argo CD mạnh về giao diện web trực quan hóa trạng thái ứng dụng và quản lý đa cluster, còn Flux mạnh về controller nhẹ · mô-đun dựa trên GitOps Toolkit cùng tự động hóa Helm · image. Dù chọn bên nào, nguyên lý hoạt động cốt lõi (lấy Git làm mục tiêu, nhìn cluster làm thực tế rồi điều chỉnh) là như nhau.

Về chiến lược triển khai, GitOps kết hợp với triển khai lũy tiến (progressive delivery) để kiểm soát rủi ro. Khai báo triển khai canary · blue-green bằng manifest, và các controller như Argo Rollouts hay Flagger quan sát chỉ số (tỷ lệ lỗi · độ trễ) để chuyển lưu lượng theo từng bước. Ví dụ, trước hết cho 5% lưu lượng vào phiên bản mới, nếu trong 5 phút tỷ lệ lỗi không vượt ngưỡng thì mở rộng 25%→50%→100%, còn nếu vượt thì tự động rollback về trạng thái commit trước. Lúc này, việc rollback không phải là "thủ tục riêng để quay về image cũ" mà là git revert chính là lợi thế vận hành của GitOps.

4. So sánh với CI/CD kiểu push

Để hiểu chính xác GitOps, phải chỉ ra khác biệt với pipeline kiểu push hiện có đến tận lý do vì sao có khác biệt. Hai cách khác nhau căn bản về chủ thể và hướng triển khai, cũng như ranh giới tin cậy.

Cốt lõi của khác biệt là vị trí của ranh giới tin cậy. Với cách push, thông tin xác thực cluster thường trú trong hệ thống CI, nên nếu CI bị xâm phạm thì toàn bộ môi trường vận hành gặp nguy hiểm. Với GitOps, thông tin xác thực chỉ ở bên trong cluster và hướng là kéo từ trong ra ngoài, nên chính con đường để thao tác trực tiếp cluster từ bên ngoài biến mất. Ngoài ra, với cách push, nếu con người chạm vào console sau khi triển khai thì không có cơ chế ngăn trôi cấu hình, còn với GitOps, vòng điều chỉnh luôn hoạt động nên trôi cấu hình được khôi phục nguyên trạng ngay. Tuy nhiên GitOps không vượt trội trong mọi tình huống; các tác vụ không lũy đẳng · mệnh lệnh mà thứ tự và chuyển trạng thái quan trọng, như di trú lược đồ DB, phải được bổ sung bằng thủ tục riêng hoặc công cụ migration.

5. Chuyên sâu — Thách thức thực tế khi áp dụng và xu hướng mới nhất

Thứ nhất, vấn đề quản lý secret. Nếu để manifest ở dạng văn bản thô trong Git thì mật khẩu · token bị lộ, nên phải thiết kế kèm Sealed Secrets (commit dưới dạng mã hóa, chỉ giải mã trong cluster), External Secrets Operator (liên kết Vault · kho secret của đám mây), SOPS v.v. Hài hòa giữa nguyên tắc "mọi thứ trong Git" và yêu cầu bảo mật "không để bí mật trong Git" là bài toán khó cốt lõi trong thực tế.

Thứ hai, khả năng quan sát trôi cấu hình. Tự động phục hồi không phải lúc nào cũng đáng mong muốn; agent có thể hoàn nguyên cả những thay đổi tạm thời mà kỹ sư cố ý thực hiện trong lúc ứng phó sự cố, gây hỗn loạn. Vì vậy phải thiết kế đồng bộ tự động (auto-sync), phê duyệt thủ công và cửa sổ đồng bộ (sync window) phù hợp với tình huống.

Thứ ba, mở rộng đa cluster · đa tenant. Để quản lý đồng thời cấu hình chung và khác biệt theo môi trường trên hàng chục cluster, cần thiết kế giảm trùng lặp cấu hình bằng overlay Kustomize, tách giá trị Helm, mẫu App-of-Apps, ApplicationSet v.v.

Về xu hướng mới nhất, nổi bật là kết hợp với quản trị dựa trên chính sách. Đưa các policy engine như OPA/Gatekeeper · Kyverno vào pipeline điều chỉnh để chặn trước khi triển khai các image chưa được phê duyệt hoặc manifest vi phạm chính sách bảo mật. Ngoài ra, gắn với bảo mật chuỗi cung ứng phần mềm, xu hướng tích hợp chữ ký commit (Sigstore · cosign) và kiểm chứng chữ ký image vào luồng GitOps để bảo đảm "thứ được triển khai có phải là sản phẩm đã kiểm chứng hay không" đang được tăng cường. Hơn nữa, GitOps đang trưởng thành theo hướng mặt phẳng điều khiển dựa trên Crossplane quản lý bằng GitOps không chỉ ứng dụng mà cả chính cluster · hạ tầng đám mây, và kết hợp với khả năng quan sát (Observability) để theo dõi kết quả điều chỉnh và trôi cấu hình trên dashboard.

6. Những điểm cần cân nhắc và hàm ý (góc nhìn Kỹ sư chuyên nghiệp)

• Chiến lược áp dụng: Thay vì bật tự động phục hồi toàn diện ngay từ đầu, áp dụng lũy tiến — bắt đầu từ giai đoạn phát hiện · cảnh báo trôi cấu hình (chỉ đọc), rồi mở rộng sang đồng bộ tự động sau khi tổ chức đã quen với luồng GitOps — là an toàn. Cần xác lập sớm việc tách kho mã nguồn và kho cấu hình, chiến lược nhánh · thư mục theo môi trường.
• Đánh đổi: Mọi thay đổi đều đi qua Git · PR nên khi có sự cố khẩn cấp tốc độ có thể bị giảm. Để khắc phục, cần thiết kế kèm đường khẩn cấp nới lỏng phê duyệt (break-glass) và thủ tục kiểm toán sau đó, nhằm cân bằng giữa kiểm soát và tính nhanh chóng.
• Bảo mật · quản trị: Nhờ loại bỏ việc ngoại hóa thông tin xác thực cluster, chữ ký commit · image và kết hợp policy engine, GitOps liên kết tự nhiên với bảo mật chuỗi cung ứng (SBOM · DevSecOps). Vì bản thân kho Git trở thành mục tiêu tấn công hàng đầu, kiểm soát truy cập kho · chữ ký · nhánh được bảo vệ là bắt buộc.
• Tổ chức · văn hóa: GitOps không phải là đưa vào một công cụ mà là sự chuyển đổi văn hóa cộng tác "vận hành bằng review mã". Vì phát triển · vận hành · bảo mật cùng cộng tác trên một kho, hiệu quả được tối đa hóa khi kết hợp với DevOps · SRE · kỹ thuật nền tảng (platform engineering).
• Triển vọng và liên kết: Mô hình điều chỉnh khai báo đang có xu hướng mở rộng vượt ra ngoài Kubernetes tới hạ tầng đám mây · edge · pipeline AI. Kết hợp với IaC · kỹ thuật nền tảng · quản trị dựa trên chính sách, GitOps được dự báo sẽ trở thành hạ tầng nền tảng cho vận hành tự chủ (autonomous operations).

Tóm tắt một câu: GitOps là mô hình vận hành lưu trạng thái mong muốn một cách khai báo trong Git và để agent trong cluster liên tục điều chỉnh trạng thái thực tế (pull · self-healing), hiện thực hóa triển khai an toàn, có thể tái lập nhờ kìm hãm trôi cấu hình, khả năng kiểm toán đầy đủ, giảm tối đa lộ thông tin xác thực và rollback bằng git revert.