Phong van Kubernetes: Giai thich chi tiet Pods, Services va Deployments

Các câu hỏi phỏng vấn Kubernetes luôn tập trung vào ba đối tượng nền tảng: Pods, Services và Deployments. Việc hiểu rõ cách chúng tương tác với nhau — từ việc lập lịch container đến định tuyến mạng và cập nhật liên tục — giúp phân biệt những ứng viên chỉ ghi nhớ định nghĩa với những người có thể thiết kế các hệ thống production. Bài viết này sẽ hướng dẫn chi tiết về từng primitive với YAML chuẩn production, giải thích các khía cạnh nội bộ mà người phỏng vấn quan tâm, và đề cập đến những câu hỏi thường gặp trong các buổi phỏng vấn DevOps và platform engineering.

Hiểu về Kubernetes Pods: Đơn vị nhỏ nhất có thể triển khai

Pod là đơn vị nguyên tử của việc lập lịch trong Kubernetes. Nó bao bọc một hoặc nhiều container chia sẻ cùng một network namespace, IPC namespace và storage volumes. Mọi container bên trong một Pod đều nhận cùng một địa chỉ IP và có thể giao tiếp với các container anh em thông qua localhost.

Pod đơn container là pattern phổ biến nhất. Pod đa container tồn tại cho các kịch bản sidecar — log collectors, service meshes, hoặc init containers chuẩn bị filesystem trước khi tiến trình chính khởi động.

# api-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: api-server
  labels:
    app: api
    version: v2
spec:
  containers:
    - name: api
      image: registry.example.com/api:3.1.0
      ports:
        - containerPort: 8080
      resources:
        requests:
          cpu: "250m"        # 0.25 CPU core reserved
          memory: "256Mi"    # 256 MB reserved
        limits:
          cpu: "500m"        # hard cap at 0.5 core
          memory: "512Mi"    # OOMKilled beyond this
      readinessProbe:
        httpGet:
          path: /healthz
          port: 8080
        initialDelaySeconds: 5
        periodSeconds: 10
      livenessProbe:
        httpGet:
          path: /healthz
          port: 8080
        initialDelaySeconds: 15
        periodSeconds: 20

Phần resources rất quan trọng trong các buổi phỏng vấn. requests xác định việc lập lịch — scheduler đặt Pod trên một node có đủ capacity khả dụng. limits áp dụng các ngưỡng trần runtime — vượt quá memory limit sẽ kích hoạt OOMKill, trong khi vượt quá CPU limit gây ra throttling.

Các giai đoạn vòng đời của Pod và chính sách khởi động lại

Kubernetes theo dõi mọi Pod qua năm giai đoạn: Pending, Running, Succeeded, Failed và Unknown. Người phỏng vấn thường hỏi điều gì kích hoạt từng chuyển đổi.

| Giai đoạn | Ý nghĩa | Nguyên nhân phổ biến | |-------|---------|-------------| | Pending | Đã lập lịch nhưng chưa chạy | Kéo image, tài nguyên không đủ | | Running | Ít nhất một container đang hoạt động | Hoạt động bình thường | | Succeeded | Tất cả container thoát với mã 0 | Batch jobs, init containers | | Failed | Ít nhất một container thoát với mã khác 0 | Ứng dụng crash, OOMKill | | Unknown | Mất kết nối với node | Phân vùng mạng, node lỗi |

Trường restartPolicy kiểm soát điều gì xảy ra sau khi container thoát. Always (mặc định cho Deployments) khởi động lại bất kể mã thoát. OnFailure chỉ khởi động lại khi thoát với mã khác 0 — hữu ích cho Jobs. Never để container ở trạng thái dừng — sử dụng cho debug Pods một lần.

# batch-job-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: data-migration
spec:
  restartPolicy: OnFailure   # restart only on crash
  containers:
    - name: migrate
      image: registry.example.com/migrate:1.0.0
      command: ["python", "migrate.py"]
      env:
        - name: DATABASE_URL
          valueFrom:
            secretKeyRef:
              name: db-credentials
              key: connection-string

Pattern valueFrom.secretKeyRef giữ dữ liệu nhạy cảm ra khỏi manifest. Kubernetes Secrets được mã hóa base64 theo mặc định — không được encrypt. Đối với production, hãy bật encryption at rest thông qua EncryptionConfiguration API hoặc sử dụng external secret manager như HashiCorp Vault.

Kubernetes Deployments: Triển khai và mở rộng theo cách khai báo

Deployment tạo và quản lý các ReplicaSets, đến lượt nó quản lý các Pods. Deployment controller theo dõi trạng thái mong muốn và điều chỉnh nó với thực tế — thêm Pods khi mở rộng, thay thế chúng trong quá trình triển khai, và rollback khi health checks thất bại.

Việc tạo Pod trực tiếp hầu như không bao giờ phù hợp trong production. Deployments cung cấp quản lý replica, rolling updates, lịch sử rollback, và khả năng pause/resume.

# api-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-server
  labels:
    app: api
spec:
  replicas: 3                    # run 3 identical Pods
  revisionHistoryLimit: 5        # keep 5 old ReplicaSets for rollback
  selector:
    matchLabels:
      app: api                   # must match Pod template labels
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1          # at most 1 Pod down during update
      maxSurge: 1                # at most 1 extra Pod during update
  template:
    metadata:
      labels:
        app: api
        version: v2
    spec:
      containers:
        - name: api
          image: registry.example.com/api:3.1.0
          ports:
            - containerPort: 8080
          resources:
            requests:
              cpu: "250m"
              memory: "256Mi"
            limits:
              cpu: "500m"
              memory: "512Mi"
          readinessProbe:
            httpGet:
              path: /healthz
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 10

Phần strategy.rollingUpdate định nghĩa hành vi triển khai zero-downtime. Với maxUnavailable: 1 và maxSurge: 1, Kubernetes tạo một Pod mới, đợi nó vượt qua readiness checks, sau đó chấm dứt một Pod cũ. Chu kỳ này lặp lại cho đến khi tất cả replicas chạy phiên bản mới.

Rollback một Kubernetes Deployment thất bại

Rollbacks là chủ đề phỏng vấn tần suất cao. Deployment controller giữ các ReplicaSets cũ (được kiểm soát bởi revisionHistoryLimit) nên rollback là tức thì — không cần rebuild image.

# Check rollout status
kubectl rollout status deployment/api-server

# View revision history
kubectl rollout history deployment/api-server

# Roll back to previous version
kubectl rollout undo deployment/api-server

# Roll back to specific revision
kubectl rollout undo deployment/api-server --to-revision=3

Lệnh undo vá Deployment spec để khớp với Pod template của revision đích. Chiến lược rolling update sau đó áp dụng như bình thường, dần dần thay thế các Pod hiện tại bằng phiên bản rollback.

Kubernetes Services: Mạng ổn định cho các Pod động

Pods là tạm thời. Chúng nhận địa chỉ IP mới mỗi khi khởi động lại. Service giải quyết vấn đề này bằng cách cung cấp một virtual IP ổn định (ClusterIP) và tên DNS định tuyến traffic đến các Pod khỏe mạnh khớp với label selector.

Thành phần kube-proxy trên mỗi node lập trình các quy tắc iptables hoặc IPVS để phân phối traffic qua các backend Pods. Khi một Pod thất bại readiness probe, Endpoints controller loại bỏ nó khỏi Service — không có traffic đến các instance không khỏe mạnh.

# api-service.yaml
apiVersion: v1
kind: Service
metadata:
  name: api-service
spec:
  type: ClusterIP               # internal-only by default
  selector:
    app: api                     # routes to Pods with this label
  ports:
    - name: http
      port: 80                   # Service port (what clients use)
      targetPort: 8080           # Pod port (where container listens)
      protocol: TCP

Sau khi tạo, bất kỳ Pod nào trong cluster có thể truy cập Service này tại api-service.default.svc.cluster.local (hoặc chỉ api-service trong cùng namespace). CoreDNS xử lý việc phân giải.

Các loại Service: ClusterIP, NodePort và LoadBalancer

Người phỏng vấn mong đợi ứng viên giải thích ba loại Service chính và khi nào áp dụng từng loại.

| Loại | Phạm vi truy cập | Trường hợp sử dụng | |------|-------------|----------| | ClusterIP | Chỉ nội bộ cluster | Backend APIs, databases, caches | | NodePort | Bên ngoài thông qua <NodeIP>:<Port> | Phát triển, bare-metal clusters | | LoadBalancer | Bên ngoài thông qua cloud LB | Traffic production trên AWS/GCP/Azure |

# api-loadbalancer.yaml
apiVersion: v1
kind: Service
metadata:
  name: api-public
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-type: "nlb"  # AWS NLB
spec:
  type: LoadBalancer
  selector:
    app: api
  ports:
    - name: https
      port: 443
      targetPort: 8080
      protocol: TCP

Loại LoadBalancer kích hoạt load balancer controller của cloud provider để cung cấp một điểm truy cập bên ngoài. Trên AWS, điều này tạo ra NLB hoặc ALB tùy thuộc vào annotations. Trên các bare-metal clusters không có tích hợp cloud, MetalLB hoặc kube-vip đảm nhận vai trò này.

Kết nối Deployments với Services thông qua Label Selectors

Liên kết giữa Deployment và Service là label selector — không có gì khác. Không có tham chiếu rõ ràng giữa hai đối tượng. Service theo dõi các Pod có nhãn khớp với spec.selector của nó và tự động duy trì danh sách Endpoints.

Kiến trúc tách rời này có nghĩa là một Service duy nhất có thể định tuyến đến Pods từ nhiều Deployments (hữu ích cho canary releases), và một Deployment có thể được expose bởi nhiều Services (các port khác nhau, các mức truy cập khác nhau).

# canary-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-server-canary
spec:
  replicas: 1
  selector:
    matchLabels:
      app: api                   # same label as main Deployment
  template:
    metadata:
      labels:
        app: api                 # Service picks this up automatically
        version: v3-canary
    spec:
      containers:
        - name: api
          image: registry.example.com/api:3.2.0-rc1
          ports:
            - containerPort: 8080

Với Deployment chính chạy 3 replicas và canary chạy 1, Service phân phối khoảng 25% traffic đến canary. Không cần thay đổi cấu hình Service — label matching xử lý mọi thứ.

Horizontal Pod Autoscaling cho Kubernetes Deployments

Số lượng replica tĩnh lãng phí tài nguyên trong thời gian traffic thấp và quá tải dưới các đợt tăng đột biến. HorizontalPodAutoscaler (HPA) điều chỉnh số lượng replica dựa trên các metrics quan sát được.

# api-hpa.yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-server
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70   # scale up above 70% CPU
    - type: Resource
      resource:
        name: memory
        target:
          type: Utilization
          averageUtilization: 80
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300  # wait 5 min before scaling down

HPA poll metrics server mỗi 15 giây theo mặc định. behavior.scaleDown.stabilizationWindowSeconds ngăn chặn flapping — các chu kỳ scale-up/scale-down nhanh gây ra bởi các pattern traffic bùng nổ.

Các câu hỏi phỏng vấn Kubernetes phổ biến và câu trả lời

Những câu hỏi này xuất hiện lặp đi lặp lại trong các cuộc phỏng vấn DevOps và platform engineering. Mỗi câu trả lời nhắm đến độ sâu mà người phỏng vấn mong đợi.

Điều gì xảy ra khi một Pod vượt quá memory limit của nó? Kubelet gửi SIGKILL thông qua OOM killer. Container thoát với mã 137. Deployment controller phát hiện Pod thất bại và tạo một replacement, tuân theo restart policy và bất kỳ backoff delays nào.

Kubernetes định tuyến traffic đến một phiên bản Pod cụ thể như thế nào trong canary releases? Service selector khớp trên các shared labels (ví dụ: app: api). Cả Deployments ổn định và canary đều sử dụng label này. Phân phối traffic tỷ lệ thuận với số lượng ready endpoints — 3 replicas ổn định + 1 replica canary có nghĩa là khoảng 25% traffic canary. Để chia traffic chính xác (ví dụ: 5%), hãy sử dụng Gateway API HTTPRoute với weighted backends.

Sự khác biệt giữa readinessProbe và livenessProbe là gì? Readiness probe kiểm soát liệu Pod có nhận traffic từ Service hay không. Readiness probe thất bại loại bỏ Pod khỏi danh sách Endpoints nhưng không khởi động lại nó. Liveness probe kiểm soát liệu container có được khởi động lại hay không. Liveness probe thất bại kích hoạt container restart. Cả hai đều có thể sử dụng HTTP, TCP hoặc exec checks.

Rolling updates đảm bảo zero downtime như thế nào? Deployment controller tạo Pods mới trước khi chấm dứt Pods cũ, được điều chỉnh bởi maxSurge và maxUnavailable. Pods mới phải vượt qua readiness probes trước khi Pods cũ được drained. terminationGracePeriodSeconds (mặc định: 30s) cho các requests đang xử lý thời gian hoàn thành trước SIGKILL.

Chuẩn bị cho cuộc phỏng vấn Kubernetes đòi hỏi thực hành YAML thực tế, không chỉ lý thuyết. Các câu hỏi phỏng vấn DevOps trên SharpSkill bao gồm những chủ đề này với các bài tập tương tác.

Kết luận

• Pods là đơn vị lập lịch — luôn đặt resource requests và limits, và cấu hình cả readiness và liveness probes
• Deployments quản lý số lượng replica, rolling updates và lịch sử rollback thông qua ReplicaSets — không bao giờ tạo bare Pods trong production
• Services cung cấp mạng ổn định thông qua label selectors và virtual IPs — ClusterIP cho traffic nội bộ, LoadBalancer cho external
• Liên kết giữa Deployments và Services hoàn toàn dựa trên label, cho phép các pattern canary mà không cần thay đổi cấu hình
• HPA scale Deployments dựa trên CPU/memory metrics — sử dụng stabilizationWindowSeconds để ngăn chặn flapping
• Gateway API thay thế Ingress NGINX kể từ Kubernetes v1.35 — các dự án mới nên áp dụng nó ngay từ đầu
• Thực hành với các YAML manifests thực tế và lệnh kubectl thay vì ghi nhớ định nghĩa