Tuần 1 (Ngày 1–5): Dựng control plane bằng tay, không kubeadm

Ngày 1 - Tự sinh toàn bộ chứng chỉ TLS của cluster

• Học: mỗi cặp giao tiếp trong cluster (etcd↔etcd, apiserver↔etcd, kubelet↔apiserver, admin↔apiserver...) cần một cert riêng, do một CA gốc ký.

• Làm: dùng openssl hoặc cfssl, tự tay tạo CA gốc rồi ký cert cho: etcd (peer + client), kube-apiserver, kube-controller-manager, kube-scheduler, mỗi kubelet, user admin.

• Tại sao: khi thi hoặc khi prod báo lỗi x509: certificate signed by unknown authority, bạn phải biết chính xác cert nào sai, ký bởi CA nào - không thể đoán.

Ngày 2 - Dựng etcd cluster 3 node bằng tay

• Học: etcd dùng thuật toán Raft, cần số node lẻ để có quorum; các flag --initial-cluster, --initial-cluster-state.

• Làm: viết systemd unit chạy etcd trên 3 máy (hoặc 3 container/VM), dùng cert Ngày 1, xác nhận bằng etcdctl member list và etcdctl endpoint health.

• Tại sao: mất quorum etcd = cluster chết hoàn toàn. Phải hiểu etcd trước khi hiểu Kubernetes.

Ngày 3 - Chạy kube-apiserver, controller-manager, scheduler bằng tay

• Học: từng flag bắt buộc của 3 binary này, cách chúng trỏ vào etcd và tin nhau qua cert.

• Làm: tải binary trực tiếp (không container), viết 3 systemd unit, khởi động, xác nhận kubectl get --raw /healthz trả ok - lúc này chưa có node nào.

• Tại sao: đây chính là những gì kubeadm làm giùm bạn dưới dạng static pod. Tự làm một lần để không còn coi nó là hộp đen.

Ngày 4 - Bootstrap worker node bằng tay

• Học: cơ chế TLS bootstrapping của kubelet (bootstrap token → CSR → admin approve CSR → cert chính thức).

• Làm: cài containerd + kubelet + kube-proxy trên 2 máy, bootstrap bằng token, chạy kubectl certificate approve, xác nhận kubectl get nodes thấy Ready - dù chưa cài CNI nên pod vẫn không chạy được.

• Tại sao: sự cố "node không join được" luôn nằm ở bước này (token hết hạn, CSR không được approve, cert sai).

Ngày 5 - Networking bằng tay: tự viết CNI plugin tối giản

• Học: CNI hoạt động thế nào - kubelet gọi một binary, truyền JSON qua stdin, binary trả IP/route qua stdout.

• Làm: viết một CNI plugin bằng bash hoặc Go (gán IP tĩnh qua bridge, thêm route) đủ để 2 pod ở 2 node ping được nhau. Sau đó gỡ ra, cài Calico thật, so sánh.

• Tại sao: hiểu CNI ở mức này thì mọi lỗi "pod stuck ContainerCreating" hay "pod không ping được pod khác node" sẽ không còn là bí ẩn.

Tuần 2 (Ngày 6–10): Hoàn thiện cluster tay, đối chiếu kubeadm, static pod

Ngày 6 - DNS và smoke test cluster tự dựng

• Học: CoreDNS chỉ là một Deployment bình thường chạy trong cluster, không có gì đặc biệt.

• Làm: tự viết manifest CoreDNS + Service kube-dns, deploy app 2 tầng (web + database) hoàn toàn trên cluster tự dựng Ngày 1–5, xác nhận DNS resolve và Service hoạt động đúng.

• Tại sao: đây là bài kiểm tra "cluster tay của bạn có thật sự chạy được app hay không".

Ngày 7 - Dựng lại bằng kubeadm, liệt kê chính xác nó tự động hoá gì

• Học: đọc log/behaviour của kubeadm init và đối chiếu từng bước với Ngày 1–6.

• Làm: phá cluster tay, dựng HA 3 control-plane bằng kubeadm + HAProxy + keepalived. Viết ra danh sách: "kubeadm tự làm A, B, C - những cái này tôi đã tự tay làm rồi nên biết nó làm đúng/sai ở đâu".

• Tại sao: đây là lúc kiến thức Ngày 1–6 biến thành lợi thế thật khi thi CKA (đề thi luôn dùng kubeadm).

Ngày 8 - etcd: backup/restore và rotate cert

• Học: snapshot etcd, restore từ snapshot, rotate (rotate) cert apiserver mà không làm rớt kết nối kubelet.

• Làm: backup + restore etcd trên cả cluster tay và cluster kubeadm; xoay cert apiserver sắp hết hạn trên cluster kubeadm mà không downtime.

• Tại sao: mất etcd mà không có backup = mất toàn bộ state cluster. Đây là kỹ năng bắt buộc trong đề CKA và trong thực tế.

Ngày 9 - Static Pod: hiểu control plane của kubeadm thật sự là gì

• Học: static pod là pod do chính kubelet quản lý qua thư mục /etc/kubernetes/manifests, không qua apiserver - vì vậy control plane có thể tự phục hồi ngay cả khi apiserver đang chết.

• Làm: sửa sai một trường trong manifest static pod của apiserver (VD: sai port), quan sát kubelet log và cách nó tự restart lại, rồi sửa đúng.

• Tại sao: đây là dạng lỗi hay gặp nhất trong đề CKA phần troubleshooting control plane.

Ngày 10 - Workload: StatefulSet, DaemonSet, Job/CronJob

• Học: vì sao StatefulSet cho Pod một identity ổn định (tên, storage) qua headless Service; DaemonSet đảm bảo 1 pod/node; Job đảm bảo chạy xong mới thôi.

• Làm: StatefulSet chạy database có headless Service; DaemonSet chạy agent trên mọi node; CronJob backup định kỳ; test xoá 1 pod trong StatefulSet xem nó tái tạo với đúng tên cũ không.

• Tại sao: production luôn có ít nhất một service stateful (database, cache, queue) - phải hiểu StatefulSet không phải chỉ "Deployment có tên số thứ tự".

Tuần 3 (Ngày 11–15): Scheduling, autoscaling, networking, storage

Ngày 11 - Scheduling

• Học: QoS class (Guaranteed/Burstable/BestEffort), PriorityClass, Affinity/AntiAffinity, Taints/Tolerations.

• Làm: ép 2 pod luôn chạy cùng node (podAffinity), ép 2 pod luôn tách node (podAntiAffinity), taint 1 node rồi test toleration; tạo pod chiếm hết resource để quan sát pod QoS BestEffort bị evict trước.

• Tại sao: production cần kiểm soát pod nào ưu tiên, pod nào có thể hy sinh khi thiếu tài nguyên.

Ngày 12 - Autoscaling

• Học: HPA theo custom metric, VPA, Cluster Autoscaler, và vì sao HPA + VPA chạy cùng lúc trên cùng 1 field (CPU) sẽ xung đột.

• Làm: HPA scale theo số message trong queue RabbitMQ; VPA điều chỉnh resource cho 1 StatefulSet; Cluster Autoscaler tự thêm node khi hết chỗ; thử chạy HPA và VPA cùng trên CPU để tự thấy xung đột.

• Tại sao: autoscaling cấu hình sai là nguyên nhân phổ biến gây outage do scale không kịp hoặc scale loop.

Ngày 13 - Service, Ingress & Gateway API

• Học: ClusterIP/NodePort/LoadBalancer khác nhau ở tầng iptables/IPVS thế nào. Gateway API đã được đưa vào đề thi CKA từ đầu 2026, nằm trong domain "Services and Networking" (20% điểm) cùng với Ingress - là chuẩn kế nhiệm Ingress, tách vai trò GatewayClass (do đội hạ tầng định nghĩa loại controller), Gateway (đội vận hành cluster định nghĩa listener/port), HTTPRoute/GRPCRoute/TCPRoute (đội ứng dụng định nghĩa route) - hết phụ thuộc annotation riêng từng vendor như Ingress. Ingress chưa bị gỡ khỏi đề thi, cả hai vẫn cùng nằm trong syllabus chính thức và thực tế nhiều đề vẫn ra Ingress nhiều hơn.

• Làm: dùng tcpdump bắt gói tin để thấy rewrite địa chỉ khi gọi Service; cài MetalLB cho LoadBalancer trên bare-metal; cấu hình Ingress với canary annotation + rate limiting. Sau đó cài 1 Gateway controller (Envoy Gateway hoặc NGINX Gateway Fabric), tạo GatewayClass → Gateway → HTTPRoute cho cùng app, chú ý field parentRefs trong HTTPRoute phải trỏ đúng vào Gateway - quên field này route sẽ "mồ côi" mà kubectl không báo lỗi gì. Thực hành migrate 1 Ingress có sẵn sang Gateway API: đọc kubectl describe ingress lấy host/path/service/port, dựng Gateway/HTTPRoute tương đương, verify traffic đúng rồi mới xoá Ingress cũ.

• Tại sao: hiểu Service ở tầng iptables giúp debug "Service không route đúng" nhanh gấp nhiều lần so với chỉ đọc YAML; Gateway API là kỹ năng migrate thật sự đang được hỏi trong đề CKA 2026 (đã ghi nhận câu hỏi dạng "migrate Ingress sang Gateway API" trong đề thi thật).

Ngày 14 - Network Policy & Service Mesh

• Học: NetworkPolicy mặc định cho phép hết, phải tự viết default-deny rồi mở dần.

• Làm: viết NetworkPolicy default-deny cho 1 namespace, mở dần theo nhu cầu thật của app; cài Istio hoặc Linkerd, làm traffic splitting + bật mTLS giữa service.

• Tại sao: production đa tenant bắt buộc phải có network segmentation, không thể để mọi pod nói chuyện tự do.

Ngày 15 - Storage: CSI, dynamic provisioning, snapshot

• Học: StorageClass + CSI driver hoạt động thế nào khi PVC được tạo (provision động).

• Làm: viết StorageClass dùng CSI driver thật (Ceph hoặc EBS), test ReadWriteOnce vs ReadWriteMany, tạo VolumeSnapshot rồi restore vào PVC mới.

• Tại sao: mất dữ liệu do không có snapshot/backup storage là sự cố production nghiêm trọng nhất, không có "restart lại là xong".

Tuần 4 (Ngày 16–21): Backup/restore, config, DNS ngoài, admission control, RBAC, image security

Ngày 16 - Backup & Restore ứng dụng: Velero

• Học: etcd snapshot (Ngày 8) chỉ backup định nghĩa resource (manifest lưu trong etcd), không backup dữ liệu thật trong PV - mất node storage thì etcd snapshot không cứu được dữ liệu database. Velero backup cả 2 lớp: manifest resource (Deployment, Service, ConfigMap...) và dữ liệu volume thật (qua CSI snapshot hoặc File System Backup dùng Kopia/Restic), theo phạm vi linh hoạt (cả cluster, theo namespace, hoặc theo label) - đây là công cụ thực tế hầu hết công ty dùng cho backup ứng dụng, khác hẳn mục đích của etcd snapshot (chỉ dành cho disaster recovery control plane).

• Làm: cài Velero + 1 object storage backend (MinIO nếu không có cloud, hoặc S3 thật); backup toàn bộ 1 namespace có app + PVC đang có dữ liệu; xoá sạch namespace đó; restore từ backup bằng Velero, xác nhận cả Deployment/Service lẫn dữ liệu trong PVC đều khôi phục đúng. Sau đó thử backup theo lịch (velero schedule create) và restore chọn lọc chỉ 1 vài resource thay vì toàn bộ.

• Production check: backup 1 namespace, restore sang namespace khác hoặc cluster khác - đây là cách dùng thật để migrate/nhân bản môi trường, không chỉ để phòng sự cố; xác nhận Velero xử lý đúng các resource có tham chiếu cố định tên namespace (VD: RoleBinding, NetworkPolicy) khi đổi namespace đích.

• Tại sao: etcd snapshot và Velero giải quyết 2 loại mất mát khác nhau - nhầm lẫn 2 công cụ này là lỗi phổ biến khiến nhiều team tưởng mình đã có backup đầy đủ nhưng thực ra chỉ mới có nửa vế (chỉ etcd, không có dữ liệu ứng dụng, hoặc ngược lại).

Ngày 17 - Quản lý cấu hình multi-environment

• Học: Helm chart phức tạp (dependency, sub-chart) và Kustomize overlay khác nhau ở điểm nào.

• Làm: viết 1 Helm chart cho app microservices nhiều component; dùng Kustomize overlay để cùng 1 chart chạy khác nhau ở dev/staging/production.

• Tại sao: hardcode YAML riêng cho từng môi trường là nguồn lỗi "chạy dev được, lên prod chết" phổ biến nhất.

Ngày 18 - DNS ngoài cluster & tự động cấp SSL

• Học: ExternalDNS tự đồng bộ DNS record khi Ingress mới tạo; cert-manager tự xin cert Let's Encrypt.

• Làm: cài ExternalDNS trỏ Route53/Cloudflare, tạo Ingress mới và xác nhận record tự sinh; cài cert-manager, cấp SSL tự động cho 1 domain thật.

• Tại sao: quản lý DNS/cert bằng tay ở production là việc không ai làm, luôn phải tự động hoá.

Ngày 19 - Admission Control

• Học: ValidatingAdmissionWebhook/MutatingAdmissionWebhook, Pod Security Admission (PSA - thay cho PodSecurityPolicy đã bị loại bỏ từ v1.25), OPA Gatekeeper/Kyverno.

• Làm: viết policy Gatekeeper chặn deploy image dùng tag :latest; viết webhook tự chặn resource thiếu label bắt buộc.

• Tại sao: đây là lớp phòng thủ để ngăn lỗi cấu hình xấu lọt vào cluster trước khi nó chạy, không phải xử lý sau khi đã hỏng.

Ngày 20 - RBAC

• Học: Role/ClusterRole/RoleBinding, Aggregate Role, nguyên tắc least privilege cho ServiceAccount.

• Làm: dựng RBAC cho một hệ thống nhiều thành phần (mỗi service 1 ServiceAccount quyền tối thiểu); bật audit logging và lọc log chỉ giữ hành vi nhạy cảm (delete, exec, secret access).

• Tại sao: RBAC sai (quá lỏng) là nguyên nhân hàng đầu của sự cố bảo mật trong cluster đa người dùng.

Ngày 21 - Bảo mật image/supply chain

• Học: quét lỗ hổng image, ký image để đảm bảo image chạy đúng là image đã build, không bị thay thế.

• Làm: quét image bằng Trivy ngay trong CI; ký image bằng Cosign; viết admission policy chặn image không có chữ ký hợp lệ.

• Tại sao: chạy image không rõ nguồn gốc trong production là lỗ hổng bảo mật lớn nhất mà nhiều team bỏ qua.

Tuần 5 (Ngày 22–26): Mã hoá, logging, monitoring, troubleshooting control plane/etcd/node

Ngày 22 - Mã hoá dữ liệu nhạy cảm

• Học: mặc định Secret trong etcd lưu ở dạng base64 (không phải mã hoá), phải bật EncryptionConfiguration mới thật sự mã hoá.

• Làm: bật encryption-at-rest cho Secret, xoay khoá mã hoá, kiểm tra bằng cách đọc trực tiếp etcd snapshot xác nhận không đọc được plaintext.

• Tại sao: nhiều người tưởng Secret đã an toàn chỉ vì tên gọi là "Secret" - thực tế phải tự cấu hình.

Ngày 23 - Logging tập trung

• Học: kiến trúc thu log (agent trên node → aggregator → storage → UI truy vấn).

• Làm: dựng EFK (Elasticsearch-Fluentd-Kibana) hoặc Loki+Fluent Bit thu log toàn cluster; viết filter loại log rác; tạo alert khi log xuất hiện pattern lỗi cụ thể.

• Tại sao: khi sự cố xảy ra lúc 2h sáng, log tập trung là thứ duy nhất giúp bạn không phải SSH vào từng node.

Ngày 24 - Monitoring & Tracing

• Học: Prometheus Operator quản lý Prometheus instance bằng CRD; Alertmanager định tuyến cảnh báo; distributed tracing giúp gì khi request đi qua nhiều service.

• Làm: cài Prometheus Operator + viết alert rule tuỳ chỉnh → Alertmanager → Slack; tự thiết kế 1 Grafana dashboard; cài Jaeger tracing cho 1 luồng request xuyên nhiều microservice.

• Tại sao: không có tracing thì debug latency trong hệ microservices gần như bất khả thi.

Ngày 25 - Troubleshooting: control plane & etcd (giới hạn 10–15 phút/tình huống)

• Làm 5 tình huống tự tạo: apiserver không start do cert hết hạn/sai flag; etcd mất quorum; nâng cấp control plane bằng kubeadm zero-downtime; kubeadm từ chối CA tuỳ chỉnh; static pod manifest sai khiến control plane crash loop.

• Tại sao: đây đúng dạng bài chiếm điểm nặng nhất trong đề thi CKA.

Ngày 26 - Troubleshooting: node & network

• Làm 5 tình huống: node NotReady do kubelet crash; kube-proxy không chạy; pod không ra được internet; DNS resolve sai do CoreDNS config lỗi; node không join được do cert/token sai.

• Tại sao: đây là nhóm lỗi network chiếm tỷ trọng lớn thứ hai trong cả đề thi lẫn sự cố production thật.

Tuần 6 (Ngày 27–31): Troubleshooting workload/ingress/rbac, multi-cluster, mock exam

Ngày 27 - Troubleshooting: workload & storage

• Làm 5 tình huống: Pod Pending do thiếu tài nguyên/taint; ImagePullBackOff; PVC không bound do StorageClass sai; CrashLoopBackOff do readiness/liveness probe sai; Pod OOMKilled liên tục.

Ngày 28 - Troubleshooting: Ingress/Service/RBAC

• Làm 5 tình huống: Ingress không route đúng Service; Service không có Endpoints; lỗi 403 do ServiceAccount thiếu quyền; NetworkPolicy chặn nhầm traffic hợp lệ; kube-proxy/kubelet chạy chậm cần performance tuning.

Ngày 29 - Kiến trúc multi-cluster

• Học: Cluster API để tạo/quản lý nhiều cluster (thay KubeFed - dự án này không còn phát triển tích cực); tích hợp EKS/GKE/AKS; ý tưởng triển khai edge bằng k3s.

• Làm: dùng Cluster API tạo 1 cluster mới trên cloud; tích hợp thử với EKS hoặc GKE nếu có tài khoản.

Ngày 30 - Mock exam CKA đầy đủ (2 giờ, tính giờ nghiêm túc)

• Làm 1 đề mock CKA đầy đủ, chỉ được dùng kubernetes.io/docs (đúng luật thi thật). Tự chấm điểm nghiêm khắc.

Ngày 31 - Review mock exam

• Xem lại từng câu sai, làm lại riêng phần yếu; luyện kubectl alias/autocompletion và thao tác vim/tmux để tăng tốc gõ lệnh trong 2 giờ thi.

Tuần 7 (Ngày 32–36): Đọc source code - controller pattern & scheduler

Ngày 32 - Kiến trúc client-go: informer, lister, workqueue

• Học: vì sao controller không gọi API liên tục mà dùng informer cache + watch stream; workqueue xử lý reconcile thế nào.

• Làm: viết 1 chương trình Go dùng client-go informer, in ra console mỗi khi có Pod được tạo/xoá/sửa trong cluster.

• Tại sao: mọi controller trong Kubernetes (kể cả Deployment controller, ReplicaSet controller) đều theo đúng pattern này - hiểu nó là hiểu lõi Kubernetes.

Ngày 33 - Tự viết controller bằng tay (không dùng kubebuilder)

• Làm: viết reconcile loop tay cho một CRD tự định nghĩa (VD: CRD Website mà khi tạo ra sẽ tự sinh Deployment + Service tương ứng).

• Tại sao: đây là bước bắt buộc để hiểu Operator pattern thay vì chỉ copy code mẫu.

Ngày 34 - Viết lại controller Ngày 33 bằng kubebuilder/operator-sdk

• Làm: dùng kubebuilder tạo cùng CRD Website, so sánh code sinh ra tự động với code viết tay Ngày 33.

• Tại sao: giờ bạn biết chính xác framework tự động hoá phần nào, không còn coi Operator là ma thuật.

Ngày 35 - Scheduler internals

• Học: scheduler framework có các pha filter (loại node không đủ điều kiện) và score (chấm điểm node còn lại).

• Làm: viết 1 scheduler plugin hoặc scheduler extender ưu tiên node theo một label tuỳ chỉnh (VD: cost-tier: cheap).

• Tại sao: production lớn thường cần scheduling logic riêng (ưu tiên node rẻ, ưu tiên node cùng AZ với database...).

Ngày 36 - API Aggregation Layer

• Học: cách Kubernetes cho phép mở rộng API bằng APIService, không chỉ CRD.

• Làm: viết một extension API server tối giản, đăng ký qua APIService, gọi thử bằng kubectl get.

Tuần 8 (Ngày 37–41): Container runtime & Linux internals

Ngày 37 - cgroups: resource limit thực chất là gì

• Học: khi bạn set resources.limits.cpu, Kubernetes ghi giá trị đó vào cgroup của container.

• Làm: set limit cho 1 pod, sau đó vào node, đọc trực tiếp file trong /sys/fs/cgroup/... để thấy đúng con số đó.

• Tại sao: khi kubectl top không đủ thông tin, đọc cgroup trực tiếp là cách debug resource issue chuyên sâu.

Ngày 38 - Namespaces: tự dựng "container" không dùng Docker

• Học: container thực chất là process bình thường bị cô lập bằng Linux namespaces (net/pid/mount/uts/ipc/user).

• Làm: dùng unshare và chroot tự tay tạo một môi trường cô lập giống container, không dùng Docker/containerd.

• Tại sao: hiểu ở mức này thì "container" không còn là khái niệm trừu tượng.

Ngày 39 - OCI spec: build và chạy image không qua Docker

• Học: image-spec (cấu trúc 1 image) và runtime-spec (cách chạy 1 container theo chuẩn OCI).

• Làm: build 1 image OCI thủ công (không dùng docker build), chạy trực tiếp bằng runc.

• Tại sao: containerd/CRI-O/Docker đều chỉ là lớp quản lý phía trên runc - hiểu runc là hiểu tầng thấp nhất.

Ngày 40 - Kiến trúc containerd

• Học: CRI plugin, containerd-shim, snapshotter hoạt động thế nào khi kubelet yêu cầu chạy 1 container.

• Làm: dùng ctr và crictl thao tác trực tiếp với containerd, không qua kubectl, để thấy đúng luồng kubelet → CRI → containerd → shim → runc.

Ngày 41 - Sandbox mạnh hơn: seccomp, AppArmor, gVisor

• Học: khi nào namespace thường không đủ an toàn cho multi-tenant, cần sandbox mạnh hơn như gVisor/Kata Containers.

• Làm: áp seccomp profile cho 1 pod để chặn syscall nguy hiểm; test chạy pod với runtimeClassName: gvisor nếu có điều kiện cài.

Tuần 9 (Ngày 42–46): Vòng đời cluster

Ngày 42 - Cordon/drain

• Học: PodDisruptionBudget đảm bảo không drain quá nhiều pod cùng lúc làm sập service.

• Làm: cấu hình PDB cho 1 deployment, thử drain node và quan sát Kubernetes tôn trọng PDB thế nào; giả lập rolling upgrade cả node pool.

Ngày 43 - Nâng cấp Kubernetes version

• Làm: nâng control plane trước, worker sau (đúng thứ tự bắt buộc); chuẩn bị kế hoạch rollback nếu lỗi giữa chừng; thực hiện trên staging trước khi note lại runbook cho production.

Ngày 44 - Capacity planning

• Học: bin-packing, tỷ lệ overcommit CPU/memory hợp lý là bao nhiêu.

• Làm: dùng VPA ở chế độ chỉ recommend (không tự apply) để lấy số liệu request/limit thực tế, so sánh với con số đang cấu hình.

Ngày 45 - Cost visibility

• Làm: cài Kubecost hoặc OpenCost, đọc report chi phí theo namespace/team, xác định namespace nào đang lãng phí resource nhất.

Ngày 46 - Di chuyển workload giữa 2 cluster không downtime

• Làm: dựng cluster thứ 2, deploy cùng app, chuyển traffic dần từ cluster cũ sang cluster mới bằng DNS hoặc Load Balancer (blue-green cluster).

• Tại sao: đây là kỹ năng cần khi migrate cloud provider, nâng version lớn, hoặc tách cluster theo region.

Tuần 10 (Ngày 47–50): Multi-tenancy & Platform Engineering

Ngày 47 - Multi-tenancy bằng namespace

• Làm: thiết kế ResourceQuota + LimitRange + NetworkPolicy riêng cho từng team trong cùng 1 cluster, đảm bảo team A không ảnh hưởng team B.

Ngày 48 - Virtual cluster (vcluster)

• Học: vcluster tạo một "cluster ảo" bên trong namespace, cô lập mạnh hơn namespace thường.

• Làm: dựng 1 vcluster cho 1 team, xác nhận team đó thấy như đang có cluster riêng.

Ngày 49 - Policy as code cho toàn fleet

• Làm: viết policy Kyverno/Gatekeeper áp dụng cho mọi namespace (chặn thiếu resource limit, chặn thiếu label bắt buộc); thiết kế quy trình exemption khi 1 team cần ngoại lệ hợp lý.

Ngày 50 - Self-service platform

• Làm: chuẩn hoá 1 Helm chart nội bộ hoặc Backstage template để dev team tự deploy đúng chuẩn mà không cần hỏi platform team mỗi lần.

Tuần 11 (Ngày 51–54): GitOps & Progressive Delivery

Ngày 51 - ArgoCD cơ bản đến app-of-apps

• Làm: cài ArgoCD, deploy 1 app qua Git; dựng pattern app-of-apps quản lý nhiều app cùng lúc; hiểu sync waves để deploy đúng thứ tự phụ thuộc.

Ngày 52 - Drift detection

• Làm: sửa tay 1 resource trực tiếp trong cluster (không qua Git), quan sát ArgoCD phát hiện drift thế nào và cách xử lý (sync lại hoặc override).

Ngày 53 - Progressive delivery

• Làm: cài Argo Rollouts hoặc Flagger, cấu hình canary tự động rollback dựa theo metric Prometheus thật (VD: error rate tăng thì tự rollback), không phải rollback bằng tay.

Ngày 54 - Secret trong GitOps

• Làm: dùng Sealed Secrets hoặc SOPS hoặc External Secrets kết hợp Vault để không bao giờ commit secret dạng plaintext lên Git.

Tuần 12 (Ngày 55–59): Chaos Engineering & Resilience

Ngày 55 - Chaos Mesh/Litmus: pod kill có kiểm soát

• Làm: cài Chaos Mesh, giả lập kill ngẫu nhiên 1 pod trong lúc traffic thật đang chạy, quan sát hệ thống tự phục hồi thế nào.

Ngày 56 - Giả lập network delay/partition

• Làm: tạo network delay hoặc partition giữa 2 service, quan sát timeout/circuit breaker có hoạt động đúng không.

Ngày 57 - Giả lập node failure/disk pressure

• Làm: giả lập 1 node chết đột ngột và 1 node đầy disk, quan sát Kubernetes evict pod và scheduler phản ứng ra sao.

Ngày 58 - Game day

• Làm: tự viết 1 runbook sự cố, tổ chức game day có đồng hồ bấm giờ, 1 người đóng vai on-call xử lý sự cố giả lập theo đúng runbook.

Ngày 59 - Disaster recovery toàn cluster

• Làm: giả lập mất toàn bộ 1 cluster, thực hành khôi phục cả 2 lớp sang cluster mới: etcd snapshot (khôi phục control plane nếu cần) + Velero (khôi phục toàn bộ namespace/app + dữ liệu PV, học từ Ngày 16) + GitOps (đồng bộ lại cấu hình mong muốn), đo thời gian thực tế để tính RTO/RPO cho từng lớp riêng - chỉ etcd snapshot sẽ không đủ nếu dữ liệu ứng dụng cũng mất.

Tuần 13 (Ngày 60–64): SRE

Ngày 60 - Định nghĩa SLI/SLO

• Làm: chọn 1 service thật, định nghĩa SLI (VD: tỷ lệ request thành công) và SLO (VD: 99.9% trong 30 ngày), đo bằng Prometheus thật chứ không phải số lý thuyết.

Ngày 61 - Error budget

• Làm: tính error budget còn lại của service Ngày 60; viết chính sách khi budget cạn (VD: dừng release tính năng mới, ưu tiên fix reliability).

Ngày 62 - On-call runbook

• Làm: viết runbook đủ rõ để người không quen hệ thống vẫn xử lý được lúc nửa đêm; rà soát alert hiện có để giảm alert fatigue (alert nào không actionable thì bỏ).

Ngày 63 - Postmortem blameless

• Làm: viết postmortem thật cho 1 sự cố giả lập ở Ngày 55–59, theo format blameless (tập trung vào hệ thống, không quy trách nhiệm cá nhân).

Ngày 64 - Incident command

• Làm: thực hành vai trò incident commander trong 1 sự cố lớn giả lập có nhiều người tham gia, luyện kỹ năng điều phối thay vì tự tay fix hết.

Tuần 14 (Ngày 65–69): Bảo mật cấp độ toàn fleet

Ngày 65 - SBOM

• Làm: dùng Syft sinh SBOM (Software Bill of Materials) cho 1 image, lưu trữ SBOM để truy vết dependency khi có CVE mới.

Ngày 66 - Provenance & SLSA

• Làm: ký attestation cho quá trình build (không chỉ ký image), viết admission policy chặn image không có attestation hợp lệ.

Ngày 67 - Falco: runtime security

• Học: khác với scan tĩnh (Ngày 21), Falco phát hiện hành vi bất thường khi container đang chạy (VD: mở shell trong container production).

• Làm: cài Falco, viết rule tuỳ chỉnh phát hiện hành vi đáng ngờ, test bằng cách tự exec vào 1 pod production giả lập.

Ngày 68 - Cilium & Hubble

• Làm: thay CNI hiện tại bằng Cilium (eBPF-based), viết NetworkPolicy layer 7 (theo HTTP method/path, không chỉ IP/port), dùng Hubble quan sát traffic thời gian thực.

Ngày 69 - CIS Benchmark thật

• Làm: chạy kube-bench trên cluster thật, liệt kê top 5 finding nghiêm trọng nhất, tự fix trong tuần đó.

Bài tập thêm luyện thi

Nhóm 1 - Dựng cluster

Làm lần lượt, mỗi lần đổi 1 biến số để hiểu ảnh hưởng riêng của nó:

1. Cluster 1 master + 2 worker, container runtime containerd.

2. Cluster tương tự nhưng đổi sang CRI-O, so sánh log/flag khác containerd chỗ nào.

3. HA cluster 3 master dùng HAProxy + Keepalived làm load balancer cho control plane.

4. Cài cluster với CA tùy chỉnh (tự ký, không để kubeadm tự sinh) - dùng lại cert từ bài PKI đã học.

5. Cài cluster với kubelet config tùy chỉnh (đổi cgroup driver, đổi DNS server riêng cho kubelet).

6. Dùng kubeadm thêm 1 node mới vào cluster đã chạy sẵn (không phải dựng từ đầu).

7. Nâng cấp version cluster zero-downtime (control plane trước, worker sau, đúng thứ tự).

8. Dùng Terraform tạo hạ tầng AWS (VPC, subnet, EC2) rồi kubeadm init lên trên - tách rõ "hạ tầng" và "cluster" là 2 lớp khác nhau.

Nhóm 2 - Workload & quản lý cấu hình

1. Deployment 3 replicas, rolling update đổi image, quan sát kubectl rollout status.

2. Cùng Deployment: scale 3→5→2, quan sát ReplicaSet cũ/mới trong lúc scale.

3. ConfigMap + Secret cho 1 app kết nối database - thử đổi ConfigMap sau khi Pod đã chạy, xác nhận Pod không tự nhận giá trị mới (phải hiểu vì sao).

4. Readiness + liveness probe - cấu hình readiness probe kiểm tra kết nối database thật trước khi nhận traffic (không phải probe giả).

5. Init Container copy file cấu hình vào container chính trước khi app khởi động.

6. StatefulSet + headless Service cho app cần identity ổn định (VD: MongoDB).

7. SecurityContext giới hạn quyền Pod (non-root, read-only filesystem, drop capabilities).

8. EmptyDir volume chia sẻ dữ liệu tạm giữa 2 container trong cùng Pod (sidecar pattern).

Nhóm 3 - Resource, scaling, scheduling

1. ResourceQuota giới hạn tổng tài nguyên 1 namespace.

2. LimitRange đặt giới hạn mặc định cho Pod trong namespace không khai request/limit.

3. Pod cố tình vượt limit - quan sát hành vi (CPU bị throttle, memory bị OOMKilled - 2 hành vi khác nhau, phải phân biệt).

4. HPA scale theo CPU > 80%.

5. VPA tự điều chỉnh request/limit cho 1 Deployment dựa trên usage thật.

6. Cluster Autoscaler tự thêm node khi không đủ chỗ lập lịch.

7. PriorityClass ưu tiên Pod quan trọng khi tài nguyên hạn chế - cố tình gây thiếu tài nguyên để thấy Pod ưu tiên thấp bị evict trước.

8. PodAffinity/PodAntiAffinity ràng buộc vị trí Pod.

9. DaemonSet chạy agent trên mọi node.

10. Job chạy một lần đảm bảo hoàn thành; CronJob backup định kỳ mỗi đêm.

11. PodDisruptionBudget đảm bảo ≥50% replica khả dụng khi node bảo trì - thử drain node và xác nhận Kubernetes tôn trọng PDB.

Nhóm 4 - Networking

1. Service type LoadBalancer + MetalLB trên bare-metal, quan sát tương tác với Endpoints.

2. Ingress controller (nginx) + Ingress resource expose app ra ngoài.

3. cert-manager tự cấp SSL cho Ingress với domain tùy chỉnh. 3b. Gateway API (đã vào đề CKA từ đầu 2026, nằm trong domain Services & Networking 20% cùng Ingress - cả hai đều có thể ra thi): cài Gateway controller (Envoy Gateway/NGINX Gateway Fabric), tạo GatewayClass → Gateway → HTTPRoute cho cùng app đã dùng ở bài 2, đặc biệt chú ý parentRefs trong HTTPRoute phải trỏ đúng Gateway - thiếu field này route bị "mồ côi" không có lỗi hiển thị. 3c. Migrate Ingress → Gateway API thật: đọc kubectl describe ingress lấy host/path/service/port của bài 2, dựng Gateway + HTTPRoute tương đương, verify traffic đúng bằng curl, chỉ xoá Ingress cũ sau khi verify xong - đúng quy trình đã xuất hiện trong đề thi CKA thật.

4. NetworkPolicy default-deny 1 namespace, chỉ mở port 80/443.

5. NetworkPolicy hạn chế traffic giữa các Pod trong cùng namespace (không phải chỉ giữa namespace).

6. NetworkPolicy cho phép traffic từ namespace A sang namespace B, chặn namespace C.

7. CoreDNS thêm custom domain nội bộ cho Service.

8. So sánh Flannel vs Calico cho 1 kịch bản cụ thể (VD: cần NetworkPolicy layer 3/4 - Flannel không hỗ trợ, phải chọn Calico).

9. Istio hoặc Linkerd - traffic splitting + canary + mTLS giữa service.

Nhóm 5 - Storage

1. StorageClass dùng AWS EBS (hoặc CSI driver tương đương), dynamic provisioning PVC.

2. PersistentVolume với access mode và reclaim policy khác nhau (Retain vs Delete) - xóa PVC và quan sát PV còn/mất dữ liệu tương ứng.

3. App ghi dữ liệu thật vào PVC, restart Pod, xác nhận dữ liệu còn nguyên.

4. PersistentVolume access mode ReadWriteMany chia sẻ dữ liệu giữa nhiều Pod cùng lúc (cần storage backend hỗ trợ, VD: NFS).

5. Job backup dữ liệu dùng PVC, lưu ra snapshot.

6. Velero: cài Velero + object storage backend (MinIO hoặc S3), backup 1 namespace có cả Deployment lẫn PVC đang chứa dữ liệu thật.

7. Velero: xoá sạch namespace vừa backup, restore lại từ Velero, xác nhận cả resource lẫn dữ liệu trong PVC khôi phục đúng - phân biệt rõ với bài etcd backup/restore (Nhóm 1) chỉ khôi phục định nghĩa resource, không khôi phục dữ liệu PV.

8. Velero: đặt lịch backup tự động (velero schedule create), restore chọn lọc chỉ 1 loại resource (VD: chỉ ConfigMap) thay vì toàn bộ namespace.

9. Velero: backup 1 namespace rồi restore sang namespace khác hoặc cluster khác - mô phỏng đúng cách dùng thật để nhân bản môi trường, không chỉ để phòng sự cố.

Nhóm 6 - RBAC & bảo mật

1. Role + RoleBinding cấp quyền cho 1 user trong 1 namespace.

2. RBAC cho user chỉ đọc (read-only) trên 1 namespace cụ thể.

3. ServiceAccount với quyền cụ thể, gắn vào 1 Deployment (không dùng default ServiceAccount).

4. RBAC least-privilege cho nhiều ServiceAccount khác nhau trong 1 hệ thống nhiều thành phần - mỗi component chỉ có đúng quyền nó cần, không hơn.

5. Pod Security Admission (namespace label pod-security.kubernetes.io/enforce) thay vì PodSecurityPolicy đã deprecated.

6. OPA Gatekeeper hoặc Kyverno policy chặn Pod không có resource limit hoặc dùng image tag :latest.

7. Kubernetes Auditing - bật audit log, lọc chỉ giữ hành vi nhạy cảm (delete, exec, secret access), lưu ra file riêng.

Nhóm 7 - Observability

1. EFK stack (Elasticsearch + Fluentd + Kibana) thu log toàn cluster.

2. Pod gửi log stdout/stderr đến Elasticsearch qua Fluentd - xác nhận log có gắn đúng metadata (namespace, pod name).

3. Prometheus + Grafana giám sát resource/hiệu năng 1 Deployment cụ thể, tự thiết kế 1 dashboard.

4. Alert tùy chỉnh trong Prometheus (VD: error rate > 5%) → Alertmanager → gửi thông báo thật (Slack/email).

5. Deploy Prometheus Operator hoặc Elasticsearch Operator - so sánh với cài tay để thấy Operator tự động hoá gì.

Nhóm 8 - CI/CD & vận hành

1. CI/CD pipeline (Jenkins/GitLab CI/GitHub Actions) tự build + deploy lên cluster mỗi khi có commit mới.

2. Helm chart đóng gói 1 ứng dụng nhiều thành phần, quản lý version bằng helm upgrade/rollback.

3. HashiCorp Vault hoặc AWS Secrets Manager quản lý secret thay vì Kubernetes Secret thô.

4. etcd snapshot định kỳ + restore thật từ snapshot (không phải chỉ đọc lý thuyết).

5. Deploy cluster trên EKS và GKE - so sánh phần nào cloud provider tự quản lý (control plane) khác gì tự kubeadm.

Nhóm 9 - Troubleshooting

Mỗi bài: chỉ có triệu chứng, tự chẩn đoán bằng kubectl describe, kubectl logs, kubectl get events.

1. kubectl get pods cho thấy 1 Pod đứng mãi ở Pending, không có container nào start.

2. Pod A chạy được nhưng gọi curl service-b từ bên trong Pod A bị timeout, dù Pod B đang Running.

3. kubectl get nodes cho thấy 1 node chuyển sang NotReady khoảng 5 phút trước, không rõ lý do.

4. Traffic đến qua Service không tới được Pod dù kubectl get endpoints từng có địa chỉ - giờ danh sách rỗng.

5. Ứng dụng bên trong Pod báo lỗi Connection refused khi gọi ra 1 service khác.

6. Một Pod cứ chạy được vài phút rồi bị restart liên tục, kubectl describe pod có dòng OOMKilled.

7. Máy client chạy kubectl get pods bị treo/timeout, không nhận được phản hồi từ cluster.

8. Pod ở trạng thái ContainerCreating mãi không lên Running, kubectl describe có sự kiện liên quan đến volume.

9. Người dùng ngoài không truy cập được domain trỏ qua Ingress dù DNS đã resolve đúng IP.

10. Pod chạy được nhưng không gọi ra được domain bên ngoài internet (VD: không tải được package).

11. kubectl get pods cho thấy container ở trạng thái chờ (Waiting) với reason liên quan đến image.

12. PVC ở trạng thái Pending mãi không bound dù đã tạo PV tương ứng.

13. Node mới thêm vào cluster bằng kubeadm join báo lỗi và không xuất hiện trong kubectl get nodes.

14. Service có type: LoadBalancer nhưng cột EXTERNAL-IP mãi ở trạng thái <pending>.

15. Đã tạo Gateway và HTTPRoute đầy đủ, kubectl apply không báo lỗi gì, nhưng gọi vào domain vẫn không có phản hồi (gợi ý: kiểm tra status của HTTPRoute bằng kubectl describe httproute, khả năng cao route chưa được Gateway nào nhận).

16. Sau khi restore 1 namespace từ Velero backup, Pod của app lên Running bình thường nhưng dữ liệu bên trong database trống rỗng như mới cài - chưa hề có dữ liệu cũ (gợi ý: kiểm tra backup đó có bật chế độ backup volume/PV hay chỉ backup định nghĩa resource).