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

package/content/series/luyen-thi/luyen-thi-cka/chapters/02-workloads-scheduling/lessons/05-scheduling-taints-affinity.md

@@ -0,0 +1,163 @@
+---
+id: cka-d2-l05
+title: 'Bài 5: Scheduling — Taints, Tolerations & Affinity'
+slug: 05-scheduling-taints-affinity
+description: >-
+  Node scheduling chi tiết: Taints và Tolerations, Node Affinity, Pod Affinity,
+  Priority, resource requests trong scheduling. Hands-on CKA tasks.
+duration_minutes: 55
+is_free: true
+video_url: null
+sort_order: 5
+section_title: "Domain 2: Workloads & Scheduling (15%)"
+course:
+  id: lt-cka-series-001
+  title: 'Luyện thi CKA — Certified Kubernetes Administrator'
+  slug: luyen-thi-cka
+---
+
+<img src="/storage/uploads/2026/04/k8s-cert-cka-bai5-scheduling.png" alt="Taints, Tolerations và Node Affinity trong Kubernetes" style="max-width: 800px; width: 100%; border-radius: 12px;" />
+
+<h2 id="taints-tolerations">1. Taints & Tolerations</h2>
+
+<pre><code class="language-text"># Add taint to node
+kubectl taint nodes node1 gpu=true:NoSchedule
+kubectl taint nodes node1 gpu=true:PreferNoSchedule
+kubectl taint nodes node1 gpu=true:NoExecute
+
+# Remove taint
+kubectl taint nodes node1 gpu=true:NoSchedule-
+
+# View taints on node
+kubectl describe node node1 | grep -A5 Taints</code></pre>
+
+<table>
+<thead><tr><th>Taint Effect</th><th>Behavior</th></tr></thead>
+<tbody>
+<tr><td><strong>NoSchedule</strong></td><td>Pods không có matching toleration sẽ không được schedule</td></tr>
+<tr><td><strong>PreferNoSchedule</strong></td><td>Scheduler cố tránh, nhưng không bắt buộc</td></tr>
+<tr><td><strong>NoExecute</strong></td><td>Evict existing pods + không schedule mới (có thể set tolerationSeconds)</td></tr>
+</tbody>
+</table>
+
+<pre><code class="language-text"># Pod toleration
+spec:
+  tolerations:
+  - key: "gpu"
+    operator: "Equal"
+    value: "true"
+    effect: "NoSchedule"
+  # OR tolerate all taints on a node:
+  - operator: "Exists"</code></pre>
+
+<blockquote><p><strong>Exam tip:</strong> Taints/Tolerations = <strong>repulsion</strong> (node pushes pods away, pod tolerates). Node Affinity = <strong>attraction</strong> (pod prefers/requires certain nodes). Thường phải dùng kết hợp cả hai để đảm bảo pods chỉ chạy trên nodes mong muốn.</p></blockquote>
+
+<h2 id="node-affinity">2. Node Affinity</h2>
+
+<pre><code class="language-text">spec:
+  affinity:
+    nodeAffinity:
+      # HARD rule: Pod MUST be on matching node
+      requiredDuringSchedulingIgnoredDuringExecution:
+        nodeSelectorTerms:
+        - matchExpressions:
+          - key: disktype
+            operator: In
+            values: [ssd, nvme]
+      # SOFT rule: prefer but not required
+      preferredDuringSchedulingIgnoredDuringExecution:
+      - weight: 100
+        preference:
+          matchExpressions:
+          - key: zone
+            operator: In
+            values: [us-east-1a]</code></pre>
+
+<table>
+<thead><tr><th>Affinity Type</th><th>Scheduling</th><th>Running</th></tr></thead>
+<tbody>
+<tr><td>requiredDuringScheduling<strong>IgnoredDuring</strong>Execution</td><td>Hard requirement</td><td>Pod stays even if node label removed</td></tr>
+<tr><td>preferredDuringScheduling<strong>IgnoredDuring</strong>Execution</td><td>Best effort</td><td>Pod stays even if node label removed</td></tr>
+<tr><td>requiredDuringScheduling<strong>RequiredDuring</strong>Execution (future)</td><td>Hard</td><td>Evict if node no longer matches</td></tr>
+</tbody>
+</table>
+
+<h2 id="pod-affinity">3. Pod Affinity & Anti-Affinity</h2>
+
+<pre><code class="language-text"># Pod anti-affinity: spread pods across nodes
+spec:
+  affinity:
+    podAntiAffinity:
+      requiredDuringSchedulingIgnoredDuringExecution:
+      - labelSelector:
+          matchLabels:
+            app: frontend
+        topologyKey: kubernetes.io/hostname  # 1 pod per node
+
+# Pod affinity: co-locate pods (e.g., app + cache on same node)
+spec:
+  affinity:
+    podAffinity:
+      preferredDuringSchedulingIgnoredDuringExecution:
+      - weight: 100
+        podAffinityTerm:
+          labelSelector:
+            matchLabels:
+              app: redis
+          topologyKey: kubernetes.io/hostname</code></pre>
+
+<h2 id="node-selector">4. NodeSelector (Simple)</h2>
+
+<pre><code class="language-text"># Label node
+kubectl label nodes node1 disktype=ssd
+
+# Use in pod spec
+spec:
+  nodeSelector:
+    disktype: ssd
+
+# Schedule pod on specific node
+spec:
+  nodeName: node1  # Bypass scheduler entirely</code></pre>
+
+<h2 id="cheatsheet">5. Cheat Sheet</h2>
+
+<table>
+<thead><tr><th>Need</th><th>Solution</th></tr></thead>
+<tbody>
+<tr><td>Node dành riêng cho GPU</td><td>Taint node + Pod toleration</td></tr>
+<tr><td>Pod phải chạy trên SSD nodes</td><td>Node affinity (required) hoặc nodeSelector</td></tr>
+<tr><td>Spread pods across nodes</td><td>Pod anti-affinity (required, topologyKey: hostname)</td></tr>
+<tr><td>Co-locate app + cache</td><td>Pod affinity (preferred, topologyKey: hostname)</td></tr>
+<tr><td>Schedule trên specific node</td><td>spec.nodeName hoặc nodeSelector</td></tr>
+</tbody>
+</table>
+
+<h2 id="practice">6. Practice Questions</h2>
+
+<p><strong>Q1:</strong> A node has been tainted with <code>dedicated=database:NoExecute</code>. A running Pod without tolerations is on this node. What happens?</p>
+<ul>
+<li>A) The Pod continues running; NoExecute only affects new Pods</li>
+<li>B) The Pod is evicted immediately ✓</li>
+<li>C) The Pod is evicted after 5 minutes</li>
+<li>D) The Pod gets an error but continues running</li>
+</ul>
+<p><em>Explanation: NoExecute evicts existing Pods that don't tolerate the taint. The eviction is immediate unless the Pod has a toleration with tolerationSeconds (which allows it to remain for that duration before eviction).</em></p>
+
+<p><strong>Q2:</strong> You want Pods of "frontend" Deployment to never run on the same node as each other. Which configuration achieves this?</p>
+<ul>
+<li>A) Node affinity with required rule</li>
+<li>B) Taint each node after the first frontend Pod runs</li>
+<li>C) Pod anti-affinity with required rule and topologyKey: kubernetes.io/hostname ✓</li>
+<li>D) Use DaemonSet instead of Deployment</li>
+</ul>
+<p><em>Explanation: Pod anti-affinity with requiredDuringScheduling and topologyKey of hostname ensures no two Pods with matching labels land on the same node. This is the preferred way to spread Pods for high availability.</em></p>
+
+<p><strong>Q3:</strong> A Pod has nodeAffinity with "requiredDuringSchedulingIgnoredDuringExecution" targeting nodes with label <code>zone=east</code>. After scheduling, the label is removed from the node. What happens to the running Pod?</p>
+<ul>
+<li>A) The Pod is immediately evicted</li>
+<li>B) The Pod continues running ✓</li>
+<li>C) The Pod restarts on a matching node</li>
+<li>D) The Pod enters Pending state</li>
+</ul>
+<p><em>Explanation: "IgnoredDuringExecution" means the affinity rule only applies at scheduling time. Once running, removing the label doesn't affect the Pod. Future replacements (after crash/update) would fail to schedule if no matching node exists.</em></p>

package/content/series/luyen-thi/luyen-thi-cka/chapters/03-services-networking/lessons/06-services-endpoints-coredns.md

@@ -0,0 +1,145 @@
+---
+id: cka-d3-l06
+title: 'Bài 6: Services, Endpoints & CoreDNS'
+slug: 06-services-endpoints-coredns
+description: >-
+  Service types sâu hơn, Endpoints object, kube-proxy modes. CoreDNS
+  configuration và troubleshooting DNS. ExternalName, headless services.
+duration_minutes: 55
+is_free: true
+video_url: null
+sort_order: 6
+section_title: "Domain 3: Services & Networking (20%)"
+course:
+  id: lt-cka-series-001
+  title: 'Luyện thi CKA — Certified Kubernetes Administrator'
+  slug: luyen-thi-cka
+---
+
+<img src="/storage/uploads/2026/04/k8s-cert-cka-bai6-coredns.png" alt="CoreDNS, kube-proxy và Service Discovery trong Kubernetes" style="max-width: 800px; width: 100%; border-radius: 12px;" />
+
+<h2 id="services-deep">1. Services & Endpoints</h2>
+
+<p>Khi Service được tạo, Kubernetes tự động tạo <strong>Endpoints</strong> object chứa danh sách IPs của Pods matching selector.</p>
+
+<pre><code class="language-text"># Service → Endpoints → Pods
+kubectl get service my-app        # Virtual IP (ClusterIP)
+kubectl get endpoints my-app      # List: 10.244.1.2:80, 10.244.1.3:80
+kubectl describe endpoints my-app # Detailed
+
+# Nếu Endpoints rỗng → service selector không match pod labels
+# Debug: so sánh service selector vs pod labels
+kubectl get svc my-app -o jsonpath='{.spec.selector}'
+kubectl get pods --show-labels | grep app=my-app</code></pre>
+
+<h2 id="coredns">2. CoreDNS Configuration</h2>
+
+<pre><code class="language-text"># CoreDNS runs as Deployment in kube-system
+kubectl get pods -n kube-system -l k8s-app=kube-dns
+kubectl get configmap coredns -n kube-system -o yaml
+
+# Default Corefile:
+.:53 {
+    errors
+    health { lameduck 5s }
+    ready
+    kubernetes cluster.local in-addr.arpa ip6.arpa {  # cluster domain
+       pods insecure
+       fallthrough in-addr.arpa ip6.arpa
+    }
+    prometheus :9153
+    forward . /etc/resolv.conf  # Forward non-cluster queries to upstream
+    cache 30
+    loop
+    reload
+    loadbalance
+}</code></pre>
+
+<blockquote><p><strong>Exam tip:</strong> CoreDNS troubleshooting: 1) Check CoreDNS Pods running, 2) Check kube-dns Service in kube-system, 3) Run <code>kubectl exec -it pod -- nslookup kubernetes</code> to test DNS from inside pod, 4) Check Pod's <code>/etc/resolv.conf</code> points to kube-dns cluster IP.</p></blockquote>
+
+<h2 id="kube-proxy">3. kube-proxy Modes</h2>
+
+<table>
+<thead><tr><th>Mode</th><th>Mechanism</th><th>Performance</th></tr></thead>
+<tbody>
+<tr><td><strong>iptables</strong> (default)</td><td>Linux iptables rules, random pod selection</td><td>Good, O(n) rules</td></tr>
+<tr><td><strong>IPVS</strong></td><td>Linux IPVS (kernel, hash-based)</td><td>Better for large clusters</td></tr>
+<tr><td><strong>userspace</strong> (deprecated)</td><td>User-space proxy</td><td>Slow, legacy</td></tr>
+</tbody>
+</table>
+
+<h2 id="headless-services">4. Headless Services</h2>
+
+<pre><code class="language-text"># Headless: clusterIP: None
+# DNS returns Pod IPs directly (không qua virtual IP)
+apiVersion: v1
+kind: Service
+metadata:
+  name: mysql-headless
+spec:
+  clusterIP: None
+  selector:
+    app: mysql
+  ports:
+  - port: 3306
+
+# DNS behavior:
+# mysql-headless → multiple A records (one per Pod IP)
+# mysql-0.mysql-headless → specific Pod IP (StatefulSet)</code></pre>
+
+<h2 id="debug-dns">5. DNS Troubleshooting Commands</h2>
+
+<pre><code class="language-text"># Test DNS từ trong pod
+kubectl run dns-test --image=busybox --rm -it -- nslookup kubernetes
+kubectl run dns-test --image=busybox --rm -it -- nslookup my-service.namespace
+
+# Check resolv.conf trong pod
+kubectl exec -it my-pod -- cat /etc/resolv.conf
+# Should show: nameserver 10.96.0.10 (kube-dns service IP)
+
+# Check CoreDNS logs
+kubectl logs -n kube-system -l k8s-app=kube-dns
+
+# Check kube-dns service
+kubectl get svc -n kube-system kube-dns</code></pre>
+
+<h2 id="cheatsheet">6. Cheat Sheet</h2>
+
+<table>
+<thead><tr><th>Problem</th><th>Check</th></tr></thead>
+<tbody>
+<tr><td>Service không thể reach pods</td><td>kubectl get endpoints NAME</td></tr>
+<tr><td>Endpoints empty</td><td>Service selector vs Pod labels mismatch</td></tr>
+<tr><td>Pod không resolve DNS</td><td>/etc/resolv.conf + CoreDNS pods status</td></tr>
+<tr><td>StatefulSet pod DNS</td><td>Cần headless service cùng tên với serviceName</td></tr>
+</tbody>
+</table>
+
+<h2 id="practice">7. Practice Questions</h2>
+
+<p><strong>Q1:</strong> A Service is created but traffic never reaches the Pods. The Endpoints object for the Service shows "no endpoints". What is the most likely cause?</p>
+<ul>
+<li>A) The Service port doesn't match the container port</li>
+<li>B) The Service selector labels don't match the Pod labels ✓</li>
+<li>C) A NetworkPolicy is blocking traffic</li>
+<li>D) The Pods are in a different cluster</li>
+</ul>
+<p><em>Explanation: Empty Endpoints means the Service can't find any matching Pods. This is caused by a label selector mismatch. Verify with: kubectl get svc myapp -o jsonpath='{.spec.selector}' and compare with kubectl get pods --show-labels.</em></p>
+
+<p><strong>Q2:</strong> A Pod running in namespace "frontend" needs to reach a Service "payments" in namespace "backend". Which DNS name is correct?</p>
+<ul>
+<li>A) payments</li>
+<li>B) payments.backend</li>
+<li>C) payments.backend.svc.cluster.local ✓</li>
+<li>D) backend.payments.cluster.local</li>
+</ul>
+<p><em>Explanation: Cross-namespace DNS requires the full namespace: {service}.{namespace}.svc.cluster.local. Short names only work within the same namespace. Both B and C work, but C is the most explicit and reliable form.</em></p>
+
+<p><strong>Q3:</strong> CoreDNS is not responding. What sequence of steps should you follow to diagnose?</p>
+<ul>
+<li>A) Restart the entire cluster</li>
+<li>B) Check CoreDNS Pods running, check kube-dns Service ClusterIP, test from inside a Pod with nslookup ✓</li>
+<li>C) Reinstall kube-proxy</li>
+<li>D) Recreate the kube-system namespace</li>
+</ul>
+<p><em>Explanation: Systematic DNS debugging: (1) kubectl get pods -n kube-system -l k8s-app=kube-dns, (2) verify kube-dns Service has ClusterIP, (3) check Pod's /etc/resolv.conf points to that IP, (4) run nslookup from a test pod.</em></p>

package/content/series/luyen-thi/luyen-thi-cka/chapters/03-services-networking/lessons/07-ingress-networkpolicies-cni.md

@@ -0,0 +1,172 @@
+---
+id: cka-d3-l07
+title: 'Bài 7: Ingress, Network Policies & CNI'
+slug: 07-ingress-networkpolicies-cni
+description: >-
+  Ingress resources và controllers. Network Policies isolate traffic.
+  CNI plugins: Flannel, Calico, Cilium. Troubleshoot Pod networking.
+duration_minutes: 60
+is_free: true
+video_url: null
+sort_order: 7
+section_title: "Domain 3: Services & Networking (20%)"
+course:
+  id: lt-cka-series-001
+  title: 'Luyện thi CKA — Certified Kubernetes Administrator'
+  slug: luyen-thi-cka
+---
+
+<img src="/storage/uploads/2026/04/k8s-cert-cka-bai7-ingress-network.png" alt="Ingress Routing và NetworkPolicy — L7 routing và network segmentation" style="max-width: 800px; width: 100%; border-radius: 12px;" />
+
+<h2 id="ingress">1. Ingress</h2>
+
+<p><strong>Ingress</strong> cung cấp HTTP/HTTPS routing vào cluster. Cần <strong>Ingress Controller</strong> (nginx-ingress, Traefik, ALB) để xử lý Ingress resources.</p>
+
+<pre><code class="language-text">Internet
+   │
+[Ingress Controller] (nginx Pod, port 80/443)
+   │
+   ├── /api/* ──────────────► Service: api-svc:8080
+   ├── /web/* ──────────────► Service: web-svc:80
+   └── shop.example.com ───► Service: shop-svc:3000</code></pre>
+
+<pre><code class="language-text">apiVersion: networking.k8s.io/v1
+kind: Ingress
+metadata:
+  name: app-ingress
+  annotations:
+    nginx.ingress.kubernetes.io/rewrite-target: /
+spec:
+  ingressClassName: nginx
+  rules:
+  - host: api.example.com
+    http:
+      paths:
+      - path: /
+        pathType: Prefix
+        backend:
+          service:
+            name: api-svc
+            port:
+              number: 8080
+  tls:
+  - hosts:
+    - api.example.com
+    secretName: tls-secret  # TLS cert stored in Secret</code></pre>
+
+<blockquote><p><strong>Exam tip:</strong> Ingress không hoạt động nếu không có <strong>Ingress Controller</strong>. CKA exam thường đã có controller cài sẵn. Kiểm tra <code>kubectl get ingressclass</code> để xem class name cần dùng trong <code>spec.ingressClassName</code>.</p></blockquote>
+
+<h2 id="network-policies">2. Network Policies — CKA Depth</h2>
+
+<pre><code class="language-text">apiVersion: networking.k8s.io/v1
+kind: NetworkPolicy
+metadata:
+  name: allow-frontend-to-backend
+  namespace: app
+spec:
+  podSelector:
+    matchLabels:
+      app: backend      # Apply to backend pods
+  policyTypes:
+  - Ingress             # Control incoming traffic
+  ingress:
+  - from:
+    - podSelector:
+        matchLabels:
+          app: frontend  # Only from frontend pods
+    ports:
+    - protocol: TCP
+      port: 8080
+
+---
+# Deny all ingress (default deny)
+apiVersion: networking.k8s.io/v1
+kind: NetworkPolicy
+metadata:
+  name: deny-all
+spec:
+  podSelector: {}     # Select ALL pods
+  policyTypes:
+  - Ingress           # No ingress rules = block all ingress</code></pre>
+
+<table>
+<thead><tr><th>Selector</th><th>Ý nghĩa</th></tr></thead>
+<tbody>
+<tr><td><code>podSelector: {}</code></td><td>Select tất cả Pods trong namespace</td></tr>
+<tr><td><code>namespaceSelector</code></td><td>Cho phép traffic từ specific namespace</td></tr>
+<tr><td><code>ipBlock</code></td><td>Cho phép traffic từ CIDR range</td></tr>
+</tbody>
+</table>
+
+<h2 id="cni">3. CNI Plugins</h2>
+
+<table>
+<thead><tr><th>CNI</th><th>Network Policy?</th><th>Đặc điểm</th></tr></thead>
+<tbody>
+<tr><td><strong>Flannel</strong></td><td>Không</td><td>Simple overlay, VXLAN/host-gw</td></tr>
+<tr><td><strong>Calico</strong></td><td>Có</td><td>BGP routing, high performance, enterprise</td></tr>
+<tr><td><strong>Cilium</strong></td><td>Có (eBPF)</td><td>eBPF-based, L7 policies, observability</td></tr>
+<tr><td><strong>Weave Net</strong></td><td>Có</td><td>Simple, mesh network</td></tr>
+</tbody>
+</table>
+
+<blockquote><p><strong>Exam tip:</strong> Calico và Cilium hỗ trợ NetworkPolicy. Flannel không. Nếu exam hỏi "configure network policies" → phải có Calico/Cilium. Trên kubeadm lab, Calico là lựa chọn phổ biến nhất.</p></blockquote>
+
+<h2 id="pod-network-debug">4. Pod Network Troubleshooting</h2>
+
+<pre><code class="language-text"># Test pod-to-pod connectivity
+kubectl exec -it pod1 -- ping 10.244.1.5
+kubectl exec -it pod1 -- curl http://pod2:8080
+
+# Check pod's IP
+kubectl get pod pod1 -o jsonpath='{.status.podIP}'
+
+# Check CNI config on node
+ls /etc/cni/net.d/
+cat /etc/cni/net.d/10-calico.conflist
+
+# Check kube-proxy rules
+kubectl get pod -n kube-system -l k8s-app=kube-proxy
+iptables -t nat -L KUBE-SERVICES | head -20</code></pre>
+
+<h2 id="cheatsheet">5. Cheat Sheet</h2>
+
+<table>
+<thead><tr><th>Task</th><th>Command/Object</th></tr></thead>
+<tbody>
+<tr><td>HTTP routing into cluster</td><td><strong>Ingress</strong> (+ IngressClass)</td></tr>
+<tr><td>Block all traffic to a Pod</td><td>NetworkPolicy with empty ingress: []</td></tr>
+<tr><td>Allow traffic from namespace</td><td>NetworkPolicy with namespaceSelector</td></tr>
+<tr><td>Check CNI plugins</td><td><code>ls /etc/cni/net.d/</code></td></tr>
+<tr><td>Check ingressclass</td><td><code>kubectl get ingressclass</code></td></tr>
+</tbody>
+</table>
+
+<h2 id="practice">6. Practice Questions</h2>
+
+<p><strong>Q1:</strong> You create an Ingress resource but it has no ADDRESS and traffic doesn't route. What is the most likely cause?</p>
+<ul>
+<li>A) The Service type must be LoadBalancer</li>
+<li>B) No Ingress Controller is installed in the cluster ✓</li>
+<li>C) The Ingress must be in the kube-system namespace</li>
+<li>D) The IngressClass must be set to "default"</li>
+</ul>
+<p><em>Explanation: An Ingress resource is just configuration — it has no effect without an Ingress Controller (nginx, Traefik, etc.) to implement it. The controller watches Ingress objects and configures the actual proxy.</em></p>
+
+<p><strong>Q2:</strong> A NetworkPolicy selects Pods with label app=database and specifies policyTypes: [Ingress]. No ingress rules are defined. What is the effect?</p>
+<ul>
+<li>A) All traffic is allowed (no rules = allow all)</li>
+<li>B) All ingress traffic to database Pods is blocked ✓</li>
+<li>C) Only egress traffic is affected</li>
+<li>D) The policy is invalid and has no effect</li>
+</ul>
+<p><em>Explanation: A NetworkPolicy with policyTypes: [Ingress] but empty ingress rules acts as a default deny for all ingress traffic to the selected Pods. This is a common way to implement default-deny policies.</em></p>
+
+<p><strong>Q3:</strong> Which CNI plugin should you choose if you need both pod networking AND NetworkPolicy enforcement?</p>
+<ul>
+<li>A) Flannel</li>
+<li>B) Calico ✓</li>
+<li>C) CoreDNS</li>
+<li>D) kube-proxy</li>
+</ul>
+<p><em>Explanation: Flannel provides only overlay networking without NetworkPolicy support. Calico (and Cilium, Weave) implement the NetworkPolicy API. CoreDNS is DNS, and kube-proxy handles Service load balancing — they're not CNI plugins.</em></p>

package/content/series/luyen-thi/luyen-thi-cka/chapters/04-storage/lessons/08-persistent-volumes-storageclass.md

@@ -0,0 +1,159 @@
+---
+id: cka-d4-l08
+title: 'Bài 8: Persistent Volumes, PVCs & StorageClass'
+slug: 08-persistent-volumes-storageclass
+description: >-
+  PersistentVolume, PersistentVolumeClaim, StorageClass hands-on. Dynamic
+  provisioning, reclaim policies, volume modes và access modes cho CKA.
+duration_minutes: 55
+is_free: true
+video_url: null
+sort_order: 8
+section_title: "Domain 4: Storage (10%)"
+course:
+  id: lt-cka-series-001
+  title: 'Luyện thi CKA — Certified Kubernetes Administrator'
+  slug: luyen-thi-cka
+---
+
+<img src="/storage/uploads/2026/04/k8s-cert-cka-bai8-storage.png" alt="Persistent Volumes, PVCs và StorageClass — Static và Dynamic Provisioning" style="max-width: 800px; width: 100%; border-radius: 12px;" />
+
+<h2 id="pv-pvc">1. PV & PVC Lifecycle</h2>
+
+<pre><code class="language-text">Static Provisioning:
+  Admin creates PV → Developer creates PVC → K8s binds PVC to matching PV
+
+Dynamic Provisioning:
+  Developer creates PVC (with storageClassName) → StorageClass auto-creates PV
+
+Binding criteria:
+  ✓ accessMode match
+  ✓ storage size: PV >= PVC requested
+  ✓ storageClass match (or "")
+  ✓ volumeMode match</code></pre>
+
+<h2 id="create-pv">2. Tạo PV và PVC</h2>
+
+<pre><code class="language-text"># PersistentVolume (static, hostPath cho lab)
+apiVersion: v1
+kind: PersistentVolume
+metadata:
+  name: pv-data
+spec:
+  capacity:
+    storage: 5Gi
+  accessModes:
+    - ReadWriteOnce
+  persistentVolumeReclaimPolicy: Retain
+  storageClassName: manual
+  hostPath:
+    path: /mnt/data    # Lab only; use NFS/EBS in production
+
+---
+# PersistentVolumeClaim
+apiVersion: v1
+kind: PersistentVolumeClaim
+metadata:
+  name: pvc-data
+spec:
+  accessModes:
+    - ReadWriteOnce
+  resources:
+    requests:
+      storage: 2Gi
+  storageClassName: manual</code></pre>
+
+<table>
+<thead><tr><th>Reclaim Policy</th><th>Hành vi khi PVC deleted</th></tr></thead>
+<tbody>
+<tr><td><strong>Retain</strong></td><td>PV giữ data, phase = Released (admin phải xóa thủ công)</td></tr>
+<tr><td><strong>Delete</strong></td><td>PV và storage backend bị xóa tự động</td></tr>
+<tr><td><strong>Recycle</strong> (deprecated)</td><td>Xóa files, PV sẵn sàng cho PVC mới</td></tr>
+</tbody>
+</table>
+
+<blockquote><p><strong>Exam tip:</strong> PV phase lifecycle: <strong>Available</strong> (không có PVC) → <strong>Bound</strong> (PVC bound) → <strong>Released</strong> (PVC deleted, Retain policy) → <strong>Failed</strong>. PV Released không thể bind PVC mới cho đến khi admin manually edit PV để remove <code>.spec.claimRef</code>.</p></blockquote>
+
+<h2 id="storageclass">3. StorageClass</h2>
+
+<pre><code class="language-text">apiVersion: storage.k8s.io/v1
+kind: StorageClass
+metadata:
+  name: fast
+  annotations:
+    storageclass.kubernetes.io/is-default-class: "true"  # Default SC
+provisioner: kubernetes.io/aws-ebs
+parameters:
+  type: gp3
+  iopsPerGB: "10"
+reclaimPolicy: Delete
+allowVolumeExpansion: true
+volumeBindingMode: WaitForFirstConsumer  # Delay until Pod scheduled</code></pre>
+
+<table>
+<thead><tr><th>volumeBindingMode</th><th>Behavior</th></tr></thead>
+<tbody>
+<tr><td><strong>Immediate</strong></td><td>PV provisioned immediately khi PVC tạo</td></tr>
+<tr><td><strong>WaitForFirstConsumer</strong></td><td>Delay until Pod scheduled (ensures same zone)</td></tr>
+</tbody>
+</table>
+
+<h2 id="pod-with-pvc">4. Pod dùng PVC</h2>
+
+<pre><code class="language-text">apiVersion: v1
+kind: Pod
+metadata:
+  name: app-pod
+spec:
+  containers:
+  - name: app
+    image: nginx
+    volumeMounts:
+    - name: data-volume
+      mountPath: /var/data
+  volumes:
+  - name: data-volume
+    persistentVolumeClaim:
+      claimName: pvc-data    # Reference PVC name</code></pre>
+
+<h2 id="cheatsheet">5. Cheat Sheet</h2>
+
+<table>
+<thead><tr><th>Task</th><th>Command</th></tr></thead>
+<tbody>
+<tr><td>List PVs</td><td><code>kubectl get pv</code></td></tr>
+<tr><td>List PVCs</td><td><code>kubectl get pvc -n NAMESPACE</code></td></tr>
+<tr><td>PVC status</td><td><code>kubectl describe pvc NAME</code></td></tr>
+<tr><td>List StorageClasses</td><td><code>kubectl get storageclass</code></td></tr>
+<tr><td>Expand PVC</td><td>Edit PVC spec.resources.requests.storage (SC must allow)</td></tr>
+</tbody>
+</table>
+
+<h2 id="practice">6. Practice Questions</h2>
+
+<p><strong>Q1:</strong> A PVC is stuck in "Pending" state. A PV with 10Gi exists. The PVC requests 5Gi with ReadWriteMany, but the PV only supports ReadWriteOnce. What happens?</p>
+<ul>
+<li>A) The PVC binds to the PV and uses RWO</li>
+<li>B) The PVC remains Pending — no PV matches the requested access mode ✓</li>
+<li>C) Kubernetes auto-converts the PV access mode</li>
+<li>D) The Pod using the PVC starts but cannot write</li>
+</ul>
+<p><em>Explanation: PVC binding requires all criteria to match: storage size (PV >= PVC), access mode, storageClass, and volumeMode. If the PV only supports RWO but PVC needs RWX, they won't bind.</em></p>
+
+<p><strong>Q2:</strong> A PVC bound to a PV is deleted. The PV has reclaimPolicy: Retain. What is the PV's state?</p>
+<ul>
+<li>A) The PV is deleted</li>
+<li>B) The PV transitions to Available and can be reused</li>
+<li>C) The PV transitions to Released — data is preserved but PV can't be rebound automatically ✓</li>
+<li>D) The PV is immediately provisioned for another PVC</li>
+</ul>
+<p><em>Explanation: Retain policy preserves the PV and its data. The PV enters Released state. To reuse it, an admin must manually delete the old claimRef (kubectl patch pv myPV -p '{"spec":{"claimRef":null}}') to return it to Available.</em></p>
+
+<p><strong>Q3:</strong> In a cloud environment, WaitForFirstConsumer volumeBindingMode is recommended over Immediate. Why?</p>
+<ul>
+<li>A) It reduces storage costs</li>
+<li>B) It ensures the volume is provisioned in the same availability zone as the scheduled Pod ✓</li>
+<li>C) It allows multiple Pods to share the volume</li>
+<li>D) It speeds up Pod startup time</li>
+</ul>
+<p><em>Explanation: With Immediate, the PV might be provisioned in zone-a while the Pod schedules to zone-b (EBS volumes are zone-specific). WaitForFirstConsumer delays provisioning until the scheduler determines which node/zone will host the Pod.</em></p>