16. Lightning Labs

Mục lục

• 1. Lightning Labs là gì?
• 2. Điều kiện và cách tiếp cận
• 3. Chiến lược làm bài hiệu quả
• 4. Tuyên bố miễn trừ trách nhiệm
• 5. Kỳ thi CKA thật: các con số đã xác minh
• Nguồn tham khảo

---

1. Lightning Labs là gì?

Học xong lý thuyết là một chuyện. Làm được nó trong 3 phút, khi đồng hồ đang chạy ngược, lại là chuyện khác hẳn. Lightning Labs sinh ra để lấp đúng khoảng cách đó.

Lightning Labs (tạm dịch: "lab chớp nhoáng") là bài lab mô phỏng kỳ thi CKA, thiết kế để rèn tốc độ và độ chính xác trong môi trường bị giới hạn thời gian. Khác với lab thông thường — nơi bạn có thể đọc đi đọc lại tài liệu, thử sai bao nhiêu lần cũng được — Lightning Labs bắt bạn hoàn thành nhiều câu hỏi liên tiếp trong một khoảng thời gian ngắn, giống cách kỳ thi thật vận hành.

Điểm mấu chốt: cả Lightning Labs lẫn kỳ thi CKA thật đều là bài thi performance-based — không có câu trắc nghiệm nào cả. Bạn được đẩy vào một terminal Linux nối tới cluster thật, và được chấm bằng trạng thái cuối cùng của cluster đó. Không ai đọc suy nghĩ của bạn. Object tồn tại đúng như đề yêu cầu thì có điểm, không tồn tại thì không có điểm.

Trong phần này, cần trả lời 3 câu hỏi cốt lõi:

• Lightning Labs khác gì so với lab thông thường?
• Làm sao phân bổ thời gian hiệu quả?
• Chiến lược nào giúp hoàn thành được nhiều câu hỏi nhất?

💡 Hình dung: Lightning Labs giống thi thử TOEIC có bấm giờ — không chỉ kiểm tra bạn biết bao nhiêu, mà còn kiểm tra bạn áp dụng được nhanh đến đâu dưới áp lực.

---

2. Điều kiện và cách tiếp cận

2.1. Thông tin môi trường

Các con số dưới đây là của bài Lightning Lab trong khóa học, không phải của kỳ thi CKA thật. Số liệu chính thức của kỳ thi nằm ở phần 5.

• Thời gian: môi trường lab có hiệu lực trong 60 phút.
• Thử thách: hoàn thành cả 5–8 câu hỏi trong vòng 30 phút — đây là mục tiêu tự đặt ra, không phải giới hạn cứng.
• Điều hướng: có thể nhảy qua lại giữa các câu hỏi, không bắt buộc làm tuần tự.
• Kết thúc: nhớ bấm nút END EXAM trước khi hết giờ. Đây là nút kết thúc phiên thi và nộp bài — trong ExamUI của Linux Foundation, hệ thống cũng cảnh báo khi còn 30, 15 và 5 phút, nhưng đừng chờ tới lúc đó mới soát lại.
• Điểm đạt: bài lab yêu cầu 80%. Ngưỡng này khắt khe hơn kỳ thi thật (66%) — cố ý, để tạo biên an toàn khi luyện.

2.2. Chuẩn bị trước

Trước khi bắt đầu Lightning Labs, cần nắm vững:

• Các câu lệnh kubectl thường dùng: get, describe, logs, exec, edit.
• Cách tạo và apply Kubernetes object từ file YAML.
• Cách dùng kubectl explain để tra cứu cấu trúc resource mà không phải rời terminal.
• Các lệnh sinh nhanh YAML: kubectl run, kubectl create kèm --dry-run=client -o yaml.

Nếu còn phải nghĩ mất vài giây mới nhớ ra cú pháp của một trong bốn nhóm trên, hãy quay lại luyện trước khi bấm giờ. Lightning Labs không dạy cú pháp — nó đo xem cú pháp đã thành phản xạ chưa.

2.3. Tip cho kỳ thi thật

Tự thử thách bản thân: đặt mục tiêu hoàn thành tất cả câu hỏi trong thời gian ngắn nhất có thể, rồi lặp lại bài lab cho tới khi thời gian đó ổn định. Con số bạn cần theo dõi không phải là "đúng hay sai", mà là "mất bao lâu để đúng".

---

3. Chiến lược làm bài hiệu quả

3.1. Nguyên tắc phân bổ thời gian

Sai lầm kinh điển trong phòng thi không phải là làm sai, mà là làm đúng một câu quá lâu. Một câu RBAC rối rắm ngốn 20 phút có thể kéo theo ba câu dễ chưa kịp chạm tới. Vì vậy việc đầu tiên khi mở một câu hỏi không phải là gõ lệnh — mà là phân loại nó.

Loại câu hỏi	Thời gian ước tính	Ưu tiên
Câu quen thuộc (tạo Pod, Service)	2–3 phút	Làm trước
Câu cần sửa một lỗi nhỏ	3–5 phút	Làm ngay sau
Câu phức tạp (RBAC, NetworkPolicy)	5–8 phút	Làm khi còn thời gian
Câu lạ, chưa từng gặp	8–10 phút	Đánh dấu, quay lại sau

Quy tắc duy nhất cần nhớ từ sơ đồ trên: quyết định phân loại phải mất ít thời gian hơn bản thân câu hỏi. Đọc 30 giây, quyết ngay, rồi hoặc làm hoặc bỏ qua.

3.2. Chiến lược 3 vòng

Thay vì đi tuần tự từ câu 1 tới câu cuối, hãy quét bộ đề ba lượt — mỗi lượt với một mục tiêu khác nhau.

Vòng 1 — quick wins (15 phút đầu):

• Đọc lướt toàn bộ câu hỏi trước khi gõ dòng lệnh đầu tiên.
• Làm những câu quen thuộc nhất trước, lấy điểm chắc chắn về túi.
• Đánh dấu lại những câu khó, đừng cố sức ngay lúc này.

Vòng 2 — medium difficulty (phút 15–25):

• Quay lại những câu đã đánh dấu, giờ đầu óc đã ấm lên và áp lực "chưa làm được gì" đã hết.
• Dùng kubectl explain để tra nhanh cấu trúc field thay vì mở tài liệu.
• Áp dụng lại pattern đã học từ các bài lab trước — hầu hết câu hỏi là biến thể của một pattern quen.

Vòng 3 — hard problems (phút 25–30):

• Xử lý những câu còn lại, những câu cần nhiều thời gian nhất.
• Câu nào thật sự không làm được, vẫn cố viết YAML skeleton để lấy điểm từng phần (partial credit) — tức phần điểm cho những gì đã làm đúng trong một câu hỏi nhiều ý, thay vì bỏ trắng hoàn toàn.

💡 Lưu ý: Linux Foundation có công bố rằng các câu multi-part được tính điểm cao hơn câu đơn giản, nhưng không xác minh được từ nguồn chính thức rằng một task làm dở dang chắc chắn được chấm điểm từng phần. Cứ để lại object đã tạo — chi phí bằng không, và khả năng có điểm thì khác không.

3.3. Lệnh tiết kiệm thời gian

Bốn nhóm lệnh dưới đây chiếm phần lớn thao tác trong một bài thi bấm giờ. Điều quan trọng không phải là thuộc lòng chúng, mà là biết chính xác mỗi lệnh trả về cái gì — để không mất thời gian đọc lại output.

Sinh nhanh khung YAML. Không ai viết YAML từ đầu trong phòng thi. Luôn để kubectl sinh khung, rồi sửa.

kubectl run nginx --image=nginx --dry-run=client -o yaml > nginx.yaml
cat nginx.yaml

# Output minh họa
# apiVersion: v1
# kind: Pod
# metadata:
#   creationTimestamp: null
#   labels:
#     run: nginx
#   name: nginx
# spec:
#   containers:
#   - image: nginx
#     name: nginx
#     resources: {}
#   dnsPolicy: ClusterFirst
#   restartPolicy: Always
# status: {}

(Output minh họa — cấu trúc và tên field đúng theo lệnh thật, giá trị cụ thể chỉ mang tính ví dụ.)

--dry-run=client nghĩa là kubectl dựng object rồi in ra, không gửi lên API server. Hai field creationTimestamp: null và status: {} là rác do quá trình serialize sinh ra — xóa đi hay để nguyên đều không ảnh hưởng khi apply.

Tra cứu cấu trúc resource. Khi quên tên field, kubectl explain nhanh hơn mở tài liệu rất nhiều vì không phải rời terminal.

kubectl explain pod.spec

# Output minh họa (rút gọn)
# GROUP:
# KIND:       Pod
# VERSION:    v1
#
# FIELD: spec <PodSpec>
#
# DESCRIPTION:
#     Specification of the desired behavior of the pod.
#     PodSpec is a description of a pod.
#
# FIELDS:
#   activeDeadlineSeconds <integer>
#   affinity              <Affinity>
#   containers            <[]Container> -required-
#   nodeName              <string>
#   nodeSelector          <map[string]string>
#   serviceAccountName    <string>
#   tolerations           <[]Toleration>
#   volumes               <[]Volume>

(Output minh họa — cấu trúc và tên field đúng theo lệnh thật, giá trị cụ thể chỉ mang tính ví dụ.)

Dấu -required- cho biết field bắt buộc. Đi sâu thêm một cấp bằng cách nối tiếp đường dẫn: kubectl explain pod.spec.containers.resources. Thêm --recursive để xem toàn bộ cây field một lần, không kèm mô tả.

Xem toàn cảnh một namespace. Khi đề nói "namespace app-prod có gì đó hỏng", đây là lệnh đầu tiên cần gõ.

kubectl get all -n app-prod

# Output minh họa
# NAME                       READY   STATUS             RESTARTS   AGE
# pod/web-5c8f7d9b44-2xqzl   0/1     CrashLoopBackOff   4          3m21s
#
# NAME                  TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
# service/web-service   ClusterIP   10.104.22.180   <none>        80/TCP    3m21s
#
# NAME                  READY   UP-TO-DATE   AVAILABLE   AGE
# deployment.apps/web   0/1     1            0           3m21s
#
# NAME                             DESIRED   CURRENT   READY   AGE
# replicaset.apps/web-5c8f7d9b44   1         1         0       3m21s

(Output minh họa — cấu trúc và tên field đúng theo lệnh thật, giá trị cụ thể chỉ mang tính ví dụ.)

Lưu ý get all không thật sự liệt kê tất cả — nó bỏ qua ConfigMap, Secret, PVC, Ingress, NetworkPolicy và mọi custom resource. Nó chỉ trả về nhóm workload phổ biến nhất. Cần đầy đủ thì phải gọi tên resource cụ thể.

Debug nhanh một Pod. Ba lệnh, theo đúng thứ tự này — từ ngoài vào trong.

kubectl get pod web-5c8f7d9b44-2xqzl -n app-prod -o wide

# Output minh họa
# NAME                   READY   STATUS             RESTARTS   AGE     IP           NODE     NOMINATED NODE   READINESS GATES
# web-5c8f7d9b44-2xqzl   0/1     CrashLoopBackOff   4          3m40s   10.244.1.7   node01   <none>           <none>

(Output minh họa — cấu trúc và tên field đúng theo lệnh thật, giá trị cụ thể chỉ mang tính ví dụ.)

-o wide thêm cột IP và NODE — đủ để biết Pod đã được schedule chưa và nằm ở node nào. Nếu cột NODE trống, vấn đề nằm ở scheduler chứ không phải ở container.

kubectl describe pod web-5c8f7d9b44-2xqzl -n app-prod

# Output minh họa (rút gọn)
# Name:         web-5c8f7d9b44-2xqzl
# Namespace:    app-prod
# Node:         node01/192.168.1.11
# Containers:
#   web:
#     State:          Waiting
#       Reason:       CrashLoopBackOff
#     Last State:     Terminated
#       Reason:       Error
#       Exit Code:    1
# Events:
#   Type     Reason     Age                 From     Message
#   ----     ------     ----                ----     -------
#   Normal   Pulled     2m (x4 over 3m)     kubelet  Container image "web:1.2" already present on machine
#   Warning  BackOff    30s (x8 over 3m)    kubelet  Back-off restarting failed container

(Output minh họa — cấu trúc và tên field đúng theo lệnh thật, giá trị cụ thể chỉ mang tính ví dụ.)

Phần đáng đọc nhất luôn là mục Events ở cuối, và Last State — nó cho biết lần chạy trước chết vì lý do gì. Exit Code: 1 nghĩa là chính ứng dụng thoát với lỗi, không phải Kubernetes giết nó.

kubectl logs web-5c8f7d9b44-2xqzl -n app-prod --tail=50

# Output minh họa
# 2026-09-14T08:12:44Z  INFO   starting web server
# 2026-09-14T08:12:44Z  FATAL  dial tcp 10.104.9.11:5432: connect: connection refused

(Output minh họa — cấu trúc và tên field đúng theo lệnh thật, giá trị cụ thể chỉ mang tính ví dụ.)

--tail=50 giới hạn 50 dòng cuối — quan trọng khi container đã chạy lâu và log dài hàng nghìn dòng. Với Pod đang CrashLoopBackOff, thêm --previous để đọc log của lần chạy trước khi nó restart, vì container hiện tại có thể chưa kịp in gì.

💡 Mẹo: Luôn bật tab completion và alias trước khi làm câu đầu tiên. Xem mục 5.4 để có block setup hoàn chỉnh.

---

4. Tuyên bố miễn trừ trách nhiệm

Vui lòng lưu ý:

1. Bài thi này không phải là bản sao chính xác của bài thi thực tế.
2. Các câu hỏi trong bài thi này không giống với các câu hỏi trong bài thi thực tế.
3. Giao diện không giống với bài thi thực tế.
4. Hệ thống chấm điểm có thể không giống với bài thi thực tế.
5. Mức độ khó có thể không tương ứng với bài thi thực tế.

Tuy nhiên, Lightning Labs vẫn là công cụ luyện tập rất tốt để:

• Rèn tốc độ thao tác với kubectl.
• Làm quen với áp lực thời gian.
• Kiểm tra kiến thức thực hành một cách toàn diện.

---

5. Kỳ thi CKA thật: các con số đã xác minh

Phần trên nói về bài lab. Phần này nói về kỳ thi thật — toàn bộ số liệu dưới đây lấy từ tài liệu chính thức của Linux Foundation và CNCF, có dẫn nguồn ở cuối trang. Thông tin về kỳ thi thay đổi theo thời gian, nên luôn đối chiếu lại với trang chính thức trước ngày thi.

5.1. Format và điều kiện đạt

Hạng mục	Giá trị
Thời lượng	2 tiếng
Số lượng câu hỏi	15–20 task performance-based
Điểm đạt	66%
Hình thức	Online, có giám thị từ xa (remote-proctored), làm hoàn toàn trên command line — không có câu trắc nghiệm
Thi lại	Gói thi kèm 1 lần retake miễn phí
Hạn kích hoạt	12 tháng kể từ khi mua để đặt lịch và thi
Hiệu lực chứng chỉ	2 năm (chứng chỉ cấp trước 01/04/2024 vẫn có hiệu lực 3 năm)
Phiên bản Kubernetes	Môi trường thi hiện chạy v1.35

Về cách chấm: các câu hỏi không cùng trọng số. Linux Foundation nêu rõ câu multi-part và câu đòi kỹ năng khó hơn sẽ có điểm cao hơn câu đơn giản. Và với bài thi performance-based, thường có nhiều cách làm ra cùng một kết quả — miễn trạng thái cuối cùng đúng, cách làm nào cũng được chấp nhận. Đừng phí thời gian tìm cách "chuẩn nhất".

5.2. Curriculum v1.35 và trọng số domain

Curriculum hiện hành là CKA Curriculum v1.35 (số hiệu curriculum luôn khớp với phiên bản Kubernetes tương ứng). Trọng số các domain:

Domain	Trọng số
Troubleshooting	30%
Cluster Architecture, Installation & Configuration	25%
Services and Networking	20%
Workloads and Scheduling	15%
Storage	10%

Con số 30% cho Troubleshooting là điều đáng chú ý nhất ở bản curriculum này: domain nặng nhất không phải là "biết tạo resource", mà là "biết sửa khi resource đã hỏng". Nếu chỉ còn thời gian để ôn một phần, hãy ôn Troubleshooting.

Hai điểm mới cũng đáng lưu ý: curriculum yêu cầu dùng Helm và Kustomize để cài cluster component, và dùng Gateway API để quản lý Ingress traffic — bên cạnh Ingress controller cổ điển. Cả hai đều xuất hiện trong danh sách tài liệu được phép mở ở mục dưới, không phải ngẫu nhiên.

5.3. Tài liệu được phép mở trong lúc thi

Đây là thông tin thực dụng nhất cho việc luyện tập: nếu bạn quen tra cứu ở đâu, hãy quen đúng những domain này, vì trong phòng thi sẽ không mở được gì khác.

• https://kubernetes.io/docs — tài liệu Kubernetes.
• https://kubernetes.io/blog/ — blog Kubernetes.
• https://helm.sh/docs — tài liệu Helm.
• https://gateway-api.sigs.k8s.io — tài liệu Gateway API.
• Các link tài liệu theo từng task nằm trong ô Quick Reference của đề thi.

Ba ràng buộc đi kèm, cần nhớ chính xác:

• Được dùng ô search ngay trên kubernetes.io/docs, nhưng không được mở kết quả trỏ ra ngoài các domain trên.
• Mọi bản dịch ngôn ngữ của kubernetes.io đều được phép, tuy vậy nên dùng bản tiếng Anh vì được cập nhật sớm nhất.
• Chỉ được mở đúng một tab tài liệu bên cạnh terminal — đừng xây thói quen mở mười tab khi luyện ở nhà.

Hệ quả cho việc ôn: mọi thứ bạn định tra trong phòng thi phải tồn tại dưới bốn domain trên. Tập tra YAML mẫu trực tiếp từ kubernetes.io/docs thay vì từ blog cá nhân hay Stack Overflow, và tập nhớ tên trang chứ không phải nhớ URL đầy đủ.

5.4. 60 giây đầu tiên: dựng môi trường gõ lệnh

Trước khi đọc câu hỏi đầu tiên, dành đúng một phút để dựng môi trường. Một phút này đổi lại hàng chục phút không phải gõ tay kubectl và không phải thêm -n <namespace> vào mọi lệnh.

# 1. Bật autocomplete cho kubectl, rồi cho cả alias k
source <(kubectl completion bash)
alias k=kubectl
complete -o default -F __start_kubectl k

# 2. Biến tắt cho dry-run — dùng lại được ở mọi lệnh sinh YAML
export do="--dry-run=client -o yaml"

# 3. Ghim namespace của câu hỏi vào context hiện tại
kubectl config set-context --current --namespace=app-prod

# 4. Vim: tab thành 2 space, bật số dòng — YAML sai thụt lề là mất điểm oan
cat >> ~/.vimrc <<'VIMEOF'
set expandtab
set tabstop=2
set shiftwidth=2
set number
VIMEOF

Sau khi có hai thứ trên, một lệnh tạo Pod rút gọn còn thế này:

k run nginx --image=nginx $do > nginx.yaml

# Output minh họa
# (lệnh không in gì ra màn hình — toàn bộ YAML đã được ghi vào nginx.yaml)

(Output minh họa — cấu trúc và tên field đúng theo lệnh thật, giá trị cụ thể chỉ mang tính ví dụ.)

Ba lưu ý về block trên:

• complete -o default -F __start_kubectl k là dòng làm cho autocomplete hoạt động với alias k. Thiếu dòng này thì alias k=kubectl vẫn chạy, nhưng gõ k get po<TAB> sẽ không gợi ý gì.
• Trong kỳ thi CKA thật, alias k và bash autocompletion đã được cấu hình sẵn trên các SSH host, cùng với yq, curl, wget và man pages. Biết cách tự dựng vẫn có giá trị: bạn sẽ dùng nó ở mọi môi trường luyện tập, và sẽ không hoảng nếu môi trường thi khác với mong đợi.
• kubectl config set-context --current --namespace=... phải chạy lại mỗi khi chuyển sang câu hỏi dùng namespace khác. Quên bước này là nguyên nhân số một của tình trạng "lệnh chạy thành công nhưng chấm không ra điểm" — object được tạo đúng, chỉ là tạo nhầm chỗ.

Cuối cùng, hãy biến ba thứ thành phản xạ chứ không phải kiến thức: gõ k thay vì kubectl, thêm $do thay vì --dry-run=client -o yaml, và ghim namespace ngay khi mở một câu hỏi mới. Kiến thức Kubernetes quyết định bạn có làm được bài hay không — ba phản xạ này quyết định bạn có kịp giờ hay không.

---

Nguồn tham khảo

Nguồn gốc: Khóa "Certified Kubernetes Administrator (CKA)" — bài "Lightning Lab Introduction" (Phần 16), nền tảng KodeKloud. Giảng viên: Mumshad Mannambeth.

Repo ghi chú, link tài liệu, và đáp án các practice question của toàn bộ khóa học: kodekloudhub/certified-kubernetes-administrator-course.

Fact-check:

• Thời lượng 2 tiếng, gói thi kèm 1 lần retake, hạn kích hoạt 12 tháng, chứng chỉ có hiệu lực 2 năm, môi trường thi chạy Kubernetes v1.35 — 2026-09-23, Linux Foundation — Certified Kubernetes Administrator (CKA)
• Điểm đạt 66%; hiệu lực 2 năm (chứng chỉ trước 01/04/2024 là 3 năm); môi trường thi hiện chạy Kubernetes v1.35 — 2026-09-23, Linux Foundation — FAQ: CKA and CKAD & CKS
• Đề gồm 15–20 task performance-based; SSH host cài sẵn kubectl với alias k và bash autocompletion, yq, curl, wget, man pages — 2026-09-23, Linux Foundation — Important Instructions: CKA and CKAD
• Danh sách domain tài liệu được phép mở (kubernetes.io/docs, kubernetes.io/blog, helm.sh/docs, gateway-api.sigs.k8s.io), quy tắc dùng ô search và bản dịch ngôn ngữ — 2026-09-23, Linux Foundation — Resources Allowed: All LF Certification Programs
• Trọng số domain của CKA Curriculum v1.35: Troubleshooting 30%, Cluster Architecture/Installation/Configuration 25%, Services and Networking 20%, Workloads and Scheduling 15%, Storage 10% — 2026-09-23, cncf/curriculum — CKA_Curriculum_v1.35.pdf
• Câu multi-part và câu khó có điểm cao hơn; bài thi performance-based chấp nhận mọi cách làm ra đúng kết quả — 2026-09-23, Linux Foundation — Certification FAQ
• Nút "End Exam" kết thúc phiên thi; hệ thống cảnh báo khi còn 30, 15 và 5 phút — 2026-09-23, Linux Foundation — ExamUI: Performance Based Exams
• Cú pháp source <(kubectl completion bash), alias k=kubectl, complete -o default -F __start_kubectl k và kubectl config set-context --current --namespace= — 2026-09-23, Kubernetes — kubectl Quick Reference