@xdev-asia/xdev-knowledge-mcp 1.0.44 → 1.0.46

package/content/series/luyen-thi/luyen-thi-ckad/chapters/01-app-design-build/lessons/01-multi-container-pods.md

@@ -0,0 +1,146 @@
+---
+id: ckad-d1-l01
+title: 'Bài 1: Multi-container Pods & Init Containers'
+slug: 01-multi-container-pods
+description: >-
+  Multi-container Pod patterns: Sidecar, Ambassador, Adapter. Init Containers
+  cho prerequisites. Shared volumes giữa containers. CKAD hands-on tasks.
+duration_minutes: 55
+is_free: true
+video_url: null
+sort_order: 1
+section_title: "Domain 1: Application Design and Build (20%)"
+course:
+  id: lt-ckad-series-001
+  title: 'Luyện thi CKAD — Certified Kubernetes Application Developer'
+  slug: luyen-thi-ckad
+---
+
+<img src="/storage/uploads/2026/04/k8s-cert-ckad-bai1-multicontainer.png" alt="Multi-Container Pod Patterns — Sidecar, Ambassador, Adapter và Init Containers" style="max-width: 800px; width: 100%; border-radius: 12px;" />
+
+<h2 id="multi-container">1. Multi-container Pod Patterns</h2>
+
+<p>Containers trong cùng một Pod chia sẻ: network (same IP), IPC, và có thể chia sẻ storage volumes. Dùng nhiều containers khi chúng cần phối hợp chặt chẽ.</p>
+
+<table>
+<thead><tr><th>Pattern</th><th>Vai trò</th><th>Ví dụ thực tế</th></tr></thead>
+<tbody>
+<tr><td><strong>Sidecar</strong></td><td>Extend/enhance container chính (cùng lifecycle)</td><td>Log shipper, service mesh proxy (Envoy), config reloader</td></tr>
+<tr><td><strong>Ambassador</strong></td><td>Proxy traffic đến/từ container chính</td><td>Local proxy cache, connection multiplexer</td></tr>
+<tr><td><strong>Adapter</strong></td><td>Transform output của container chính</td><td>Metrics format converter (app → Prometheus format)</td></tr>
+</tbody>
+</table>
+
+<pre><code class="language-text">Sidecar Pattern:
+┌─────────────────────────────────────────────┐
+│                    POD                      │
+│  ┌──────────────┐    ┌─────────────────┐    │
+│  │  App         │    │  Log Sidecar    │    │
+│  │  Container   │    │  (Fluentd)      │    │
+│  └──────┬───────┘    └────────┬────────┘    │
+│         │                     │             │
+│         └──── Shared Volume ──┘             │
+│              /var/log/app                   │
+└─────────────────────────────────────────────┘</code></pre>
+
+<h2 id="multi-container-yaml">2. Multi-container Pod YAML</h2>
+
+<pre><code class="language-text">apiVersion: v1
+kind: Pod
+metadata:
+  name: web-with-sidecar
+spec:
+  containers:
+  - name: web
+    image: nginx:1.21
+    volumeMounts:
+    - name: shared-logs
+      mountPath: /var/log/nginx
+
+  - name: log-shipper
+    image: fluent/fluentd:v1.14
+    volumeMounts:
+    - name: shared-logs
+      mountPath: /var/log/nginx
+      readOnly: true  # Sidecar reads, doesn't write
+
+  volumes:
+  - name: shared-logs
+    emptyDir: {}     # Ephemeral, lost when pod deleted</code></pre>
+
+<blockquote><p><strong>Exam tip:</strong> CKAD thường cho task tạo Pod với sidecar container. Key điểm: cần shared volume để containers communicate, và cả 2 containers phải mount volume đúng path. Sidecar thường mount <code>readOnly: true</code>.</p></blockquote>
+
+<h2 id="init-containers">3. Init Containers</h2>
+
+<p><strong>Init Containers</strong> chạy trước main containers, phải hoàn thành thành công trước khi Pod start. Dùng cho: DB migration, wait for dependency, pre-populate volume.</p>
+
+<pre><code class="language-text">apiVersion: v1
+kind: Pod
+metadata:
+  name: app-with-init
+spec:
+  initContainers:
+  - name: wait-for-db
+    image: busybox
+    command: ['sh', '-c', 'until nc -z postgres-service 5432; do sleep 2; done']
+
+  - name: db-migrate
+    image: myapp:1.0
+    command: ['python', 'manage.py', 'migrate']
+
+  containers:
+  - name: app
+    image: myapp:1.0
+    ports:
+    - containerPort: 8000</code></pre>
+
+<table>
+<thead><tr><th>Property</th><th>Init Container</th><th>Regular Container</th></tr></thead>
+<tbody>
+<tr><td>Execution order</td><td>Sequential, all before app</td><td>Parallel start</td></tr>
+<tr><td>Must complete?</td><td>Yes (exit 0)</td><td>Runs continuously</td></tr>
+<tr><td>Liveness probe</td><td>Not supported</td><td>Supported</td></tr>
+<tr><td>Resources</td><td>Counted separately</td><td>Normal requests/limits</td></tr>
+</tbody>
+</table>
+
+<h2 id="cheatsheet">4. Cheat Sheet</h2>
+
+<table>
+<thead><tr><th>Câu hỏi exam</th><th>Đáp án</th></tr></thead>
+<tbody>
+<tr><td>Log collection từ app container?</td><td><strong>Sidecar</strong> với shared volume</td></tr>
+<tr><td>Wait for service before starting?</td><td><strong>Init Container</strong></td></tr>
+<tr><td>Run DB migration before app?</td><td><strong>Init Container</strong> với migration command</td></tr>
+<tr><td>Shared storage giữa containers?</td><td><strong>emptyDir</strong> volume</td></tr>
+</tbody>
+</table>
+
+<h2 id="practice">5. Practice Questions</h2>
+
+<p><strong>Q1:</strong> You need to ensure a Pod's main application only starts after a config file is downloaded from an external URL. What is the best approach?</p>
+<ul>
+<li>A) Use a Sidecar container to download the file</li>
+<li>B) Use an Init Container that runs wget and completes before the main container starts ✓</li>
+<li>C) Use a DaemonSet to pre-populate config on all nodes</li>
+<li>D) Mount a ConfigMap as the initial configuration</li>
+</ul>
+<p><em>Explanation: Init Containers run sequentially before main containers and must complete (exit 0). They're perfect for "prerequisites" like downloading config, waiting for services, or running migrations. Sidecar runs in parallel alongside the main container.</em></p>
+
+<p><strong>Q2:</strong> Two containers in the same Pod need to share data. Container A writes to /tmp/data, Container B reads from /tmp/data. What should you configure?</p>
+<ul>
+<li>A) ExternalDNS shared volume</li>
+<li>B) emptyDir volume mounted at /tmp/data in both containers ✓</li>
+<li>C) A PersistentVolumeClaim for each container</li>
+<li>D) ConfigMap mounted as a volume</li>
+</ul>
+<p><em>Explanation: emptyDir is created when a Pod is assigned to a Node, and deleted when the Pod is removed. It's perfect for sharing ephemeral data between containers in the same Pod. Both containers mount it at the same path.</em></p>
+
+<p><strong>Q3:</strong> A Pod has a single Init Container that keeps failing (exit code 1). What happens to the main application container?</p>
+<ul>
+<li>A) The main container starts after a timeout</li>
+<li>B) The main container is skipped and the Pod succeeds</li>
+<li>C) The main container never starts; Pod shows Init:Error or Init:CrashLoopBackOff ✓</li>
+<li>D) The init container failure is ignored if main container is defined</li>
+</ul>
+<p><em>Explanation: Init Containers MUST exit with code 0. If they fail, Kubernetes restarts them based on Pod's restartPolicy. The main container never starts until all init containers complete successfully.</em></p>

package/content/series/luyen-thi/luyen-thi-ckad/chapters/01-app-design-build/lessons/02-jobs-cronjobs-resources.md

@@ -0,0 +1,174 @@
+---
+id: ckad-d1-l02
+title: 'Bài 2: Jobs, CronJobs & Resource Management'
+slug: 02-jobs-cronjobs-resources
+description: >-
+  Jobs (batch tasks), CronJobs (scheduled tasks). Resource requests và limits,
+  LimitRange, ResourceQuota. QoS classes cho CKAD exam.
+duration_minutes: 55
+is_free: true
+video_url: null
+sort_order: 2
+section_title: "Domain 1: Application Design and Build (20%)"
+course:
+  id: lt-ckad-series-001
+  title: 'Luyện thi CKAD — Certified Kubernetes Application Developer'
+  slug: luyen-thi-ckad
+---
+
+<img src="/storage/uploads/2026/04/k8s-cert-ckad-bai2-jobs.png" alt="Jobs và CronJobs — completions, parallelism, concurrencyPolicy" style="max-width: 800px; width: 100%; border-radius: 12px;" />
+
+<h2 id="jobs">1. Jobs</h2>
+
+<p>Một <strong>Job</strong> tạo một hoặc nhiều Pods và đảm bảo chúng hoàn thành thành công. Khi Job hoàn thành, Pods không bị xóa (cho log inspection).</p>
+
+<pre><code class="language-text">apiVersion: batch/v1
+kind: Job
+metadata:
+  name: data-processor
+spec:
+  completions: 3       # Run 3 successful completions
+  parallelism: 2       # Run 2 pods at a time
+  backoffLimit: 4      # Retry up to 4 times on failure
+  template:
+    spec:
+      restartPolicy: Never  # OnFailure or Never (required for Job)
+      containers:
+      - name: processor
+        image: busybox
+        command: ['sh', '-c', 'echo Processing; sleep 5']</code></pre>
+
+<table>
+<thead><tr><th>Field</th><th>Ý nghĩa</th><th>Default</th></tr></thead>
+<tbody>
+<tr><td><code>completions</code></td><td>Số lần phải hoàn thành</td><td>1</td></tr>
+<tr><td><code>parallelism</code></td><td>Số Pods chạy concurrent</td><td>1</td></tr>
+<tr><td><code>backoffLimit</code></td><td>Số lần retry khi fail</td><td>6</td></tr>
+<tr><td><code>activeDeadlineSeconds</code></td><td>Timeout tổng thể của Job</td><td>Unlimited</td></tr>
+</tbody>
+</table>
+
+<blockquote><p><strong>Exam tip:</strong> Job Pods phải có <code>restartPolicy: Never</code> hoặc <code>OnFailure</code>. Không thể dùng <code>Always</code> (default cho regular Pods). CKAD hay test việc tạo Job và kiểm tra completion status.</p></blockquote>
+
+<h2 id="cronjobs">2. CronJobs</h2>
+
+<pre><code class="language-text">apiVersion: batch/v1
+kind: CronJob
+metadata:
+  name: nightly-backup
+spec:
+  schedule: "0 2 * * *"  # Cron syntax: minute hour day month weekday
+  concurrencyPolicy: Forbid  # Allow | Forbid | Replace
+  successfulJobsHistoryLimit: 3
+  failedJobsHistoryLimit: 1
+  jobTemplate:
+    spec:
+      template:
+        spec:
+          restartPolicy: OnFailure
+          containers:
+          - name: backup
+            image: backup-tool:1.0
+            command: ['./backup.sh']</code></pre>
+
+<table>
+<thead><tr><th>concurrencyPolicy</th><th>Hành vi</th></tr></thead>
+<tbody>
+<tr><td><strong>Allow</strong></td><td>Cho phép Jobs chạy concurrent (default)</td></tr>
+<tr><td><strong>Forbid</strong></td><td>Skip new Job nếu previous chưa xong</td></tr>
+<tr><td><strong>Replace</strong></td><td>Cancel previous Job, start new one</td></tr>
+</tbody>
+</table>
+
+<h2 id="resources">3. Resource Requests & Limits</h2>
+
+<pre><code class="language-text">spec:
+  containers:
+  - name: app
+    image: myapp
+    resources:
+      requests:
+        cpu: "250m"      # 0.25 CPU core (minimum guaranteed)
+        memory: "128Mi"  # 128 MiB minimum
+      limits:
+        cpu: "500m"      # Max 0.5 CPU core
+        memory: "256Mi"  # Max 256 MiB (OOM if exceeded)</code></pre>
+
+<pre><code class="language-text">QoS Classes (dựa trên requests/limits):
+
+Guaranteed:  requests == limits (both CPU and memory)
+             → Last to be evicted under pressure
+
+Burstable:   requests < limits (or only one set)
+             → Middle priority for eviction
+
+BestEffort:  NO requests, NO limits
+             → First to be evicted under pressure</code></pre>
+
+<blockquote><p><strong>Exam tip:</strong> Để Pod có QoS class <strong>Guaranteed</strong>: phải set cả <code>cpu</code> và <code>memory</code> trong cả <code>requests</code> và <code>limits</code>, và chúng phải bằng nhau. Mỗi container trong Pod đều phải thỏa mãn điều kiện này.</p></blockquote>
+
+<h2 id="limitrange">4. LimitRange & ResourceQuota</h2>
+
+<table>
+<thead><tr><th>Object</th><th>Scope</th><th>Mục đích</th></tr></thead>
+<tbody>
+<tr><td><strong>LimitRange</strong></td><td>Namespace</td><td>Set default requests/limits cho Pods/Containers trong namespace</td></tr>
+<tr><td><strong>ResourceQuota</strong></td><td>Namespace</td><td>Giới hạn tổng resources namespace được dùng</td></tr>
+</tbody>
+</table>
+
+<pre><code class="language-text">ResourceQuota example:
+apiVersion: v1
+kind: ResourceQuota
+metadata:
+  name: dev-quota
+  namespace: development
+spec:
+  hard:
+    requests.cpu: "4"
+    requests.memory: "8Gi"
+    limits.cpu: "8"
+    limits.memory: "16Gi"
+    pods: "20"</code></pre>
+
+<h2 id="cheatsheet">5. Cheat Sheet</h2>
+
+<table>
+<thead><tr><th>Câu hỏi exam</th><th>Đáp án</th></tr></thead>
+<tbody>
+<tr><td>Job cần restartPolicy gì?</td><td><code>Never</code> hoặc <code>OnFailure</code></td></tr>
+<tr><td>CronJob mỗi 5 phút?</td><td><code>*/5 * * * *</code></td></tr>
+<tr><td>Container bị OOM Kill do gì?</td><td>Vượt <code>limits.memory</code></td></tr>
+<tr><td>QoS Guaranteed cần gì?</td><td>requests == limits (cả CPU và Memory)</td></tr>
+<tr><td>Giới hạn resources của namespace?</td><td><strong>ResourceQuota</strong></td></tr>
+</tbody>
+</table>
+
+<h2 id="practice">6. Practice Questions</h2>
+
+<p><strong>Q1:</strong> A Job is configured with completions: 5 and parallelism: 2. How does it execute?</p>
+<ul>
+<li>A) Creates 5 Pods simultaneously until all complete</li>
+<li>B) Runs 2 Pods at a time, creating new ones as old ones complete, until 5 total completions ✓</li>
+<li>C) Runs 5 Pods sequentially one by one</li>
+<li>D) Creates 2 Pods, each completing 2.5 times</li>
+</ul>
+<p><em>Explanation: completions=5 means 5 PODs must exit successfully. parallelism=2 means at most 2 run at once. As each Pod completes, a new one starts until completion count is reached. Total Pods created could be more if some fail.</em></p>
+
+<p><strong>Q2:</strong> A Pod has no resource requests or limits set. What QoS class is it assigned and how does this affect eviction?</p>
+<ul>
+<li>A) Guaranteed — it will be last to be evicted</li>
+<li>B) Burstable — it has medium eviction priority</li>
+<li>C) BestEffort — it will be first to be evicted under resource pressure ✓</li>
+<li>D) NoQoS — it has no eviction priority</li>
+</ul>
+<p><em>Explanation: Pods with no resource requests or limits get BestEffort QoS class. When nodes face resource pressure, Kubernetes evicts BestEffort Pods first to free resources for higher-priority workloads.</em></p>
+
+<p><strong>Q3:</strong> A CronJob is scheduled every hour. A previous job is still running when the next scheduled time arrives. With concurrencyPolicy: Forbid, what happens?</p>
+<ul>
+<li>A) The running job is cancelled; the new one starts</li>
+<li>B) Both jobs run concurrently</li>
+<li>C) The new job is skipped; the running job continues ✓</li>
+<li>D) The CronJob is suspended until the running job completes</li>
+</ul>
+<p><em>Explanation: Forbid policy prevents a new job from starting if the previous job is still running. The scheduled run is skipped. Use Allow to permit concurrent runs or Replace to cancel the old and start the new one.</em></p>

package/content/series/luyen-thi/luyen-thi-ckad/chapters/02-app-deployment/lessons/03-rolling-updates-rollbacks.md

@@ -0,0 +1,148 @@
+---
+id: ckad-d2-l03
+title: 'Bài 3: Rolling Updates, Rollbacks & Deployment Strategies'
+slug: 03-rolling-updates-rollbacks
+description: >-
+  Deployment strategies: RollingUpdate vs Recreate. Kubectl rollout commands,
+  maxUnavailable/maxSurge. Revision history và rollback kỹ thuật cho CKAD.
+duration_minutes: 55
+is_free: true
+video_url: null
+sort_order: 3
+section_title: "Domain 2: Application Deployment (20%)"
+course:
+  id: lt-ckad-series-001
+  title: 'Luyện thi CKAD — Certified Kubernetes Application Developer'
+  slug: luyen-thi-ckad
+---
+
+<img src="/storage/uploads/2026/04/k8s-cert-ckad-bai3-rolling-update.png" alt="Rolling Update và Rollback — maxUnavailable, maxSurge, ReplicaSet history" style="max-width: 800px; width: 100%; border-radius: 12px;" />
+
+<h2 id="strategies">1. Deployment Strategies</h2>
+
+<table>
+<thead><tr><th>Strategy</th><th>Cách hoạt động</th><th>Downtime?</th><th>Khi dùng</th></tr></thead>
+<tbody>
+<tr><td><strong>RollingUpdate</strong></td><td>Replace pods dần dần, maintain availability</td><td>Không</td><td>Default, production</td></tr>
+<tr><td><strong>Recreate</strong></td><td>Kill tất cả pods cũ, tạo mới</td><td>Có</td><td>Dev/test, breaking changes</td></tr>
+</tbody>
+</table>
+
+<pre><code class="language-text">spec:
+  strategy:
+    type: RollingUpdate
+    rollingUpdate:
+      maxUnavailable: 1   # OR "25%"  — Max pods unavailable during update
+      maxSurge: 1         # OR "25%"  — Max extra pods above desired count
+
+      ┌─────────────────────────────────────────────────┐
+      │ Desired: 4 pods                                  │
+      │                                                  │
+      │ maxUnavailable: 1 → min 3 pods must be running  │
+      │ maxSurge: 1       → max 5 pods total at once    │
+      │                                                  │
+      │ Step 1: Create 1 new pod (5 total = desired+surge)│
+      │ Step 2: Terminate 1 old pod (4 total)           │
+      │ Step 3: Repeat until all replaced               │
+      └─────────────────────────────────────────────────┘</code></pre>
+
+<blockquote><p><strong>Exam tip:</strong> <code>maxUnavailable</code> và <code>maxSurge</code> KHÔNG thể cùng lúc là 0. Nếu cần zero-downtime update: set <code>maxUnavailable: 0</code> và <code>maxSurge: 1</code> (hoặc cao hơn).</p></blockquote>
+
+<h2 id="rollout">2. kubectl rollout Commands</h2>
+
+<pre><code class="language-text"># Xem trạng thái rollout
+kubectl rollout status deployment/myapp
+
+# Xem revision history
+kubectl rollout history deployment/myapp
+kubectl rollout history deployment/myapp --revision=2
+
+# Rollback về version trước
+kubectl rollout undo deployment/myapp
+
+# Rollback về revision cụ thể
+kubectl rollout undo deployment/myapp --to-revision=2
+
+# Tạm dừng rollout
+kubectl rollout pause deployment/myapp
+
+# Resume rollout
+kubectl rollout resume deployment/myapp</code></pre>
+
+<table>
+<thead><tr><th>Command</th><th>Tác dụng</th></tr></thead>
+<tbody>
+<tr><td><code>rollout status</code></td><td>Wait/show current rollout progress</td></tr>
+<tr><td><code>rollout history</code></td><td>List revision history</td></tr>
+<tr><td><code>rollout undo</code></td><td>Rollback to previous (or specific) revision</td></tr>
+<tr><td><code>rollout pause/resume</code></td><td>Pause để canary test, rồi resume</td></tr>
+<tr><td><code>rollout restart</code></td><td>Force restart tất cả pods (rolling)</td></tr>
+</tbody>
+</table>
+
+<blockquote><p><strong>Exam tip:</strong> Để lưu <code>CHANGE-CAUSE</code> trong revision history, thêm annotation: <code>kubectl annotate deployment/myapp kubernetes.io/change-cause="Updated image to v2"</code> TRƯỚC khi update. Hoặc dùng <code>--record</code> flag (deprecated nhưng vẫn hoạt động trong exam).</p></blockquote>
+
+<h2 id="trigger">3. Trigger & Monitor Update</h2>
+
+<pre><code class="language-text"># Update image (trigger rolling update)
+kubectl set image deployment/myapp container-name=nginx:1.25
+
+# Xem ReplicaSet history (mỗi update tạo mới 1 RS)
+kubectl get rs
+# NAME              DESIRED   CURRENT   READY
+# myapp-7d9b8c      4         4         4     ← current
+# myapp-6f5a2b      0         0         0     ← old (kept for rollback)
+
+# Scale deployment
+kubectl scale deployment/myapp --replicas=6
+
+# Edit deployment trực tiếp
+kubectl edit deployment/myapp</code></pre>
+
+<h2 id="revisionhistory">4. Revision History Limit</h2>
+
+<pre><code class="language-text">spec:
+  revisionHistoryLimit: 10  # Default: 10 old RS kept for rollback
+                             # Set to 0 to disable rollback capability</code></pre>
+
+<h2 id="cheatsheet">5. Cheat Sheet</h2>
+
+<table>
+<thead><tr><th>Tình huống exam</th><th>Command</th></tr></thead>
+<tbody>
+<tr><td>Update image</td><td><code>kubectl set image deploy/app c=image:v2</code></td></tr>
+<tr><td>Check rollout</td><td><code>kubectl rollout status deploy/app</code></td></tr>
+<tr><td>Rollback nhanh</td><td><code>kubectl rollout undo deploy/app</code></td></tr>
+<tr><td>Rollback về rev 3</td><td><code>kubectl rollout undo deploy/app --to-revision=3</code></td></tr>
+<tr><td>Zero-downtime config</td><td><code>maxUnavailable: 0, maxSurge: 1</code></td></tr>
+</tbody>
+</table>
+
+<h2 id="practice">6. Practice Questions</h2>
+
+<p><strong>Q1:</strong> A Deployment with 10 replicas is configured with maxUnavailable: 2 and maxSurge: 3. During a rolling update, what is the maximum number of pods that can exist at any given time?</p>
+<ul>
+<li>A) 10</li>
+<li>B) 12</li>
+<li>C) 13 ✓</li>
+<li>D) 15</li>
+</ul>
+<p><em>Explanation: maxSurge=3 means up to 3 extra pods above the desired count (10) can exist simultaneously. So maximum = 10 + 3 = 13 pods. Meanwhile, maxUnavailable=2 means at least 8 pods must be available.</em></p>
+
+<p><strong>Q2:</strong> You updated a Deployment and then realized the new version has a bug. Which command quickly reverts to the previous working version?</p>
+<ul>
+<li>A) <code>kubectl delete deployment myapp && kubectl apply -f old.yaml</code></li>
+<li>B) <code>kubectl rollout undo deployment/myapp</code> ✓</li>
+<li>C) <code>kubectl rollout history deployment/myapp</code></li>
+<li>D) <code>kubectl set image deployment/myapp container=old-image</code></li>
+</ul>
+<p><em>Explanation: rollout undo is the fastest way to revert to the previous revision. It creates a new rolling update back to the previous ReplicaSet. Option D also works but requires knowing the exact old image name.</em></p>
+
+<p><strong>Q3:</strong> A Deployment uses Recreate strategy. What is the expected behavior during an update?</p>
+<ul>
+<li>A) Pods are replaced one at a time with no downtime</li>
+<li>B) All existing pods are terminated before new pods are created, causing downtime ✓</li>
+<li>C) Half the pods are updated at once while the other half serve traffic</li>
+<li>D) New pods are created first, then old pods are terminated</li>
+</ul>
+<p><em>Explanation: Recreate strategy terminates ALL existing pods at once (scale to 0), then creates the new pods. This causes downtime but ensures no two versions run simultaneously — suitable when old and new versions cannot coexist.</em></p>

package/content/series/luyen-thi/luyen-thi-ckad/chapters/02-app-deployment/lessons/04-helm-kustomize.md

@@ -0,0 +1,181 @@
+---
+id: ckad-d2-l04
+title: 'Bài 4: Helm & Kustomize'
+slug: 04-helm-kustomize
+description: >-
+  Helm charts, releases, values.yaml và upgrade/rollback workflow. Kustomize
+  overlays và bases. Phân biệt khi nào dùng Helm vs Kustomize cho CKAD.
+duration_minutes: 50
+is_free: true
+video_url: null
+sort_order: 4
+section_title: "Domain 2: Application Deployment (20%)"
+course:
+  id: lt-ckad-series-001
+  title: 'Luyện thi CKAD — Certified Kubernetes Application Developer'
+  slug: luyen-thi-ckad
+---
+
+<img src="/storage/uploads/2026/04/k8s-cert-ckad-bai4-helm-kustomize.png" alt="Helm vs Kustomize — Chart structure, template engine, overlays" style="max-width: 800px; width: 100%; border-radius: 12px;" />
+
+<h2 id="helm-concepts">1. Helm Core Concepts</h2>
+
+<p><strong>Helm</strong> là Kubernetes package manager. Nó đóng gói các Kubernetes manifests vào <strong>Charts</strong> và quản lý deployments dưới dạng <strong>Releases</strong>.</p>
+
+<pre><code class="language-text">Helm Architecture:
+
+  values.yaml          Chart templates
+       │                    │
+       ▼                    ▼
+  ┌──────────────────────────────┐
+  │   Helm Template Engine       │
+  │   Renders YAML manifests     │
+  └──────────────┬───────────────┘
+                 │
+                 ▼ kubectl apply
+         Kubernetes Cluster
+          (stored as Release)</code></pre>
+
+<table>
+<thead><tr><th>Term</th><th>Định nghĩa</th></tr></thead>
+<tbody>
+<tr><td><strong>Chart</strong></td><td>Package của Helm — bao gồm templates + default values</td></tr>
+<tr><td><strong>Release</strong></td><td>Instance của Chart đã được deploy lên cluster</td></tr>
+<tr><td><strong>Repository</strong></td><td>Nơi lưu trữ Charts (như artifact hub, bitnami)</td></tr>
+<tr><td><strong>Values</strong></td><td>Configuration parameters để customize Chart</td></tr>
+<tr><td><strong>Revision</strong></td><td>Mỗi install/upgrade tạo ra một revision mới</td></tr>
+</tbody>
+</table>
+
+<h2 id="helm-commands">2. Helm Commands</h2>
+
+<pre><code class="language-text"># Add repository
+helm repo add bitnami https://charts.bitnami.com/bitnami
+helm repo update
+
+# Search charts
+helm search repo bitnami/nginx
+helm search hub wordpress
+
+# Install chart
+helm install my-release bitnami/nginx
+helm install my-release bitnami/nginx --values custom-values.yaml
+helm install my-release bitnami/nginx --set image.tag=1.25
+
+# List releases
+helm list
+helm list -n production
+
+# Upgrade release
+helm upgrade my-release bitnami/nginx --set replicaCount=3
+
+# Rollback to previous revision
+helm rollback my-release 1   # rollback to revision 1
+helm rollback my-release     # rollback to previous revision
+
+# Uninstall
+helm uninstall my-release
+
+# View rendered templates (dry-run)
+helm template my-release bitnami/nginx
+helm install my-release bitnami/nginx --dry-run</code></pre>
+
+<blockquote><p><strong>Exam tip:</strong> CKAD thường test <code>helm install</code> với flag <code>--set</code> (override values trực tiếp) và <code>--values file.yaml</code> (override từ file). Cũng test <code>helm upgrade</code> và <code>helm rollback</code>. Nhớ rằng <code>--set</code> override trumps <code>--values</code> file.</p></blockquote>
+
+<h2 id="kustomize">3. Kustomize</h2>
+
+<p><strong>Kustomize</strong> là tool built vào kubectl cho phép customize Kubernetes manifests mà không cần templates hoặc parameters. Dùng overlay pattern.</p>
+
+<pre><code class="language-text">Kustomize Structure:
+  base/
+  ├── kustomization.yaml    # Base kustomization
+  ├── deployment.yaml
+  └── service.yaml
+
+  overlays/
+  ├── development/
+  │   ├── kustomization.yaml  # Patches for dev
+  │   └── replica-patch.yaml
+  └── production/
+      ├── kustomization.yaml  # Patches for prod
+      └── replica-patch.yaml</code></pre>
+
+<pre><code class="language-text"># base/kustomization.yaml
+apiVersion: kustomize.config.k8s.io/v1beta1
+kind: Kustomization
+resources:
+  - deployment.yaml
+  - service.yaml
+
+# overlays/production/kustomization.yaml
+apiVersion: kustomize.config.k8s.io/v1beta1
+kind: Kustomization
+bases:
+  - ../../base
+patches:
+  - path: replica-patch.yaml
+images:
+  - name: myapp
+    newTag: "2.0"</code></pre>
+
+<pre><code class="language-text"># Apply với kustomize
+kubectl apply -k overlays/production/
+
+# Preview rendered output
+kubectl kustomize overlays/production/</code></pre>
+
+<h2 id="comparison">4. Helm vs Kustomize</h2>
+
+<table>
+<thead><tr><th>Tiêu chí</th><th>Helm</th><th>Kustomize</th></tr></thead>
+<tbody>
+<tr><td>Approach</td><td>Template-based (Go templates)</td><td>Overlay/patching (plain YAML)</td></tr>
+<tr><td>Learning curve</td><td>Cao hơn (template syntax)</td><td>Thấp hơn (YAML patches)</td></tr>
+<tr><td>Package mgmt</td><td>Có (charts, repos, versioning)</td><td>Không</td></tr>
+<tr><td>Release history</td><td>Có (upgrade/rollback)</td><td>Không built-in</td></tr>
+<tr><td>Built into kubectl</td><td>Không (separate binary)</td><td>Có (<code>kubectl apply -k</code>)</td></tr>
+<tr><td>Best for</td><td>Phân phối (distribute) apps</td><td>Env-specific customization</td></tr>
+</tbody>
+</table>
+
+<h2 id="cheatsheet">5. Cheat Sheet</h2>
+
+<table>
+<thead><tr><th>Task</th><th>Command</th></tr></thead>
+<tbody>
+<tr><td>Install chart với custom values</td><td><code>helm install rel chart --values f.yaml</code></td></tr>
+<tr><td>Override một value</td><td><code>helm install rel chart --set key=val</code></td></tr>
+<tr><td>Rollback Helm release</td><td><code>helm rollback release-name 2</code></td></tr>
+<tr><td>Apply kustomize overlay</td><td><code>kubectl apply -k overlays/prod/</code></td></tr>
+<tr><td>Preview kustomize output</td><td><code>kubectl kustomize overlays/prod/</code></td></tr>
+</tbody>
+</table>
+
+<h2 id="practice">6. Practice Questions</h2>
+
+<p><strong>Q1:</strong> You need to deploy a Helm chart from the "stable" repo with a custom replica count of 5. Which command accomplishes this?</p>
+<ul>
+<li>A) <code>helm deploy myapp stable/nginx --replicas=5</code></li>
+<li>B) <code>helm install myapp stable/nginx --set replicaCount=5</code> ✓</li>
+<li>C) <code>helm install myapp stable/nginx -e replicaCount=5</code></li>
+<li>D) <code>helm apply myapp stable/nginx --values replicaCount=5</code></li>
+</ul>
+<p><em>Explanation: helm install uses --set flag to override values. The syntax is --set key=value. The exact key name (replicaCount) depends on the chart's values.yaml, but --set is the correct flag for inline value overrides.</em></p>
+
+<p><strong>Q2:</strong> A team uses Kustomize with a base configuration and production/staging overlays. Which command applies the production overlay?</p>
+<ul>
+<li>A) <code>kubectl apply -f overlays/production/</code></li>
+<li>B) <code>kubectl kustomize overlays/production/ | kubectl apply -f -</code></li>
+<li>C) <code>kubectl apply -k overlays/production/</code> ✓</li>
+<li>D) <code>kustomize apply overlays/production/</code></li>
+</ul>
+<p><em>Explanation: kubectl apply -k (note -k not -f) is the built-in way to apply a kustomization directory. Option B also works but is more verbose. The -k flag tells kubectl to process the directory as a Kustomize configuration.</em></p>
+
+<p><strong>Q3:</strong> After a Helm upgrade introduces a bug, you need to revert to the previous working state. What is the correct approach?</p>
+<ul>
+<li>A) kubectl rollout undo deployment/myapp</li>
+<li>B) helm install --replace myapp stable/nginx</li>
+<li>C) helm rollback myapp ✓</li>
+<li>D) helm upgrade myapp --version=previous</li>
+</ul>
+<p><em>Explanation: helm rollback reverts a release to a previous revision. Without specifying a revision number, it rolls back to the previous one. This undoes all the changes made by the failed upgrade, including ConfigMaps, Secrets, and other resources managed by the chart.</em></p>