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

package/content/series/luyen-thi/luyen-thi-cka/chapters/01-cluster-architecture/lessons/01-kien-truc-cka-kubeadm.md

@@ -0,0 +1,133 @@
+---
+id: cka-d1-l01
+title: 'Bài 1: Kubernetes Architecture & Cluster Components'
+slug: 01-kien-truc-cka-kubeadm
+description: >-
+  Control plane và worker node components. kubeadm bootstrap cluster.
+  ETCD, API Server, Scheduler, Controller Manager trong môi trường CKA exam.
+duration_minutes: 60
+is_free: true
+video_url: null
+sort_order: 1
+section_title: "Domain 1: Cluster Architecture, Installation & Configuration (25%)"
+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-bai1-kubeadm.png" alt="kubeadm Cluster Initialization Sequence và kubeconfig" style="max-width: 800px; width: 100%; border-radius: 12px;" />
+
+<h2 id="architecture">1. Kubernetes Architecture Review (CKA Focus)</h2>
+
+<p>CKA exam yêu cầu bạn có thể troubleshoot cluster components, không chỉ biết lý thuyết.</p>
+
+<pre><code class="language-text">Control Plane Node                 Worker Nodes
+──────────────────                 ────────────
+  kube-apiserver  ◄──────────────── kubelet
+  etcd                               kube-proxy
+  kube-scheduler                     container runtime
+  controller-manager                 (containerd)
+  cloud-controller-manager (opt)
+  
+All components communicate via kube-apiserver (only etcd talks directly to API server)</code></pre>
+
+<table>
+<thead><tr><th>Component</th><th>Location</th><th>Config / Pod Path</th><th>Troubleshoot</th></tr></thead>
+<tbody>
+<tr><td><strong>kube-apiserver</strong></td><td>Control plane</td><td><code>/etc/kubernetes/manifests/kube-apiserver.yaml</code></td><td>kubectl get pods -n kube-system</td></tr>
+<tr><td><strong>etcd</strong></td><td>Control plane</td><td><code>/etc/kubernetes/manifests/etcd.yaml</code></td><td>etcdctl member list</td></tr>
+<tr><td><strong>kube-scheduler</strong></td><td>Control plane</td><td><code>/etc/kubernetes/manifests/kube-scheduler.yaml</code></td><td>logs in kube-system</td></tr>
+<tr><td><strong>controller-manager</strong></td><td>Control plane</td><td><code>/etc/kubernetes/manifests/kube-controller-manager.yaml</code></td><td>logs in kube-system</td></tr>
+<tr><td><strong>kubelet</strong></td><td>Every node</td><td><code>/var/lib/kubelet/config.yaml</code>, systemd service</td><td>systemctl status kubelet</td></tr>
+</tbody>
+</table>
+
+<blockquote><p><strong>Exam tip:</strong> Trên kubeadm cluster, control plane components chạy như <strong>static Pods</strong> (files trong <code>/etc/kubernetes/manifests/</code>). Kubelet tự động start/restart chúng. Khi sửa manifest file, kubelet tự reload Pod — không cần kubectl apply.</p></blockquote>
+
+<h2 id="kubeadm">2. kubeadm — Cluster Bootstrap</h2>
+
+<pre><code class="language-text"># 1. Init control plane
+kubeadm init --pod-network-cidr=10.244.0.0/16
+
+# 2. Setup kubeconfig (sau khi init)
+mkdir -p $HOME/.kube
+cp /etc/kubernetes/admin.conf $HOME/.kube/config
+
+# 3. Install CNI plugin (required trước khi nodes Ready)
+kubectl apply -f https://raw.githubusercontent.com/flannel-io/flannel/master/Documentation/kube-flannel.yml
+
+# 4. Join worker nodes (token từ kubeadm init output)
+kubeadm join 192.168.1.10:6443 --token abc.xyz \
+  --discovery-token-ca-cert-hash sha256:...</code></pre>
+
+<h2 id="kubeconfig">3. kubeconfig & Contexts</h2>
+
+<pre><code class="language-text">~/.kube/config structure:
+  clusters:     → cluster API endpoints
+  users:        → auth credentials (certificates, tokens)
+  contexts:     → cluster + user + namespace combo
+  current-context → active context
+
+kubectl config commands:
+  kubectl config get-contexts       # List contexts
+  kubectl config use-context NAME   # Switch context
+  kubectl config current-context    # Show active
+  kubectl config set-context NAME --namespace=prod  # Set default ns</code></pre>
+
+<blockquote><p><strong>Exam tip:</strong> CKA có nhiều clusters. Câu hỏi đầu tiên luôn là: "switch sang đúng context trước khi làm". Nhớ kiểm tra <code>kubectl config current-context</code>.</p></blockquote>
+
+<h2 id="static-pods">4. Static Pods</h2>
+
+<p><strong>Static Pods</strong> được kubelet quản lý trực tiếp, không qua API server. Config files nằm trong <code>staticPodPath</code> (thường là <code>/etc/kubernetes/manifests/</code>).</p>
+
+<table>
+<thead><tr><th>Static Pod</th><th>Khác Pod thường</th></tr></thead>
+<tbody>
+<tr><td>Kubelet tạo trực tiếp</td><td>Không có ReplicaSet, không có Deployment</td></tr>
+<tr><td>Không thể xóa qua kubectl delete</td><td>Phải xóa file manifest</td></tr>
+<tr><td>Mirror Pod xuất hiện trên API server</td><td>Hiển thị kubectl get pods nhưng read-only</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>Check control plane health</td><td><code>kubectl get pods -n kube-system</code></td></tr>
+<tr><td>View apiserver config</td><td><code>cat /etc/kubernetes/manifests/kube-apiserver.yaml</code></td></tr>
+<tr><td>Kubelet status</td><td><code>systemctl status kubelet</code></td></tr>
+<tr><td>Kubelet logs</td><td><code>journalctl -u kubelet -n 50</code></td></tr>
+<tr><td>Regenerate join token</td><td><code>kubeadm token create --print-join-command</code></td></tr>
+</tbody>
+</table>
+
+<h2 id="practice">6. Practice Questions</h2>
+
+<p><strong>Q1:</strong> A cluster's kube-apiserver Pod is not running. You check /etc/kubernetes/manifests/kube-apiserver.yaml and find a syntax error. After fixing it, what happens?</p>
+<ul>
+<li>A) You must run kubectl apply -f kube-apiserver.yaml</li>
+<li>B) kubelet automatically detects the file change and restarts the static Pod ✓</li>
+<li>C) kubeadm must be run to restart  the control plane</li>
+<li>D) The API server restart requires a full node reboot</li>
+</ul>
+<p><em>Explanation: Static Pods are managed by kubelet, which watches the manifest directory for changes. When the YAML file is fixed, kubelet automatically kills the old Pod and starts a new one.</em></p>
+
+<p><strong>Q2:</strong> After running kubeadm init, a cluster admin runs kubectl get nodes and sees the control plane node with status "NotReady". What is the most likely cause?</p>
+<ul>
+<li>A) kubeadm init failed to create etcd</li>
+<li>B) CNI plugin has not been installed ✓</li>
+<li>C) The kubelet service is not running</li>
+<li>D) The cluster lacks worker nodes</li>
+</ul>
+<p><em>Explanation: After kubeadm init, nodes remain NotReady until a CNI (Container Network Interface) plugin is installed. Without CNI, Pod networking doesn't work and nodes cannot report Ready.</em></p>
+
+<p><strong>Q3:</strong> An administrator needs to run kubectl commands on a different cluster. What is the fastest way to switch without modifying the current kubeconfig permanently?</p>
+<ul>
+<li>A) Edit ~/.kube/config and change current-context</li>
+<li>B) Use --context flag or kubectl config use-context ✓</li>
+<li>C) Create a new kubeconfig file and delete the old one</li>
+<li>D) Re-run kubeadm init with the target cluster</li>
+</ul>
+<p><em>Explanation: kubectl config use-context TARGET switches the active context. Alternatively, use --context=TARGET on individual commands for per-command switching without changing the default.</em></p>

package/content/series/luyen-thi/luyen-thi-cka/chapters/01-cluster-architecture/lessons/02-cluster-upgrade-kubeadm.md

@@ -0,0 +1,147 @@
+---
+id: cka-d1-l02
+title: 'Bài 2: Cluster Upgrade với kubeadm'
+slug: 02-cluster-upgrade-kubeadm
+description: >-
+  Upgrade Kubernetes cluster với kubeadm. Node drain, cordon, uncordon.
+  Upgrade control plane trước rồi mới worker nodes.
+duration_minutes: 55
+is_free: true
+video_url: null
+sort_order: 2
+section_title: "Domain 1: Cluster Architecture, Installation & Configuration (25%)"
+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-bai2-upgrade.png" alt="Kubernetes Cluster Upgrade Sequence — Control Plane first, then Workers" style="max-width: 800px; width: 100%; border-radius: 12px;" />
+
+<h2 id="upgrade-overview">1. Upgrade Strategy Overview</h2>
+
+<p>Kubernetes chỉ hỗ trợ upgrade <strong>1 minor version</strong> một lần (v1.28 → v1.29, không nhảy v1.28 → v1.30). Luôn upgrade control plane trước worker nodes.</p>
+
+<pre><code class="language-text">Upgrade sequence:
+  1. Upgrade kubeadm (on control plane node)
+  2. kubeadm upgrade apply v1.29.0 (control plane components)
+  3. Upgrade kubelet + kubectl (on control plane)
+  4. For each worker node:
+     a. kubectl drain NODE --ignore-daemonsets
+     b. Upgrade kubeadm + kubelet + kubectl on node
+     c. kubeadm upgrade node
+     d. kubectl uncordon NODE</code></pre>
+
+<h2 id="drain-cordon">2. Drain, Cordon & Uncordon</h2>
+
+<table>
+<thead><tr><th>Command</th><th>Effect</th><th>Dùng khi</th></tr></thead>
+<tbody>
+<tr><td><code>kubectl cordon NODE</code></td><td>Mark node Unschedulable (no new pods)</td><td>Chuẩn bị maintenance</td></tr>
+<tr><td><code>kubectl drain NODE</code></td><td>Cordon + evict tất cả non-DaemonSet pods</td><td>Upgrade / replace node</td></tr>
+<tr><td><code>kubectl uncordon NODE</code></td><td>Mark node Schedulable lại</td><td>Sau khi maintenance xong</td></tr>
+</tbody>
+</table>
+
+<pre><code class="language-text">kubectl drain flags thường dùng:
+  --ignore-daemonsets     # DaemonSet pods không thể evict, ignore them
+  --delete-emptydir-data  # Evict pods dùng emptyDir volume
+  --force                 # Evict pods không managed by controller</code></pre>
+
+<blockquote><p><strong>Exam tip:</strong> <code>kubectl drain</code> mà không có <code>--ignore-daemonsets</code> sẽ fail nếu node có DaemonSet pods. Luôn thêm flag này. Nếu có pods dùng <code>emptyDir</code>, cũng cần <code>--delete-emptydir-data</code>.</p></blockquote>
+
+<h2 id="upgrade-steps">3. Chi tiết Upgrade Steps</h2>
+
+<pre><code class="language-text"># ====== CONTROL PLANE NODE ======
+
+# Step 1: Upgrade kubeadm
+apt-mark unhold kubeadm
+apt-get install -y kubeadm=1.29.0-00
+apt-mark hold kubeadm
+
+# Step 2: Verify upgrade plan
+kubeadm upgrade plan
+
+# Step 3: Apply upgrade
+kubeadm upgrade apply v1.29.0
+
+# Step 4: Upgrade kubelet + kubectl  
+apt-mark unhold kubelet kubectl
+apt-get install -y kubelet=1.29.0-00 kubectl=1.29.0-00
+apt-mark hold kubelet kubectl
+systemctl daemon-reload && systemctl restart kubelet
+
+# ====== WORKER NODE ======
+(SSH vào worker node)
+
+# Step 1: Drain node from control plane
+kubectl drain worker-1 --ignore-daemonsets --delete-emptydir-data
+
+# Step 2: Upgrade packages on worker
+apt-mark unhold kubeadm kubelet kubectl
+apt-get install -y kubeadm=1.29.0-00 kubelet=1.29.0-00 kubectl=1.29.0-00
+
+# Step 3: Upgrade node config
+kubeadm upgrade node
+
+# Step 4: Restart kubelet
+systemctl daemon-reload && systemctl restart kubelet
+
+# Step 5: Uncordon from control plane
+kubectl uncordon worker-1</code></pre>
+
+<h2 id="version-skew">4. Version Skew Policy</h2>
+
+<table>
+<thead><tr><th>Component</th><th>Allowed skew vs kube-apiserver</th></tr></thead>
+<tbody>
+<tr><td>kube-apiserver</td><td>Must be same version as other control plane</td></tr>
+<tr><td>kubelet</td><td>Can be 2 minor versions older</td></tr>
+<tr><td>kubectl</td><td>±1 minor version from apiserver</td></tr>
+<tr><td>kube-scheduler</td><td>Must match apiserver version</td></tr>
+</tbody>
+</table>
+
+<blockquote><p><strong>Exam tip:</strong> Worker node kubelet có thể chạy phiên bản cũ hơn trong quá trình upgrade. Đây là lý do upgrade từng node một mà cluster vẫn hoạt động.</p></blockquote>
+
+<h2 id="cheatsheet">5. Cheat Sheet</h2>
+
+<table>
+<thead><tr><th>Task</th><th>Command</th></tr></thead>
+<tbody>
+<tr><td>Check upgrade plan</td><td><code>kubeadm upgrade plan</code></td></tr>
+<tr><td>Apply control plane upgrade</td><td><code>kubeadm upgrade apply v1.XX.0</code></td></tr>
+<tr><td>Drain node (safe)</td><td><code>kubectl drain NODE --ignore-daemonsets --delete-emptydir-data</code></td></tr>
+<tr><td>Mark node schedulable</td><td><code>kubectl uncordon NODE</code></td></tr>
+<tr><td>Check node versions</td><td><code>kubectl get nodes -o wide</code></td></tr>
+</tbody>
+</table>
+
+<h2 id="practice">6. Practice Questions</h2>
+
+<p><strong>Q1:</strong> You need to upgrade a worker node. Before running the upgrade commands on the node, what step must you perform from the control plane?</p>
+<ul>
+<li>A) kubectl cordon the node to prevent new Pod scheduling</li>
+<li>B) kubectl drain the node to evict running Pods ✓</li>
+<li>C) kubectl delete the node and re-add it after upgrade</li>
+<li>D) Run kubeadm upgrade plan to verify compatibility</li>
+</ul>
+<p><em>Explanation: kubectl drain both cordons (marks unschedulable) AND evicts all Pods gracefully. This ensures the node has no running workloads before maintenance begins. kubeadm upgrade plan is run on control plane, not required per-worker-node.</em></p>
+
+<p><strong>Q2:</strong> The kubectl drain command fails with "cannot delete Pods not managed by ReplicationController, ReplicaSet, Job, DaemonSet or StatefulSet". What flag resolves this?</p>
+<ul>
+<li>A) --ignore-daemonsets</li>
+<li>B) --delete-emptydir-data</li>
+<li>C) --force ✓</li>
+<li>D) --grace-period=0</li>
+</ul>
+<p><em>Explanation: --force is required to evict Pods that are not managed by any controller. Without a controller, the Pod won't be rescheduled elsewhere, so kubectl warns you and requires --force to confirm you accept potential data loss.</em></p>
+
+<p><strong>Q3:</strong> What is the maximum kubelet version skew allowed compared to the kube-apiserver?</p>
+<ul>
+<li>A) ±1 minor version</li>
+<li>B) 2 minor versions older ✓</li>
+<li>C) Any version</li>
+<li>D) Must be identical version</li>
+</ul>
+<p><em>Explanation: Per Kubernetes version skew policy, kubelet can be at most 2 minor versions older than kube-apiserver. This allows rolling upgrades where nodes are upgraded one at a time while the control plane is already on the new version.</em></p>

package/content/series/luyen-thi/luyen-thi-cka/chapters/01-cluster-architecture/lessons/03-rbac-cka.md

@@ -0,0 +1,152 @@
+---
+id: cka-d1-l03
+title: 'Bài 3: RBAC & Authorization'
+slug: 03-rbac-cka
+description: >-
+  RBAC in-depth cho CKA. Tạo Roles, ClusterRoles, RoleBindings. ServiceAccounts.
+  Kiểm tra quyền với kubectl auth can-i. Certificate-based authentication.
+duration_minutes: 60
+is_free: true
+video_url: null
+sort_order: 3
+section_title: "Domain 1: Cluster Architecture, Installation & Configuration (25%)"
+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-bai3-rbac-cka.png" alt="RBAC Hands-on — ServiceAccount, RoleBinding, kubectl auth can-i" style="max-width: 800px; width: 100%; border-radius: 12px;" />
+
+<h2 id="rbac-review">1. RBAC Concepts (CKA Depth)</h2>
+
+<p>CKA yêu cầu hands-on: tạo RBAC resources bằng kubectl, verify permissions, và debug access issues.</p>
+
+<pre><code class="language-text">RBAC objects:
+  Role          → namespaced permissions
+  ClusterRole   → cluster-wide permissions
+  RoleBinding   → bind Role or ClusterRole to Subject (in a namespace)
+  ClusterRoleBinding → bind ClusterRole to Subject (cluster-wide)
+
+Subject types:
+  - User (string, không có K8s object)
+  - Group (string)
+  - ServiceAccount (K8s object: namespace/name)</code></pre>
+
+<h2 id="create-rbac">2. Tạo RBAC Imperatively</h2>
+
+<pre><code class="language-text"># Tạo Role (namespaced)
+kubectl create role pod-reader \
+  --verb=get,list,watch \
+  --resource=pods \
+  --namespace=default
+
+# Tạo RoleBinding
+kubectl create rolebinding read-pods \
+  --role=pod-reader \
+  --user=jane \
+  --namespace=default
+
+# Tạo ClusterRole
+kubectl create clusterrole secret-reader \
+  --verb=get,list \
+  --resource=secrets
+
+# Tạo ClusterRoleBinding
+kubectl create clusterrolebinding read-secrets \
+  --clusterrole=secret-reader \
+  --user=jane
+
+# Bind ClusterRole trong 1 namespace (dùng RoleBinding!)
+kubectl create rolebinding read-secrets-dev \
+  --clusterrole=secret-reader \
+  --user=jane \
+  --namespace=dev</code></pre>
+
+<blockquote><p><strong>Exam tip:</strong> Dùng <code>--dry-run=client -o yaml</code> để generate YAML rồi edit. Nhanh hơn viết tay. Ví dụ: <code>kubectl create role myrole --verb=get --resource=pods --dry-run=client -o yaml &gt; role.yaml</code></p></blockquote>
+
+<h2 id="serviceaccounts">3. ServiceAccounts trong CKA</h2>
+
+<pre><code class="language-text"># Tạo ServiceAccount
+kubectl create serviceaccount monitoring-sa -n default
+
+# Bind permissions
+kubectl create clusterrole metrics-reader \
+  --verb=get,list,watch \
+  --resource=pods,nodes
+
+kubectl create clusterrolebinding monitoring-binding \
+  --clusterrole=metrics-reader \
+  --serviceaccount=default:monitoring-sa
+
+# Sử dụng SA trong Pod spec
+spec:
+  serviceAccountName: monitoring-sa</code></pre>
+
+<h2 id="verify-permissions">4. Verify Permissions — kubectl auth can-i</h2>
+
+<pre><code class="language-text"># Kiểm tra quyền của user hiện tại
+kubectl auth can-i get pods
+kubectl auth can-i delete pods --namespace=production
+kubectl auth can-i '*' '*'  # Check all
+
+# Kiểm tra qua user khác (--as)
+kubectl auth can-i get pods --as=jane
+kubectl auth can-i get pods --as=jane --namespace=dev
+kubectl auth can-i get secrets --as=system:serviceaccount:default:monitoring-sa</code></pre>
+
+<h2 id="certificate-auth">5. Certificate-Based Authentication</h2>
+
+<pre><code class="language-text">Create user with client certificate:
+  1. Generate key: openssl genrsa -out alice.key 2048
+  2. Create CSR: openssl req -new -key alice.key -out alice.csr -subj "/CN=alice/O=developers"
+  3. Sign with K8s CA:
+     # Create CertificateSigningRequest object
+     kubectl apply -f alice-csr.yaml
+     kubectl certificate approve alice
+  4. Get signed cert: kubectl get csr alice -o jsonpath='{.status.certificate}' | base64 -d > alice.crt
+  5. Add to kubeconfig</code></pre>
+
+<blockquote><p><strong>Exam tip:</strong> CKA thường cho task "create user với certificate và bind RBAC". Nhớ quy trình: generate key → CSR → approve CSR → extract cert → kubeconfig. Dùng <code>kubectl auth can-i</code> để verify.</p></blockquote>
+
+<h2 id="cheatsheet">6. Cheat Sheet</h2>
+
+<table>
+<thead><tr><th>Task</th><th>Command</th></tr></thead>
+<tbody>
+<tr><td>Check what user can do</td><td><code>kubectl auth can-i --list --as=user</code></td></tr>
+<tr><td>Check specific permission</td><td><code>kubectl auth can-i get secrets --as=user -n ns</code></td></tr>
+<tr><td>Create serviceaccount</td><td><code>kubectl create sa SA-NAME -n NAMESPACE</code></td></tr>
+<tr><td>Role binding to SA</td><td><code>--serviceaccount=ns:sa-name</code></td></tr>
+<tr><td>Approve cert request</td><td><code>kubectl certificate approve NAME</code></td></tr>
+</tbody>
+</table>
+
+<h2 id="practice">7. Practice Questions</h2>
+
+<p><strong>Q1:</strong> A developer needs read-only access to all Pods and Services across the entire cluster. Which RBAC approach is most appropriate?</p>
+<ul>
+<li>A) Create a Role with get/list in the default namespace</li>
+<li>B) Create a ClusterRole with get/list on pods and services, then ClusterRoleBinding ✓</li>
+<li>C) Create a Role in each namespace</li>
+<li>D) Grant the developer cluster-admin access</li>
+</ul>
+<p><em>Explanation: For cluster-wide access, use ClusterRole (defines permissions) + ClusterRoleBinding (grants cluster-wide). Creating Roles in each namespace is tedious and error-prone. cluster-admin is too broad.</em></p>
+
+<p><strong>Q2:</strong> After creating a ServiceAccount and RoleBinding for a monitoring application, you need to verify the SA can list pods in the "monitoring" namespace. Which command does this?</p>
+<ul>
+<li>A) kubectl get rolebinding -n monitoring</li>
+<li>B) kubectl describe serviceaccount monitoring-sa</li>
+<li>C) kubectl auth can-i list pods --as=system:serviceaccount:monitoring:monitoring-sa -n monitoring ✓</li>
+<li>D) kubectl auth check serviceaccount monitoring-sa</li>
+</ul>
+<p><em>Explanation: kubectl auth can-i with --as=system:serviceaccount:NAMESPACE:NAME impersonates the ServiceAccount. This verifies the exact access path (SA → binding → role) rather than just inspecting the objects.</em></p>
+
+<p><strong>Q3:</strong> A ClusterRole named "pod-manager" exists. You want user "alice" to use this ClusterRole but ONLY within the "staging" namespace. What should you create?</p>
+<ul>
+<li>A) ClusterRoleBinding for alice → pod-manager</li>
+<li>B) RoleBinding in staging namespace for alice → pod-manager ✓</li>
+<li>C) A new Role in staging with the same permissions as pod-manager</li>
+<li>D) A new ClusterRole scoped to the staging namespace</li>
+</ul>
+<p><em>Explanation: RoleBinding can reference a ClusterRole but constrains it to the binding's namespace. This reuses the ClusterRole definition without granting cluster-wide access. ClusterRoleBinding would grant access to all namespaces.</em></p>

package/content/series/luyen-thi/luyen-thi-cka/chapters/02-workloads-scheduling/lessons/04-deployments-daemonsets-statefulsets.md

@@ -0,0 +1,186 @@
+---
+id: cka-d2-l04
+title: 'Bài 4: Deployments, DaemonSets & StatefulSets'
+slug: 04-deployments-daemonsets-statefulsets
+description: >-
+  Hands-on với Deployments (rolling update, rollback), DaemonSets, StatefulSets.
+  Resource requests, limits, và horizontal scaling cho CKA exam.
+duration_minutes: 55
+is_free: true
+video_url: null
+sort_order: 4
+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-bai4-workloads.png" alt="Deployment Rolling Update Mechanism — ReplicaSets và rollback" style="max-width: 800px; width: 100%; border-radius: 12px;" />
+
+<h2 id="deployments">1. Deployments — Rolling Updates & Rollbacks</h2>
+
+<pre><code class="language-text"># Tạo deployment
+kubectl create deployment nginx --image=nginx:1.20 --replicas=3
+
+# Scale
+kubectl scale deployment nginx --replicas=5
+
+# Update image (triggers rolling update)
+kubectl set image deployment/nginx nginx=nginx:1.21
+
+# Monitor rollout
+kubectl rollout status deployment/nginx
+kubectl rollout history deployment/nginx
+
+# Rollback to previous version
+kubectl rollout undo deployment/nginx
+kubectl rollout undo deployment/nginx --to-revision=2</code></pre>
+
+<table>
+<thead><tr><th>Rollout Strategy</th><th>Key Fields</th><th>Behavior</th></tr></thead>
+<tbody>
+<tr><td><strong>RollingUpdate</strong> (default)</td><td>maxUnavailable, maxSurge</td><td>Gradual, zero-downtime trên nhiều replicas</td></tr>
+<tr><td><strong>Recreate</strong></td><td>Không có</td><td>Kill all old → deploy new (có downtime)</td></tr>
+</tbody>
+</table>
+
+<pre><code class="language-text">RollingUpdate settings:
+spec:
+  strategy:
+    type: RollingUpdate
+    rollingUpdate:
+      maxUnavailable: 1  # Max pods down trong update
+      maxSurge: 1        # Max extra pods có thể chạy</code></pre>
+
+<blockquote><p><strong>Exam tip:</strong> Để rollout history có chú thích, dùng <code>--record</code> hoặc set annotation trong <code>kubernetes.io/change-cause</code>. Khi cần rollback đến revision cụ thể: <code>kubectl rollout undo deployment/name --to-revision=3</code></p></blockquote>
+
+<h2 id="horizontal-scaling">2. HPA (Horizontal Pod Autoscaler)</h2>
+
+<pre><code class="language-text"># Tạo HPA
+kubectl autoscale deployment nginx --cpu-percent=70 --min=2 --max=10
+
+# Hoặc YAML
+apiVersion: autoscaling/v2
+kind: HorizontalPodAutoscaler
+metadata:
+  name: nginx-hpa
+spec:
+  scaleTargetRef:
+    apiVersion: apps/v1
+    kind: Deployment
+    name: nginx
+  minReplicas: 2
+  maxReplicas: 10
+  metrics:
+  - type: Resource
+    resource:
+      name: cpu
+      target:
+        type: Utilization
+        averageUtilization: 70</code></pre>
+
+<h2 id="daemonset">3. DaemonSet Operations</h2>
+
+<pre><code class="language-text">DaemonSet update strategies:
+  spec:
+    updateStrategy:
+      type: RollingUpdate      # Gradual update per node
+      # OR
+      type: OnDelete           # Manual: update only when Pod deleted
+
+# View DaemonSet
+kubectl get daemonset -n kube-system
+kubectl get daemonset fluentd -o yaml
+
+# DaemonSet trên specific nodes (tolerations)
+spec:
+  template:
+    spec:
+      tolerations:
+      - key: node-role.kubernetes.io/control-plane
+        effect: NoSchedule    # Deploy trên control plane nodes</code></pre>
+
+<h2 id="statefulset">4. StatefulSet Operations</h2>
+
+<pre><code class="language-text">apiVersion: apps/v1
+kind: StatefulSet
+metadata:
+  name: web
+spec:
+  serviceName: "web"  # Headless Service required
+  replicas: 3
+  selector:
+    matchLabels:
+      app: web
+  template:
+    spec:
+      containers:
+      - name: nginx
+        image: nginx:1.21
+        volumeMounts:
+        - name: www
+          mountPath: /usr/share/nginx/html
+  volumeClaimTemplates:  # Each pod gets own PVC
+  - metadata:
+      name: www
+    spec:
+      accessModes: ["ReadWriteOnce"]
+      resources:
+        requests:
+          storage: 1Gi
+
+---
+# Headless Service (clusterIP: None)
+apiVersion: v1
+kind: Service
+metadata:
+  name: web
+spec:
+  clusterIP: None   # Headless!
+  selector:
+    app: web</code></pre>
+
+<blockquote><p><strong>Exam tip:</strong> StatefulSet yêu cầu <strong>Headless Service</strong> (clusterIP: None). Điều này tạo DNS entries cho từng Pod: <code>web-0.web.default.svc.cluster.local</code>. Nếu thiếu headless service, StatefulSet hoạt động nhưng pod DNS sẽ không hoạt động.</p></blockquote>
+
+<h2 id="cheatsheet">5. Cheat Sheet</h2>
+
+<table>
+<thead><tr><th>Task</th><th>Command</th></tr></thead>
+<tbody>
+<tr><td>Update image</td><td><code>kubectl set image deploy/NAME CONTAINER=IMAGE</code></td></tr>
+<tr><td>Rollback</td><td><code>kubectl rollout undo deploy/NAME</code></td></tr>
+<tr><td>Rollout status</td><td><code>kubectl rollout status deploy/NAME</code></td></tr>
+<tr><td>Pause rollout</td><td><code>kubectl rollout pause deploy/NAME</code></td></tr>
+<tr><td>Resume rollout</td><td><code>kubectl rollout resume deploy/NAME</code></td></tr>
+</tbody>
+</table>
+
+<h2 id="practice">6. Practice Questions</h2>
+
+<p><strong>Q1:</strong> A Deployment was updated 3 times. The current version (revision 3) is causing issues. How do you revert to revision 1?</p>
+<ul>
+<li>A) kubectl rollout undo deployment/app</li>
+<li>B) kubectl rollout undo deployment/app --to-revision=1 ✓</li>
+<li>C) kubectl set image deployment/app app=old-image</li>
+<li>D) kubectl delete deployment/app and recreate it</li>
+</ul>
+<p><em>Explanation: --to-revision flag specifies which historical revision to roll back to. Without it, rollout undo goes to the previous revision (n-1). kubectl rollout history shows all revisions and their CHANGE-CAUSE annotations.</em></p>
+
+<p><strong>Q2:</strong> A StatefulSet named "kafka" is deployed but Pods cannot resolve each other's DNS names. What is likely missing?</p>
+<ul>
+<li>A) The StatefulSet needs a Deployment alongside it</li>
+<li>B) A Headless Service (clusterIP: None) with matching selector is required ✓</li>
+<li>C) The namespace needs a NetworkPolicy allowing DNS</li>
+<li>D) Each Pod needs a separate Service</li>
+</ul>
+<p><em>Explanation: StatefulSets require a Headless Service (clusterIP: None) to create DNS records for individual Pods (pod-name.service.namespace.svc.cluster.local). Without it, stable network identities don't work.</em></p>
+
+<p><strong>Q3:</strong> You need to update a DaemonSet but want to control which nodes update first. Which updateStrategy should you use?</p>
+<ul>
+<li>A) RollingUpdate with maxUnavailable: 1</li>
+<li>B) Recreate strategy</li>
+<li>C) OnDelete — manually delete Pods node by node ✓</li>
+<li>D) DaemonSets cannot be updated without recreating</li>
+</ul>
+<p><em>Explanation: OnDelete strategy only updates a DaemonSet Pod when you manually delete it. This gives full control over update order and timing. RollingUpdate would automatically update nodes following Kubernetes' own ordering.</em></p>