Quản Lý Kubernetes chuyên nghiệp Với Argo CD & Flux CD

Trong thế giới phát triển phần mềm hiện đại, việc triển khai ứng dụng lên Kubernetes ngày càng trở nên phổ biến. Tuy nhiên, việc quản lý cấu hình, cập nhật ứng dụng và đảm bảo trạng thái cluster luôn đồng nhất là một thách thức không nhỏ. Đây là lúc GitOps xuất hiện như một “người hùng”, mang lại một phương pháp tiếp cận mạnh mẽ và đáng tin cậy hơn nhiều so với CI/CD truyền thống.

Bài viết này sẽ đi sâu vào GitOps, giải thích tại sao nó lại được coi là “tương lai” của việc triển khai ứng dụng lên Kubernetes, và quan trọng nhất, chúng ta sẽ cùng nhau thực hành triển khai và quản lý Kubernetes cluster của mình bằng hai công cụ GitOps hàng đầu: Argo CD và Flux CD. Hãy cùng mình bắt tay vào hành trình này nhé!

I. CI/CD Truyền Thống và Những Nỗi “Đau Đầu”

Trước khi nói về GitOps, chúng ta hãy nhìn lại CI/CD (Continuous Integration/Continuous Delivery) truyền thống một chút. Trong mô hình này:

CI (Tích hợp liên tục): Developer commit code lên Git, CI pipeline (ví dụ: Jenkins, GitLab CI, GitHub Actions) sẽ tự động build, chạy test, tạo artifact (Docker image).
CD (Triển khai liên tục): Sau khi artifact được tạo, CD pipeline sẽ “đẩy” (push) các thay đổi này vào môi trường. Điều này thường bao gồm việc chạy kubectl apply -f hoặc Helm commands từ chính pipeline CI/CD.

Vậy, vấn đề ở đây là gì?

Trạng thái “trôi dạt” (Configuration Drift): Các thay đổi có thể được áp dụng thủ công trực tiếp lên cluster mà không thông qua pipeline, dẫn đến sự khác biệt giữa cấu hình thực tế trên cluster và cấu hình trong Git. Điều này gây khó khăn trong việc gỡ lỗi và phục hồi.
Vấn đề bảo mật: Pipeline CI/CD cần có quyền truy cập rất cao vào Kubernetes cluster để deploy ứng dụng. Nếu pipeline bị xâm nhập, toàn bộ cluster có thể gặp rủi ro.
Auditability (Khả năng kiểm toán): Khó theo dõi ai đã triển khai cái gì, khi nào, và tại sao, đặc biệt khi các thao tác được thực hiện thủ công hoặc từ các script phức tạp trong pipeline.
Phục hồi thảm họa: Việc tái tạo lại một cluster từ đầu và đưa nó về trạng thái mong muốn có thể rất phức tạp và tốn thời gian nếu không có một nguồn đáng tin cậy duy nhất cho tất cả cấu hình.

II. GitOps: Khi Git Trở Thành Nguồn Chân Lý Duy Nhất

GitOps là một phương pháp vận hành cơ sở hạ tầng sử dụng Git làm nguồn chân lý duy nhất (Single Source of Truth) cho tất cả các cấu hình, trạng thái mong muốn của hệ thống. Thay vì “đẩy” thay đổi từ pipeline CI/CD, GitOps dựa vào một Operator chạy bên trong cluster Kubernetes để “kéo” (pull) các thay đổi từ Git và áp dụng chúng.

Các nguyên tắc cốt lõi của GitOps:

Toàn bộ hệ thống được mô tả một cách khai báo: Tất cả mọi thứ, từ ứng dụng, cấu hình, cho đến cơ sở hạ tầng (nếu dùng IaC) đều được mô tả bằng các file khai báo (declarative files) và lưu trữ trong Git.
Trạng thái mong muốn được phiên bản hóa trong Git: Bất kỳ thay đổi nào đối với hệ thống đều phải được thực hiện thông qua một pull request (PR) trên Git. Lịch sử của Git trở thành lịch sử của các thay đổi hệ thống.
Thay đổi được tự động áp dụng (pulled): Một phần mềm (GitOps Operator) chạy trong cluster sẽ liên tục theo dõi Git repository. Khi phát hiện thay đổi, nó sẽ tự động “kéo” về và áp dụng để đảm bảo trạng thái cluster khớp với trạng thái trong Git.
Các agent đảm bảo sự đối chiếu (reconciliation): Operator sẽ liên tục kiểm tra xem trạng thái thực tế của cluster có khớp với trạng thái mong muốn trong Git hay không. Nếu có sự “trôi dạt” (drift), nó sẽ tự động điều chỉnh lại.

Lợi ích của GitOps:

Tăng tốc độ triển khai: Quy trình tự động hóa hoàn toàn.
Độ tin cậy cao: Giảm thiểu lỗi do con người, dễ dàng rollback về trạng thái trước đó.
An toàn hơn: Pipeline CI/CD không cần quyền truy cập cao vào cluster. Operator trong cluster chỉ cần quyền đọc từ Git.
Khả năng kiểm toán (Auditability) mạnh mẽ: Lịch sử Git cung cấp đầy đủ thông tin về mọi thay đổi.
Dễ phục hồi thảm họa: Chỉ cần một cluster mới và cấu hình GitOps, hệ thống có thể được tái tạo nhanh chóng.

III. Các Công Cụ GitOps Hàng Đầu: Argo CD và Flux CD

Trong thế giới Kubernetes, hai công cụ phổ biến nhất triển khai GitOps là Argo CD và Flux CD. Cả hai đều là dự án của Cloud Native Computing Foundation (CNCF), mạnh mẽ và có những điểm mạnh riêng.

A. Argo CD

Điểm nổi bật: Giao diện người dùng (UI) trực quan, dễ sử dụng, cung cấp cái nhìn tổng quan rất tốt về trạng thái ứng dụng và cluster.
Cách hoạt động: Argo CD hoạt động như một Kubernetes controller liên tục theo dõi các ứng dụng được định nghĩa trong Git. Khi có thay đổi, nó sẽ tự động đồng bộ trạng thái mong muốn từ Git vào cluster.
Các tính năng chính:
- Application CRD: Định nghĩa ứng dụng Kubernetes bằng một Custom Resource Definition (CRD) riêng.
- UI Dashboard: Giao diện web đẹp mắt để quản lý, giám sát và khắc phục sự cố ứng dụng.
- Automatic Sync/Manual Sync: Tự động hoặc đồng bộ thủ công.
- Health Checks: Theo dõi sức khỏe của các tài nguyên Kubernetes.
- Rollback: Dễ dàng quay lại các phiên bản trước.
- PreSync/Sync/PostSync Hooks: Thực thi các script trước/trong/sau quá trình đồng bộ.
- ApplicationSet CRD: Quản lý nhiều ứng dụng/dự án từ một nguồn duy nhất.

B. Flux CD

Điểm nổi bật: Tập trung vào CLI (Command Line Interface), kiến trúc modular, và tích hợp sâu hơn với các yếu tố GitOps khác như quản lý image (Image Automation).
Cách hoạt động: Flux CD cũng là một tập hợp các controller chạy trong cluster, giám sát Git repo và các Image Registry.
Các tính năng chính:
- GitRepository & Kustomization/HelmRelease CRDs: Các CRD riêng để định nghĩa nguồn Git và cách triển khai Kustomize/Helm.
- Image Automation: Tự động cập nhật các thẻ (tag) của Docker image trong Git khi có image mới trên registry.
- Event-driven: Có thể cấu hình để phản ứng với webhook từ Git repo.
- Modularity: Các thành phần riêng biệt cho từng nhiệm vụ (source, kustomize, helm, notification, image-reflector-controller, image-automation-controller).

C. So sánh nhanh Argo CD vs. Flux CD

Đặc điểm	Argo CD	Flux CD
Giao diện người dùng	Rất mạnh mẽ, trực quan, dễ sử dụng.	Chủ yếu CLI, có giao diện dạng plugin cho Grafana.
Kiến trúc	Monolithic hơn (một controller chính).	Modular (nhiều controller nhỏ).
Ưu điểm nổi bật	Trực quan, dễ onboarding, nhanh chóng xem trạng thái.	Linh hoạt, mạnh về tự động hóa image, CLI focused.
Trường hợp sử dụng	Phù hợp cho đội nhóm cần UI mạnh, visibility cao.	Phù hợp cho đội nhóm thích CLI, tự động hóa sâu.

IV. LAB THỰC HÀNH: TRIỂN KHAI VÀ QUẢN LÝ KUBERNETES VỚI GITOPS

Để bài viết này không chỉ là lý thuyết suông, chúng ta sẽ cùng nhau thực hành triển khai GitOps với cả Argo CD và Flux CD trên một Kubernetes cluster cục bộ.

Yêu cầu môi trường Lab:

Docker Desktop (có kèm Kubernetes) hoặc minikube/kind: Để chạy một Kubernetes cluster cục bộ.
kubectl: Công cụ dòng lệnh để tương tác với Kubernetes.
git: Để làm việc với Git repository.
Tài khoản GitHub/GitLab: Chúng ta sẽ cần một repository công khai để lưu trữ cấu hình Kubernetes.
Editor: VS Code hoặc bất kỳ trình soạn thảo mã nào bạn thích.

Cấu trúc Repo GitOps mẫu:

Mình sẽ sử dụng một cấu trúc repo đơn giản như sau (tạo một repo mới trên GitHub/GitLab và clone về máy):

my-gitops-repo/
├── applications/
│   ├── guestbook/
│   │   ├── base/
│   │   │   ├── deployment.yaml
│   │   │   └── service.yaml
│   │   └── overlays/
│   │       ├── dev/
│   │       │   └── kustomization.yaml
│   │       └── prod/
│   │           └── kustomization.yaml
├── infrastructure/
│   └── argocd/
│       └── argocd-install.yaml
└── flux/
    └── flux-install.yaml

Tạo files ứng dụng mẫu guestbook (trong applications/guestbook/base/):

deployment.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: guestbook-app
  labels:
    app: guestbook
spec:
  selector:
    matchLabels:
      app: guestbook
  replicas: 1
  template:
    metadata:
      labels:
        app: guestbook
    spec:
      containers:
      - name: guestbook-app
        image: k8s.gcr.io/echoserver:1.4 # Hoặc một image đơn giản khác
        ports:
        - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: guestbook-service
spec:
  selector:
    app: guestbook
  ports:
  - port: 80
    targetPort: 8080
    protocol: TCP
  type: LoadBalancer # Hoặc NodePort nếu không có LoadBalancer

kustomization.yaml (trong applications/guestbook/overlays/dev/):

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- ../../base
patchesStrategicMerge:
- deployment-patch.yaml

deployment-patch.yaml (trong applications/guestbook/overlays/dev/):

apiVersion: apps/v1
kind: Deployment
metadata:
  name: guestbook-app
spec:
  replicas: 2 # Override replicas cho môi trường dev

kustomization.yaml (trong applications/guestbook/overlays/prod/):

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- ../../base
patchesStrategicMerge:
- deployment-patch.yaml

deployment-patch.yaml (trong applications/guestbook/overlays/prod/):

apiVersion: apps/v1
kind: Deployment
metadata:
  name: guestbook-app
spec:
  replicas: 3 # Override replicas cho môi trường prod

Sau khi tạo các file này, hãy commit và push tất cả lên Git repository của bạn.

LAB 1: GitOps với Argo CD cơ bản và Quản lý Đa Môi Trường

Trong lab này, chúng ta sẽ cài đặt Argo CD và cấu hình nó để triển khai ứng dụng guestbook của chúng ta cho môi trường dev.

Bước 1: Khởi động Kubernetes Cluster

Nếu bạn dùng Docker Desktop, hãy đảm bảo Kubernetes đã được bật. Nếu dùng minikube/kind:

minikube start # Hoặc kind create cluster

Bước 2: Cài đặt Argo CD

Sử dụng kubectl để cài đặt Argo CD.

kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

Chờ một vài phút để các Pod của Argo CD khởi động hoàn toàn.

Bước 3: Truy cập Argo CD UI

Mặc định, service argocd-server có kiểu ClusterIP. Chúng ta sẽ port-forward để truy cập UI.

kubectl port-forward svc/argocd-server -n argocd 8080:443

Mở trình duyệt và truy cập https://localhost:8080. Bạn sẽ thấy giao diện đăng nhập.

Lấy mật khẩu admin:

kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d; echo

Đăng nhập với username admin và mật khẩu vừa lấy được.

Bước 4: Tạo ứng dụng `guestbook-dev` trong Argo CD

Trong Argo CD UI, click vào + New App.

Hoặc sử dụng argocd cli (cài đặt argocd cli nếu chưa có: brew install argocd hoặc theo hướng dẫn trên trang chủ Argo CD).

argocd app create guestbook-dev \
  --repo <URL_REPO_CỦA_BẠN> \ # Ví dụ: https://github.com/your-username/my-gitops-repo.git
  --path applications/guestbook/overlays/dev \
  --dest-server https://kubernetes.default.svc \
  --dest-namespace default \
  --sync-policy automated \ # Tự động đồng bộ
  --auto-prune \ # Tự động xóa tài nguyên không còn trong Git
  --self-heal # Tự động điều chỉnh nếu có drift

Giải thích:

--repo: URL Git repository của bạn.
--path: Đường dẫn đến folder Kustomize overlay cho môi trường dev.
--dest-server: URL của Kubernetes API server (luôn là https://kubernetes.default.svc khi tạo ứng dụng từ bên trong cluster).
--dest-namespace: Namespace mà ứng dụng sẽ được triển khai.
--sync-policy automated: Khi có thay đổi trong Git, Argo CD sẽ tự động đồng bộ.

Quay lại Argo CD UI, bạn sẽ thấy ứng dụng guestbook-dev xuất hiện và trạng thái sẽ chuyển từ OutOfSync sang Syncing rồi Synced. Argo CD sẽ tự động triển khai guestbook-app với 2 replicas vào namespace default.

Kiểm tra trong cluster:

kubectl get deployments -n default
kubectl get services -n default

Bạn sẽ thấy guestbook-app với 2 replicas đang chạy.

Bước 5: Thực hiện thay đổi và quan sát GitOps hoạt động

Chúng ta sẽ tăng số lượng replicas cho môi trường dev từ 2 lên 3.

Mở file my-gitops-repo/applications/guestbook/overlays/dev/deployment-patch.yaml.
Thay đổi replicas: 2 thành replicas: 3.
Commit và push thay đổi này lên Git repository của bạn.

git add .
git commit -m "Increase guestbook replicas to 3 for dev"
git push origin main # hoặc master tùy branch của bạn

Quan sát Argo CD UI: Sau vài giây hoặc vài phút (tùy thuộc vào polling interval của Argo CD, mặc định là 3 phút hoặc khi có webhook), bạn sẽ thấy ứng dụng guestbook-dev chuyển trạng thái sang OutOfSync, sau đó tự động Syncing và cuối cùng là Synced.

Kiểm tra trong cluster:

kubectl get deployments -n default

Bạn sẽ thấy số lượng replicas của guestbook-app đã tự động tăng lên 3. Thật tuyệt vời phải không nào? GitOps đã hoạt động!

Bước 6: Triển khai môi trường `prod`

Trong Argo CD UI, tạo một ứng dụng mới tương tự cho prod:

argocd app create guestbook-prod \
  --repo <URL_REPO_CỦA_BẠN> \
  --path applications/guestbook/overlays/prod \
  --dest-server https://kubernetes.default.svc \
  --dest-namespace prod \ # Triển khai vào namespace 'prod'
  --sync-policy automated \
  --auto-prune \
  --self-heal

Lưu ý: Bạn có thể cần tạo namespace prod trước: kubectl create namespace prod.

Quan sát Argo CD triển khai guestbook-app với 3 replicas (theo cấu hình prod/deployment-patch.yaml) vào namespace prod.

LAB 2: GitOps với Flux CD cơ bản

Trong lab này, chúng ta sẽ khám phá Flux CD bằng cách triển khai một ứng dụng đơn giản khác.

Bước 1: Cài đặt Flux CLI

Theo hướng dẫn trên trang chủ Flux CD:

# Đối với Mac/Linux
curl -s https://fluxcd.io/install.sh | sudo bash

Xác minh cài đặt:

flux --version

Bước 2: Chuẩn bị Git Repository và Personal Access Token (PAT)

Flux CD sẽ cần quyền ghi lên Git repository của bạn để thực hiện Image Automation sau này (nếu bạn muốn). Tạo một Personal Access Token (PAT) trên GitHub/GitLab của bạn với quyền repo (hoặc api cho GitLab).

Bước 3: Bootstrap Flux CD vào Cluster

Bước này sẽ cài đặt Flux CD controller vào cluster và cấu hình nó để theo dõi Git repository của bạn.

flux bootstrap github \
  --owner=
<YOUR_GITHUB_USERNAME> \
  --repository=
<YOUR_REPO_NAME> \
  --branch=main \ # hoặc master
  --personal=true \
  --path=clusters/my-cluster # Thư mục trong repo sẽ chứa cấu hình Flux

Giải thích:

--personal=true: Cho biết đây là một repo cá nhân.
--path=clusters/my-cluster: Flux sẽ tạo ra các file cấu hình của chính nó trong thư mục này trên repo của bạn.

Sau khi chạy lệnh này, Flux sẽ cài đặt các thành phần của nó vào namespace flux-system và tự động commit các file cấu hình bootstrap vào repo của bạn.

Kiểm tra trạng thái Flux:

flux get kustomizations -n flux-system
flux get sources git -n flux-system

Bước 4: Triển khai ứng dụng mẫu với Flux CD

Chúng ta sẽ tạo một ứng dụng Nginx đơn giản để Flux triển khai. Tạo file nginx-app.yaml trong thư mục my-gitops-repo/applications/nginx/ của bạn:

# my-gitops-repo/applications/nginx/nginx-app.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
  type: LoadBalancer # Hoặc NodePort

Commit và push file này lên Git repository.

Bây giờ, chúng ta cần nói cho Flux biết về ứng dụng này. Tạo một Kustomization CRD để Flux biết phải đồng bộ cái gì. Thêm đoạn sau vào file my-gitops-repo/clusters/my-cluster/apps.yaml:

# my-gitops-repo/clusters/my-cluster/apps.yaml
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: nginx-app
  namespace: flux-system # Nơi Flux controller chạy
spec:
  interval: 1m0s # Tần suất Flux kiểm tra Git repo
  sourceRef:
    kind: GitRepository
    name: my-gitops-repo # Tên GitRepository đã được tạo bởi flux bootstrap
  path: "./applications/nginx" # Đường dẫn đến thư mục ứng dụng nginx
  prune: true # Xóa các tài nguyên không còn tồn tại trong Git
  validation: client # Kiểm tra yaml trước khi apply

Commit và push clusters/my-cluster/apps.yaml lên Git.

Quan sát Flux CD: Sau khoảng 1 phút (theo interval: 1m0s), Flux sẽ phát hiện file mới và triển khai ứng dụng Nginx.

Kiểm tra trong cluster:

kubectl get deployments -n default

Bạn sẽ thấy nginx-deployment đang chạy.

Bước 5: Thực hiện thay đổi và quan sát Flux CD hoạt động

Thay đổi số lượng replicas của Nginx từ 1 lên 2:

Mở file my-gitops-repo/applications/nginx/nginx-app.yaml.
Thay đổi replicas: 1 thành replicas: 2.
Commit và push thay đổi này lên Git repository của bạn.

git add .
git commit -m "Increase nginx replicas to 2"
git push origin main

Sau khoảng 1 phút, Flux sẽ tự động đồng bộ thay đổi.

Kiểm tra trong cluster:

kubectl get deployments -n default

nginx-deployment sẽ có 2 replicas.

V. Các Bước Nâng Cao và Lưu Ý Quan Trọng

Để bài viết thực sự chuyên sâu, bạn có thể mở rộng thêm các phần này:

Secret Management trong GitOps (với Sealed Secrets hoặc External Secrets):
- Giải thích vấn đề lưu trữ secret trong Git.
- Hướng dẫn cài đặt Sealed Secrets controller và cách tạo SealedSecret để commit vào Git một cách an toàn.
- Lab (nâng cao): Thêm một secret vào ứng dụng guestbook và quản lý nó bằng Sealed Secrets.
Chiến lược Rollback: Hướng dẫn chi tiết cách rollback với Argo CD UI và Flux CD CLI.
Giám sát GitOps Operators: Làm thế nào để giám sát sức khỏe của Argo CD và Flux CD controllers (sử dụng Prometheus/Grafana).
Best Practices cho Cấu trúc Repo GitOps:
- Monorepo vs. Multirepo.
- Tổ chức thư mục cho ứng dụng, hạ tầng, môi trường.
Image Automation (đối với Flux CD): Hướng dẫn cách Flux tự động cập nhật image tag trong Git khi có image mới trên Container Registry. (Điều này yêu cầu cấu hình PAT).
DevSecOps trong GitOps: Làm thế nào để tích hợp các bước quét bảo mật (SAST, SCA, quét image) vào pipeline CI/CD trước khi thay đổi được merge vào nhánh GitOps.

VI. Kết Luận

GitOps là một sự chuyển mình mạnh mẽ trong cách chúng ta triển khai và quản lý ứng dụng trên Kubernetes. Bằng cách lấy Git làm trung tâm, chúng ta đạt được sự đồng nhất, tin cậy, an toàn và khả năng kiểm toán vượt trội. Argo CD và Flux CD là những công cụ tuyệt vời giúp chúng ta hiện thực hóa tầm nhìn này.

Hy vọng thông qua bài viết lý thuyết và các lab thực hành chi tiết này, bạn đã có được cái nhìn sâu sắc và kinh nghiệm thực tế về GitOps.