Chuyển đến nội dung chính
Kai liên tục giám sát cụm Amazon EKS của bạn, phát hiện pod được cấp phát thừa, node chưa được tận dụng, và thiếu chính sách autoscaling trước khi chúng gây ra sự cố nghiêm trọng.

Tình huống

Một nhóm platform đang vận hành cụm EKS production trải dài nhiều namespace. Cảnh báo CPU xuất hiện ngắt quãng nhưng điều tra chậm chạp — kỹ sư phải chạy thủ công các lệnh kubectl qua hàng trăm pod để tương quan log, metrics, và event.
Thách thức khi xử lý sự cố Kubernetes thủ công qua các namespace và tài nguyên

Thách thức khi xử lý sự cố Kubernetes thủ công

Nhóm yêu cầu Kai đánh giá toàn diện cụm, xác định lãng phí tài nguyên, và khuyến nghị chính sách autoscaling cho những nơi còn thiếu.

Hướng dẫn từng bước

1
Kết nối Kai với cụm của bạn
2
Làm theo hướng dẫn kết nối Kubernetes để cấp cho Kai quyền truy cập cụm EKS của bạn. Khi kết nối hiển thị trạng thái Connected, Kai có thể truy vấn cụm trực tiếp.
3
Phân tích mức sử dụng tài nguyên pod
4
@kai #report analyze pod resource utilization in production namespace
5
Phân tích mức sử dụng tài nguyên pod thể hiện mẫu sử dụng CPU và bộ nhớ
6
Phân tích mức sử dụng tài nguyên pod
7
Trực quan hóa phân tích pod kèm khuyến nghị hiệu năng
8
Trực quan hóa phân tích pod kèm khuyến nghị hiệu năng
9
Kai phát hiện ba vấn đề: auth-service và notification-worker được cấp phát thừa (CPU 18–21%), api-gateway và cache-redis có kích thước phù hợp, và payment-processor đang thiếu tài nguyên nguy hiểm ở mức CPU 80–86% và bộ nhớ 88–94% — có nguy cơ cao bị OOM kill và gián đoạn dịch vụ.
10
Xác định node chưa được tận dụng
11
@kai #chart identify nodes with <30% CPU utilization
12
Phân tích mức sử dụng CPU node cho thấy instance chưa được tận dụng và lãng phí chi phí
13
Phân tích mức sử dụng CPU node cho thấy instance chưa được tận dụng
14
Kai tìm thấy năm node có mức CPU trung bình dưới 30% (một số chỉ 12–15%), lãng phí khoảng $573 mỗi tháng. Các instance t3.xlarge quá lớn chạy workload nhẹ — kết hợp với lịch trình pod kém — khiến một số node chỉ có 2–3 pod trong khi các node khác mang 8–9 pod.
15
Nhận khuyến nghị HPA
16
@kai #recommend HPA policies for web deployments
17
Khuyến nghị chính sách HPA cho cấu hình auto-scaling web deployment
18
Khuyến nghị chính sách HPA cho auto-scaling
19
Kai đánh dấu payment-processor là có rủi ro nghiêm trọng — chỉ có 2 replica ở mức CPU 80–86%, không có autoscaling. Kai khuyến nghị thêm HPA cho api-gateway để xử lý spike lưu lượng, và loại bỏ capacity dư thừa khỏi user-service và auth-service.

Điều gì tạo nên hiệu quả

  • Kai truy vấn trực tiếp cluster API, thay thế các phiên kubectl thủ công và chuyển đổi công cụ.
  • Tương quan đa lớp liên kết mức sử dụng pod, dung lượng node, và mẫu lịch trình trong một lượt phân tích duy nhất.
  • #report#chart tạo đầu ra có cấu trúc để Kai suy luận trước khi trình bày phát hiện.
  • #recommend tạo ra các thay đổi chính sách HPA có thể thực thi thay vì chỉ dump metrics thô.
  • CloudKeepers có thể chạy phân tích này theo lịch để phát hiện vấn đề trước khi kỹ sư trực bị gọi.

Tự mình thử

Tài liệu tham khảo agent Kai

Toàn bộ khả năng của Kai, agent Kỹ sư Kubernetes
https://mintcdn.com/cloudthinker/aLd-ttc-SCW-aFky/images/icons/kubernetes.svg?fit=max&auto=format&n=aLd-ttc-SCW-aFky&q=85&s=7c03292954ff635a1994623a5c39971b

Kết nối Kubernetes

Hướng dẫn từng bước kết nối CloudThinker với cụm EKS của bạn

Topology Explorer

Vẽ sơ đồ phụ thuộc dịch vụ Kubernetes để phân tích nguyên nhân gốc rễ nhanh hơn

CloudKeepers

Chạy kiểm tra sức khỏe liên tục trên workload Kubernetes của bạn một cách tự động