Lesson 9: Helm, GitOps & CI/CD

1. Helm — Kubernetes Package Manager

Helm is the package manager for Kubernetes. Charts are reusable, parameterizable YAML templates.

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	Function
helm install	Deploy a new chart (create a release)
helm upgrade	Update a release with a new chart/values
helm rollback	Revert to a previous revision
helm list	List all releases
helm uninstall	Remove a release
helm template	Render templates without deploying

Exam tip: Helm stores release history in Kubernetes Secrets (not ConfigMaps). This enables helm rollback to work. History retains 10 revisions by default.

2. GitOps

GitOps is an operational framework that uses Git as the single source of truth for both code and infrastructure configuration.

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	Meaning
Declarative	System state described in YAML in Git
Versioned & immutable	Git history = audit trail
Pulled automatically	Agent pulls changes, no push access to cluster needed
Continuously reconciled	Drift detection — auto-correct if cluster differs from Git

Argo CD

Argo CD is the most popular GitOps controller for Kubernetes (CNCF Incubating → Graduated 2022).

Exam tip: GitOps uses pull-based deployment instead of push. Benefits: the cluster doesn't need to expose its API externally, and CI pipelines don't need kubeconfig credentials.

3. CI/CD for 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	How it works	Downtime	Rollback	Use when
Rolling Update	Replace pods gradually (default)	None	kubectl rollout undo	Stateless apps, gradual
Recreate	Kill all v1, then deploy v2	Yes	Redeploy v1	Breaking changes, simple
Blue-Green	Run v1 (blue) + v2 (green) side by side, switch traffic	None	Switch back instantly	Critical apps, fast rollback
Canary	Route small % traffic to new version	None	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

Exam question	Answer
Where does Helm store release history?	Kubernetes Secrets
GitOps single source of truth?	Git repository
Does GitOps use pull or push?	Pull-based (agent pulls)
Deployment with no downtime?	Rolling or Blue-Green
Test new version with 5% traffic?	Canary deployment
Fast rollback when issues arise?	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.