46 câu hỏi phỏng vấn Kubernetes hàng đầu và đáp án năm 2026

Câu hỏi phỏng vấn Kubernetes cơ bản

Bắt đầu với các câu hỏi cơ bản về Kubernetes. Những câu hỏi này bao quát kiến thức nền tảng cần có để hiểu và làm việc với Kubernetes. 

1. Pod trong Kubernetes là gì?

Pod là đơn vị triển khai nhỏ nhất trong Kubernetes. Nó đại diện cho một hoặc nhiều container chạy trong cùng một môi trường chia sẻ. Các container trong một Pod dùng chung tài nguyên mạng và lưu trữ.

Đây là một file YAML định nghĩa Pod đơn giản:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: nginx-container
    image: nginx:1.21
    ports:
    - containerPort: 80

2. Mục đích của kubectl là gì?

Kubectl là công cụ CLI chính để quản lý tài nguyên Kubernetes và tương tác với cụm. Dưới đây là một vài lệnh kubectl phổ biến bạn nên biết:

kubectl get pods 				 # list all Pods
kubectl get services 			 # list all Services
kubectl logs <pod-name> 	  	 # view logs of a Pod
kubectl exec -it <pod-name> – /bin/sh # open a shell inside a Pod

3. Deployment trong Kubernetes là gì?

Deployment trong Kubernetes là một lớp trừu tượng cao hơn để quản lý vòng đời của các Pod. Nó đảm bảo số lượng bản sao mong muốn luôn sẵn sàng và cung cấp các tính năng như rolling update, rollback và tự phục hồi. 

Đây là file YAML định nghĩa Deployment đơn giản: 

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.21
        ports:
        - containerPort: 80

4. Kubernetes Service là gì và vì sao cần?

Service trong Kubernetes phơi bày một nhóm Pod và cho phép giao tiếp nội bộ và tới các Pod đó. 

Vì Pod là thực thể tạm thời nên IP của chúng có thể thay đổi, nghĩa là ứng dụng giao tiếp với Pod cũng phải thay đổi địa chỉ IP. Do đó, Service cung cấp một điểm cuối mạng ổn định với IP cố định.

Ví dụ YAML định nghĩa Service đơn giản:

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: my-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  type: ClusterIP

Service trên sẽ chuyển tiếp lưu lượng đến các Pod có nhãn app: my-app.

5. Có những loại Service nào trong Kubernetes?

Kubernetes cung cấp bốn loại Service chính, mỗi loại phục vụ một mục đích mạng khác nhau:

• ClusterIP (mặc định): Cho phép giao tiếp nội bộ giữa các Pod. Chỉ truy cập được từ trong cụm.
• NodePort: Phơi bày Service trên một cổng tĩnh của mỗi Node, giúp truy cập được từ ngoài cụm.
• LoadBalancer: Sử dụng load balancer bên ngoài của nhà cung cấp đám mây. Service sẽ truy cập qua IP công khai.
• ExternalName: Ánh xạ một Service của Kubernetes tới một hostname bên ngoài. 

6. Vai trò của ConfigMap và Secret trong Kubernetes là gì?

ConfigMap lưu dữ liệu cấu hình không nhạy cảm, trong khi Secret lưu dữ liệu nhạy cảm như khóa API và mật khẩu.

Sử dụng Secret giúp bạn tránh đưa thông tin bí mật vào mã ứng dụng. Ngược lại, ConfigMap giúp ứng dụng dễ cấu hình hơn, vì các giá trị này có thể được chỉnh sửa dễ dàng và bạn không cần lưu cố định trong mã ứng dụng.

Ví dụ YAML định nghĩa ConfigMap:

apiVersion: v1
kind: ConfigMap
metadata:
  name: my-config
data:
  database_url: "postgres://db.example.com"

Ví dụ YAML định nghĩa Secret (dữ liệu mã hóa base64 [không phải mã hóa an toàn]):

apiVersion: v1
kind: Secret
metadata:
  name: my-secret
type: Opaque
data:
  password: cGFzc3dvcmQ=  # "password" encoded in Base64

7. Namespace trong Kubernetes là gì?

Namespace là một cụm ảo bên trong một cụm Kubernetes. Nó giúp tổ chức workload trong môi trường đa người dùng bằng cách cô lập tài nguyên trong một cụm.

Dưới đây là đoạn lệnh ngắn cho thấy cách tạo Namespace bằng kubectl và cách tạo, lấy Pod trong Namespace đó:

# create a namespace called “dev”
kubectl create namespace dev

# create a Pod in that namespace
kubectl run nginx --image=nginx --namespace=dev

# get Pods in that namespace
kubectl get pods --namespace=dev

8. Label và Selector trong Kubernetes là gì?

Label là cặp khóa/giá trị gắn vào các đối tượng (ví dụ Pod). Chúng giúp tổ chức đối tượng Kubernetes. Selector lọc tài nguyên dựa trên Label. 

Đây là ví dụ một Pod có các label environment: production và app: nginx:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
  labels:
    environment: production
    app: nginx
spec:
  containers:
  - name: nginx-container
    image: nginx:1.21
    ports:
    - containerPort: 80

Bạn có thể dùng selector sau để lấy tất cả các Pod có gán label environment: pod:

kubectl get pods -l environment=production

9. Persistent Volume (PV) và Persistent Volume Claim (PVC) là gì?

Persistent Volume (PV) cung cấp lưu trữ tồn tại vượt qua vòng đời của Pod. PV là một phần lưu trữ trong cụm do quản trị viên cung cấp hoặc cấp phát động qua StorageClass.

Persistent Volume Claim (PVC) là một yêu cầu lưu trữ từ người dùng. 

Ví dụ YAML định nghĩa PV và PVC: 

apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-pv
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  hostPath:
    path: "/mnt/data"

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

Câu hỏi phỏng vấn Kubernetes trung cấp

Giờ bạn đã luyện tập những kiến thức cơ bản, chúng ta chuyển sang cấp độ trung cấp. Ở mức này, việc hiểu các khái niệm như mạng, bảo mật, quản lý tài nguyên và xử lý sự cố là thiết yếu.

10. Mạng trong Kubernetes là gì và hoạt động ra sao?

Mạng trong Kubernetes cho phép giao tiếp giữa các Pod, Service và client bên ngoài. Nó theo cấu trúc mạng phẳng, nghĩa là theo mặc định, tất cả Pod có thể giao tiếp với nhau.  

Các khái niệm mạng chính trong Kubernetes gồm:

• Giao tiếp pod-to-pod: Mỗi Pod có một IP riêng và có thể giao tiếp trong cụm. 
• Giao tiếp service-to-pod: Service cung cấp một điểm cuối mạng ổn định cho một nhóm Pod, vì Pod là tạm thời. Mỗi lần tạo lại, Pod sẽ có IP mới.
• Ingress controller: Quản lý lưu lượng HTTP/HTTPS từ bên ngoài.
• NetworkPolicy: Định nghĩa các luật hạn chế hoặc cho phép giao tiếp giữa các Pod.

11. Role-Based Access Control (RBAC) trong Kubernetes là gì?

RBAC là cơ chế bảo mật hạn chế người dùng và dịch vụ dựa trên quyền hạn của họ. Nó bao gồm:

• Role và ClusterRole: Xác định các hành động được phép trên tài nguyên.
• RoleBinding và ClusterRoleBinding: Gán role cho người dùng hoặc service account.

YAML sau minh họa một role chỉ cho phép quyền đọc đối với Pod:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "watch", "list"]

Role pod-reader này có thể được gắn cho một người dùng bằng RoleBinding:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: pod-reader-binding
subjects:
  - kind: User
    name: dummy
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

12. Kubernetes autoscaling hoạt động như thế nào?

Kubernetes cung cấp ba loại tự động mở rộng để tối ưu sử dụng tài nguyên:

1. Horizontal Pod Autoscaler (HPA): Điều chỉnh số lượng Pod dựa trên CPU, bộ nhớ hoặc chỉ số tùy chỉnh.
2. Vertical Pod Autoscaler (VPA): Điều chỉnh yêu cầu CPU và bộ nhớ cho từng Pod.
3. Cluster Autoscaler: Điều chỉnh số lượng worker node trong cụm dựa trên nhu cầu tài nguyên.

Bạn có thể tạo HPA bằng kubectl:

kubectl autoscale deployment nginx --cpu-percent=50 --min=1 --max=10

Lệnh trên tạo HPA cho Deployment tên nginx và cố gắng giữ mức sử dụng CPU trung bình trên tất cả Pod ở 50%, với số bản sao tối thiểu là 1 và tối đa là 10.

13. Bạn gỡ lỗi Pod trong Kubernetes như thế nào?

Khi Pod gặp lỗi, Kubernetes cung cấp nhiều cách để gỡ lỗi:

• Dùng kubectl logs để xem log của container và tìm lỗi.
• Dùng kubectl describe pod để xem sự kiện và các thay đổi trạng thái gần đây.
• Dùng kubectl exec để mở shell tương tác và điều tra từ bên trong container.
• Dùng kubectl get pods --field-selector=status.phase=Failed để liệt kê tất cả Pod đang lỗi.

# get logs of a specific Pod
kubectl get logs <pod-name>

# describe the Pod and check events
kubectl describe pod <pod-name>

# open an interactive shell inside the Pod
kubectl exec -it <pod-name> – /bin/sh

# check all failing pods
kubectl get pods --field-selector=status.phase=Failed

Các lệnh này giúp xác định cấu hình sai, giới hạn tài nguyên hoặc lỗi ứng dụng.

14. Bạn thực hiện rolling update và rollback trong Kubernetes như thế nào?

Deployment hỗ trợ rolling update để tránh downtime. Bạn có thể thực hiện rolling update bằng cách chỉnh sửa Deployment hoặc đặt image sang phiên bản mới bằng:

kubectl set image deployment/my-deployment nginx=nginx:1.21

Sau đó kiểm tra trạng thái Deployment:

kubectl rollout status deployment my-deployment

Nếu muốn quay lại phiên bản trước, chạy:

kubectl rollout undo deployment my-deployment

15. Ingress trong Kubernetes là gì và hoạt động thế nào?

Ingress là một đối tượng API quản lý truy cập HTTP/HTTPS từ bên ngoài vào các Service trong cụm Kubernetes.  Nó cho phép định tuyến dựa trên hostname và đường dẫn, hoạt động như một reverse proxy cho nhiều ứng dụng.

Ví dụ YAML định nghĩa Ingress:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
    - host: my-app.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: my-service
                port:
                  number: 80

16. Kubernetes Gateway API là gì và khác gì với Ingress?

Gateway API là sự phát triển hiện đại của mạng Kubernetes với mục tiêu thay thế Ingress tiêu chuẩn. Trong khi Ingress được thiết kế cho định tuyến HTTP đơn giản, nó trở nên hạn chế và phân mảnh khi cụm ngày càng phức tạp.

Gateway API cải thiện điều này bằng cách:

• Thiết kế theo vai trò: Tách biệt định nghĩa Gateway (do kỹ sư hạ tầng quản lý) với Route (do nhà phát triển ứng dụng quản lý).
• Hỗ trợ tốt hơn: Hỗ trợ gốc các tính năng lưu lượng nâng cao như chia lưu lượng (A/B testing), khớp header và mạng đa cụm mà không cần annotation tùy chỉnh phức tạp.

17. Kubernetes xử lý giới hạn và yêu cầu tài nguyên như thế nào?

Kubernetes cho phép đặt yêu cầu (request) và giới hạn (limit) tài nguyên cho Pod để đảm bảo phân bổ công bằng và tránh lạm dụng tài nguyên cụm.

• Request là lượng CPU và bộ nhớ tối thiểu một Pod cần. Chúng được cấp phát cố định cho Pod. 
• Limit là mức tối đa Pod có thể dùng. Không cấp phát cố định, nhưng nếu cần thêm, Pod có thể tăng tới mức limit.

Ví dụ YAML định nghĩa Pod với request và limit tài nguyên:

apiVersion: v1
kind: Pod
metadata:
  name: resource-limited-pod
spec:
  containers:
    - name: my-container
      image: nginx
      resources:
        requests:
          memory: "256Mi"
          cpu: "250m"
        limits:
          memory: "512Mi"
          cpu: "500m"

18. Điều gì xảy ra nếu tài nguyên của Pod cần vượt quá limit đã gán?

Nếu mức sử dụng bộ nhớ của Pod vượt quá limit, Kubernetes sẽ ngay lập tức hạ container với lỗi hết bộ nhớ (OOM). Container sẽ khởi động lại nếu có chính sách restart.

Khác với bộ nhớ, nếu Pod vượt quá limit CPU, nó không bị hạ. Thay vào đó, Kubernetes sẽ bóp băng thông CPU, khiến ứng dụng chạy chậm lại.

19. Init container là gì và khi nào nên dùng?

Init container là container đặc biệt chạy trước khi container chính khởi động. Chúng giúp chuẩn bị môi trường bằng cách kiểm tra phụ thuộc, nạp file cấu hình hoặc thiết lập dữ liệu.

Ví dụ có thể là init container chờ cơ sở dữ liệu sẵn sàng:

apiVersion: v1
kind: Pod
metadata:
  name: app-with-init
spec:
  initContainers:
    - name: wait-for-db
      image: busybox
      command: ['sh', '-c', 'until nc -z db-service 5432; do sleep 2; done']
  containers:
    - name: my-app
      image: my-app-image

20. Kubernetes xử lý gián đoạn Pod và tính sẵn sàng cao như thế nào?

Kubernetes đảm bảo tính sẵn sàng cao thông qua Pod Disruption Budget (PDB), quy tắc anti-affinity và cơ chế tự phục hồi. Cụ thể:

• Pod Disruption Budget (PDB): Đảm bảo số Pod tối thiểu vẫn khả dụng trong các gián đoạn tự nguyện (ví dụ: nâng cấp cụm cần scale down node).
• Pod affinity và anti-affinity: Kiểm soát việc Pod được lập lịch cùng nhau hay tách rời.
• Node selector và Taint/Toleration: Kiểm soát cách phân phối workload trên các Node.

Ví dụ YAML PDB đảm bảo luôn có ít nhất hai Pod chạy trong quá trình gián đoạn:

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: my-app-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: my-app

Câu hỏi phỏng vấn Kubernetes nâng cao

Phần này bao quát các câu hỏi nâng cao, tập trung vào ứng dụng trạng thái (stateful), quản lý đa cụm, bảo mật, tối ưu hiệu năng và xử lý sự cố. Nếu bạn ứng tuyển vị trí cấp cao, hãy chú ý phần này.

21. StatefulSet là gì và khác gì với Deployment?

StatefulSet dùng cho ứng dụng có trạng thái cần danh tính mạng ổn định, lưu trữ bền vững và thứ tự triển khai. Khác với Deployment, StatefulSet đảm bảo:

• Pod có danh tính mạng ổn định và duy nhất, được đặt tên như pod-0, pod-1…
• Pod được tạo, cập nhật, xóa theo thứ tự.
• Mỗi Pod giữ lưu trữ bền vững qua các lần khởi động lại. Lưu trữ bền vững được định nghĩa trong YAML của StatefulSet.

22. Service mesh là gì và vì sao dùng trong Kubernetes?

Service mesh quản lý giao tiếp giữa các dịch vụ, cung cấp:

• Quản lý lưu lượng (cân bằng tải, canary).
• Bảo mật (mTLS giữa các dịch vụ).
• Quan sát (tracing, metric, logging)

Tất cả ở lớp hạ tầng, nên không cần thay đổi mã. 

Các service mesh phổ biến: Istio, Linkerd, Consul.

23. Làm thế nào để bảo mật một cụm Kubernetes?

Hãy theo mô hình bảo mật 4C để bảo vệ cụm Kubernetes:

1. Bảo mật nhà cung cấp đám mây: Dùng IAM và firewall.
2. Bảo mật cụm: Bật RBAC, audit log và bảo mật API server.
3. Bảo mật container: Quét image và dùng user không phải root.
4. Bảo mật mã nguồn: Triển khai quản lý secret và dùng NetworkPolicy.

24. Taint và Toleration trong Kubernetes là gì?

Taint và Toleration kiểm soát nơi Pod được chạy:

• Taint: Đánh dấu node để từ chối Pod.
• Toleration: Cho phép Pod bỏ qua một số Taint nhất định.

Ví dụ taint một node chỉ chấp nhận workload cụ thể:

kubectl taint nodes node1 key1=value1:NoSchedule

Điều này nghĩa là không Pod nào được lập lịch trên node1 trừ khi có Toleration phù hợp.

Một Toleration được thêm vào phần PodSpec như sau:

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    env: test
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
  tolerations:
  - key: "key1"
    operator: "Equal"
    value: “value1”
    effect: "NoSchedule"

Pod này sẽ được phép lập lịch trên node1.

25. Sidecar container trong Kubernetes là gì và dùng như thế nào?

Sidecar container chạy song song với container chính trong cùng một Pod. Thường dùng cho:

• Ghi log và giám sát (ví dụ thu thập log bằng Fluentd).
• Proxy bảo mật (ví dụ chạy Envoy của Istio cho service mesh).
• Quản lý cấu hình (ví dụ đồng bộ cài đặt ứng dụng).

Ví dụ sidecar xử lý log:

apiVersion: v1
kind: Pod
metadata:
  name: app-with-sidecar
spec:
  containers:
    - name: main-app
      image: my-app
      volumeMounts:
        - mountPath: /var/log
          name: shared-logs
    - name: log-collector
      image: fluentd
      volumeMounts:
        - mountPath: /var/log
          name: shared-logs
  volumes:
    - name: shared-logs
      emptyDir: {}

Sidecar chạy Fluentd, thu thập log từ container chính qua volume chia sẻ.

26. Native Sidecars (SidecarContainers) là gì và chúng giải quyết vấn đề nào?

Trước Kubernetes v1.28/1.29, sidecar chỉ là container thường chạy cạnh ứng dụng của bạn. Điều này gây ra "điều kiện tranh chấp": nếu ứng dụng khởi động trước sidecar (ví dụ proxy bảo mật hoặc bộ gửi log), ứng dụng có thể crash hoặc mất dữ liệu vì thành phần hỗ trợ chưa sẵn sàng.

Native Sidecars giải quyết bằng cách cho phép bạn định nghĩa sidecar trong phần initContainers với restartPolicy: Always.

• Cách hoạt động: Kubernetes coi chúng như init container, nghĩa là chúng phải khởi động thành công trước khi ứng dụng chính chạy.
• Lợi ích: Đảm bảo proxy bảo mật hoặc logger hoạt động đầy đủ trước khi ứng dụng xử lý bất kỳ yêu cầu nào.

27. Nêu ba nguyên nhân lỗi Pod thường gặp và cách khắc phục.

Pod có thể bị kẹt ở trạng thái Pending, CrashLoopBackOff hoặc ImagePullBackOff:

• Pod kẹt ở Pending: Kiểm tra khả dụng của node và giới hạn tài nguyên. Xem sự kiện của Pod để biết thêm chi tiết.
• CrashLoopBackOff: Kiểm tra log ứng dụng và cấu hình sai.
• ImagePullBackOff: Đảm bảo tên image đúng và có thông tin kéo image. Cũng hãy xem sự kiện của Pod để biết thêm thông tin.

Bạn có thể xem sự kiện của Pod bằng lệnh describe:

kubectl describe pod <pod-name>

28. Mutating admission webhook trong Kubernetes là gì và hoạt động ra sao?

Mutating admission webhook cho phép chỉnh sửa theo thời gian thực đối tượng Kubernetes trước khi áp dụng vào cụm và lưu trữ. Nó chạy một bộ điều khiển admission động trong Kubernetes, chặn các yêu cầu API trước khi đối tượng được lưu vào etcd. Nó có thể chỉnh sửa payload yêu cầu bằng cách chèn, thay đổi hoặc loại bỏ trường trước khi cho phép yêu cầu tiếp tục.

Các trường hợp dùng phổ biến:

• Chèn sidecar.
• Đặt giá trị mặc định cho Pod, Deployment hoặc tài nguyên khác.
• Áp dụng best practice (ví dụ: tự động gán limit tài nguyên).
• Thêm cấu hình bảo mật (ví dụ: yêu cầu nhãn cho mục đích audit).

29. Bạn triển khai Deployment không downtime trong Kubernetes như thế nào?

Deployment không downtime đảm bảo cập nhật không làm gián đoạn lưu lượng đang chạy. Kubernetes đạt được bằng cách:

• Rolling update (mặc định, thay dần Pod cũ bằng Pod mới).
• Canary (thử nghiệm với một phần người dùng).
• Blue-green (chuyển đổi giữa môi trường sản xuất và thử nghiệm).

Readiness probe giúp Kubernetes tránh gửi lưu lượng tới Pod chưa sẵn sàng.

30. Custom Resource Definition (CRD) trong Kubernetes là gì và khi nào nên dùng?

CRD mở rộng API Kubernetes, cho phép người dùng định nghĩa và quản lý tài nguyên tùy chỉnh. Dùng cho các trường hợp cần tiếp tục quản lý qua API Kubernetes, như:

• Quản lý ứng dụng tùy chỉnh (ví dụ: mô hình machine learning).
• Kích hoạt operator Kubernetes cho ứng dụng tự phục hồi.

Ví dụ YAML định nghĩa CRD:

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: shirts.stable.example.com
spec:
  group: stable.example.com
  scope: Namespaced
  names:
    plural: shirts
    singular: shirt
    kind: Shirt
  versions:
  - name: v1
    served: true
    storage: true
    schema:
      openAPIV3Schema:
        type: object
        properties:
          spec:
            type: object
            properties:
              color:
                type: string
              size:
                type: string
    selectableFields:
    - jsonPath: .spec.color
    - jsonPath: .spec.size
    additionalPrinterColumns:
    - jsonPath: .spec.color
      name: Color
      type: string
    - jsonPath: .spec.size
      name: Size
      type: string

Bạn có thể, ví dụ, lấy đối tượng shirt bằng kubectl:

kubectl get shirts

Khám phá cách tận dụng Docker và Kubernetes cho quy trình machine learning trong bài hướng dẫn container hóa thực hành này.

31. Operator trong Kubernetes là gì và hoạt động ra sao?

Operator mở rộng chức năng Kubernetes bằng cách tự động hóa triển khai, mở rộng và quản lý các ứng dụng phức tạp. Nó được xây dựng bằng CRD và controller tùy chỉnh để xử lý logic đặc thù ứng dụng.

Operator hoạt động bằng cách định nghĩa tài nguyên tùy chỉnh trong Kubernetes và theo dõi thay đổi trong cụm để tự động hóa các tác vụ cụ thể. 

Các thành phần chính của một operator:

• Custom Resource Definition (CRD): Định nghĩa một tài nguyên API mới trong Kubernetes.
• Controller tùy chỉnh: Theo dõi CRD và áp dụng logic tự động dựa trên trạng thái mong muốn.
• Vòng hòa giải (reconciliation loop): Liên tục đảm bảo trạng thái ứng dụng khớp với trạng thái kỳ vọng.

Câu hỏi phỏng vấn Kubernetes dành cho quản trị viên

Quản trị viên Kubernetes duy trì, bảo mật và tối ưu cụm cho workload sản xuất. Phần này tập trung vào các câu hỏi về quản lý cụm.

32. Bạn sao lưu và khôi phục cụm etcd trong Kubernetes như thế nào?

Etcd là kho khóa-giá trị lưu toàn bộ trạng thái cụm. Sao lưu định kỳ là cần thiết để tránh mất dữ liệu.

Bạn có thể tạo bản sao lưu bằng lệnh sau:

ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \
  --cacert=<trusted-ca-file> --cert=<cert-file> --key=<key-file> \
  snapshot save <backup-file-location>

Để khôi phục từ bản sao lưu, bạn có thể chạy:

etcdutl --data-dir <data-dir-location> snapshot restore snapshot.db

33. Làm thế nào để nâng cấp cụm Kubernetes an toàn?

Nâng cấp cụm là quá trình nhiều bước, yêu cầu thời gian chết tối thiểu và giữ ổn định cụm. Quản trị viên nên theo quy trình có cấu trúc để tránh sự cố trong quá trình nâng cấp:

1. Drain và sao lưu etcd trước khi nâng cấp để có thể khôi phục nếu thất bại.
2. Nâng cấp node control plane.
3. Nâng cấp kubelet và kubectl trên các node control plane.
4. Nâng cấp các worker node lần lượt. Trước khi nâng cấp, phải drain mỗi worker node để tránh gián đoạn workload.
5. Nâng cấp add-on của cụm (ví dụ Ingress controller, công cụ giám sát,…).

34. Bạn giám sát cụm Kubernetes như thế nào?

Quản trị viên cần theo dõi CPU, bộ nhớ, đĩa, mạng và sức khỏe ứng dụng. Các công cụ khuyến nghị:

• Prometheus + Grafana: Thu thập và trực quan hóa metric cụm. Tạo cảnh báo thời gian thực để được thông báo khi có sự cố.
• Loki + Fluentd: Thu thập và phân tích log.
• Kubernetes dashboard: Giám sát cụm qua giao diện UI.
• Jaeger/OpenTelemetry: Tracing phân tán.

35. Bạn bảo mật một cụm Kubernetes như thế nào?

Bảo mật là yếu tố then chốt, và mọi quản trị viên nên tuân theo thực hành tốt nhất để bảo vệ cụm:

• Bật RBAC: Hạn chế truy cập người dùng bằng Role và RoleBinding.
• Pod security admission: Dùng admission controller để áp chuẩn bảo mật Pod.
• Áp dụng NetworkPolicy: Hạn chế giao tiếp giữa Pod, vì mặc định tất cả Pod có thể liên lạc với nhau.
• Xoay vòng token API và chứng chỉ thường xuyên.
• Sử dụng quản lý secret: Dùng công cụ như Vault, AWS Secrets Manager, v.v. 

Tìm hiểu cách Kubernetes được triển khai trên đám mây qua hướng dẫn về điều phối container bằng AWS Elastic Kubernetes Service (EKS).

36. Bạn thiết lập logging cho Kubernetes như thế nào?

Logging tập trung là cần thiết cho gỡ lỗi và kiểm toán. Hai lựa chọn stack logging:

• Loki + Fluentd + Grafana (nhẹ và nhanh).
• ELK Stack (Elastic, Logstash, Kibana) (mở rộng tốt và cấp doanh nghiệp).

37. Bạn triển khai tính sẵn sàng cao trong Kubernetes như thế nào?

Tính sẵn sàng cao rất quan trọng để tránh downtime cho ứng dụng chạy trong cụm. Bạn có thể đảm bảo bằng cách:

• Dùng nhiều node control plane. Nhiều API server giúp tránh downtime nếu một cái hỏng.
• Bật cluster autoscaler. Tự động thêm/bớt node theo nhu cầu.

38. Bạn triển khai đa người dùng (multi-tenancy) cho cụm Kubernetes như thế nào?

Multi-tenancy rất quan trọng khi bạn triển khai Kubernetes cho công ty. Nó cho phép nhiều đội/ứng dụng dùng chung một cụm một cách an toàn mà không can thiệp lẫn nhau.

Có hai kiểu multi-tenancy:

1. Soft multi-tenancy: Dùng Namespace, RBAC và NetworkPolicy để cô lập ở cấp namespace.
2. Hard multi-tenancy: Dùng cụm ảo hoặc control plane riêng để cô lập cụm vật lý (ví dụ: KCP).

39. Bạn mã hóa Secret trong etcd như thế nào?

Etcd lưu trạng thái hoàn chỉnh của cụm, nghĩa là thông tin quan trọng nằm ở đó. 

Mặc định, Kubernetes lưu Secret chưa mã hóa trong etcd, dễ bị lộ. Do đó, rất quan trọng bật mã hóa Secret ở trạng thái lưu trữ (at REST) để Secret được lưu trữ và mã hóa. 

Bước đầu, tạo file cấu hình mã hóa và lưu khóa mã hóa/giải mã trong file đó:

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
    providers:
      - aescbc:
          keys:
            - name: key1
              secret: <BASE64_ENCODED_SECRET>
      - identity: {}

Cấu hình trên chỉ ra Kubernetes sẽ dùng nhà cung cấp aescbc để mã hóa tài nguyên Secret, với dự phòng identity cho dữ liệu chưa mã hóa.

Tiếp theo, chỉnh file cấu hình kube-apiserver, thường ở /etc/kubernetes/manifests/kube-apiserver.yaml trên node control plane, và thêm cờ -- encryption-provider-config trỏ tới file cấu hình mã hóa bạn đã tạo:

command:
  - kube-apiserver
  ...
  - --encryption-provider-config=/path/to/encryption-config.yaml

Lưu thay đổi và khởi động lại kube-apiserver để áp dụng cấu hình mới.

40. Bạn quản lý quota tài nguyên trong môi trường đa người dùng như thế nào?

Resource quota ngăn một tenant (namespace) tiêu thụ quá mức tài nguyên cụm, gây ảnh hưởng đến tenant khác.

Bạn có thể định nghĩa ResourceQuota cho namespace để cấp một lượng tài nguyên xác định cho namespace đó. Người dùng namespace đó có thể tạo tài nguyên tiêu thụ nhiều nhất bằng mức được định nghĩa trong ResourceQuota.

Ví dụ YAML ResourceQuota:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: namespace-quota
  namespace: team-a
spec:
  hard:
    requests.cpu: "4"
    requests.memory: "8Gi"
    limits.cpu: "8"
    limits.memory: "16Gi"
    pods: "20"

Bạn có thể xem ResourceQuota của một namespace bằng:

kubectl describe resourcequota namespace-quota -n team-a

41. CoreDNS là gì? Cấu hình và sử dụng thế nào?

CoreDNS là nhà cung cấp DNS mặc định cho các cụm Kubernetes. Nó cung cấp khám phá dịch vụ và cho phép Pod giao tiếp bằng tên DNS nội bộ thay vì IP.

Tính năng của CoreDNS:

• Xử lý phân giải DNS nội bộ (my-service.default.svc.cluster.local).
• Hỗ trợ cấu hình DNS tùy chỉnh.
• Cân bằng tải truy vấn DNS qua nhiều Pod.
• Cho phép cache để cải thiện hiệu năng.

Bạn có thể cấu hình CoreDNS bằng ConfigMap trong namespace kube-system. Xem cấu hình hiện tại bằng:

kubectl get configmap coredns -n kube-system -o yaml

Chỉ cần cập nhật ConfigMap đó và áp dụng thay đổi để điều chỉnh cấu hình CoreDNS.

Câu hỏi phỏng vấn Kubernetes theo kịch bản và giải quyết vấn đề

Kỹ sư thường xuyên đối mặt với các thách thức thực tế về khả năng mở rộng, mạng, bảo mật, hiệu năng và xử lý sự cố trong môi trường Kubernetes, và người phỏng vấn hiểu điều đó. Phần này đưa ra các câu hỏi theo kịch bản để kiểm tra khả năng giải quyết vấn đề thực tiễn của bạn.

42. Gỡ lỗi một ứng dụng Kubernetes chạy chậm

“Nhóm của bạn báo cáo một ứng dụng chạy trên Kubernetes trở nên chậm, người dùng gặp thời gian phản hồi cao. Bạn sẽ giải quyết thế nào?”

Bạn có thể tiếp cận theo các bước sau:

1. Kiểm tra mức sử dụng tài nguyên của Pod. Tăng tài nguyên nếu đang chạm ngưỡng.

kubectl top pods --sort-by=cpu
kubectl top pods --sort-by=memory

2. Mô tả Pod chạy chậm để lấy thêm thông tin. Tìm dấu hiệu throttling tài nguyên, số lần restart hoặc lỗi liveness probe.

kubectl describe pod <pod-name>

3. Kiểm tra log container để tìm lỗi. Tìm timeout, lỗi hoặc lỗi kết nối.

kubectl logs <pod-name>

4. Kiểm tra độ trễ mạng vì có thể làm chậm ứng dụng.

kubectl exec -it <pod-name> -- ping my-database
kubectl exec -it <pod-name> -- curl http://my-service

5. Xác minh sức khỏe node và kiểm tra cạn kiệt tài nguyên trên node.

kubectl get nodes
kubectl describe node <node-name>

43. Nginx chạy nhưng URL phơi bày không kết nối được

“Bạn đã triển khai Nginx trong Kubernetes, Pod chạy bình thường nhưng ứng dụng không truy cập được qua URL phơi bày. Bạn làm gì?”

Các bước tiếp cận:

1. Xác minh Pod Nginx đang chạy và khỏe mạnh.

kubectl get pods -o wide
kubectl describe pod nginx-web

2. Kiểm tra Service và ánh xạ cổng. Đảm bảo cổng phơi bày đúng và khớp với containerPort của Pod. Kiểm tra Service tìm đúng Pod.

kubectl describe service nginx-service

3. Kiểm tra NetworkPolicy. Nếu policy chặn ingress, Service sẽ không truy cập được.

kubectl get networkpolicies
kubectl describe networkpolicy <policy-name>

4. Xác minh Ingress và cấu hình DNS bên ngoài.

kubectl describe ingress nginx-ingress

44. Deployment thất bại sau khi nâng cấp

“Bạn triển khai phiên bản mới của ứng dụng, nhưng nó không khởi động được, gây downtime cho người dùng. Bạn khắc phục thế nào?”

Cách tiếp cận:

1. Rollback về phiên bản hoạt động trước đó.

kubectl rollout undo deployment my-app

2. Kiểm tra lịch sử Deployment và xác định thay đổi ở phiên bản mới.

kubectl rollout history deployment my-app

3. Xem log của Pod mới để tìm lỗi.

kubectl logs -l app=my-app

4. Kiểm tra readiness và liveness probe.

5. Xác minh vấn đề kéo image. Đôi khi image mới sai hoặc không khả dụng.

45. Ứng dụng không thể kết nối tới cơ sở dữ liệu bên ngoài

“Một microservice chạy trong Kubernetes không thể kết nối tới cơ sở dữ liệu bên ngoài, được lưu trữ ngoài cụm. Bạn khắc phục ra sao?”

Các bước tiếp cận:

1. Xác minh kết nối bên ngoài từ trong một Pod. Kiểm tra DB có thể truy cập từ mạng Kubernetes không.

kubectl exec -it <pod-name> -- curl http://my-database.example.com:5432

2. Kiểm tra phân giải DNS trong Pod. Nếu lỗi, có thể CoreDNS cấu hình sai.

kubectl exec -it <pod-name> -- nslookup my-database.example.com

3. Kiểm tra có NetworkPolicy nào chặn truy cập ra ngoài không, vì có thể ngăn lưu lượng outbound.

kubectl get networkpolicies
kubectl describe networkpolicy <policy-name>

46. Tài nguyên cụm cạn kiệt khiến Pod mới ở trạng thái pending

“Pod mới ở trạng thái Pending. Kiểm tra sâu thấy thông báo “0/3 nodes are available: insufficient CPU and memory”. Bạn gỡ lỗi và giải quyết thế nào?”

Các bước tiếp cận:

1. Kiểm tra tài nguyên khả dụng của cụm. Tìm mức dùng CPU/bộ nhớ cao ngăn việc lập lịch.

kubectl describe node <node-name>
kubectl top nodes

2. Kiểm tra Pod nào tiêu thụ nhiều tài nguyên nhất. Đặt request/limit cho Pod để tránh lạm dụng. Bạn cũng có thể áp đặt cho tất cả namespace trong cụm.

kubectl top pods --all-namespaces

3. Giảm scale các workload không thiết yếu để giải phóng tài nguyên.

kubectl scale deployment <deployment-name> --replicas=0

4. Tăng số node để tăng tài nguyên cụm. Bạn cũng có thể thêm node cho cluster autoscaler nếu đang dùng.

Mẹo chuẩn bị cho phỏng vấn Kubernetes

Từ kinh nghiệm của tôi, thành công không chỉ đến từ việc ghi nhớ khái niệm. Bạn cần áp dụng kiến thức vào tình huống thực, xử lý sự cố hiệu quả và giải thích rõ ràng giải pháp của mình.

Nếu muốn thành công trong các buổi phỏng vấn Kubernetes, hãy làm theo các mẹo sau:

1. Nắm vững các khái niệm lõi của Kubernetes. Đảm bảo bạn hiểu Pod, Deployment, Service, Persistent Volume, ConfigMap, Secret, v.v.
2. Trải nghiệm thực hành với Kubernetes. Khi chuẩn bị, tôi thấy tự dựng cụm Minikube và triển khai microservices giúp củng cố hiểu biết. Bạn cũng có thể dùng dịch vụ Kubernetes quản lý của nhà cung cấp đám mây để luyện ở quy mô lớn.
3. Học cách gỡ lỗi vấn đề Kubernetes, vì xử lý sự cố chiếm phần lớn công việc với Kubernetes ngoài thực tế. Bạn có lẽ sẽ dành phần lớn thời gian để gỡ lỗi ứng dụng.
• Các vấn đề điển hình gồm Pod bị kẹt, lỗi mạng, volume bền vững không mount đúng và lỗi node.
4. Hiểu mạng và cân bằng tải trong Kubernetes. Tập trung cách triển khai mạng, cách Pod giao tiếp, các loại Service và cách phơi bày ứng dụng.
5. Biết cách mở rộng và tối ưu workload Kubernetes. Người phỏng vấn thường hỏi về chiến lược mở rộng và tối ưu chi phí. Thành thạo HPA, cluster autoscaler, request và limit tài nguyên. 
6. Nắm thực hành tốt nhất về bảo mật Kubernetes. Quen thuộc RBAC, security context của Pod, NetworkPolicy và quản lý Secret.
7. Tìm hiểu kiến trúc và nội bộ Kubernetes. Biết các thành phần control plane và cách kubelet cùng container runtime tương tác.

Kết hợp kiến thức lý thuyết với thực hành và học từ việc gỡ lỗi thực tế, bạn sẽ làm chủ mọi buổi phỏng vấn Kubernetes!

Kết luận

Kubernetes là hệ thống điều phối container mạnh mẽ nhưng phức tạp. Phỏng vấn cho các vai trò Kubernetes đòi hỏi hiểu sâu lý thuyết và giải quyết vấn đề thực tiễn. Dù bạn là kỹ sư junior tìm công việc đầu tiên hay kỹ sư senior hướng tới vị trí cao hơn, sự chuẩn bị luôn là chìa khóa.

Tôi không thể nhấn mạnh đủ tầm quan trọng của việc thực hành. Nó giúp bạn tìm vấn đề trong ứng dụng nhanh hơn và tự tin hơn.

Nếu bạn muốn củng cố nền tảng, tôi rất khuyến nghị khám phá các khóa học như Khái niệm Containerization và Virtualization để xây nền tảng vững chắc, sau đó là Nhập môn Kubernetes để có trải nghiệm thực hành. Khi sẵn sàng, bạn có thể xem chứng chỉ Kubernetes để chứng minh kỹ năng. 

Chúc bạn thành công trong các buổi phỏng vấn!