Argo CD cho FDE: một manifest trong Git, nhiều cụm Kubernetes của khách

Bật auto-sync trong Argo CD rồi gỡ một resource khỏi Git, resource đó vẫn nằm nguyên trên cụm của khách, trừ khi bạn chủ động bật prune. Ai đó sửa tay bằng kubectl trên production cũng không làm auto-sync chạy lại, trừ khi bạn bật self-heal.

Hai mặc định ấy cho thấy rõ cách Argo CD được thiết kế: nó báo chỗ lệch trước, và chỉ tự sửa khi bạn cho phép.

Với một FDE, đây đúng là thứ cần có. Bạn deploy vào hạ tầng không thuộc về mình, thường có nhiều cụm, và có nhiều người khác cùng chạm vào. Vì thế phải hiểu công cụ làm gì và không làm gì trước khi bật bất kỳ chế độ tự động nào.

Git là sự thật, cụm chỉ là bản sao

Tài liệu chính thức gọi Argo CD là công cụ continuous delivery kiểu khai báo theo GitOps cho Kubernetes. Repo Git chứa trạng thái mong muốn của ứng dụng. Phần lõi là application controller: nó liên tục so trạng thái đang chạy với trạng thái đích trong Git, đánh dấu OutOfSync khi hai bên lệch nhau, và có thể tự sửa nếu bạn cấu hình như vậy.

Bên cạnh controller là API server, một server gRPC/REST phục vụ Web UI, CLI và các hệ thống CI/CD. Nó cũng quản lý credentials của repo và của cụm.

Khi nào FDE nên dùng nó?

Thử hình dung một khách hàng có bốn cụm: dev, staging và hai cụm production ở hai khu vực. Bạn deploy cùng một dịch vụ inference lên cả bốn. Nếu dùng script và kubectl, sau ba tuần rất dễ không ai dám chắc cụm nào đang chạy phiên bản nào.

Dấu hiệu nên dùng Argo CD khá rõ: từ hai cụm trở lên, nhiều người có quyền ghi, và khách muốn biết ai đã đổi gì. Khi mọi thay đổi đều đi qua Git, lịch sử commit trở thành nhật ký thay đổi. Màn hình OutOfSync thì cho thấy chỗ nào đã đi chệch khỏi nhật ký đó.

Nếu đội bảo mật của khách hỏi về độ trưởng thành, câu trả lời ngắn: Argo vào CNCF ngày 26/3/2020 và lên mức Graduated ngày 6/12/2022.

Ví dụ tối giản: thêm cụm thứ năm mà không sửa manifest

Bước một là đăng ký cụm theo kiểu khai báo. Mỗi cụm là một Kubernetes Secret, và tài liệu yêu cầu Secret đó phải mang nhãn argocd.argoproj.io/secret-type: cluster. Một bản phác tối giản trông như sau:

apiVersion: v1
kind: Secret
metadata:
  name: prod-eu
  namespace: argocd
  labels:
    argocd.argoproj.io/secret-type: cluster
stringData:
  name: prod-eu
  server: https://<cluster-api-url>
  config: |
    { "<credentials>": "..." }

Credentials của cụm được lưu trong Secret, giống credentials của repo. Vì vậy đừng commit file này dạng plaintext vào Git. Hãy mã hoá trước khi commit, hoặc để credentials nằm ngoài repo và chỉ đưa vào cụm chạy Argo CD theo quy trình bảo mật mà khách đã duyệt.

Bước hai là viết một ApplicationSet. Tính năng này cho phép một manifest nhắm tới nhiều cụm. Cluster generator tự sinh tham số từ các cụm đã khai báo trong Argo CD, nên bốn Secret cho ra bốn Application:

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: inference
  namespace: argocd
spec:
  generators:
    - clusters: {}
  template:
    metadata:
      name: 'inference-{{name}}'
    spec:
      project: default
      source:
        repoURL: https://git.example.com/customer/deploy.git
        targetRevision: main
        path: inference
      destination:
        server: '{{server}}'
        namespace: inference
      syncPolicy:
        automated: {}

Dòng automated: {} bật auto-sync với hai mặc định thận trọng nói ở đầu bài: không prune, không self-heal. Giờ khách mở thêm cụm thứ năm. Bạn chỉ thêm một Secret có nhãn, không phải sửa ApplicationSet, và cụm mới tự nhận bản deploy.

Đó là lý do tài liệu khuyên dùng ApplicationSet khi dựng cụm mới. Cách thay thế là app-of-apps, nhưng tài liệu ghi rõ đó là công cụ chỉ dành cho admin. Nếu bạn không giữ quyền admin trên Argo CD của khách, lựa chọn gần như đã có sẵn.

Hai mặc định phải chốt với khách

Quay lại cụm production. Giả sử lúc hai giờ sáng, một kỹ sư trực ca dùng kubectl tăng replica từ 3 lên 6 để chống tải. Controller thấy cụm lệch khỏi Git và báo OutOfSync, nhưng khi self-heal chưa bật, thay đổi trên cụm không kích hoạt auto-sync, nên 6 replica vẫn được giữ nguyên.

Câu chuyện chưa dừng ở đó. Git vẫn ghi 3 replica, nên theo đúng logic GitOps, lần sync kế tiếp từ Git, chẳng hạn khi có người merge một commit khác hoặc bấm Sync, sẽ áp lại trạng thái đích và đưa cụm về 3 replica.

Việc đó có thể xảy ra đúng lúc tải vẫn còn cao. Nếu self-heal đang bật, cụm còn bị kéo về 3 ngay, gần như không giữ được 6 replica.

Vì thế, cách sửa đúng lúc hai giờ sáng là một commit đổi replica trong Git, không phải một lệnh kubectl. Prune cũng có đánh đổi tương tự. Bật prune thì ConfigMap bạn xoá khỏi Git sẽ biến mất khỏi cụm; không bật thì nó nằm lại như rác cấu hình.

Người quyết định hai cờ này không phải bạn. Nên bắt đầu với cả hai đều tắt, theo dõi danh sách OutOfSync khoảng một tuần, rồi mang dữ liệu đó vào buổi họp với đội platform. Cũng cần nói thẳng: Argo CD quản lý credentials của mọi cụm mà nó deploy tới, nên cụm chạy Argo CD phải được bảo vệ như tài sản nhạy cảm nhất trong hệ thống.

Những lỗi nào hay gặp?

Lỗi phổ biến nhất là tin rằng xoá file khỏi Git thì resource trên cụm cũng mất. Với auto-sync mặc định, nó vẫn còn đó. Trước khi báo khách “đã gỡ xong”, hãy kiểm tra cụm thật hoặc bật prune có chủ đích.

Lỗi thứ hai là nghĩ Argo CD sẽ tự kéo cụm về khi có người sửa tay. Không bật self-heal thì nó chỉ báo OutOfSync. Nếu không ai nhìn màn hình đó, chỗ lệch có thể nằm im hàng tuần, cho tới khi một lần sync bất ngờ xoá nó đi.

Lỗi thứ ba là commit Secret của cụm kèm credentials dạng plaintext để “cho đủ GitOps”. Lỗi cuối là chọn app-of-apps khi bạn không có quyền admin, rồi kẹt giữa engagement vì phải đi xin quyền.

Học theo thứ tự nào?

Bắt đầu với một Application trên một cụm, để thấy tận mắt vòng so sánh và trạng thái OutOfSync. Tiếp theo là các cờ của auto-sync, rồi đăng ký cụm bằng Secret, cuối cùng là ApplicationSet với cluster generator. Mỗi bước chỉ thêm đúng một khái niệm mới.

Khi đọc job description FDE, hãy để ý các cụm từ GitOps, Argo CD và multi-cluster. Trong CV, đừng chỉ ghi “dùng Argo CD”. Hãy viết bằng con số thật của bạn: bao nhiêu cụm, và việc thêm một cụm mới đã từ nhiều bước thủ công rút xuống còn một Secret như thế nào.

Tại chỗ khách hàng, người ta không nhớ bạn deploy nhanh đến đâu. Họ nhớ bạn là người trả lời được câu “production đang chạy gì?” mà không cần SSH vào máy nào.