Kubernetes cho developer: Deployment, Service, readiness và autoscaling

Đừng bắt đầu Kubernetes bằng YAML#

Kubernetes dễ làm người học choáng vì có nhiều object và cấu hình. Cách học tốt hơn là hiểu vấn đề vận hành mà từng object giải quyết. Với developer, bốn khái niệm thực dụng nhất là Deployment, Pod, Service và probe. Sau đó mới học ConfigMap, Secret, Ingress, autoscaling và rollout strategy.

Pod là đơn vị chạy container. Deployment quản lý số lượng Pod mong muốn và rollout phiên bản mới. Service cung cấp endpoint ổn định để các Pod khác gọi tới, vì Pod có thể bị thay đổi IP khi recreate.

Deployment quản lý rollout#

Khi bạn cập nhật image trong Deployment, Kubernetes tạo ReplicaSet mới và đưa Pod mới vào dần theo chiến lược rollout. Với rolling update, hệ thống có thể thay Pod từng phần thay vì dừng toàn bộ app. Điều kiện quan trọng là app phải có health check đúng để Kubernetes biết Pod nào sẵn sàng nhận traffic.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  replicas: 3
  selector:
    matchLabels:
      app: api
  template:
    metadata:
      labels:
        app: api
    spec:
      containers:
        - name: api
          image: registry.example.com/api:1.4.2
          ports:
            - containerPort: 3000
          readinessProbe:
            httpGet:
              path: /health/ready
              port: 3000
          livenessProbe:
            httpGet:
              path: /health/live
              port: 3000

Readiness và liveness không giống nhau. Readiness trả lời "Pod đã sẵn sàng nhận request chưa". Liveness trả lời "Pod có cần restart không". Nếu liveness check phụ thuộc database và database chậm tạm thời, bạn có thể vô tình restart hàng loạt Pod đang khỏe. Hãy thiết kế probe theo đúng mục đích.

Service ổn định hóa network#

Pod IP không phải contract ổn định. Service chọn các Pod theo label và cung cấp DNS name ổn định trong cluster. App khác có thể gọi http://api.default.svc.cluster.local hoặc tên ngắn trong cùng namespace. Nếu cần public traffic, bạn thường dùng Ingress hoặc load balancer phía trước Service.

Resource request và limit ảnh hưởng scheduling#

Kubernetes scheduler cần biết Pod cần bao nhiêu CPU/memory để đặt lên node phù hợp. Request là lượng tài nguyên Pod được đảm bảo tương đối; limit là mức tối đa được phép dùng. Không đặt request/limit có thể làm cluster khó dự đoán. Đặt limit quá thấp có thể gây OOM hoặc throttling.

Với ứng dụng web, hãy bắt đầu bằng đo thực tế dưới tải bình thường và tải cao. Sau đó đặt request gần mức cần ổn định, còn limit có khoảng thở hợp lý. Đừng copy con số từ blog khác vào production.

Autoscaling cần metric đúng#

Horizontal Pod Autoscaler có thể tăng giảm số Pod dựa trên CPU, memory hoặc custom metric. CPU autoscaling phù hợp worker CPU-bound, nhưng không phải lúc nào cũng phản ánh request backlog hoặc latency. Với queue worker, queue depth hoặc processing lag thường có ý nghĩa hơn.

Autoscaling không thay thế tối ưu ứng dụng. Nếu query database chậm, tăng Pod có thể làm database quá tải hơn. Trước khi scale out, hãy xem bottleneck nằm ở app, database, cache hay network.

Checklist Kubernetes cho developer#

• Image có tag rõ, không dùng latest ở production.
• Readiness probe nhẹ và phản ánh khả năng nhận request.
• Liveness probe không restart app vì dependency tạm thời chậm.
• Service chọn Pod bằng label nhất quán.
• Request/limit dựa trên đo đạc, không đoán mò.
• ConfigMap và Secret tách khỏi image.
• Rollout có thể pause, resume và rollback khi cần.
• Log ra stdout/stderr và có correlation id cho request.

Nguồn tham khảo chính#

• Kubernetes Docs: Deployments
• Kubernetes Docs: Services
• Kubernetes Docs: Liveness, readiness, startup probes