Lab 5 — ArgoCD Sync & Self-Healing
🎯 1. Mục tiêu
Sau lab này, bạn sẽ hiểu và thực hành được:
- 🔄 ArgoCD Sync là gì và tại sao cần Sync.
- 👀 Phân biệt Git Desired State và trạng thái thực tế trên Kubernetes.
- 🤖 Cấu hình Automated Sync để ArgoCD tự deploy khi Git thay đổi.
- 🩹 Hiểu Self-Healing và cách ArgoCD tự sửa khi Kubernetes bị thay đổi ngoài Git.
- 🧹 Hiểu Prune và tại sao resource bị xóa khỏi Git có thể cần được xóa khỏi cluster.
🤔 2. Vấn đề thực tế
Ở Lab trước, chúng ta đã dùng ArgoCD để deploy application.
Nhưng hãy tưởng tượng một ngày developer thay đổi file:
deployment.yaml
và push lên Git.
Nếu ArgoCD đang ở chế độ Manual Sync, chuyện gì xảy ra?
Developer
│
│ git push
▼
Git Repository
│
│
│ ArgoCD phát hiện có thay đổi
▼
┌──────────────┐
│ ArgoCD │
│ │
│ OutOfSync ❗ │
└──────────────┘
│
│ Chưa deploy
▼
Kubernetes
Application trên Kubernetes chưa thay đổi.
DevOps Engineer phải vào ArgoCD và bấm:
SYNC
Nếu application có hàng chục lần thay đổi mỗi ngày, việc này nhanh chóng trở thành công việc thủ công không cần thiết.
Nhưng còn một vấn đề nguy hiểm hơn.
Một người có thể chạy:
kubectl edit deployment todo-backend -n todo-app
và thay đổi:
replicas: 3
thành:
replicas: 1
Git vẫn nói:
replicas: 3
nhưng Kubernetes đang chạy:
replicas: 1
Đây chính là configuration drift — trạng thái thực tế đã lệch khỏi trạng thái mong muốn trong Git.
ArgoCD có thể giải quyết cả hai vấn đề này bằng:
Automated Sync
+
Self-Healing
+
Prune
🧠 3. Hiểu nhanh
3.1. Desired State và Live State
Đây là concept quan trọng nhất của GitOps.
Desired State
Git chứa trạng thái mà chúng ta muốn Kubernetes có:
replicas: 3
Có thể hiểu:
"Tôi muốn application chạy 3 Pod."
Live State
Kubernetes đang thực sự chạy:
Deployment
replicas: 1
Có thể hiểu:
"Hiện tại cluster chỉ đang chạy 1 Pod."
ArgoCD liên tục so sánh hai trạng thái:
Git
Desired State
│
│
▼
┌─────────┐
│ ArgoCD │
└────┬────┘
│
│ Compare
▼
Kubernetes
Live State
Nếu giống nhau:
Synced ✅
Nếu khác nhau:
OutOfSync ⚠️
🔄 4. Manual Sync
🧠 Explain
Ở chế độ Manual Sync:
Git change
│
▼
ArgoCD detects change
│
▼
OutOfSync
│
│ Manual action
▼
Sync
│
▼
Kubernetes updated
ArgoCD phát hiện thay đổi nhưng không tự deploy.
Điều này hữu ích khi bạn muốn kiểm soát deployment bằng tay.
🧪 Do
Trước tiên kiểm tra Application:
kubectl get applications -n argocd
Bạn có thể thấy:
NAME SYNC STATUS HEALTH
todo-app Synced Healthy
Bây giờ mở file Deployment trong Git repository.
Ví dụ:
spec:
replicas: 2
Đổi thành:
spec:
replicas: 3
Commit và push:
git add .
git commit -m "scale todo backend to 3 replicas"
git push
👀 See Result
Quay lại ArgoCD.
Bạn sẽ thấy:
SYNC STATUS
OutOfSync
Điều này có nghĩa:
Git:
replicas = 3
Kubernetes:
replicas = 2
ArgoCD biết có sự khác biệt nhưng chưa tự thay đổi cluster.
Bấm:
SYNC
Sau đó:
Synced ✅
Kiểm tra:
kubectl get deployment -n todo-app
Bạn sẽ thấy:
NAME READY UP-TO-DATE AVAILABLE
todo-backend 3/3 3 3
🧠 Understand
Manual Sync phù hợp khi:
- Production cần approval trước deployment.
- Deployment cần thực hiện trong maintenance window.
- Team muốn kiểm soát thời điểm release.
Nhưng với nhiều workload thông thường, chúng ta muốn Git thay đổi → cluster tự cập nhật.
Đó là lúc Automated Sync xuất hiện.
🤖 5. Automated Sync
🧠 Explain
Automated Sync cho phép ArgoCD tự động đồng bộ Kubernetes khi phát hiện Git thay đổi.
Thay vì:
Git
│
▼
ArgoCD
│
▼
OutOfSync
│
│ DevOps bấm Sync
▼
Kubernetes
chúng ta có:
Git
│
│ Change
▼
ArgoCD
│
│ Auto Sync
▼
Kubernetes
Đây là một trong những lợi ích quan trọng nhất của GitOps.
🏗️ 6. Architecture
Khi bật Automated Sync:
Git Repository
Desired State
│
│ git push
▼
┌─────────────┐
│ ArgoCD │
│ │
│ Detect Diff │
└──────┬──────┘
│
│ Auto Sync
▼
┌─────────────┐
│ Kubernetes │
│ │
│ Live State │
└──────┬──────┘
│
│ Compare
└──────────────┐
│
Same → Synced
Diff → Reconcile
ArgoCD hoạt động theo tư duy:
Git nói Kubernetes nên như thế nào → ArgoCD cố gắng đưa Kubernetes về trạng thái đó.
🧪 7. Bật Automated Sync
🧠 Explain
Chúng ta có thể bật Automated Sync cho ArgoCD Application.
Nếu Application được quản lý bằng manifest, phần quan trọng sẽ giống như:
spec:
syncPolicy:
automated: {}
Ví dụ:
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: todo-app
namespace: argocd
spec:
source:
repoURL: https://github.com/example/todo-gitops.git
targetRevision: main
path: kubernetes
destination:
server: https://kubernetes.default.svc
namespace: todo-app
syncPolicy:
automated: {}
Bạn không cần học thuộc manifest này.
Chỉ cần nhớ:
syncPolicy
│
└── automated
│
└── ArgoCD tự Sync
🧪 Do
Nếu Application đang được quản lý bằng YAML, thêm:
syncPolicy:
automated: {}
Sau đó apply:
kubectl apply -f application.yaml
Kiểm tra:
kubectl get application todo-app -n argocd
🧪 8. Test Automated Sync
🧠 Explain
Bây giờ chúng ta kiểm tra xem ArgoCD có thực sự tự deploy hay không.
🧪 Do
Trong Git repository, thay đổi:
replicas: 3
thành:
replicas: 4
Commit:
git add .
git commit -m "scale todo backend"
git push
Không bấm Sync trong ArgoCD.
👀 See Result
Chờ ArgoCD phát hiện Git thay đổi.
Sau đó kiểm tra:
kubectl get deployment -n todo-app
Bạn sẽ thấy:
NAME READY UP-TO-DATE AVAILABLE
todo-backend 4/4 4 4
Không cần:
kubectl apply
Không cần:
argocd app sync
Không cần bấm nút Sync.
🧠 Understand
Flow hiện tại là:
Developer
│
│ git push
▼
Git Repository
│
▼
ArgoCD
│
│ Automated Sync
▼
Kubernetes
Đây chính là GitOps workflow mà chúng ta muốn xây dựng.
🩹 9. Self-Healing
🧠 Explain
Automated Sync giải quyết vấn đề:
Git thay đổi → Kubernetes tự cập nhật.
Nhưng chúng ta còn một vấn đề khác:
Kubernetes bị thay đổi trực tiếp.
Ví dụ Git đang quy định:
replicas: 4
Nhưng một người chạy:
kubectl scale deployment todo-backend \
--replicas=1 \
-n todo-app
Bây giờ:
Git
replicas = 4
│
│
▼
ArgoCD
│
│ Diff
▼
Kubernetes
replicas = 1
Cluster đã drift khỏi Git.
Nếu chỉ có Automated Sync, ArgoCD chủ yếu phản ứng với thay đổi từ Git.
Self-Healing giúp ArgoCD phát hiện và sửa drift trong cluster để đưa Live State quay về Desired State.
🏗️ 10. Self-Healing Architecture
Git
Desired State
│
▼
┌────────┐
│ ArgoCD │
└───┬────┘
│
│ Compare
▼
Kubernetes
Live State
│
│
Manual Change
│
▼
replicas = 1
│
│ Drift detected
▼
┌────────┐
│ ArgoCD │
│ Heal │
└───┬────┘
│
▼
replicas = 4
Tư duy rất đơn giản:
Git = Truth
↓
Cluster drift
↓
ArgoCD detects
↓
ArgoCD repairs
⚙️ 11. Bật Self-Healing
🧠 Explain
Self-Healing được bật cùng Automated Sync:
syncPolicy:
automated:
selfHeal: true
Thông thường bạn sẽ thấy:
syncPolicy:
automated:
selfHeal: true
Có thể hiểu:
automated
│
├── Git change → Auto Sync
│
└── Cluster drift → Self-Heal
🧪 12. Test Self-Healing
🧪 Do
Giả sử Git đang quy định:
replicas: 4
Kiểm tra:
kubectl get deployment todo-backend -n todo-app
Kết quả:
READY
4/4
Bây giờ cố tình tạo drift:
kubectl scale deployment todo-backend \
--replicas=1 \
-n todo-app
Kiểm tra:
kubectl get deployment todo-backend -n todo-app
Bạn có thể thấy:
READY
1/1
Nhưng đừng sửa Git.
Hãy chờ ArgoCD reconcile.
👀 13. See Result
Sau một khoảng thời gian ngắn, kiểm tra lại:
kubectl get deployment todo-backend -n todo-app
Kết quả sẽ quay lại:
READY
4/4
ArgoCD đã phát hiện:
Desired State = 4
Live State = 1
và thực hiện:
1 → 4
🧠 14. Understand
Đây chính là Self-Healing.
Bạn có thể hình dung ArgoCD giống như một người giám sát:
Git:
"Application phải có 4 replicas."
Kubernetes:
"Hiện tại tôi chỉ có 1."
ArgoCD:
"Không đúng với Git."
ArgoCD:
"Tôi sửa lại."
Kubernetes:
"OK → 4 replicas."
Điểm quan trọng:
Self-Healing không phải backup hay disaster recovery.
Nó chỉ giúp đưa resource Kubernetes trở lại trạng thái được định nghĩa trong Git.
🧹 15. Prune
🧠 Explain
Có một tình huống khác.
Git ban đầu có:
deployment.yaml
service.yaml
configmap.yaml
ArgoCD deploy cả 3:
Kubernetes
Deployment
Service
ConfigMap
Sau đó developer xóa:
configmap.yaml
khỏi Git.
Nếu chỉ Sync thông thường, resource cũ có thể vẫn tồn tại trong cluster tùy cấu hình.
Đây là lúc Prune hữu ích.
Prune có ý nghĩa:
Resource không còn được Git quản lý nữa → xóa resource đó khỏi cluster.
🏗️ 16. Automated Sync + Self-Healing + Prune
Đây là cấu hình thường gặp:
syncPolicy:
automated:
prune: true
selfHeal: true
Tư duy:
Git
│
▼
ArgoCD
│
┌───────┼────────┐
│ │ │
▼ ▼ ▼
Sync Self-Heal Prune
│ │ │
▼ ▼ ▼
Git diff Drift Deleted
│ │ │
└───────┼────────┘
▼
Kubernetes
🧪 17. Test Prune
🧪 Do
Giả sử Git đang có:
kubernetes/
├── deployment.yaml
├── service.yaml
└── configmap.yaml
ArgoCD đã deploy:
kubectl get configmap -n todo-app
Bây giờ xóa configmap.yaml khỏi Git:
git rm kubernetes/configmap.yaml
git commit -m "remove unused configmap"
git push
Nếu:
prune: true
ArgoCD sẽ nhận ra resource này không còn thuộc Desired State.
👀 18. See Result
Sau khi ArgoCD reconcile:
kubectl get configmap -n todo-app
ConfigMap tương ứng sẽ bị xóa.
Flow:
configmap.yaml
│
│ git rm
▼
Git
│
▼
ArgoCD
│
│ Prune
▼
Kubernetes
│
▼
ConfigMap deleted
⚠️ 19. Cẩn thận với Prune trong Production
Đây là một kinh nghiệm rất quan trọng.
prune: true rất mạnh.
Nếu một resource bị xóa khỏi Git do:
- Git merge nhầm.
- Developer xóa nhầm file.
- CI/CD generate manifest sai.
- Repository bị rollback sai.
ArgoCD có thể hiểu:
"Resource này không còn trong Desired State → xóa nó."
Vì vậy production cần:
Git review
↓
Pull Request
↓
CI validation
↓
Approval
↓
Merge
↓
ArgoCD
Không nên để việc thay đổi production phụ thuộc vào một cú git push thiếu kiểm soát.
🔍 20. Kiểm tra trạng thái Sync
Bạn có thể kiểm tra Application bằng:
kubectl get application -n argocd
Ví dụ:
NAME SYNC STATUS HEALTH
todo-app Synced Healthy
Các trạng thái quan trọng:
| Trạng thái | Ý nghĩa |
|---|---|
Synced |
Git và Kubernetes đang giống nhau |
OutOfSync |
Git và Kubernetes đang khác nhau |
Healthy |
Application đang hoạt động bình thường |
Degraded |
Application có vấn đề |
Unknown |
ArgoCD chưa xác định được trạng thái |
🛠️ 21. Troubleshooting nhanh
❌ ArgoCD không tự Sync
Kiểm tra:
kubectl get application todo-app -n argocd -o yaml
Tìm:
syncPolicy:
automated:
Nếu không có, Automated Sync chưa được bật.
❌ Self-Healing không hoạt động
Kiểm tra:
syncPolicy:
automated:
selfHeal: true
Sau đó tạo drift:
kubectl scale deployment todo-backend \
--replicas=1 \
-n todo-app
Theo dõi:
kubectl get deployment todo-backend \
-n todo-app \
-w
❌ Resource bị xóa ngoài ý muốn
Kiểm tra:
prune: true
Nếu đang bật, hãy kiểm tra Git history:
git log --oneline
và Pull Request gần nhất.
Đây là lý do production GitOps cần Git review + CI validation + approval.
🧪 22. Final Exercise
Bây giờ hãy tự thực hiện toàn bộ flow mà không nhìn lại hướng dẫn.
Exercise 1 — Automated Sync
- [ ] Bật
automated sync. - [ ] Thay đổi replicas từ
2 → 3. - [ ] Push Git.
- [ ] Không bấm Sync trên ArgoCD.
- [ ] Kiểm tra Kubernetes.
Mục tiêu:
Git change
↓
ArgoCD
↓
Auto Sync
↓
Kubernetes updated
Exercise 2 — Self-Healing
- [ ] Git quy định
replicas: 3. - [ ] Dùng
kubectl scaleđể đổi thành1. - [ ] Quan sát ArgoCD.
- [ ] Kiểm tra Deployment.
- [ ] Xác nhận replicas quay lại
3.
Mục tiêu:
Manual change
↓
Drift
↓
ArgoCD detects
↓
Self-Heal
↓
Desired State
Exercise 3 — Prune
- [ ] Tạo một ConfigMap được quản lý bởi ArgoCD.
- [ ] Push lên Git.
- [ ] Xác nhận ConfigMap tồn tại.
- [ ] Xóa manifest khỏi Git.
- [ ] Bật
prune. - [ ] Quan sát ArgoCD.
- [ ] Xác nhận ConfigMap bị xóa khỏi Kubernetes.
🧠 23. Tổng kết
Sau Lab 5, bạn cần nhớ 4 từ khóa:
ArgoCD
│
┌─────────┼─────────┐
│ │ │
Sync Self-Heal Prune
│ │ │
▼ ▼ ▼
Git change Drift Removed
│ │ │
└─────────┼─────────┘
▼
Kubernetes
🔄 Sync
Git thay đổi → cập nhật Kubernetes.
🤖 Automated Sync
Không cần DevOps bấm Sync thủ công.
🩹 Self-Healing
Kubernetes bị thay đổi ngoài Git → ArgoCD đưa nó về trạng thái trong Git.
🧹 Prune
Resource bị xóa khỏi Git → ArgoCD có thể xóa resource tương ứng khỏi Kubernetes.
Và tư duy quan trọng nhất của GitOps là:
Git
│
│ Desired State
▼
ArgoCD
│
│ Reconcile
▼
Kubernetes
│
│ Live State
▼
Compare continuously
Không phải Kubernetes quyết định hệ thống nên như thế nào. Git mới là Source of Truth. ArgoCD có nhiệm vụ giữ Kubernetes đồng bộ với Git.
🚀 24. Bước tiếp theo
Ở Lab 5, chúng ta mới quản lý một environment tương đối đơn giản.
Nhưng thực tế thường có:
Development
│
▼
Staging
│
▼
Production
và mỗi environment có cấu hình khác nhau.
Ví dụ:
dev:
replicas: 1
staging:
replicas: 2
production:
replicas: 5
Nếu copy nguyên một đống YAML cho từng environment, repository sẽ rất khó maintain.
👉 Lab 6 — GitOps với Kustomize sẽ giải quyết bài toán này bằng:
Base
│
├── dev
├── staging
└── production
Từ đó chúng ta bắt đầu tiến gần hơn tới GitOps architecture thực tế.
All rights reserved
