Tối Ưu Autoscaling với Karpenter Trên EKS: Xử Lý DaemonSet Và Vấn Đề Node Bị Xoá

🎯 Giới Thiệu

Khi triển khai hệ thống Kubernetes trên Amazon EKS, một trong những vấn đề được nhiều DevOps quan tâm là quản lý node tự động theo nhu cầu thực tế của workload – một bài toán quan trọng về chi phí và hiệu suất. Kể từ khi AWS ra mắt Karpenter, autoscaler mới thay thế Cluster Autoscaler truyền thống, nhiều người đã chuyển sang sử dụng nhờ khả năng:

• Tạo node cực nhanh (vài giây).

• Xoá node linh hoạt dựa trên workload.

• Hỗ trợ cấu hình đa dạng (labels, taints, instance type, capacity type…).

Tuy nhiên, một trong những bẫy phổ biến mà DevOps hay gặp phải là DaemonSet như Node Exporter vẫn chạy, nhưng Karpenter vẫn xoá node. Bài viết này sẽ phân tích chi tiết lý do vì sao, kèm theo cách xử lý phù hợp.

🧱 Kiến Trúc Phổ Biến

Giả sử bạn có hệ thống EKS với các workload chính như sau:

• 🧠 Microservices chính: Chạy dạng Deployment, tự động scale.

• 📈 Monitoring agents:

  • node-exporter (Prometheus): DaemonSet

  • fluent-bit (Log collector): DaemonSet

  • kube-proxy, coredns: System Pod

Bạn dùng Karpenter để tự động tạo và xoá EC2 node tuỳ theo workload.

🤖 Cách Karpenter Đánh Giá Một Node "Đã Trống"

Karpenter có logic tự động xác định node có cần giữ lại hay không, theo hai yếu tố chính:

1. Node có chứa Pod user workload không?

2. Node có đáp ứng điều kiện để xoá?

Trong đó, Karpenter coi DaemonSet là “pod hệ thống”, không phải workload chính. Cụ thể:

Do đó, nếu một node chỉ còn DaemonSet, Karpenter coi như node đã trống.

⏱ Cấu Hình ttlSecondsAfterEmpty

Mỗi Provisioner (hoặc NodePool nếu dùng bản mới) đều có thể cấu hình:

ttlSecondsAfterEmpty: 60

Ý nghĩa: Sau khi node không còn workload user trong 60 giây, Karpenter sẽ xoá node đó – bỏ qua các Pod dạng DaemonSet.

💥 Tình Huống Thực Tế Gây Hiểu Lầm

❓ "Sao node vẫn còn node-exporter mà Karpenter lại xoá?"

Giải thích:

• Node đã hoàn thành nhiệm vụ chạy một batch workload.

• Workload chính (ví dụ Pod tính toán hoặc backend API) đã kết thúc hoặc bị scale về 0.

• Node giờ chỉ còn node-exporter đang chạy.

• Sau TTL 60 giây → Karpenter xoá node để tiết kiệm chi phí.

➡️ Monitoring ngắt quãng, bạn thấy node-exporter mất kết nối tạm thời.

🛡 Cách Giữ Node Không Bị Xoá Nếu Cần Monitoring Liên Tục

🔹 1. Gắn Pod giữ chân node

Tạo 1 Pod dạng Deployment hoặc StatefulSet cực nhẹ để giữ node tồn tại:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: keep-node-alive
spec:
  replicas: 1
  selector:
    matchLabels:
      app: keep-alive
  template:
    metadata:
      labels:
        app: keep-alive
    spec:
      nodeSelector:
        nodepool: monitoring
      containers:
      - name: sleep
        image: busybox
        command: ["/bin/sh", "-c", "sleep 360000"]

🔹 2. Tăng ttlSecondsAfterEmpty để tránh bị xoá quá nhanh

apiVersion: karpenter.sh/v1alpha5
kind: Provisioner
metadata:
  name: monitoring-pool
spec:
  ttlSecondsAfterEmpty: 600  # 10 phút

🔹 3. Dùng Annotation Tùy Biến Cho Mỗi Node

Karpenter hỗ trợ annotation để override TTL:

metadata:
  annotations:
    karpenter.sh/do-not-evict: "true"

⚠️ Tuy nhiên, không nên dùng lâu dài vì node không bị dọn dẹp, gây tốn chi phí.

✅ Tổng Kết

🔚 Kết Luận

Việc dùng Karpenter để tối ưu node lifecycle trong EKS là cực kỳ hiệu quả về chi phí, nhưng bạn cần hiểu rõ cách Karpenter đánh giá khi nào node được xem là "trống". Các Pod DaemonSet không giữ được node tồn tại – đây là điểm quan trọng khiến nhiều hệ thống monitoring hoạt động không ổn định.

Nếu bạn đang thiết kế hạ tầng EKS production, hãy đảm bảo bạn:

• Tùy chỉnh TTL phù hợp.

• Xem xét thiết kế monitoring không phụ thuộc quá nhiều vào sự tồn tại của node cụ thể.

• Sử dụng node label, taint, toleration hợp lý cho DaemonSet để tránh chúng chạy trên node tạm thời (ví dụ node batch).