xDev Asia

Helm package manager, GitOps với Argo CD, CI/CD pipelines cho Kubernetes. Deployment strategies: rolling update, canary, blue-green.

1. Helm — Kubernetes Package Manager

Helm là package manager cho Kubernetes. Charts là template YAML có thể reuse và parameterize.

Helm Concepts:
  Chart     = Package (templates + default values)
  Release   = Installed instance of a chart in a cluster
  Repository = Collection of charts (ArtifactHub.io)
  Values    = Parameters to customize a chart

$ helm install my-nginx bitnami/nginx --set service.type=LoadBalancer
  └── Release: my-nginx
      ├── templates/deployment.yaml
      ├── templates/service.yaml
      └── values.yaml (overridden)

Helm Command	Chức năng
`helm install`	Deploy chart mới (tạo release)
`helm upgrade`	Update release với chart mới/values mới
`helm rollback`	Khôi phục về revision trước
`helm list`	Liệt kê tất cả releases
`helm uninstall`	Xóa release
`helm template`	Render templates mà không deploy

Exam tip: Helm lưu release history trong Kubernetes Secrets (không phải ConfigMap). Điều này cho phép helm rollback hoạt động. History mặc định giữ 10 revisions.

2. GitOps

GitOps là operational framework dùng Git làm single source of truth cho cả code lẫn infrastructure config.

GitOps Flow:
  Developer ──push──► Git Repo (desired state)
                          │
                    GitOps Operator (Argo CD / Flux)
                    - Watches Git repo
                    - Compares with cluster state
                    - Syncs if diff found
                          │
                       K8s Cluster (actual state)

GitOps Principle	Ý nghĩa
Declarative	System state mô tả bằng YAML trong Git
Versioned & immutable	Git history = audit trail
Pulled automatically	Agent pull changes, không cần push access vào cluster
Continuously reconciled	Drift detection — auto-correct nếu cluster khác Git

Argo CD

Argo CD là GitOps controller phổ biến nhất cho Kubernetes (CNCF Incubating → Graduated 2022).

Exam tip: GitOps dùng pull-based deployment thay vì push. Lợi ích: cluster không cần expose API ra bên ngoài, CI pipeline không cần kubeconfig credentials.

3. CI/CD cho Kubernetes

CI/CD Pipeline:
  Code Push
      │
  ┌───▼───┐  CI Phase (Build)
  │ Build  │── Unit tests ── Integration tests
  │ Image  │── Security scan (Trivy, Snyk)
  └───┬───┘── Push to Registry (ECR, GCR)
      │
  ┌───▼───┐  CD Phase (Deploy)
  │ Update │── Update Helm values / K8s manifest
  │ Manifest│── Push to GitOps repo
  └───┬───┘── Argo CD picks up and syncs
      │
  ┌───▼────────────────────┐
  │ Kubernetes Cluster     │
  │  Rolling Update        │
  └────────────────────────┘

4. Deployment Strategies

Strategy	Cách hoạt động	Downtime	Rollback	Dùng khi
Rolling Update	Replace pods gradually (default)	Không	kubectl rollout undo	Stateless apps, gradual
Recreate	Kill all v1, then deploy v2	Có	Redeploy v1	Breaking changes, simple
Blue-Green	Run v1 (blue) + v2 (green) side by side, switch traffic	Không	Switch back instantly	Kritisch apps, fast rollback
Canary	Route small % traffic to new version	Không	Redirect traffic	Staged rollout, A/B testing

Canary in Kubernetes (Ingress weight):
  ┌─────────────────────────────────┐
  │  Ingress (canary annotation)     │
  │  90% ──────► Deployment v1.0    │
  │  10% ──────► Deployment v1.1    │
  └─────────────────────────────────┘
  → Monitor v1.1 errors → promote to 100% or rollback

5. Cheat Sheet

Câu hỏi exam	Đáp án
Helm lưu release history ở đâu?	Kubernetes Secrets
GitOps single source of truth?	Git repository
GitOps dùng pull hay push?	Pull-based (agent pulls)
Deployment không có downtime?	Rolling hoặc Blue-Green
Test new version với 5% traffic?	Canary deployment
Fast rollback khi có issue?	Blue-Green (instant switch)

6. Practice Questions

Q1: A team wants to deploy a new version of their app to 10% of users first, monitor for errors, then gradually increase traffic. Which deployment strategy should they use?

A) Recreate
B) Rolling Update
C) Blue-Green
D) Canary ✓

Explanation: Canary deployment routes a small percentage of traffic to the new version, allowing teams to validate it with real traffic before full rollout. This minimizes blast radius if the new version has bugs.

Q2: Which of the following best describes the GitOps model?

A) CI/CD pipeline pushes directly to Kubernetes after tests pass
B) Git repository is the single source of truth; a controller continuously reconciles cluster state with Git ✓
C) Developers manually apply kubectl commands from their workstations
D) Infrastructure is defined in a relational database for consistency

Explanation: GitOps uses a pull-based model where a controller (Argo CD, Flux) watches a Git repository and ensures the cluster matches what's declared in Git. This provides audit trail, drift detection, and secure deployments.

Q3: Where does Helm store release history to enable rollback capability?

A) Helm's local filesystem (~/.helm)
B) ConfigMap in the target namespace
C) Secret in the target namespace ✓
D) A separate etcd database

Explanation: Since Helm v3, release metadata (history, values, chart info) is stored as Secrets in the release's namespace. This enables helm rollback by reading previous revision data, and allows multiple users/systems to manage the same release.