🚧 Chia sẻ hành trình thực tế từ Argo CD đến Kro & Kargo trong GitOps

Đây không phải một bài viết quảng bá sản phẩm — mà là câu chuyện thực tế tôi đã trải qua khi triển khai GitOps cho hàng chục microservices.

📑 Mục Lục

1. Khởi đầu với Argo CD
2. Vấn đề gặp phải khi scale GitOps
3. Giải pháp: Kro và instance.yaml
4. Vì sao không chọn Helm hoặc Kustomize?
5. Workflow GitOps cuối cùng
6. Tiếp theo là gì?

🚀 Khởi đầu với Argo CD

Argo CD là GitOps tool đầu tiên mà chúng tôi lựa chọn để triển khai trên hệ thống sử dụng GitLab. Nó ổn định, có giao diện trực quan, và dễ tiếp cận khi mới bắt đầu.

Tuy nhiên, khi số lượng dịch vụ tăng lên, sự đơn giản ban đầu dần biến mất.

⚠️ Vấn đề gặp phải khi scale GitOps

Khi số lượng service tăng dần lên vài chục, tôi bắt đầu cảm thấy:

• Quản lý YAML rối rắm — mỗi service có 3 file: deployment.yaml, service.yaml, configmap.yaml.
• Muốn đổi image tag → phải sửa ở nhiều file.
• Muốn thêm env var → lại tạo pull request mới.

Tôi muốn một cách đơn giản hơn: 1 file duy nhất cho mỗi service.

🛠️ Giải pháp: Kro và instance.yaml

Khi đang tìm kiếm một công cụ có thể render YAML tự động từ file cấu hình "cao cấp", tôi gặp Kro.

Thay vì 3 file cho mỗi dịch vụ:

frontend/
├── deployment.yaml
├── service.yaml
└── configmap.yaml

→ Chỉ còn một file duy nhất:

frontend/
└── instance.yaml

Ví dụ nội dung instance.yaml:

spec:
  values:
    deployment:
      tag: 0320.1
      port: 3000
      image: frontend
    config:
      LOG_LEVEL: debug
      API_URL: https://api.example.com

Chỉ cần cập nhật 1 chỗ → Kro render ra đầy đủ manifests.

🤔 Vì sao không chọn Helm hoặc Kustomize?

Tôi đã từng dùng Helm để cài chart phổ biến, nhưng:

• Chưa bao giờ tự viết chart riêng
• Từng phải mò values.yaml, _helpers.tpl, template phức tạp
• Kustomize thì:
  • Overlay quá nhiều tầng
  • Debug patch rất khó khăn

Tôi chỉ muốn:

"Miêu tả ý định dịch vụ, và để hệ thống tự render manifest"

Kro đáp ứng:

• 1 file duy nhất là instance.yaml
• Phân tách rõ ràng giữa spec và render
• Dễ scale cho nhiều dịch vụ
• Tích hợp mượt mà với Argo CD

🔄 Workflow GitOps cuối cùng

• instance.yaml → render manifests qua Kro
• Kargo theo dõi tag → tự động cập nhật
• Argo CD tiếp tục đồng bộ

Tất cả bắt nguồn từ 1 file cấu hình duy nhất cho mỗi service.

🖼️ [Hình minh hoạ sẽ thêm sau]

🔮 Tiếp theo là gì?

Ở phần sau, tôi sẽ chia sẻ cách viết ResourceGraphDefinition (RGD) cho Kro — thứ biến instance.yaml thành các manifests thực tế.

Nếu bạn từng patch 3 file YAML chỉ để đổi version image, chuỗi bài viết này là dành cho bạn.