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

package/content/series/luyen-thi/luyen-thi-kcna/chapters/02-container-orchestration/lessons/05-container-runtimes-oci.md

@@ -0,0 +1,137 @@
+---
+id: kcna-d2-l05
+title: 'Bài 5: Container Runtimes & OCI Standards'
+slug: 05-container-runtimes-oci
+description: >-
+  OCI (Open Container Initiative), container runtime interface (CRI).
+  Docker, containerd, CRI-O. Image layers, registries và image lifecycle.
+duration_minutes: 50
+is_free: true
+video_url: null
+sort_order: 5
+section_title: "Domain 2: Container Orchestration (22%)"
+course:
+  id: lt-kcna-series-001
+  title: 'Luyện thi KCNA — Kubernetes and Cloud Native Associate'
+  slug: luyen-thi-kcna
+---
+
+<img src="/storage/uploads/2026/04/k8s-cert-kcna-bai5-oci-runtimes.png" alt="OCI Container Runtime Stack — CRI, containerd, runc" style="max-width: 800px; width: 100%; border-radius: 12px;" />
+
+<h2 id="oci">1. OCI — Open Container Initiative</h2>
+
+<p><strong>OCI</strong> là tổ chức mở (thuộc Linux Foundation) định nghĩa các chuẩn mở cho containers:</p>
+
+<table>
+<thead><tr><th>Specification</th><th>Định nghĩa</th><th>Ví dụ implement</th></tr></thead>
+<tbody>
+<tr><td><strong>OCI Image Spec</strong></td><td>Định dạng container image (layers, manifest)</td><td>Docker image, OCI image</td></tr>
+<tr><td><strong>OCI Runtime Spec</strong></td><td>Cách chạy container từ image (lifecycle, filesystem)</td><td>runc, crun, kata-containers</td></tr>
+<tr><td><strong>OCI Distribution Spec</strong></td><td>API để push/pull image từ registry</td><td>DockerHub, ECR, GCR</td></tr>
+</tbody>
+</table>
+
+<blockquote><p><strong>Exam tip:</strong> OCI standards đảm bảo <strong>interoperability</strong>: image build bằng Docker có thể chạy với containerd hoặc CRI-O mà không cần thay đổi. KCNA thường hỏi về vai trò của OCI trong cloud native ecosystem.</p></blockquote>
+
+<h2 id="container-runtime">2. Container Runtime Interface (CRI)</h2>
+
+<p>Kubernetes không giao tiếp trực tiếp với Docker hay containerd. Thay vào đó, kubelet dùng <strong>CRI (Container Runtime Interface)</strong> — một gRPC API chuẩn.</p>
+
+<pre><code class="language-text">Kubernetes Architecture (Runtime Layer):
+
+  kubelet
+     │ CRI (gRPC)
+     ├─── containerd ─── runc ─── container
+     ├─── CRI-O      ─── runc ─── container
+     └─── (Docker)   ─── (deprecated v1.24+)
+
+  OCI Runtime (runc, crun):
+  - Đọc OCI runtime bundle
+  - Gọi Linux kernel (namespaces, cgroups)
+  - Tạo container process</code></pre>
+
+<h2 id="runtimes-comparison">3. Container Runtimes Comparison</h2>
+
+<table>
+<thead><tr><th>Runtime</th><th>Loại</th><th>Đặc điểm</th><th>Dùng trong</th></tr></thead>
+<tbody>
+<tr><td><strong>containerd</strong></td><td>High-level (CRI)</td><td>Nhẹ, stable, CNCF graduated</td><td>Default Kubernetes 1.24+</td></tr>
+<tr><td><strong>CRI-O</strong></td><td>High-level (CRI)</td><td>Tối ưu cho Kubernetes, lightweight</td><td>OpenShift, Kubernetes</td></tr>
+<tr><td><strong>Docker Engine</strong></td><td>High-level (non-CRI)</td><td>Deprecated từ K8s 1.24 (dùng dockershim)</td><td>Dev environments</td></tr>
+<tr><td><strong>runc</strong></td><td>Low-level (OCI)</td><td>Reference OCI implementation</td><td>Backend của containerd/CRI-O</td></tr>
+<tr><td><strong>gVisor (runsc)</strong></td><td>Low-level (sandbox)</td><td>Security sandbox, intercepts syscalls</td><td>GKE sandbox, untrusted workloads</td></tr>
+<tr><td><strong>Kata Containers</strong></td><td>Low-level (VM-based)</td><td>VM isolation per container</td><td>Multi-tenant, high security</td></tr>
+</tbody>
+</table>
+
+<blockquote><p><strong>Exam tip:</strong> Docker bị deprecated như Kubernetes runtime từ v1.24, nhưng Docker images (OCI-compatible) vẫn chạy được trên containerd/CRI-O. "Docker deprecated" ≠ "Docker images deprecated".</p></blockquote>
+
+<h2 id="image-layers">4. Container Image Layers</h2>
+
+<pre><code class="language-text">Layer architecture:
+┌──────────────────────────────┐
+│  Layer 4: App code (5 MB)    │  ← Writeable (container layer)
+├──────────────────────────────┤
+│  Layer 3: npm packages       │  ← Read-only
+├──────────────────────────────┤
+│  Layer 2: Node.js runtime    │  ← Read-only
+├──────────────────────────────┤
+│  Layer 1: Ubuntu base image  │  ← Read-only (shared across images)
+└──────────────────────────────┘
+
+Cache benefit: nếu Layer 1-2 giống nhau, chỉ download Layer 3-4</code></pre>
+
+<h2 id="registries">5. Container Registries</h2>
+
+<table>
+<thead><tr><th>Registry</th><th>Provider</th><th>Đặc điểm</th></tr></thead>
+<tbody>
+<tr><td>Docker Hub</td><td>Docker Inc.</td><td>Public default, rate-limited pulls</td></tr>
+<tr><td>ECR (Elastic Container Registry)</td><td>AWS</td><td>Private, IAM integrated</td></tr>
+<tr><td>GCR / Artifact Registry</td><td>GCP</td><td>Private, Workload Identity</td></tr>
+<tr><td>GHCR (GitHub Container Registry)</td><td>GitHub</td><td>Package-linked, Actions CI</td></tr>
+<tr><td>Harbor</td><td>CNCF (open source)</td><td>Self-hosted, vulnerability scanning</td></tr>
+</tbody>
+</table>
+
+<h2 id="cheatsheet">6. Cheat Sheet</h2>
+
+<table>
+<thead><tr><th>Câu hỏi exam</th><th>Đáp án</th></tr></thead>
+<tbody>
+<tr><td>OCI định nghĩa chuẩn gì?</td><td>Image Spec, Runtime Spec, Distribution Spec</td></tr>
+<tr><td>Default runtime K8s 1.24+?</td><td><strong>containerd</strong></td></tr>
+<tr><td>CRI là gì?</td><td>Container Runtime Interface — gRPC API giữa kubelet và runtime</td></tr>
+<tr><td>Docker deprecated trong K8s?</td><td><strong>Từ v1.24</strong> (dockershim removed)</td></tr>
+<tr><td>Runtime cho untrusted workloads?</td><td><strong>gVisor</strong> hoặc <strong>Kata Containers</strong></td></tr>
+</tbody>
+</table>
+
+<h2 id="practice">7. Practice Questions</h2>
+
+<p><strong>Q1:</strong> A Kubernetes cluster uses containerd as the container runtime. A developer pushes a Docker image to Docker Hub. Can this image run on the cluster?</p>
+<ul>
+<li>A) No, Docker images are incompatible with containerd</li>
+<li>B) Yes, because Docker images follow OCI Image Spec and are compatible ✓</li>
+<li>C) Only if the cluster installs a Docker compatibility shim</li>
+<li>D) No, containerd only supports images from CNCF registries</li>
+</ul>
+<p><em>Explanation: Docker images follow the OCI Image Specification, making them interoperable with any OCI-compliant runtime including containerd and CRI-O. The "Docker deprecated" refers to the runtime, not the image format.</em></p>
+
+<p><strong>Q2:</strong> What is the primary purpose of the Container Runtime Interface (CRI)?</p>
+<ul>
+<li>A) Define image layer formats</li>
+<li>B) Provide a gRPC API for kubelet to communicate with container runtimes ✓</li>
+<li>C) Manage container image distribution between registries</li>
+<li>D) Schedule containers across cluster nodes</li>
+</ul>
+<p><em>Explanation: CRI gives kubelet a stable API to interact with different runtimes (containerd, CRI-O) without knowing implementation details. This decoupling enables switching runtimes without changing kubelet code.</em></p>
+
+<p><strong>Q3:</strong> Which container runtime provides VM-level isolation per container for high-security multi-tenant workloads?</p>
+<ul>
+<li>A) containerd</li>
+<li>B) CRI-O</li>
+<li>C) Kata Containers ✓</li>
+<li>D) runc</li>
+</ul>
+<p><em>Explanation: Kata Containers runs each container inside a lightweight VM, providing stronger isolation than standard Linux namespace-based containers. gVisor provides user-space isolation via syscall interception, also strong but different approach.</em></p>

package/content/series/luyen-thi/luyen-thi-kcna/chapters/02-container-orchestration/lessons/06-orchestration-patterns.md

@@ -0,0 +1,147 @@
+---
+id: kcna-d2-l06
+title: 'Bài 6: Container Orchestration Patterns'
+slug: 06-orchestration-patterns
+description: >-
+  Scheduling, auto-scaling (HPA, VPA, Cluster Autoscaler), resource requests
+  và limits, namespaces, multi-tenancy và Kubernetes upgrade strategies.
+duration_minutes: 55
+is_free: true
+video_url: null
+sort_order: 6
+section_title: "Domain 2: Container Orchestration (22%)"
+course:
+  id: lt-kcna-series-001
+  title: 'Luyện thi KCNA — Kubernetes and Cloud Native Associate'
+  slug: luyen-thi-kcna
+---
+
+<img src="/storage/uploads/2026/04/k8s-cert-kcna-bai6-scheduling.png" alt="Kubernetes Scheduling Pipeline và Autoscaling (HPA, VPA, Cluster Autoscaler)" style="max-width: 800px; width: 100%; border-radius: 12px;" />
+
+<h2 id="scheduling">1. Kubernetes Scheduling</h2>
+
+<p>Khi Pod được tạo, <strong>kube-scheduler</strong> chọn node phù hợp qua 2 bước:</p>
+
+<pre><code class="language-text">Scheduling Pipeline:
+  New Pod
+    │
+    ▼
+  1. FILTERING: Loại bỏ nodes không đủ điều kiện
+     - Không đủ CPU/Memory
+     - Taint không match Toleration
+     - Node Affinity không match
+     │
+    ▼
+  2. SCORING: Chấm điểm nodes còn lại
+     - Resource balance
+     - Affinity preferences
+     │
+    ▼
+  Bind Pod → Highest score Node</code></pre>
+
+<table>
+<thead><tr><th>Cơ chế</th><th>Mục đích</th><th>Ví dụ</th></tr></thead>
+<tbody>
+<tr><td><strong>NodeSelector</strong></td><td>Schedule Pod lên node có label</td><td><code>disktype: ssd</code></td></tr>
+<tr><td><strong>Affinity/Anti-affinity</strong></td><td>Preferred/required node rules</td><td>Prefer zone-a, avoid same node as another pod</td></tr>
+<tr><td><strong>Taints & Tolerations</strong></td><td>Repel Pods trừ khi Pod có Toleration</td><td>Node dành riêng cho GPU workloads</td></tr>
+<tr><td><strong>Resource requests</strong></td><td>Minimum CPU/memory để schedule</td><td>requests.cpu: 500m</td></tr>
+</tbody>
+</table>
+
+<blockquote><p><strong>Exam tip:</strong> <strong>Taints</strong> áp lên Node (repel pods). <strong>Tolerations</strong> áp lên Pod (accept taint). Taint có effect: <strong>NoSchedule</strong> (không schedule mới), <strong>PreferNoSchedule</strong> (ưu tiên không schedule), <strong>NoExecute</strong> (evict pods đang chạy).</p></blockquote>
+
+<h2 id="resources">2. Resource Requests & Limits</h2>
+
+<table>
+<thead><tr><th>Setting</th><th>Ảnh hưởng đến</th><th>Nếu vượt quá</th></tr></thead>
+<tbody>
+<tr><td><strong>requests.cpu</strong></td><td>Scheduling (scheduler dùng để chọn node)</td><td>Throttled (không bị kill)</td></tr>
+<tr><td><strong>limits.cpu</strong></td><td>Cgroups CPU quota</td><td>CPU throttled</td></tr>
+<tr><td><strong>requests.memory</strong></td><td>Scheduling</td><td>OOM Kill nếu vượt limit</td></tr>
+<tr><td><strong>limits.memory</strong></td><td>Cgroups memory limit</td><td>Container bị <strong>OOM Kill</strong></td></tr>
+</tbody>
+</table>
+
+<pre><code class="language-text">QoS Classes:
+  Guaranteed: requests == limits (best quality, last to be evicted)
+  Burstable:  requests < limits (middle)
+  BestEffort: no requests, no limits (first to be evicted)</code></pre>
+
+<h2 id="autoscaling">3. Auto-scaling</h2>
+
+<table>
+<thead><tr><th>Scaler</th><th>Scale gì</th><th>Metric</th></tr></thead>
+<tbody>
+<tr><td><strong>HPA</strong> (Horizontal Pod Autoscaler)</td><td>Số lượng Pod replicas</td><td>CPU%, Memory%, custom metrics</td></tr>
+<tr><td><strong>VPA</strong> (Vertical Pod Autoscaler)</td><td>CPU/Memory requests của Pod</td><td>Actual usage history</td></tr>
+<tr><td><strong>Cluster Autoscaler</strong></td><td>Số lượng nodes trong cluster</td><td>Pending Pods (unschedulable)</td></tr>
+<tr><td><strong>KEDA</strong></td><td>Số replicas (to 0)</td><td>Event-driven (queue depth, Kafka)</td></tr>
+</tbody>
+</table>
+
+<pre><code class="language-text">HPA integration:
+  metrics-server → kubelet → Node/Pod metrics
+       ↓
+  HPA controller (checks every 15s)
+       ↓
+  Scale up: replicas++  (traffic spike)
+  Scale down: replicas-- (traffic drops, 5 min cooldown)</code></pre>
+
+<blockquote><p><strong>Exam tip:</strong> HPA cần <strong>metrics-server</strong> để hoạt động. VPA và HPA có thể conflict khi cùng manage một Deployment — không nên dùng cùng lúc trên cùng resource (trừ KEDA với nhiều dimension).</p></blockquote>
+
+<h2 id="namespaces">4. Namespaces & Multi-tenancy</h2>
+
+<p><strong>Namespaces</strong> cung cấp virtual cluster isolation: scope RBAC, ResourceQuota, NetworkPolicy, và DNS resolution.</p>
+
+<table>
+<thead><tr><th>Namespace</th><th>Purpose</th><th>Ghi chú</th></tr></thead>
+<tbody>
+<tr><td><code>default</code></td><td>Objects không chỉ định namespace</td><td>Dùng trong dev, không dùng prod</td></tr>
+<tr><td><code>kube-system</code></td><td>Kubernetes system components</td><td>CoreDNS, kube-proxy, metrics-server</td></tr>
+<tr><td><code>kube-public</code></td><td>Public, readable by all</td><td>Cluster info ConfigMap</td></tr>
+<tr><td><code>kube-node-lease</code></td><td>Node heartbeat leases</td><td>Kubelet heartbeat performance</td></tr>
+</tbody>
+</table>
+
+<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>Scale số Pod dựa trên CPU?</td><td><strong>HPA</strong></td></tr>
+<tr><td>Scale số Node trong cluster?</td><td><strong>Cluster Autoscaler</strong></td></tr>
+<tr><td>Node dành riêng cho GPU, dùng gì?</td><td><strong>Taint</strong> + Pod <strong>Toleration</strong></td></tr>
+<tr><td>Container bị OOM Kill, do gì?</td><td>Vượt <strong>limits.memory</strong></td></tr>
+<tr><td>QoS class nào bị evict đầu tiên?</td><td><strong>BestEffort</strong></td></tr>
+</tbody>
+</table>
+
+<h2 id="practice">6. Practice Questions</h2>
+
+<p><strong>Q1:</strong> A node is tainted with <code>key=gpu:NoSchedule</code>. Which Pods can be scheduled on this node?</p>
+<ul>
+<li>A) Any Pod in the cluster</li>
+<li>B) Pods with matching Toleration for the taint ✓</li>
+<li>C) Pods in the kube-system namespace only</li>
+<li>D) Pods created by cluster administrators only</li>
+</ul>
+<p><em>Explanation: NoSchedule taint prevents any new Pod from being scheduled on the node UNLESS the Pod specifies a matching toleration. Existing Pods are not evicted (use NoExecute for that).</em></p>
+
+<p><strong>Q2:</strong> An application's Pods keep getting OOM-killed during traffic spikes. What is the most appropriate solution?</p>
+<ul>
+<li>A) Increase Pod CPU requests</li>
+<li>B) Configure HPA to scale based on memory usage ✓</li>
+<li>C) Move the app to a new namespace</li>
+<li>D) Use a StatefulSet instead of Deployment</li>
+</ul>
+<p><em>Explanation: OOM kills mean memory demand exceeds limits. HPA scaling out (more Pod replicas) distributes the load, reducing per-pod memory pressure. Alternatively, increase memory limits or use VPA.</em></p>
+
+<p><strong>Q3:</strong> Which Kubernetes component provides CPU and memory metrics that HPA uses for scaling decisions?</p>
+<ul>
+<li>A) kube-proxy</li>
+<li>B) kube-scheduler</li>
+<li>C) metrics-server ✓</li>
+<li>D) etcd</li>
+</ul>
+<p><em>Explanation: metrics-server is an optional cluster add-on that collects resource metrics (CPU, memory) from kubelets. The HPA controller queries the metrics API exposed by metrics-server to make scaling decisions.</em></p>

package/content/series/luyen-thi/luyen-thi-kcna/chapters/03-cloud-native-architecture/lessons/07-cloud-native-architecture.md

@@ -0,0 +1,143 @@
+---
+id: kcna-d3-l07
+title: 'Bài 7: Cloud Native Architecture & Design Patterns'
+slug: 07-cloud-native-architecture
+description: >-
+  Cloud native principles, microservices vs monolith, service mesh, 12-factor
+  app, immutable infrastructure và cloud native design patterns.
+duration_minutes: 55
+is_free: true
+video_url: null
+sort_order: 7
+section_title: "Domain 3: Cloud Native Architecture (16%)"
+course:
+  id: lt-kcna-series-001
+  title: 'Luyện thi KCNA — Kubernetes and Cloud Native Associate'
+  slug: luyen-thi-kcna
+---
+
+<img src="/storage/uploads/2026/04/k8s-cert-kcna-bai7-cloud-native.png" alt="Cloud Native Architecture — Microservices vs Monolith, 12-Factor App" style="max-width: 800px; width: 100%; border-radius: 12px;" />
+
+<h2 id="cloud-native">1. Cloud Native — Định nghĩa CNCF</h2>
+
+<p>Theo <strong>CNCF (Cloud Native Computing Foundation)</strong>, cloud native là cách build và run scalable applications trong dynamic environments như public, private, hybrid cloud, sử dụng: <strong>containers, microservices, declarative APIs, immutable infrastructure</strong>.</p>
+
+<table>
+<thead><tr><th>Principle</th><th>Ý nghĩa</th><th>Ví dụ</th></tr></thead>
+<tbody>
+<tr><td><strong>Containerized</strong></td><td>Đóng gói app + dependencies</td><td>Docker image</td></tr>
+<tr><td><strong>Dynamically orchestrated</strong></td><td>Automated scheduling, scaling, healing</td><td>Kubernetes</td></tr>
+<tr><td><strong>Microservices</strong></td><td>Loose coupling, single responsibility</td><td>Auth service, Payment service</td></tr>
+<tr><td><strong>Declarative APIs</strong></td><td>Describe desired state, not steps</td><td>kubectl apply -f deployment.yaml</td></tr>
+<tr><td><strong>Immutable infrastructure</strong></td><td>Never modify running; replace instead</td><td>New image version → rolling update</td></tr>
+</tbody>
+</table>
+
+<h2 id="microservices-vs-monolith">2. Microservices vs Monolith</h2>
+
+<pre><code class="language-text">MONOLITH                          MICROSERVICES
+─────────────────────             ──────────────────────────────
+┌──────────────────┐              ┌────────┐ ┌────────┐ ┌─────┐
+│  Auth    │  UI   │              │  Auth  │ │  Cart  │ │  UI │
+│  Cart    │  API  │              │Service │ │Service │ │Svc  │
+│  Payment │  DB   │              └────────┘ └────────┘ └─────┘
+└──────────────────┘                   │          │         │
+  Deploy as 1 unit                     └─── API Gateway ───┘
+                                            │
+                                       Client/Browser</code></pre>
+
+<table>
+<thead><tr><th>Aspect</th><th>Monolith</th><th>Microservices</th></tr></thead>
+<tbody>
+<tr><td>Deployment</td><td>All-or-nothing</td><td>Independent per service</td></tr>
+<tr><td>Scaling</td><td>Scale entire app</td><td>Scale only bottleneck service</td></tr>
+<tr><td>Complexity</td><td>Low (single codebase)</td><td>High (distributed)</td></tr>
+<tr><td>Fault isolation</td><td>One bug crashes all</td><td>Failure contained in service</td></tr>
+<tr><td>Technology</td><td>Single stack</td><td>Polyglot (best tool per service)</td></tr>
+</tbody>
+</table>
+
+<h2 id="12-factor">3. 12-Factor App</h2>
+
+<p>The <strong>12-factor app</strong> methodology định nghĩa best practices cho cloud native applications:</p>
+
+<table>
+<thead><tr><th>#</th><th>Factor</th><th>Cloud Native Practice</th></tr></thead>
+<tbody>
+<tr><td>1</td><td><strong>Codebase</strong></td><td>1 repo per app, many deploys</td></tr>
+<tr><td>2</td><td><strong>Dependencies</strong></td><td>Declare explicitly (package.json, go.mod)</td></tr>
+<tr><td>3</td><td><strong>Config</strong></td><td>Store in environment (ConfigMap, Secrets)</td></tr>
+<tr><td>4</td><td><strong>Backing services</strong></td><td>DB, cache = attached resources via URL</td></tr>
+<tr><td>5</td><td><strong>Build/Release/Run</strong></td><td>Strict separation (CI builds, CD deploys)</td></tr>
+<tr><td>6</td><td><strong>Processes</strong></td><td>Stateless processes, store state externally</td></tr>
+<tr><td>7</td><td><strong>Port binding</strong></td><td>Export service via port (no web server layer)</td></tr>
+<tr><td>8</td><td><strong>Concurrency</strong></td><td>Scale via process model (HPA)</td></tr>
+<tr><td>9</td><td><strong>Disposability</strong></td><td>Fast startup, graceful shutdown</td></tr>
+<tr><td>10</td><td><strong>Dev/Prod parity</strong></td><td>Same tools/services across environments</td></tr>
+<tr><td>11</td><td><strong>Logs</strong></td><td>Treat as event streams (stdout, not files)</td></tr>
+<tr><td>12</td><td><strong>Admin processes</strong></td><td>Run one-off admin tasks as Jobs</td></tr>
+</tbody>
+</table>
+
+<blockquote><p><strong>Exam tip:</strong> Factors 3, 6, 9, 11 hay xuất hiện trong câu hỏi KCNA. Factor 3 (config in env) → ConfigMap/Secret. Factor 6 (stateless) → lý do dùng external storage. Factor 11 (logs as streams) → stdout → log aggregator.</p></blockquote>
+
+<h2 id="service-mesh">4. Service Mesh</h2>
+
+<p>Khi microservices nhiều lên, cần quản lý: mTLS, retry, circuit breaker, observability. <strong>Service Mesh</strong> giải quyết điều này bằng cách inject <strong>sidecar proxy</strong> vào mỗi Pod.</p>
+
+<pre><code class="language-text">Without Service Mesh:          With Service Mesh (Istio):
+  App A ──────────────► App B    App A ──► [Envoy] ──► [Envoy] ──► App B
+  (manual TLS, retry code)         sidecar           sidecar
+                                 (auto mTLS, metrics, retry, tracing)</code></pre>
+
+<table>
+<thead><tr><th>Tính năng</th><th>Service Mesh cung cấp</th></tr></thead>
+<tbody>
+<tr><td>mTLS mutual authentication</td><td>Auto-encrypt traffic giữa services</td></tr>
+<tr><td>Traffic management</td><td>Canary, A/B, weighted routing</td></tr>
+<tr><td>Observability</td><td>Auto metrics, tracing, access logs</td></tr>
+<tr><td>Resilience</td><td>Retry, timeout, circuit breaker</td></tr>
+</tbody>
+</table>
+
+<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>CNCF định nghĩa cloud native bao gồm?</td><td>Containers, microservices, declarative APIs, immutable infra</td></tr>
+<tr><td>Config nên lưu ở đâu theo 12-factor?</td><td>Environment variables (không hardcode)</td></tr>
+<tr><td>Logs theo 12-factor?</td><td>Treat as streams (stdout/stderr)</td></tr>
+<tr><td>Service mesh inject gì vào Pod?</td><td><strong>Sidecar proxy</strong> (Envoy)</td></tr>
+<tr><td>Microservices scale phần nào?</td><td>Chỉ service có bottleneck</td></tr>
+</tbody>
+</table>
+
+<h2 id="practice">6. Practice Questions</h2>
+
+<p><strong>Q1:</strong> According to the 12-factor app methodology, how should an application store its database connection string?</p>
+<ul>
+<li>A) Hardcoded in the source code</li>
+<li>B) In a configuration file committed to the repository</li>
+<li>C) As an environment variable (Kubernetes ConfigMap or Secret) ✓</li>
+<li>D) In the container image as a build argument</li>
+</ul>
+<p><em>Explanation: Factor 3 (Config) states: "Store config in the environment." In Kubernetes, this means using ConfigMaps for non-sensitive config and Secrets for sensitive values, injected as environment variables.</em></p>
+
+<p><strong>Q2:</strong> What is the primary benefit of using a Service Mesh in a microservices architecture?</p>
+<ul>
+<li>A) Replace Kubernetes for container orchestration</li>
+<li>B) Provide infrastructure-level networking features (mTLS, retry, observability) without changing application code ✓</li>
+<li>C) Store application configuration</li>
+<li>D) Persist application state across container restarts</li>
+</ul>
+<p><em>Explanation: Service mesh moves cross-cutting concerns (security, observability, resilience) to the infrastructure layer via sidecar proxies. Developers don't need to implement retry logic or mTLS in each service.</em></p>
+
+<p><strong>Q3:</strong> Which characteristic distinguishes "immutable infrastructure" from traditional infrastructure?</p>
+<ul>
+<li>A) Servers are never rebooted</li>
+<li>B) Running systems are replaced rather than modified in-place ✓</li>
+<li>C) Configuration changes require manual approval</li>
+<li>D) Infrastructure is defined using only YAML files</li>
+</ul>
+<p><em>Explanation: Immutable infrastructure means you never update/patch a running container — you build a new image, deploy it, replace old containers. This eliminates configuration drift and improves repeatability.</em></p>

package/content/series/luyen-thi/luyen-thi-kcna/chapters/04-observability-delivery/lessons/08-observability.md

@@ -0,0 +1,143 @@
+---
+id: kcna-d4-l08
+title: 'Bài 8: Cloud Native Observability'
+slug: 08-observability
+description: >-
+  Ba trụ cột của Observability: Metrics, Logs, Traces. Prometheus, Grafana,
+  OpenTelemetry, Jaeger, Loki và observability trong Kubernetes.
+duration_minutes: 55
+is_free: true
+video_url: null
+sort_order: 8
+section_title: "Domain 4: Cloud Native Observability & Security (16%)"
+course:
+  id: lt-kcna-series-001
+  title: 'Luyện thi KCNA — Kubernetes and Cloud Native Associate'
+  slug: luyen-thi-kcna
+---
+
+<img src="/storage/uploads/2026/04/k8s-cert-kcna-bai8-observability.png" alt="Three Pillars of Observability — Metrics, Logs, Traces" style="max-width: 800px; width: 100%; border-radius: 12px;" />
+
+<h2 id="three-pillars">1. Ba Trụ Cột của Observability</h2>
+
+<p>Observability là khả năng hiểu trạng thái nội tại của một hệ thống qua các signals từ bên ngoài. Gồm 3 trụ cột:</p>
+
+<table>
+<thead><tr><th>Pillar</th><th>Là gì</th><th>Trả lời câu hỏi</th><th>Tool</th></tr></thead>
+<tbody>
+<tr><td><strong>Metrics</strong></td><td>Số liệu tổng hợp theo thời gian</td><td>"Hệ thống đang ở trạng thái nào?"</td><td>Prometheus + Grafana</td></tr>
+<tr><td><strong>Logs</strong></td><td>Dòng text event từ từng service</td><td>"Điều gì đã xảy ra?"</td><td>Loki, Elasticsearch, Fluentd</td></tr>
+<tr><td><strong>Traces</strong></td><td>Luồng request qua nhiều services</td><td>"Request đi qua đâu và mất bao lâu?"</td><td>Jaeger, Zipkin, Tempo</td></tr>
+</tbody>
+</table>
+
+<pre><code class="language-text">User request fails → Use 3 pillars:
+
+  METRICS: CPU spike at 14:05?
+  LOGS: Error "DB timeout" in service B  
+  TRACES: Request A→B→C, step B took 8s  
+
+  → Root cause: Service B DB connection pool exhausted</code></pre>
+
+<blockquote><p><strong>Exam tip:</strong> KCNA thường hỏi "welche tool" cho từng pillar. Prometheus = metrics. Grafana = visualization. Jaeger = distributed tracing. Loki = log aggregation.</p></blockquote>
+
+<h2 id="prometheus">2. Prometheus & Metrics</h2>
+
+<p><strong>Prometheus</strong> là CNCF graduated project cho monitoring và alerting. Pull-based: Prometheus scrapes metrics từ targets.</p>
+
+<pre><code class="language-text">Prometheus Architecture:
+  App (exposes /metrics)
+       ↑ scrape
+  Prometheus Server ──► Alert Manager ──► Slack/PagerDuty
+       │
+  Grafana (query PromQL → charts)</code></pre>
+
+<table>
+<thead><tr><th>Metric Type</th><th>Ý nghĩa</th><th>Ví dụ</th></tr></thead>
+<tbody>
+<tr><td><strong>Counter</strong></td><td>Chỉ tăng (reset khi restart)</td><td>http_requests_total</td></tr>
+<tr><td><strong>Gauge</strong></td><td>Tăng/giảm tự do</td><td>memory_usage_bytes</td></tr>
+<tr><td><strong>Histogram</strong></td><td>Distribution, quantile</td><td>request_duration_seconds</td></tr>
+<tr><td><strong>Summary</strong></td><td>Pre-computed quantiles</td><td>response_size_summary</td></tr>
+</tbody>
+</table>
+
+<h2 id="opentelemetry">3. OpenTelemetry (OTel)</h2>
+
+<p><strong>OpenTelemetry</strong> là CNCF standard cho thu thập telemetry (metrics, logs, traces) với vendor-neutral SDK và Collector.</p>
+
+<pre><code class="language-text">OpenTelemetry Flow:
+  App (instrumented with OTel SDK)
+       │ OTLP (protocol)
+  OTel Collector (receive, process, export)
+       │
+  ┌────┴────┐
+ Jaeger   Prometheus   Loki
+(traces)  (metrics)   (logs)</code></pre>
+
+<blockquote><p><strong>Exam tip:</strong> OpenTelemetry tách vendor-specific code ra khỏi apps — chỉ cần thay đổi OTel Collector config để switch từ Jaeger sang Zipkin mà không cần sửa app code.</p></blockquote>
+
+<h2 id="k8s-observability">4. Observability trong Kubernetes</h2>
+
+<table>
+<thead><tr><th>Component</th><th>Cung cấp</th></tr></thead>
+<tbody>
+<tr><td><strong>kubelet /metrics</strong></td><td>Node resource metrics cho Prometheus</td></tr>
+<tr><td><strong>metrics-server</strong></td><td>CPU/Memory cho kubectl top, HPA</td></tr>
+<tr><td><strong>kube-state-metrics</strong></td><td>Kubernetes object state (Pod, Deployment status)</td></tr>
+<tr><td><strong>Prometheus Operator</strong></td><td>Deploy Prometheus stack với CRDs (ServiceMonitor)</td></tr>
+<tr><td><strong>Loki + Promtail</strong></td><td>Log aggregation (Promtail thu thập logs từ nodes)</td></tr>
+</tbody>
+</table>
+
+<h3 id="kubectl-debug">kubectl debugging commands</h3>
+
+<pre><code class="language-text">kubectl logs pod-name              # Current container logs
+kubectl logs pod-name --previous   # Last crashed container logs
+kubectl logs -f pod-name           # Stream live logs
+kubectl describe pod pod-name      # Events + status details
+kubectl top pod                    # CPU/Memory (needs metrics-server)
+kubectl top node                   # Node resource usage</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>3 pillars of observability?</td><td><strong>Metrics, Logs, Traces</strong></td></tr>
+<tr><td>Distributed tracing tool?</td><td><strong>Jaeger</strong>, Zipkin, Tempo</td></tr>
+<tr><td>Kubernetes metrics collection?</td><td><strong>Prometheus</strong></td></tr>
+<tr><td>Visualization dashboard?</td><td><strong>Grafana</strong></td></tr>
+<tr><td>Vendor-neutral telemetry standard?</td><td><strong>OpenTelemetry</strong></td></tr>
+<tr><td>kubectl top cần gì?</td><td><strong>metrics-server</strong></td></tr>
+</tbody>
+</table>
+
+<h2 id="practice">6. Practice Questions</h2>
+
+<p><strong>Q1:</strong> A team needs to trace how a single HTTP request flows through 5 microservices to find which service adds the most latency. Which observability tool should they use?</p>
+<ul>
+<li>A) Prometheus</li>
+<li>B) Grafana</li>
+<li>C) Jaeger ✓</li>
+<li>D) Loki</li>
+</ul>
+<p><em>Explanation: Distributed tracing (Jaeger, Zipkin) tracks a request's entire flow across multiple services, showing each hop's latency and relationships. Prometheus shows aggregate metrics; Loki shows logs; Grafana is visualization.</em></p>
+
+<p><strong>Q2:</strong> What type of Prometheus metric would you use to track the total number of HTTP requests served since startup?</p>
+<ul>
+<li>A) Gauge</li>
+<li>B) Histogram</li>
+<li>C) Counter ✓</li>
+<li>D) Summary</li>
+</ul>
+<p><em>Explanation: Counter is a monotonically increasing metric — it only goes up (or resets to 0 on restart). Perfect for tracking cumulative events like requests, errors, or bytes transferred. Gauge is for values that go up and down (like memory usage).</em></p>
+
+<p><strong>Q3:</strong> Which framework allows developers to instrument their application once and export telemetry to multiple backends (Jaeger, Prometheus, etc.) without code changes?</p>
+<ul>
+<li>A) Prometheus client libraries</li>
+<li>B) OpenTelemetry ✓</li>
+<li>C) Kubernetes metrics-server</li>
+<li>D) Grafana Agent</li>
+</ul>
+<p><em>Explanation: OpenTelemetry provides vendor-neutral APIs and SDKs for generating traces, metrics, and logs. The OTel Collector routes telemetry to different backends. Switching backends requires only Collector config changes, not application code.</em></p>