B.Nhóm các Service được gom lại để chia sẻ cấu hình mạng
C.Đơn vị triển khai nhỏ nhất — gồm một hoặc nhiều container dùng chung network namespace và có thể dùng chung volume
D.Tên gọi khác của container trong Kubernetes, mỗi Pod luôn đúng một container
Đáp án: C
Pod là đơn vị nhỏ nhất mà Kubernetes lập lịch. Nó bọc một hoặc nhiều container dùng chung IP, cổng và có thể dùng chung volume — nên các container trong cùng Pod gọi nhau bằng localhost. Pod là phù du: chết đi thì được tạo mới với IP khác, không hồi sinh cái cũ.
Deployment làm gì mà tạo Pod trực tiếp không làm được?
A.Nó cấp cho Pod một địa chỉ IP cố định không đổi
B.Nó cho phép Pod ghi dữ liệu bền vững ra đĩa
C.Nó duy trì số bản sao mong muốn — Pod chết thì tự tạo lại — và quản lý việc cập nhật phiên bản theo kiểu cuốn chiếu, có thể rollback về bản trước
D.Nó tăng giới hạn CPU và bộ nhớ cho Pod
Đáp án: C
Deployment giữ cho luôn có đủ số Pod mong muốn và tự tạo lại khi Pod chết. Nó cũng lo việc nâng cấp: đổi image thì Pod mới lên dần, Pod cũ rút dần, và rollback được nếu bản mới hỏng. Pod trần chết là hết.
Pod có IP thay đổi mỗi lần tạo lại, nên không thể gọi trực tiếp. Service cho nhóm Pod (chọn qua label) một IP ảo và tên DNS cố định, rồi phân tải các request tới những Pod đang sẵn sàng.
A.ConfigMap chỉ dùng được cho một namespace, Secret dùng chung toàn cụm
B.ConfigMap gắn được vào Pod dưới dạng biến môi trường, Secret thì chỉ mount được thành file
C.Secret được mã hóa đầu cuối nên kể cả người có quyền admin cụm cũng không đọc được
D.Cả hai đều tách cấu hình khỏi image, nhưng Secret dành cho dữ liệu nhạy cảm: giá trị lưu dạng base64, có thể mã hóa khi lưu trong etcd và kiểm soát truy cập chặt hơn qua RBAC
Đáp án: D
Cả hai đưa cấu hình vào Pod mà không phải build lại image. ConfigMap cho dữ liệu thường, Secret cho dữ liệu nhạy cảm — Secret lưu base64, hỗ trợ mã hóa khi lưu và nên siết bằng RBAC. Lưu ý: base64 KHÔNG phải mã hóa.
B.Chia cụm thành nhiều mạng vật lý tách rời hoàn toàn
C.Chia cụm thành nhiều không gian tên logic để tách tài nguyên
D.Đặt tên miền công khai cho service ra internet
Đáp án: C
Namespace tách tài nguyên trong cùng một cụm thành các không gian logic — tên tài nguyên chỉ cần duy nhất trong namespace. Nó là phạm vi cho RBAC và ResourceQuota. Lưu ý: nó KHÔNG tự cách ly mạng, muốn vậy phải dùng NetworkPolicy.
Label và selector trong Kubernetes dùng để làm gì?
A.Label là cặp khóa–giá trị gắn lên tài nguyên; selector là biểu thức lọc theo label
B.Selector chỉ dùng cho lệnh kubectl get khi lọc thủ công
C.Label thay thế cho namespace trong việc phân tách tài nguyên
D.Label là tên hiển thị trên dashboard, không ảnh hưởng tới hoạt động
Đáp án: A
Label là metadata dạng khóa–giá trị gắn lên tài nguyên. Selector lọc theo label. Đây là chất keo của Kubernetes: Service tìm Pod qua selector, Deployment nhận Pod của mình qua selector. Sai lệch giữa label và selector là nguyên nhân số một khiến Service không có endpoint.
Cần chạy một agent thu log trên MỌI Node trong cụm. Loại workload nào phù hợp?
A.DaemonSet — mỗi Node đúng một bản sao, Node mới cũng có
B.StatefulSet, vì agent cần danh tính ổn định
C.Deployment với replicas bằng số Node hiện tại
D.CronJob chạy mỗi phút để đảm bảo agent còn sống
Đáp án: A
DaemonSet. Nó đặt đúng một Pod trên mỗi Node phù hợp, tự thêm khi có Node mới và tự dọn khi Node rời cụm. Dùng cho agent thu log, giám sát, network plugin — những thứ phải hiện diện ở mọi máy.
kubectl get pod <tên> và kubectl describe pod <tên> khác nhau ở chỗ nào?
A.get đọc từ Node, describe đọc từ etcd
B.get in trạng thái tóm tắt dạng bảng; describe in chi tiết đầy đủ kèm phần Events
C.describe chỉ dùng được cho Pod, get dùng cho mọi loại tài nguyên
D.get hiển thị log của container, describe thì không
Đáp án: B
get cho cái nhìn nhanh dạng bảng. describe cho chi tiết cấu hình cộng phần Events — nơi ghi lý do Pod không được lập lịch, image kéo thất bại, probe hỏng. Khi có sự cố, describe gần như luôn là lệnh thứ hai sau get.
Cụm gồm nhiều Node (máy). Mỗi Node chạy nhiều Pod. Mỗi Pod bọc một hoặc nhiều container dùng chung IP và volume. Ngoài ra cụm có control plane (API server, scheduler, controller manager, etcd) điều phối mọi thứ.
Deployment khai báo image: myapp:latest. Vì sao đây là lựa chọn tệ ở production?
A.Không biết đang chạy bytes nào, rollback không đáng tin
B.Kubernetes không hỗ trợ tag latest
C.Tag latest làm image tải chậm hơn các tag khác
D.latest bắt buộc phải dùng kèm imagePullPolicy: Never
Đáp án: A
latest là tag di động — nó trỏ vào image nào tùy thời điểm. Hệ quả: không biết production đang chạy gì, rollout undo có thể quay về đúng tag đó nên không đổi gì, và các Pod tạo ở thời điểm khác nhau có thể chạy hai phiên bản khác nhau.
Nó hiển thị những gì tiến trình trong container ghi ra đầu ra chuẩn. Vì vậy ứng dụng chạy trên Kubernetes nên ghi log ra đầu ra chuẩn thay vì ghi vào file — file trong container không lấy được bằng lệnh này.
Deployment tạo và quản lý ReplicaSet, còn ReplicaSet giữ đúng số Pod theo yêu cầu. Mỗi phiên bản của Deployment ứng với một ReplicaSet riêng — đó là cách quay lui về phiên bản cũ hoạt động được.
Nó chạy một lệnh bên trong container đang chạy, và hai tuỳ chọn kèm theo mở phiên tương tác có cấp phát thiết bị đầu cuối. Đây là cách nhanh nhất để xem file, biến môi trường và tình trạng mạng từ bên trong container.
Trong manifest YAML, apiVersion và kind cho biết điều gì?
A.Phiên bản Kubernetes của cụm đang chạy
B.Loại tài nguyên và phiên bản API
C.Cách máy chủ API xác thực người gửi
D.Phiên bản của ứng dụng được triển khai
Đáp án: B
kind cho biết loại tài nguyên — Pod, Service, Deployment — còn apiVersion cho biết nhóm và phiên bản API mô tả loại đó. Máy chủ API dùng hai trường này để chọn lược đồ khi kiểm tra và lưu tài nguyên.
Các container trong cùng một Pod chia sẻ những gì?
A.Toàn bộ hệ thống file gốc của nhau
B.Các tiến trình đang chạy bên trong
C.Địa chỉ mạng và các volume
D.Giới hạn tài nguyên đặt cho từng container
Đáp án: C
Chúng chia sẻ không gian mạng — nên gọi nhau qua địa chỉ cục bộ và không được trùng cổng — và các volume cùng được gắn. Hệ thống file gốc thì riêng, mỗi container lấy từ image của nó.
Nó mở một đường hầm tạm thời từ máy cá nhân tới service trong cụm, đi qua máy chủ API. Nhờ đó truy cập được service nội bộ để kiểm thử mà không cần mở nó ra internet.
Vì sao không nên cấu hình ứng dụng gọi trực tiếp theo IP của Pod?
A.IP của Pod đổi mỗi lần tạo lại
B.IP của Pod chỉ dùng được trong cùng Node
C.Gọi theo IP chậm hơn gọi qua tên service
D.Kubernetes chặn kết nối trực tiếp giữa các Pod
Đáp án: A
Vì IP của Pod thay đổi mỗi lần Pod được tạo lại — khi cập nhật, khi Node hỏng, hay khi mở rộng. Địa chỉ ghi cứng sẽ trỏ vào hư không ngay sau lần thay thế đầu tiên. Cách đúng là gọi qua tên của Service.
restartPolicy của Pod nhận những giá trị nào và mặc định là gì?
A.Always, OnFailure, Never — mặc định Always
B.OnFailure và Never — mặc định là OnFailure
C.Enabled và Disabled — mặc định là Enabled
D.Always và Never — mặc định là Never
Đáp án: A
Ba giá trị: luôn khởi động lại (mặc định), chỉ khi thất bại, và không bao giờ. Mặc định phù hợp cho dịch vụ chạy liên tục; các công việc chạy một lần rồi kết thúc cần một trong hai giá trị còn lại.
File kubeconfig và khái niệm context dùng để làm gì?
A.Lưu các manifest đã áp lên cụm
B.Cấu hình tài nguyên mặc định cho Pod mới
C.Lưu thông tin cụm, chuyển giữa các cụm
D.Định nghĩa quyền của người dùng trong cụm
Đáp án: C
File kubeconfig lưu địa chỉ các cụm, danh tính và namespace mặc định. Mỗi context là một bộ ba đó, nên làm việc với nhiều cụm chỉ cần chuyển context thay vì gõ lại tham số mỗi lệnh.
Cần tăng số bản sao của một Deployment từ 3 lên 5. Cách nào đúng với quy trình khai báo?
A.Sửa trực tiếp tài nguyên bằng lệnh chỉnh sửa
B.Chạy lệnh scale trực tiếp trên cụm
C.Sửa manifest trong repository, áp lại
D.Xoá Deployment rồi tạo lại với số mới
Đáp án: C
Sửa manifest trong repository rồi áp lại. Lệnh scale trực tiếp cho kết quả ngay nhưng tạo ra sai lệch: lần áp manifest tiếp theo sẽ đưa số bản sao về giá trị cũ, và không ai hiểu vì sao.
Liveness probe và readiness probe khác nhau ở hậu quả khi thất bại như thế nào?
A.Liveness thất bại → kubelet KHỞI ĐỘNG LẠI container; readiness thất bại → Pod bị gỡ khỏi endpoint của Service nên ngừng nhận traffic nhưng vẫn chạy
B.Readiness thất bại thì Pod bị xóa và tạo lại
C.Liveness chỉ chạy một lần lúc khởi động, readiness chạy liên tục
D.Cả hai đều khởi động lại container, chỉ khác tần suất kiểm tra
Đáp án: A
Liveness trả lời "tiến trình còn sống không" — hỏng thì restart container. Readiness trả lời "có sẵn sàng nhận request chưa" — hỏng thì rút khỏi Service nhưng container vẫn chạy. Nhầm hai cái này gây restart loop không cần thiết.
A.Hai giá trị giống nhau, limits chỉ là tên cũ của requests
B.requests là trần cứng, limits là mức khuyến nghị
C.requests là lượng tài nguyên được ĐẢM BẢO và là căn cứ để scheduler chọn Node; limits là trần không được vượt
D.Vượt limits bộ nhớ thì Pod chỉ bị chậm lại chứ không bị giết
Đáp án: C
requests là mức đảm bảo, scheduler dùng nó để tìm Node còn đủ chỗ. limits là trần. Vượt trần CPU thì container bị bóp (throttle) chứ không chết; vượt trần bộ nhớ thì bị kernel giết với exit code 137, vì bộ nhớ không thể nén.
Có 10 service HTTP cần cho truy cập từ internet. Vì sao Ingress thường hợp lý hơn 10 Service kiểu LoadBalancer?
A.Nhiều service dùng chung MỘT điểm vào, định tuyến theo host/path
B.LoadBalancer chỉ dùng được cho service nội bộ, không mở ra internet được
C.Ingress nhanh hơn vì bỏ qua lớp Service
D.Ingress tự động mã hóa toàn bộ traffic giữa các Pod trong cụm
Đáp án: A
Mỗi Service LoadBalancer thường tốn một load balancer và một IP công khai — 10 service là 10 lần chi phí. Ingress cho tất cả dùng chung một điểm vào, định tuyến theo tên miền và đường dẫn, và quản lý chứng chỉ TLS tập trung.
Pod ở trạng thái CrashLoopBackOff. Điều đó nghĩa là gì?
A.Pod đang chờ PersistentVolume được cấp phát
B.Không có Node nào đủ tài nguyên để xếp Pod vào
C.Container khởi động rồi thoát liên tục, nên kubelet giãn dần khoảng chờ giữa các lần thử lại
D.Không kéo được image từ registry
Đáp án: C
Container cứ khởi động rồi chết, lặp đi lặp lại. Kubelet tăng dần khoảng chờ giữa các lần thử (10s, 20s, 40s… tới 5 phút). Log của container đang chạy thường rỗng — phải dùng kubectl logs <pod> --previous để đọc log lần chạy vừa chết.
Vì sao database nên chạy bằng StatefulSet thay vì Deployment?
A.StatefulSet tự động sao lưu dữ liệu định kỳ
B.Mỗi Pod có danh tính ổn định và ổ đĩa riêng
C.StatefulSet chạy nhanh hơn vì bỏ qua lớp ReplicaSet
D.Deployment không gắn được volume vào Pod
Đáp án: B
StatefulSet cho Pod tên cố định và có thứ tự (db-0, db-1), mỗi Pod một PersistentVolumeClaim riêng bám theo nó. Pod chết và tạo lại vẫn là db-0 và vẫn gắn đúng ổ đĩa cũ. Deployment thì Pod tên ngẫu nhiên và không có ràng buộc đó.
Những phát biểu nào sau đây đúng về rolling update của Deployment? (chọn nhiều đáp án)
A.Rollback bằng kubectl rollout undo sẽ khôi phục lại cả dữ liệu trong database về trạng thái trước khi deploy
B.Trong quá trình rollout, phiên bản cũ và mới chạy song song — nên ứng dụng phải tương thích ngược, nhất là với schema database
C.Readiness probe quyết định khi nào Pod mới được coi là sẵn sàng để rollout tiếp tục — thiếu probe thì Kubernetes coi Pod sẵn sàng ngay khi container chạy, và có thể gửi traffic vào Pod chưa khởi động xong
D.maxSurge và maxUnavailable kiểm soát tốc độ chuyển đổi — bao nhiêu Pod được tạo thêm và bao nhiêu Pod được phép thiếu trong lúc cập nhật
Đáp án: B, C, D
maxSurge/maxUnavailable điều tiết tốc độ; hai phiên bản chạy song song nên phải tương thích ngược; readiness probe là thứ làm cho rollout thật sự không downtime. Rollback chỉ quay lui phiên bản code — dữ liệu và schema thì không.
Pod ở trạng thái Pending và kubectl describe báo FailedScheduling. Nguyên nhân thường gặp nhất là gì?
A.Service chưa được tạo nên Pod không có địa chỉ
B.Image trong Pod bị lỗi nên không khởi động được
C.Liveness probe thất bại ngay lần đầu
D.Không Node nào đủ tài nguyên hoặc thoả ràng buộc của Pod
Đáp án: D
Scheduler không tìm được Node phù hợp. Hai nhóm lý do: thiếu tài nguyên (tổng requests trên Node đã kín) hoặc ràng buộc không thỏa (nodeSelector, affinity, taint, hoặc PVC chưa gắn được). kubectl describe pod ghi rõ lý do cho từng Node bị loại.
PersistentVolume (PV) và PersistentVolumeClaim (PVC) quan hệ với nhau thế nào?
A.PV thuộc về Pod, PVC thuộc về Node
B.PVC là bản sao lưu của PV
C.PVC là YÊU CẦU lưu trữ do phía phát triển khai báo
D.PV và PVC là hai tên gọi của cùng một tài nguyên
Đáp án: C
PVC là đơn yêu cầu ("tôi cần 20Gi, ghi được từ một Node"), PV là ổ đĩa thật đáp ứng yêu cầu đó. Có StorageClass thì PV được cấp phát tự động khi PVC xuất hiện. Nhờ tách hai lớp, manifest ứng dụng không cần biết hạ tầng lưu trữ bên dưới là gì.
Sửa giá trị trong ConfigMap đang được Pod dùng làm biến môi trường. Pod có nhận giá trị mới không?
A.Có, biến môi trường được đồng bộ liên tục với ConfigMap
B.Có, nhưng chỉ sau khi chạy kubectl apply lại cho Deployment
C.Không — biến môi trường được đọc một lần lúc container khởi động
D.Không, và mount thành file cũng không cập nhật được
Đáp án: C
Không. Biến môi trường cố định tại thời điểm container khởi động. Muốn áp dụng phải tạo lại Pod: kubectl rollout restart deployment/<tên>. Nếu mount ConfigMap thành file thì nội dung file tự cập nhật (trễ khoảng một phút), nhưng ứng dụng phải tự đọc lại file.
A.create dùng cho file YAML, apply dùng cho tham số dòng lệnh
B.create là mệnh lệnh, tạo mới và báo lỗi nếu tài nguyên đã tồn tại; apply là khai báo, tạo nếu chưa có và cập nhật nếu đã có bằng cách so với cấu hình đã lưu
C.apply chỉ cập nhật được Deployment, các loại tài nguyên khác phải dùng create
D.Hai lệnh giống nhau, apply chỉ là tên mới của create
Đáp án: B
create báo lỗi nếu tài nguyên đã tồn tại. apply tạo mới hoặc cập nhật tùy tình trạng, và chạy lại bao nhiêu lần cũng cho cùng kết quả. Vì vậy apply là lựa chọn cho CI/CD và GitOps — file YAML trong Git là nguồn sự thật.
B.Giới hạn tài nguyên mà Pod được dùng trên một Node
C.Pod chọn Node có nhãn phù hợp để chạy
D.Node từ chối Pod trừ khi Pod chịu được taint
Đáp án: D
Nút đẩy Pod ra: nó từ chối mọi Pod trừ những Pod khai báo chịu được dấu đó. Đây là chiều ngược với cơ chế chọn theo nhãn, vốn là Pod chủ động chọn nút.
B.Ngăn hai Deployment khác nhau chạy trong cùng namespace
C.Trải bản sao ra nhiều Node để chịu được mất Node
D.Giới hạn số Pod tối đa trên mỗi Node
Đáp án: C
Trải các bản sao ra nhiều nút hoặc nhiều vùng, để mất một nút không mất toàn bộ dịch vụ. Không khai thì bộ lập lịch có thể xếp cả ba bản sao lên cùng một nút.
Service type ClusterIP, NodePort và LoadBalancer khác nhau thế nào?
A.Theo giao thức: TCP, UDP và HTTP
B.Theo phạm vi truy cập: trong cụm, qua Node, hay LB ngoài
C.Theo việc service có hỗ trợ TLS hay không
D.Theo thuật toán phân phối tải giữa các Pod
Đáp án: B
Theo phạm vi truy cập. Loại đầu chỉ truy cập được trong cụm. Loại giữa mở một cổng trên mọi nút. Loại cuối yêu cầu nhà cung cấp đám mây tạo một load balancer bên ngoài — và tốn phí cho mỗi service.
B.Gateway API tách vai trò và chuẩn hoá phần vốn dùng annotation
C.Gateway API chỉ dùng cho lưu lượng nội bộ trong cụm
D.Ingress hỗ trợ nhiều giao thức hơn Gateway API
Đáp án: B
Cơ chế mới tách vai trò — quản trị cụm khai cổng vào, còn nhóm ứng dụng khai route — và chuẩn hoá các tính năng mà cơ chế cũ phải diễn đạt bằng chú thích riêng của từng bộ điều khiển.
A.Cho phép mọi lưu lượng cho tới khi có policy áp lên Pod
B.Chỉ cho phép lưu lượng trong cùng namespace
C.Chỉ chặn lưu lượng đi ra internet
D.Chặn mọi lưu lượng cho tới khi khai báo policy cho phép
Đáp án: A
Cho phép mọi thứ — mọi Pod gọi được mọi Pod khác, kể cả ở namespace khác. Nhưng ngay khi có một chính sách chọn tới một Pod, mọi lưu lượng không được cho phép tường minh sẽ bị chặn cho Pod đó.
Khai một loại lưu trữ — ổ SSD, ổ thường, hệ tệp chia sẻ — để hệ thống tự tạo volume khi có yêu cầu. Không có nó, quản trị viên phải tạo sẵn từng volume thủ công trước khi ứng dụng dùng được.
Xoá một StatefulSet thì PersistentVolumeClaim của nó có bị xoá không?
A.Không — PVC được giữ lại, phải xoá riêng
B.Có — mọi tài nguyên con đều bị xoá theo
C.Tuỳ vào chính sách của StorageClass
D.Chỉ bị xoá nếu StatefulSet có ít hơn ba bản sao
Đáp án: A
Không. Các yêu cầu volume được giữ lại để bảo vệ dữ liệu — một mặc định an toàn có chủ đích. Nhưng nó cũng khiến các yêu cầu mồ côi tích tụ và tốn tiền lưu trữ nếu không ai dọn.
Secret trong Kubernetes được mã hoá theo mặc định không?
A.Có — chúng được mã hoá bằng khoá của cụm
B.Có, nhưng chỉ khi cụm chạy trên nhà cung cấp đám mây
C.Không — chỉ base64, cần bật mã hoá tầng lưu trữ
D.Không cần vì chúng chỉ tồn tại trong bộ nhớ
Đáp án: C
Không. Chúng chỉ được mã hoá base64 — vốn là cách biểu diễn để truyền chứ không phải để bảo mật, và ai cũng giải ra được. Cần bật mã hoá ở tầng lưu trữ của cụm, hoặc dùng một bộ quản lý bí mật bên ngoài.
D.Tài khoản để Pod truy cập cơ sở dữ liệu bên ngoài
Đáp án: A
Nó là danh tính của Pod khi gọi tới máy chủ API của cụm, và được gắn quyền qua cơ chế phân quyền theo vai trò. Không khai thì Pod dùng tài khoản mặc định của namespace — vốn thường được cấp quá rộng.
maxSurge và maxUnavailable trong rolling update quyết định gì?
A.Tốc độ tạo Pod mới tính theo số Pod mỗi giây
B.Giới hạn tài nguyên trong lúc triển khai
C.Số Pod được tạo thêm và số Pod được phép thiếu trong lúc cập nhật
D.Số lần thử lại khi Pod mới không khởi động được
Đáp án: C
Tham số đầu là số Pod được tạo thêm vượt số bản sao mong muốn; tham số sau là số Pod được phép thiếu trong lúc cập nhật. Đặt tham số sau bằng không thì dịch vụ không giảm công suất trong lúc triển khai.
Quay lui một Deployment về phiên bản trước làm thế nào?
A.Khôi phục từ bản sao lưu của cụm
B.Xoá Deployment rồi tạo lại với image cũ
C.Lệnh rollout undo — Kubernetes giữ lịch sử ReplicaSet cũ
D.Không quay lui được; phải deploy phiên bản cũ như một bản mới
Đáp án: C
Dùng lệnh quay lui của cơ chế triển khai. Kubernetes giữ lại các bộ bản sao cũ nên nó chỉ việc tăng số bản sao của bộ cũ và giảm bộ mới. Số bản lịch sử giữ lại có giới hạn cấu hình được.
PodDisruptionBudget (PDB) bảo vệ workload khỏi điều gì?
A.Rolling update tạo quá nhiều Pod cùng lúc
B.Thao tác chủ động như drain Node lấy đi quá nhiều Pod
C.Node bị hỏng đột ngột làm mất Pod
D.Pod bị kill vì vượt giới hạn bộ nhớ
Đáp án: B
Các thao tác chủ động — rút cạn nút để bảo trì, tự động thu nhỏ cụm, nâng cấp nút — làm mất quá nhiều Pod cùng lúc. Nó không bảo vệ khỏi các sự cố ngoài ý muốn như nút chết đột ngột.
Startup probe giải quyết vấn đề gì mà liveness probe không giải quyết được?
A.Ứng dụng cần kiểm tra kết nối tới cơ sở dữ liệu
B.Ứng dụng khởi động chậm bị liveness giết quá sớm
C.Ứng dụng cần chạy migration trước khi khởi động
D.Ứng dụng cần khởi tạo dữ liệu trước khi nhận request
Đáp án: B
Các ứng dụng khởi động chậm — máy ảo Java lớn, ứng dụng nạp nhiều dữ liệu — bị bài kiểm tra sống giết trước khi kịp sẵn sàng, tạo một vòng lặp khởi động lại vô tận.
Chạy một chức năng phụ trợ cạnh container chính trong cùng Pod, dùng chung không gian mạng và volume. Nhờ dùng chung mạng, hai container gọi nhau qua địa chỉ nội bộ mà không cần đi qua service.
Đóng gói một bộ khai báo thành một đơn vị tham số hoá được, để cài lại ở nhiều môi trường với các giá trị khác nhau. Không có nó, mỗi môi trường cần một bản sao khai báo và chúng dần lệch nhau.
Cluster Autoscaler khác HorizontalPodAutoscaler thế nào?
A.Một cái thêm bớt Node; cái kia thêm bớt Pod
B.Chúng làm cùng một việc, chỉ khác nhà cung cấp
C.Một cái chạy trong cụm; cái kia chạy bên ngoài
D.Một cái theo CPU; cái kia theo bộ nhớ
Đáp án: A
Một cái thêm bớt nút khi có Pod không xếp được hoặc khi nút bị bỏ trống. Cái kia thêm bớt số bản sao Pod theo chỉ số tải. Chúng phối hợp: tăng Pod mà không đủ nút thì Pod kẹt ở trạng thái Pending.
Pod Security Standards thay thế cơ chế nào và làm gì?
A.Thay ResourceQuota; giới hạn tài nguyên theo namespace
B.Thay RBAC; quản lý quyền của người dùng
C.Thay NetworkPolicy; kiểm soát lưu lượng giữa các Pod
D.Thay PodSecurityPolicy; áp ba mức chính sách theo namespace
Đáp án: D
Thay cơ chế chính sách bảo mật Pod cũ đã bị gỡ. Nó áp ba mức — thoải mái, cơ bản, và siết chặt — theo namespace bằng nhãn, với ba chế độ: chặn, cảnh báo, hoặc ghi kiểm toán.
Control plane của Kubernetes gồm những thành phần chính nào?
A.kubelet, kube-proxy và container runtime
B.Ingress controller và service mesh
C.API server, etcd, scheduler, controller
D.Docker, containerd và CRI-O
Đáp án: C
Máy chủ API là cửa ngõ duy nhất, kho dữ liệu phân tán lưu toàn bộ trạng thái, bộ lập lịch quyết định Pod chạy ở nút nào, và bộ quản lý các bộ điều khiển đưa trạng thái thật về khớp trạng thái mong muốn.
Nâng cấp phiên bản Kubernetes của một cụm production nên theo trình tự nào?
A.Node trước rồi mới tới control plane
B.Control plane trước, rồi từng Node, và không nhảy quá một minor version
C.Nâng cấp đồng thời toàn bộ để tránh lệch phiên bản
D.Nhảy thẳng tới phiên bản mới nhất để tiết kiệm công sức
Đáp án: B
Thành phần điều khiển trước, rồi lần lượt từng nút, và mỗi lần chỉ nhảy một bậc phiên bản phụ. Các thành phần trên nút được phép chạy sau vài phiên bản nhưng không bao giờ được chạy trước.
A.Không tải được image: sai tên/tag hoặc thiếu quyền registry
B.Image quá lớn nên vượt thời gian chờ
C.Image tải về được nhưng container không khởi động
D.Node không đủ dung lượng đĩa để lưu image
Đáp án: A
Không tải được ảnh container. Ba nguyên nhân phổ biến: sai tên hoặc sai thẻ, thiếu thông tin xác thực cho kho ảnh riêng tư, hoặc kho ảnh không truy cập được từ nút. Lệnh mô tả Pod cho biết thông báo lỗi cụ thể.
Debug một Pod đang chạy mà image không có shell thì làm thế nào?
A.Không debug được; phải dựa hoàn toàn vào log
B.SSH vào Node rồi dùng công cụ của container runtime
C.Dùng ephemeral container gắn vào Pod đó
D.Thêm shell vào image rồi deploy lại
Đáp án: C
Dùng container tạm thời: một lệnh gắn thêm một container từ ảnh khác vào cùng không gian tên với Pod đang chạy. Nó mang theo công cụ chẩn đoán mà không cần thêm gì vào ảnh sản xuất.
Thu thập log từ các Pod trong cụm nên làm thế nào?
A.Ghi log vào một volume dùng chung rồi đọc từ đó
B.Ứng dụng ghi ra stdout, một agent trên mỗi Node đọc và chuyển đi
C.Mỗi ứng dụng tự gửi log tới hệ thống tập trung
D.Dùng lệnh xem log khi cần chứ không thu thập
Đáp án: B
Ứng dụng ghi ra đầu ra chuẩn, và một tác nhân chạy trên mỗi nút đọc rồi chuyển tới hệ thu thập tập trung. Log nằm trong Pod mất khi Pod bị tạo lại — và điều đó xảy ra liên tục trong một cụm.
Giám sát một cụm Kubernetes nên theo dõi những chỉ số nào?
A.Chỉ cần số Pod đang chạy trong mỗi namespace
B.Chỉ cần CPU và bộ nhớ của các Node
C.Tài nguyên Node, trạng thái workload và chỉ số ứng dụng
D.Chỉ cần log vì log chứa đủ thông tin
Đáp án: C
Ba tầng: tài nguyên của nút, trạng thái các khối lượng công việc — số bản sao sẵn sàng, số lần khởi động lại, Pod đang chờ — và các chỉ số của chính ứng dụng như tỉ lệ lỗi và độ trễ.
Cách nào làm Pod tự khởi động lại khi ConfigMap thay đổi?
A.Đặt một tuỳ chọn tự nạp lại trong khai báo ConfigMap
B.Gắn hash ConfigMap vào annotation của Pod template
C.Xoá Pod thủ công mỗi lần đổi cấu hình
D.Kubernetes tự khởi động lại Pod khi ConfigMap đổi
Đáp án: B
Tính mã băm của nội dung cấu hình rồi gắn vào chú thích của Pod template. Đổi cấu hình làm mã băm đổi, template đổi, và cơ chế triển khai coi đó là phiên bản mới nên tự triển khai lại.
Operator pattern trong Kubernetes hoạt động thế nào?
A.Một giao diện web để quản trị viên thao tác với cụm
B.Một cách đóng gói ứng dụng thay cho Helm
C.CRD định nghĩa loại tài nguyên mới
D.Một script chạy theo lịch để kiểm tra trạng thái cụm
Đáp án: C
Một định nghĩa tài nguyên tuỳ chỉnh thêm một loại tài nguyên mới vào API, và một bộ điều khiển theo dõi rồi điều hoà trạng thái thật về khớp khai báo. Nó đóng gói kiến thức vận hành của con người thành mã chạy liên tục.
B.Theo label selector, không theo tên Deployment hay Pod
C.Theo namespace mà Pod thuộc về
D.Theo cổng mà container đang lắng nghe
Đáp án: B
Theo bộ chọn nhãn, hoàn toàn không biết gì về khối lượng công việc nào tạo ra Pod. Vì vậy đổi nhãn của một Pod làm nó rời khỏi service ngay lập tức — và đó chính là cơ chế của nhiều kỹ thuật triển khai.
Canary deployment trong Kubernetes làm bằng cách nào đơn giản nhất?
A.Không làm được nếu không cài service mesh
B.Hai Deployment cùng nhãn chung, tỉ lệ theo số Pod
C.Một Deployment với hai image khác nhau
D.Đổi image rồi tạm dừng rollout giữa chừng
Đáp án: B
Hai khối lượng công việc có cùng một nhãn chung mà service chọn tới, nhưng khác nhãn phiên bản. Tỉ lệ lưu lượng đi theo tỉ lệ số Pod — một Pod mới trên chín Pod cũ cho khoảng mười phần trăm.
C.Tồn tại vĩnh viễn trên Node kể cả khi Pod bị xoá
D.Chia sẻ được giữa các Pod trên cùng Node
Đáp án: A
Nó sống cùng vòng đời Pod: chia sẻ được giữa các container trong Pod, tồn tại qua các lần container khởi động lại, nhưng mất hẳn khi Pod bị xoá hoặc chuyển sang nút khác.
Chạy nhiều môi trường (dev, staging, prod) nên tách bằng namespace hay bằng cụm riêng?
A.Cụm riêng cho production
B.Namespace là đủ cho mọi môi trường vì nó cách ly hoàn toàn
C.Luôn dùng cụm riêng cho mọi môi trường
D.Dùng cùng namespace và phân biệt bằng nhãn
Đáp án: A
Cụm riêng cho môi trường thật; namespace là đủ để tách các môi trường ít quan trọng. Namespace cách ly ở tầng logic — phân quyền, hạn ngạch, tên — nhưng các Pod vẫn chia sẻ nút và nhân hệ điều hành.
Chặn hoặc sửa một tài nguyên trước khi nó được ghi vào kho dữ liệu. Nhờ đó áp được các quy tắc của tổ chức: bắt buộc có nhãn chủ sở hữu, cấm ảnh từ nguồn lạ, hoặc tự thêm các thiết lập bảo mật mặc định.
Deployment báo đủ số bản sao nhưng người dùng vẫn gặp lỗi. Kiểm tra gì?
A.Số lần khởi động lại của các Pod
B.Endpoints của Service và readiness probe
C.Dung lượng đĩa còn lại trên các Node
D.Phiên bản Kubernetes của cụm hiện tại
Đáp án: B
Kiểm tra tài nguyên liệt kê các đích của service: Pod đang chạy nhưng chưa qua bài kiểm tra sẵn sàng thì không nằm trong danh sách đó, nên service không có đích nào để gửi lưu lượng tới.
D.Liveness probe thất bại nên container bị khởi động lại
Đáp án: C
Container vượt giới hạn bộ nhớ đã khai và bị nhân hệ điều hành kết thúc. Cách xử lý là đo mức dùng thật rồi chỉnh giới hạn — và kiểm tra xem đây là nhu cầu thật hay là rò rỉ bộ nhớ.
Pod cần gọi tới một API bên ngoài qua IP cố định. Làm thế nào?
A.Đặt biến môi trường khai địa chỉ nguồn mong muốn
B.NAT gateway ở tầng mạng của cụm, không khai trong Pod
C.Gán một địa chỉ IP tĩnh cho Pod trong khai báo
D.Dùng một Service loại LoadBalancer cho lưu lượng đi ra
Đáp án: B
Cấu hình một cổng chuyển đổi địa chỉ ở tầng mạng của cụm để mọi lưu lượng đi ra mang cùng một địa chỉ. Đây là cấu hình hạ tầng, không phải thứ khai trong Pod — địa chỉ Pod thay đổi liên tục.
Chạy database migration trước khi deploy phiên bản mới nên làm thế nào?
A.Một Job riêng chạy trước, tương thích cả hai phiên bản
B.Chạy thủ công bằng lệnh kết nối trực tiếp vào database
C.Chạy trong initContainer của mỗi Pod
D.Chạy trong ứng dụng lúc khởi động
Đáp án: A
Một tác vụ riêng chạy trước khi triển khai, và quan trọng hơn: bản di trú phải tương thích với cả hai phiên bản ứng dụng. Trong lúc triển khai luân phiên, phiên bản cũ và mới cùng chạy trên một lược đồ.
Service khai báo clusterIP: None khác Service thường thế nào?
A.Không cho phép truy cập từ ngoài namespace
B.Bỏ qua kiểm tra sẵn sàng của Pod
C.Chỉ định tuyến tới một Pod duy nhất
D.Trả về địa chỉ của từng Pod
Đáp án: D
Nó không cấp địa chỉ ảo: việc phân giải tên trả về danh sách địa chỉ của từng Pod thay vì một địa chỉ trung gian. Bên gọi tự chọn Pod để kết nối — cần thiết khi mỗi bản sao có vai trò riêng.
Rolling update dừng ở 2/5 Pod mới và không tiến tiếp. Nguyên nhân thường gặp nhất?
A.Deployment thiếu khai báo giới hạn tài nguyên
B.Số bản sao khai báo lớn hơn số Node trong cụm
C.Image mới có kích thước quá lớn
D.Pod mới không qua được readiness probe
Đáp án: D
Pod mới không báo sẵn sàng. Quá trình cập nhật chỉ tiếp tục khi Pod mới vượt qua kiểm tra sẵn sàng, để bảo đảm luôn đủ số bản sao phục vụ được. Probe thất bại thì quá trình dừng lại đúng chỗ đó.
Gắn ConfigMap thành file bằng subPath có nhược điểm gì?
A.Không dùng được với Secret, chỉ với ConfigMap
B.File chỉ đọc được, không ghi được
C.Chỉ gắn được một file cho mỗi Pod
D.File không cập nhật khi ConfigMap đổi
Đáp án: D
File không được cập nhật khi ConfigMap thay đổi — nội dung bị chốt tại thời điểm Pod khởi động. Gắn cả thư mục thì hệ thống tự cập nhật nội dung, nhưng cách đó ghi đè mọi file có sẵn trong thư mục đích.
Pod bị Evicted với lý do DiskPressure. Chuyện gì đã xảy ra?
A.Image của Pod quá lớn để tải về
B.Pod ghi log vượt quá giới hạn cho phép
C.Volume gắn vào Pod đã đầy dung lượng
D.Node hết dung lượng đĩa, đẩy Pod ra
Đáp án: D
Node hết dung lượng đĩa và tự bảo vệ bằng cách đuổi bớt Pod. Kubernetes chọn Pod để đuổi dựa trên mức vượt quá tài nguyên đã yêu cầu và mức ưu tiên, nên Pod không khai báo yêu cầu tài nguyên bị đuổi trước.
Một Node chuyển sang NotReady. Các Pod trên đó được xử lý thế nào?
A.Được chuyển sang Node khác mà không khởi động lại
B.Vẫn giữ nguyên cho tới khi người vận hành can thiệp
C.Bị xoá ngay lập tức và tạo lại trên Node khác
D.Bị xoá sau một khoảng chờ, tạo lại nơi khác
Đáp án: D
Sau một khoảng chờ — mặc định khoảng năm phút — các Pod bị đánh dấu xoá và bộ điều khiển tạo Pod thay thế trên Node khác. Khoảng chờ tồn tại để tránh dời hàng loạt khi Node chỉ mất liên lạc tạm thời.
Sidecar khai báo trong initContainers với restartPolicy: Always khác sidecar thường thế nào?
A.Không dùng chung volume với container chính
B.Được cấp tài nguyên riêng ngoài hạn mức Pod
C.Khởi động trước, không chặn Pod kết thúc
D.Chạy trên Node khác với container chính
Đáp án: C
Nó khởi động xong trước container chính và không chặn Pod kết thúc. Sidecar khai báo như container thường có thể chưa sẵn sàng khi container chính bắt đầu, và với Job thì nó chạy mãi khiến Pod không bao giờ hoàn tất.
Topology spread constraints khác pod anti-affinity ở điểm nào?
A.Kiểm soát được mức lệch giữa các vùng
B.Chỉ áp dụng được ở mức Node, không ở mức vùng
C.Không cần khai báo bộ chọn nhãn cho Pod
D.Được đánh giá sau khi Pod đã được xếp lịch
Đáp án: A
Nó diễn đạt được mức lệch tối đa chấp nhận được giữa các vùng — ví dụ chênh nhau không quá một Pod. Cách kia chỉ nói được là cấm ở chung hoặc ưu tiên tách ra, nên không kiểm soát được độ đều khi số bản sao lớn.
Pod báo ErrImagePull khi kéo image từ registry riêng. Cần cấu hình gì?
A.Tải image về rồi đẩy vào registry nội bộ của cụm
B.Secret chứa thông tin đăng nhập registry
C.Đăng nhập registry trên máy cá nhân trước khi triển khai
D.Mở quyền truy cập mạng từ Node tới registry
Đáp án: B
Tạo một Secret chứa thông tin đăng nhập registry rồi tham chiếu nó trong Pod, hoặc gắn vào ServiceAccount mà Pod dùng. Thành phần kéo image chạy trên Node cần thông tin này, và nó không dùng thông tin đăng nhập ở máy cá nhân.
VerticalPodAutoscaler khác HorizontalPodAutoscaler thế nào?
A.Chạy hoàn toàn ở phía Node thay vì control plane
B.Chỉ hoạt động với workload có trạng thái
C.Điều chỉnh số Node trong cụm thay vì số Pod
D.Điều chỉnh tài nguyên mỗi Pod
Đáp án: D
Nó điều chỉnh lượng tài nguyên yêu cầu của mỗi Pod thay vì số lượng Pod. Phù hợp với ứng dụng không mở rộng ngang được, nhưng để áp giá trị mới thường phải tạo lại Pod, nên gây gián đoạn nếu số bản sao ít.
