GitOps trong 35 ngày

PHASE 0 - Nền tảng lý thuyết bắt buộc (Ngày 0–1)

Ngày 0 - Cơ chế reconciliation thật sự hoạt động thế nào

• Level-triggered vs edge-triggered: GitOps controller không "chạy pipeline khi có commit" theo nghĩa CI - nó liên tục so sánh (diff) desired state (Git) với live state (cluster), bất kể có sự kiện hay không. Đây là khác biệt cốt lõi so với CI/CD truyền thống.

• Thuật toán diff cơ bản: 3-way merge (desired manifest, last-applied-state, live state) - vì sao GitOps tool phải biết "cái gì mình từng apply" để tránh xoá field người khác chỉnh tay.

• State Drift: drift xảy ra khi ai đó kubectl edit trực tiếp - controller phát hiện và tự phục hồi (self-heal) hoặc chỉ cảnh báo, tuỳ cấu hình.

• Feedback loop & Rollback: rollback trong GitOps = git revert, không phải thao tác trong UI công cụ (dù UI có nút hỗ trợ, về bản chất nó tạo commit mới).

Bài tập:

1. Thủ công mô phỏng 1 vòng reconcile: viết script bash diff giữa 2 file YAML (desired vs "live" giả lập), in ra patch cần áp dụng.

2. Tạo drift thủ công (kubectl edit sau khi Argo CD/Flux đã sync), quan sát công cụ phát hiện và xử lý drift trong bao lâu.

Ngày 1 - Nguyên lý GitOps chính thức (OpenGitOps – CNCF)

• 4 nguyên lý OpenGitOps v1 (CNCF Sandbox spec chính thức): Declarative, Versioned & Immutable, Pulled Automatically, Continuously Reconciled - hiểu đúng từng chữ, không chỉ thuộc lòng.

• Phân biệt CaC/IaC/CI/CD/DevSecOps và vị trí của GitOps trong bức tranh đó - GitOps là cách áp dụng IaC/CaC, không phải thứ thay thế CI.

• So sánh kiến trúc 2 trường phái: Argo CD (control plane tập trung: API server + application controller + repo server + Redis + Dex) vs Flux (GitOps Toolkit: nhiều controller độc lập, không UI, dựa hoàn toàn vào K8s RBAC).

Bài tập:

1. Tạo Git repo chứa vài manifest K8s đơn giản, dùng kubectl diff -f để so sánh 2 phiên bản.

2. Lập bảng so sánh chi tiết Argo CD vs Flux theo các tiêu chí: UI, RBAC model, cách xử lý Helm, OCI support, resource footprint - tự tìm hiểu, đừng copy bảng có sẵn.

PHASE 1 - Tuần 1: Argo CD sâu (Ngày 2–6)

Ngày 2 - Cài đặt & khái niệm cốt lõi

• Kiến trúc thật: argocd-server (API+UI), argocd-application-controller (reconcile loop chính), argocd-repo-server (clone git, render Helm/Kustomize/Jsonnet - đây là nơi tốn CPU/memory nhất khi scale), argocd-redis (cache), argocd-dex-server (SSO, optional).

• Application, AppProject, Sync - CRD cốt lõi. AppProject là ranh giới multi-tenant thật sự (giới hạn source repo, destination cluster/namespace, resource kind được phép).

• Cài Argo CD v3.3 lên kind bằng Helm chart chính thức, đăng nhập UI, argocd login.

Bài tập:

1. Tạo 1 Application trỏ tới repo manifest ở Ngày 1, sync thủ công rồi bật auto-sync.

2. Tạo AppProject giới hạn 1 team chỉ được deploy vào namespace team-a, chỉ từ 1 repo cụ thể.

3. Đọc log argocd-repo-server khi render 1 Helm chart, xác định bước nào tốn thời gian nhất.

Ngày 3 - Sync mechanics: hooks, waves, ignoreDifferences

• Sync Hooks (PreSync, Sync, PostSync, SyncFail) - chạy Job trước/sau khi apply, dùng cho migration DB, smoke test.

• Sync Waves (argocd.argoproj.io/sync-wave) - kiểm soát thứ tự apply resource trong 1 Application.

• ignoreDifferences - xử lý field bị mutate bởi controller khác (HPA sửa replicas, service mesh inject sidecar) để tránh Argo CD liên tục báo "OutOfSync" giả.

• Custom health check bằng Lua script cho CRD của bên thứ ba mà Argo CD không biết cách đánh giá "Healthy" mặc định.

Bài tập:

1. Viết 1 Application có PreSync hook chạy DB migration Job trước khi Deployment mới được apply.

2. Set sync-wave để tạo Namespace → Secret → Deployment đúng thứ tự.

3. Viết ignoreDifferences cho field spec.replicas của 1 Deployment bị HPA quản lý.

4. Viết custom health check Lua cho 1 CRD tuỳ ý (ví dụ Certificate của cert-manager).

Ngày 4 - ApplicationSet: fan-out multi-cluster/multi-env

• Generator các loại: List, Cluster, Git (directory/file), Matrix (kết hợp nhiều generator), Pull Request.

• Đây là công cụ chính xác cho "multi-cluster GitOps" - không phải "GitOps Engine" như bản gốc nói.

• Pattern app-of-apps vs ApplicationSet - khi nào dùng cái nào (app-of-apps kiểm soát thủ công tốt hơn cho bootstrap; ApplicationSet tốt hơn khi fan-out theo cùng 1 template).

Bài tập:

1. Viết ApplicationSet dùng Cluster generator để deploy cùng 1 app lên tất cả cluster có label env: staging.

2. Viết ApplicationSet dùng Git directory generator để tự tạo 1 Application cho mỗi thư mục app trong monorepo.

3. Viết ApplicationSet dùng Matrix generator kết hợp cluster × environment overlay.

Ngày 5 - Helm/Kustomize trong Argo CD, Source Hydrator (v3.1+)

• Argo CD render Helm bằng helm template nội bộ - Helm release không xuất hiện trong helm list (khác biệt quan trọng so với Flux, gây nhầm lẫn khi debug).

• Multi-source Application: tách chart khỏi values (values ở repo riêng).

• Source Hydrator (mới từ v3.1): tách bước "render" (hydrate manifest ra 1 nhánh Git riêng) khỏi bước "apply" - giúp review manifest đã render trước khi Argo CD áp dụng, giảm rủi ro "what you see in Git is what actually gets applied" bị lệch do templating phức tạp.

• Kustomize: overlay theo môi trường, patch strategic-merge vs JSON patch.

Bài tập:

1. Deploy 1 Helm chart qua Argo CD multi-source (chart từ 1 repo, values từ repo khác).

2. Bật Source Hydrator cho 1 Application, quan sát nhánh Git được tạo tự động chứa manifest đã render.

3. Viết Kustomize base + 3 overlay (dev/staging/prod) khác nhau về replicas và resource limits.

Ngày 6 - RBAC, SSO, Notifications

• RBAC nội bộ Argo CD (khác RBAC Kubernetes) - policy CSV, role readonly/admin, gán theo group SSO.

• Từ v3.0: logs RBAC enforce mặc định - nếu nâng cấp từ v2 mà không cấu hình lại, user sẽ mất quyền xem log pod trên UI mà không rõ lý do; đây là 1 breaking change hay bị bỏ sót.

• Tích hợp SSO qua Dex (OIDC/LDAP).

• Notifications controller: gửi Slack/Teams khi sync fail, health degraded.

Bài tập:

1. Viết RBAC policy: team A chỉ đọc (readonly) toàn hệ thống nhưng full quyền trên AppProject của họ.

2. Cấu hình logs RBAC tường minh sau khi giả lập nâng cấp lên v3.

3. Cấu hình Notifications gửi Slack khi bất kỳ Application nào chuyển sang Degraded.

PHASE 2 - Tuần 2: Flux sâu (Ngày 7–11)

Ngày 7 - Kiến trúc GitOps Toolkit

• 5 controller chính, mỗi cái làm 1 việc: source-controller (fetch Git/Helm/OCI artifact), kustomize-controller (apply Kustomization), helm-controller (quản lý HelmRelease - tạo Helm release thật, thấy được trong helm list, khác hẳn Argo CD), notification-controller, image-automation-controller + image-reflector-controller.

• Không có UI/API server riêng - mọi quyền truy cập dựa hoàn toàn vào Kubernetes RBAC (kubectl + RoleBinding), không có user database riêng như Argo CD.

• Bootstrap Flux vào cluster bằng flux bootstrap github/gitlab - tự tạo repo, tự commit manifest Flux vào đó (chính Flux cũng được quản lý theo GitOps).

Bài tập:

1. Bootstrap Flux v2.8 vào kind bằng flux bootstrap, quan sát repo Git được tạo tự động.

2. Tạo GitRepository + Kustomization để sync 1 thư mục manifest.

3. So sánh: xoá Flux khỏi cluster rồi bootstrap lại - dữ liệu resume từ Git ra sao (đây là bài học disaster-recovery quan trọng: Flux tự "vô trạng thái", mọi thứ nằm trong Git + cluster hiện tại).

Ngày 8 - HelmRelease & OCIRepository

• HelmRelease CRD: install/upgrade remediation strategy, rollback tự động khi health check fail, Helm test integration - Flux có lifecycle management chi tiết hơn Argo CD ở khoản Helm thuần.

• OCIRepository: kéo Helm chart hoặc manifest từ OCI registry, hỗ trợ semver range (>=6.0.0) và digest pinning - chi tiết hơn OCI support hiện tại của Argo CD.

• SOPS: mã hoá secret ngay trong Git, Flux tự giải mã lúc apply - pattern "encrypted values in Git" khác hẳn cách Argo CD thường phải dựa vào plugin/Vault bên ngoài.

Bài tập:

1. Viết HelmRelease deploy 1 chart với remediation strategy tự rollback khi upgrade fail.

2. Viết OCIRepository theo dõi semver range của 1 chart trên ghcr.io.

3. Mã hoá 1 Secret bằng SOPS (age hoặc PGP key), commit vào Git, xác nhận Flux giải mã đúng lúc apply.

Ngày 9 - Image Automation

• ImageRepository/ImagePolicy (image-reflector-controller) quét registry tìm tag mới theo policy (semver, alphabetical, numerical).

• ImageUpdateAutomation (image-automation-controller) tự commit ngược lại Git khi có image mới - vòng lặp "CI build image → Flux tự cập nhật tag trong Git → tự deploy" mà không cần con người bấm nút.

• So sánh với Argo CD Image Updater (plugin riêng, không phải core) - Flux có sẵn tính năng này native.

Bài tập:

1. Cấu hình ImagePolicy theo dõi semver mới nhất của 1 image.

2. Cấu hình ImageUpdateAutomation tự commit tag mới vào file Kustomization, xác nhận Flux tự sync theo commit đó.

Ngày 10 - Multi-tenancy trong Flux

• Vì không có AppProject như Argo CD, multi-tenancy dựa vào: Kustomization.spec.serviceAccountName (impersonation - Flux chạy reconcile bằng identity của ServiceAccount đó, giới hạn quyền qua RoleBinding) + namespace isolation cho từng team's GitRepository/Kustomization.

• Pattern "Kustomization of Kustomizations" (tương đương app-of-apps của Argo).

Bài tập:

1. Tạo 2 team, mỗi team có ServiceAccount riêng với Role giới hạn namespace, gán vào Kustomization.spec.serviceAccountName tương ứng.

2. Viết cấu trúc "Kustomization gốc" trỏ tới nhiều Kustomization con theo từng team.

Ngày 11 - Chọn công cụ đúng cho từng bài toán (không chọn kiểu tôn giáo)

• Bảng quyết định thực tế: cần UI cho dev không rành kubectl → Argo CD; cần release lifecycle Helm chi tiết (rollback tự động, test hook) → Flux; cần SSO/RBAC tập trung nhiều cluster → Argo CD; muốn footprint nhẹ, hàng trăm cluster, không muốn thêm control-plane có UI → Flux; cần cả hai đặc điểm → nhiều tổ chức lớn dùng Flux để reconcile + Argo CD chỉ để hiển thị (Argo CD có thể "adopt" resource do Flux tạo ra để xem, dù không phổ biến và có rủi ro 2 controller giẫm chân nhau nếu cấu hình sai).

Bài tập:

1. Viết 1 trang quyết định (decision doc) thật cho tổ chức giả định: 5 team, 20 cluster, một nửa dùng Helm nặng, một nửa cần self-service UI.

PHASE 3 - Tuần 3: Progressive Delivery (Ngày 12–16)

Ngày 12 - Khái niệm & chiến lược release

• Rolling Update (mặc định K8s) vs Blue-Green (2 môi trường song song, chuyển traffic tức thì, rollback tức thì) vs Canary (tăng dần % traffic, có thể tự động dừng nếu metric xấu).

• Feature Flags vs Progressive Delivery: 2 khái niệm khác nhau - feature flag kiểm soát logic trong code, progressive delivery kiểm soát traffic tới version hạ tầng. Chúng bổ trợ, không thay thế nhau.

Bài tập:

1. Thực hiện Rolling Update thường bằng kubectl set image, quan sát Argo CD/Flux hiển thị trạng thái trong lúc rollout.

2. Vẽ sơ đồ so sánh 3 chiến lược, chỉ rõ rollback time và blast radius của từng loại.

Ngày 13 - Argo Rollouts

• Rollout CRD thay thế Deployment, tích hợp AnalysisTemplate/AnalysisRun để tự động promote/abort dựa trên metric Prometheus.

• Traffic management: cần 1 traffic provider (Istio VirtualService, NGINX Ingress canary annotation, ALB weighted target group, SMI) - Argo Rollouts tự nó không route traffic, nó điều khiển traffic provider.

Bài tập:

1. Chuyển 1 Deployment sang Rollout với chiến lược Canary 4 bước (10%→30%→60%→100%).

2. Viết AnalysisTemplate query Prometheus (error rate < 1%) để tự động abort nếu vi phạm.

3. Tích hợp với NGINX Ingress để thực hiện canary traffic splitting thật.

Ngày 14 - Blue-Green với Argo Rollouts

• activeService/previewService, prePromotionAnalysis/postPromotionAnalysis, thời gian giữ bản preview trước khi promote.

Bài tập:

1. Cấu hình Blue-Green với autoPromotionEnabled: false, thực hiện promote thủ công sau khi kiểm tra preview service.

2. Thêm prePromotionAnalysis chạy smoke test tự động trước khi cho phép promote.

Ngày 15 - Flagger (tương đương phía Flux)

• Flagger làm việc tương tự Argo Rollouts nhưng tích hợp tự nhiên với hệ sinh thái Flux, hỗ trợ Istio/Linkerd/App Mesh/Gloo/NGINX/Contour.

• Canary CRD của Flagger + MetricTemplate (tương đương AnalysisTemplate).

Bài tập:

1. Cài Flagger, chuyển 1 Deployment sang canary release qua Flagger + NGINX Ingress.

2. Viết MetricTemplate custom check latency p99 từ Prometheus.

3. So sánh trải nghiệm cấu hình Flagger vs Argo Rollouts cho cùng 1 use case canary.

Ngày 16 - Tích hợp observability cho progressive delivery

• Dashboard Grafana theo dõi rollout đang chạy: % traffic hiện tại, error rate theo version, thời gian mỗi bước.

• Alert khi rollout bị Paused quá lâu (dấu hiệu human cần can thiệp) hoặc Degraded/abort tự động.

Bài tập:

1. Xây dashboard Grafana hiển thị song song metric của phiên bản cũ và mới trong lúc canary chạy.

2. Viết alert Slack khi Argo Rollouts/Flagger tự động abort 1 release.

PHASE 4 - Tuần 4: Argo Events & Argo Workflows (Ngày 17–21)

Ngày 17 - Argo Workflows cơ bản

• Workflow, WorkflowTemplate, Template (container/script/DAG/steps), Artifact (input/output giữa các bước, lưu ở S3/GCS/MinIO).

Bài tập:

1. Viết Workflow 3 bước tuần tự xử lý dữ liệu, truyền artifact giữa các bước qua MinIO.

2. Tạo WorkflowTemplate tái sử dụng, gọi lại từ nhiều Workflow khác nhau.

Ngày 18 - DAG nâng cao

• DAG với dependency phức tạp, when condition, retry strategy, withParam/withItems để chạy song song theo tập dữ liệu động.

Bài tập:

1. Viết DAG có 2 nhánh song song hội tụ vào 1 bước cuối, có retry với backoff cho bước hay lỗi.

2. Dùng withParam chạy N job song song theo danh sách file đầu vào động (lấy từ output bước trước).

Ngày 19 - Argo Events

• EventSource (webhook, SQS, Kafka, cron, GitHub, ...), Sensor, Trigger (khởi chạy Workflow/K8s object/HTTP request khi điều kiện khớp) - kiến trúc pub/sub dựa trên NATS/EventBus nội bộ.

Bài tập:

1. Cài Argo Events, tạo EventSource nhận webhook GitHub.

2. Viết Sensor + Trigger khởi chạy 1 Argo Workflow khi có push event.

Ngày 20 - Tích hợp Workflows/Events với vòng lặp GitOps

• Pattern thực tế: Argo Events trigger Workflow build+push image → Flux Image Automation hoặc Argo CD Image Updater phát hiện tag mới → tự cập nhật Git → GitOps controller deploy. Vẽ toàn bộ vòng lặp end-to-end.

Bài tập:

1. Nối toàn bộ chuỗi: push code → Argo Events trigger Workflow build image → push registry → Flux Image Automation cập nhật Git → Flux deploy bản mới.

Ngày 21 - Ôn tập tuần 4 + so sánh với Airflow/Kubeflow

• Khi nào Argo Workflows đủ dùng, khi nào cần Airflow (lịch phức tạp, dependency giữa nhiều pipeline dài hạn) hay Kubeflow Pipelines (chuyên biệt cho ML) thay vì cố nhét mọi thứ vào Argo Workflows.

Bài tập:

1. Viết 1 trang so sánh ngắn: Argo Workflows vs Airflow - chọn cái nào cho bài toán ETL hàng ngày có 50 task phụ thuộc nhau.

PHASE 5 - Tuần 5: Bảo mật & Policy as Code (Ngày 22–26)

Ngày 22 - Quản lý secret trong GitOps: so sánh thật các phương án

• SOPS (mã hoá field trong file, giải mã lúc apply - Flux native, Argo CD cần plugin): tốt cho team nhỏ, secret ít thay đổi.

• Sealed Secrets (Bitnami): mã hoá 1 chiều bằng public key của controller trong cluster, chỉ controller đó giải mã được - phù hợp khi muốn secret gắn chặt với 1 cluster cụ thể.

• External Secrets Operator + Vault/AWS Secrets Manager: secret không nằm trong Git ở bất kỳ dạng nào, ESO đồng bộ vào K8s Secret - phù hợp production lớn, cần rotation, audit trail tập trung.

• Không có phương án nào "đúng tuyệt đối" - chọn theo mức độ compliance và quy mô team.

Bài tập:

1. Triển khai cả 3 phương án cho cùng 1 secret DB password, so sánh độ phức tạp vận hành và khả năng rotate.

2. Viết runbook: khi 1 secret bị lộ, quy trình rotate với từng phương án khác nhau ra sao.

Ngày 23 - Supply chain security

• Ký artifact (container image, Helm chart, OCI manifest) bằng Sigstore/cosign - keyless signing với OIDC.

• Verify chữ ký ở tầng admission bằng Kyverno (verifyImages) hoặc policy-controller (Sigstore) - chặn image chưa ký được deploy.

• SLSA provenance cơ bản: build từ CI có ký attestation, không chỉ ký image.

Bài tập:

1. Ký 1 image bằng cosign (keyless, qua GitHub OIDC), viết Kyverno policy chặn image chưa ký.

2. Thử deploy 1 image chưa ký, xác nhận bị admission controller chặn với thông báo rõ ràng.

Ngày 24 - Policy as Code cho manifest GitOps

• OPA/Conftest chạy trong CI (kiểm tra manifest trước khi merge - "shift-left") vs Kyverno/Gatekeeper chạy ở admission (chặn lúc apply - lớp phòng thủ thứ hai).

• Viết policy thực tế: cấm hostNetwork: true, bắt buộc resources.limits, bắt buộc label cost-center, giới hạn image registry được phép dùng.

Bài tập:

1. Viết policy Conftest chạy trong CI chặn PR nếu manifest thiếu resources.limits.

2. Viết Kyverno ClusterPolicy tương đương ở tầng admission làm lớp phòng thủ thứ hai (đề phòng ai đó bypass CI).

3. Viết policy chỉ cho phép pull image từ registry nội bộ, chặn docker.io trực tiếp.

Ngày 25 - RBAC & kiểm soát truy cập GitOps thực tế

• Ranh giới quyền: ai được sửa Git (PR review, CODEOWNERS) vs ai được cấu hình chính công cụ GitOps (Argo CD RBAC / Flux ServiceAccount) vs ai có quyền admin cluster thật - 3 lớp độc lập, dễ nhầm là 1.

• Bảo vệ nhánh Git (branch protection) là một phần bắt buộc của "security" trong GitOps - vì Git chính là control plane, ai push được vào nhánh main coi như có quyền deploy.

Bài tập:

1. Thiết lập CODEOWNERS + branch protection cho repo platform, yêu cầu 2 approval cho thay đổi vào namespace prod.

2. Vẽ sơ đồ 3 lớp quyền (Git / công cụ GitOps / cluster RBAC) cho tổ chức giả định 4 team.

Ngày 26 - Incident response cho GitOps

• Khi phát hiện 1 commit độc hại đã được auto-sync vào production: quy trình git revert + force-sync + kiểm tra tài nguyên đã bị thay đổi có cần rollback thủ công thêm (ví dụ DB migration không tự revert được).

• Tạm dừng auto-sync (syncPolicy.automated tắt / Flux suspend: true) trong lúc điều tra, tránh commit revert bị "resync đè" nếu ai đó push tiếp trong lúc xử lý.

Bài tập:

1. Mô phỏng 1 incident: commit sai vào main, auto-sync đã áp dụng. Viết đúng thứ tự thao tác xử lý.

2. Viết runbook "tạm dừng GitOps controller trong bảo trì khẩn cấp" cho cả Argo CD và Flux.

PHASE 6 - Tuần 6: Observability, Scale, Multi-cluster thực tế (Ngày 27–31)

Ngày 27 - Observability cho chính công cụ GitOps

• Metrics Argo CD: argocd_app_info (label chứa sync/health status - các metric cũ argocd_app_sync_status đã bị xoá, dùng label trên argocd_app_info thay thế), argocd_app_reconcile_*.

• Metrics Flux: mỗi controller export metric riêng (gotk_reconcile_duration_seconds, gotk_reconcile_condition).

• Dashboard Grafana: app nào OutOfSync/Degraded lâu nhất, thời gian reconcile trung bình theo cluster.

Bài tập:

1. Cài ServiceMonitor scrape Argo CD + Flux, dùng label trên argocd_app_info (không dùng metric deprecated) để build dashboard.

2. Alert khi 1 Application ở trạng thái Degraded > 15 phút.

Ngày 28 - Multi-cluster thực tế

• Pattern hub-spoke: 1 cluster quản lý (chạy Argo CD/Flux control plane) + N cluster workload - ApplicationSet Cluster generator hoặc bootstrap Flux riêng từng cluster.

• So sánh: Argo CD hub-spoke (1 UI quản lý tất cả) vs Flux per-cluster (mỗi cluster tự chủ, không phụ thuộc 1 hub duy nhất - tốt hơn cho fault isolation).

• Cluster API (nếu cần tự động hoá cả vòng đời tạo/xoá cluster theo GitOps, không chỉ deploy app lên cluster có sẵn) - công cụ riêng biệt, không phải Argo CD/Flux.

Bài tập:

1. Setup 3 cluster kind, đăng ký cả 3 vào 1 Argo CD hub, dùng ApplicationSet Cluster generator fan-out 1 app.

2. Làm lại tương tự bằng cách bootstrap Flux độc lập trên từng cluster (per-cluster repo pattern), so sánh độ phức tạp vận hành khi 1 cluster bị mất kết nối.

Ngày 29 - Scale control plane

• Argo CD: sharding argocd-application-controller theo cluster, scale argocd-repo-server theo số lượng Application/kích thước repo, tuning Redis cache.

• Flux: source-controller là điểm nghẽn khi nhiều GitRepository cùng poll - tối ưu bằng --concurrent flag, giảm interval polling không cần thiết, ưu tiên OCI artifact thay vì Git polling liên tục cho các resource ít đổi.

Bài tập:

1. Load test: tạo 200 Application trên 1 Argo CD instance, đo thời gian reconcile, bật sharding và đo lại.

2. Tuning --concurrent cho Flux kustomize-controller, đo throughput trước/sau.

Ngày 30 - Disaster recovery cho chính GitOps control plane

• Vì bản thân Argo CD/Flux là stateless theo thiết kế (mọi state quan trọng nằm trong Git + cluster), DR chủ yếu là: backup Git (đã có sẵn qua remote), backup cấu hình Argo CD (Application/AppProject - nên tự chúng cũng nằm trong Git theo app-of-apps để tái tạo control plane từ đầu).

• Backup dữ liệu ứng dụng thật (PVC, database) là việc khác, ngoài phạm vi GitOps controller - vẫn cần Velero/snapshot riêng.

Bài tập:

1. Xoá hoàn toàn Argo CD khỏi cluster, cài lại từ đầu, chỉ dùng app-of-apps repo để tái tạo toàn bộ cấu hình.

2. Viết runbook DR: thời gian phục hồi ước tính (RTO) cho kịch bản mất control-plane cluster.

Ngày 31 - Ôn tập tuần 6, chuẩn bị capstone

PHASE 7 - Tuần 7: Capstone Projects (Ngày 32–35)

Capstone 1 (Ngày 32–33): Hệ thống GitOps hoàn chỉnh cho ứng dụng microservices

Yêu cầu:

1. Repo tách theo pattern "per-cluster/per-env" hoặc "monorepo + overlay" (tự chọn, giải thích lý do).

2. Dùng Argo CD ApplicationSet fan-out qua dev/staging/prod, mỗi môi trường có AppProject riêng giới hạn quyền.

3. Áp dụng Canary release bằng Argo Rollouts cho service quan trọng nhất, có AnalysisTemplate tự abort.

4. Secret quản lý qua External Secrets Operator + Vault.

5. Policy Kyverno chặn image chưa ký, bắt buộc resource limits.

6. Dashboard Grafana + alert Slack khi Degraded.

7. Viết runbook incident response đầy đủ.

Capstone 2 (Ngày 34–35): Tự động hoá quản lý hạ tầng bằng GitOps

Yêu cầu:

1. Dùng Flux quản lý cấu hình hạ tầng: service mesh (Istio/Linkerd), ingress controller, storage (Rook/Longhorn) - theo pattern layer riêng, tách khỏi layer ứng dụng.

2. HelmRelease với remediation strategy cho từng thành phần hạ tầng.

3. Image Automation cho các add-on cần cập nhật thường xuyên (ingress controller, cert-manager).

4. Policy as Code (Conftest ở CI + Kyverno ở admission) đảm bảo mọi thay đổi hạ tầng tuân thủ chuẩn bảo mật tối thiểu.

5. Viết tài liệu so sánh: nếu phải chọn lại từ đầu giữa Argo CD và Flux cho riêng layer hạ tầng này, bạn chọn gì và vì sao - bảo vệ quan điểm bằng dữ liệu thu thập được suốt khoá học, không phải cảm tính.