Chẩn đoán sự cố Kubernetes bằng k8sgpt: từ Pod lỗi đến giả thuyết kiểm chứng
k8sgpt quét cluster, gom tín hiệu sự cố và dùng AI diễn giải bằng ngôn ngữ đơn giản. Playbook này giúp DevOps/SRE biến kết quả quét thành giả thuyết có bằng chứng, thay vì xử lý theo cảm tính.
Một cảnh báo Pod lỗi xuất hiện ngay sau khi pipeline deploy. Người trực ca có event, log và trạng thái workload, nhưng câu hỏi quan trọng vẫn là: lỗi nằm ở image, cấu hình, quyền truy cập hay tài nguyên cluster?
Trong tình huống này, đội SRE không cần thêm một chatbot đoán mò. Điều cần là một lớp triage giúp gom các tín hiệu Kubernetes liên quan, diễn giải chúng thành hướng điều tra, rồi đưa người vận hành quay lại kiểm chứng bằng dữ liệu gốc.
k8sgpt là công cụ quét, chẩn đoán và triage vấn đề Kubernetes bằng ngôn ngữ đơn giản. Với DevOps, SRE và platform engineer, giá trị của nó là rút ngắn thời gian từ “có alert” đến “biết cần kiểm tra gì tiếp theo” — không phải thay thế quy trình incident response hoặc tự động sửa production.
k8sgpt đứng ở đâu trong quy trình incident?
k8sgpt đóng gói kinh nghiệm SRE vào các analyzer: các bộ kiểm tra tập trung vào những dạng vấn đề Kubernetes. Công cụ lấy thông tin liên quan từ cluster, sau đó dùng backend AI để làm giàu phần diễn giải.
Theo README, OpenAI hiện là provider mặc định. k8sgpt cũng hỗ trợ Azure, Cohere, Amazon Bedrock, Google Gemini và các mô hình chạy local. Với platform team, lựa chọn backend cần được cân nhắc theo chính sách dữ liệu, chi phí và vị trí xử lý dữ liệu vận hành.
Một luồng xử lý phù hợp có thể là:
Alert hoặc người trực phát hiện bất thường.
k8sgpt quét cluster qua các filter đang hoạt động.
Công cụ trả về các vấn đề phát hiện được và có thể giải thích chi tiết hơn bằng AI.
Engineer đối chiếu nhận định với event, manifest, quan sát hệ thống và thay đổi gần nhất.
Chỉ sau khi có bằng chứng, đội mới thực hiện remediation theo quy trình review hiện có.
> Hãy xem kết quả AI như một phiếu điều tra ban đầu: nó giúp ưu tiên hướng kiểm tra, không phải bằng chứng kết luận nguyên nhân gốc.
Cài CLI và chạy lần quét đầu tiên
Trên máy dùng Homebrew, cài CLI bằng:
sh
brew install k8sgpt
Hoặc dùng tap riêng:
sh
brew tap k8sgpt-ai/k8sgpt
brew install k8sgpt
README cũng cung cấp hướng dẫn cài đặt gói RPM, DEB và APK. Trên Windows, hãy tải binary phù hợp với kiến trúc máy từ trang Release, giải nén và thêm thư mục chứa binary vào biến môi trường PATH.
Sau khi CLI có thể truy cập đúng cluster cần điều tra, quy trình khởi tạo trong README gồm các bước sau.
1. Tạo API key cho provider mặc định
sh
k8sgpt generate
Lệnh này mở liên kết trên trình duyệt để tạo key.
2. Thêm thông tin xác thực
sh
k8sgpt auth add
README nêu rằng có thể truyền mật khẩu trực tiếp bằng cờ --password. Tuy nhiên, tránh đặt secret trong command history hoặc trên máy dùng chung.
3. Xem các filter đang hoạt động
sh
k8sgpt filters
Theo README, mặc định tất cả filter sẽ được chạy khi phân tích. Đây là điểm cần lưu ý nếu bạn muốn khoanh vùng triage cho một incident cụ thể.
4. Chạy quét
sh
k8sgpt analyze
5. Yêu cầu diễn giải chi tiết hơn
sh
k8sgpt analyze --explain
6. Kèm tài liệu Kubernetes
sh
k8sgpt analyze --with-doc
Có thể dùng --with-doc cùng hoặc không cùng --explain.
Trong ca trực, kết quả này có thể là bản tóm tắt có cấu trúc để quyết định nên mở event, kiểm manifest hay chuyển incident đến đúng owner — thay vì phải bắt đầu từ một danh sách giả định không có thứ tự.
Biến kết quả quét thành giả thuyết có thể kiểm chứng
Giả sử một workload gặp vấn đề sau khi deploy, bạn chạy:
sh
k8sgpt analyze --explain --with-doc
Kết quả cụ thể phụ thuộc vào trạng thái cluster, filter đang bật và backend AI. README không công bố một mẫu output cố định. Vì vậy, thay vì xem nội dung trả về là câu trả lời cuối cùng, hãy chuyển nó thành khung điều tra rõ ràng:
Tín hiệu: k8sgpt báo vấn đề ở workload hoặc Pod.
Giả thuyết: thay đổi gần nhất khiến workload không đạt trạng thái mong muốn.
Bằng chứng cần tìm: event liên quan, cấu hình workload đang chạy, thay đổi từ pipeline hoặc IaC, và tài liệu Kubernetes được trả về qua --with-doc.
Điều kiện bác bỏ: nếu dữ liệu gốc không ủng hộ giả thuyết, quay lại kết quả quét và chọn hướng điều tra khác.
Đừng đi thẳng từ câu trả lời AI sang “sửa YAML này”. Trong ghi chú incident, người trực nên nêu rõ tín hiệu nào trong cluster xác nhận từng nhận định. Cách làm này hữu ích cho handover, postmortem và các sự cố cần phối hợp giữa đội ứng dụng với đội nền tảng.
Mẫu prompt để chuẩn hóa ghi chú incident
Khi cần dùng một AI khác để chuẩn hóa ghi chú, chỉ đưa dữ liệu đã được rà soát và loại bỏ secret:
text
Bạn là SRE hỗ trợ triage Kubernetes.
Bối cảnh incident:
Cluster/môi trường: <environment>
Thời điểm và thay đổi gần nhất: <changecontext>
Kết quả k8sgpt đã được lọc: <k8sgptoutput>
Event và trạng thái đã được rà soát: <sanitizedevidence>
Tài liệu Kubernetes liên quan: <officialdocscontext>
Hãy trả lời theo cấu trúc:
Tín hiệu quan sát được, không suy diễn.
Tối đa <sốlượng> giả thuyết nguyên nhân, xếp theo mức cần kiểm tra.
Với từng giả thuyết: bằng chứng đang ủng hộ, bằng chứng còn thiếu và điều kiện bác bỏ.
Các bước kiểm chứng chỉ-đọc hoặc dry-run nếu phù hợp.
Rủi ro nếu áp dụng remediation khi chưa xác minh.
Không bịa lệnh, không yêu cầu secret và không đề xuất áp dụng thay đổi trực tiếp vào production.
Kiểm chứng trước khi chạm vào cluster
AI có thể tạo ra một diễn giải nghe hợp lý nhưng không đúng. Rủi ro này tăng lên khi incident có nhiều thay đổi diễn ra gần nhau: deploy ứng dụng, cập nhật policy và biến động hạ tầng có thể trùng thời điểm.
Vì vậy, với mọi đề xuất remediation được AI diễn giải, hãy giữ các cổng kiểm soát kỹ thuật:
Đối chiếu dữ liệu gốc: event, trạng thái đối tượng Kubernetes và tài liệu liên quan.
So với thay đổi gần nhất: commit ứng dụng, pipeline, Helm chart hoặc thay đổi Terraform/IaC.
Review bởi người có ngữ cảnh: service owner và platform/SRE cùng xác nhận trước thay đổi có tác động.
Dùng plan, dry-run, linter và scanner trước khi áp dụng manifest hoặc IaC do AI đề xuất.
Giới hạn blast radius: ưu tiên môi trường không phải production hoặc rollout có kiểm soát khi remediation đã được duyệt.
Không coi YAML “trông đúng” là YAML đã an toàn.
Khi cần theo dõi liên tục
k8sgpt có dự án k8sgpt-operator để cài đặt trong Kubernetes cluster. Theo README, chế độ này phù hợp cho continuous monitoring và có thể tích hợp với Prometheus cùng Alertmanager.
Trước khi đưa operator vào cluster, đội platform vẫn nên review quyền truy cập, phạm vi dữ liệu và cách alert mới đi vào quy trình on-call hiện tại.
Dữ liệu vận hành không phải prompt miễn phí
Output chẩn đoán có thể chứa tên service, namespace, endpoint nội bộ, cấu hình hoặc dấu vết nhạy cảm.
Không đưa API key, token, kubeconfig, mật khẩu hay Kubernetes Secret vào prompt hoặc dữ liệu gửi tới công cụ AI.
Trước khi chọn backend cloud, hãy xác định:
Dữ liệu nào được phép rời khỏi môi trường của bạn.
Ai được phép sử dụng API key.
Log chẩn đoán được lưu ở đâu.
Quy trình rà soát dữ liệu nhạy cảm trước khi phân tích là gì.
k8sgpt hỗ trợ local models, đây có thể là lựa chọn cần đánh giá khi yêu cầu kiểm soát dữ liệu nghiêm ngặt. Tuy nhiên, README không nêu chi tiết kiến trúc triển khai hoặc chính sách dữ liệu cho từng backend.
Checklist đưa k8sgpt vào ca trực
[ ] Xác nhận CLI đang trỏ đến đúng môi trường trước khi quét.
[ ] Kiểm tra filter đang hoạt động bằng k8sgpt filters.
[ ] Chạy k8sgpt analyze để lấy tín hiệu ban đầu.
[ ] Dùng --explain và --with-doc khi cần diễn giải và tài liệu tham khảo.
[ ] Đối chiếu mọi nhận định với dữ liệu gốc và thay đổi gần nhất.
[ ] Không để AI tự quyết remediation; luôn review và kiểm tra trước khi áp dụng.
[ ] Loại bỏ secret khỏi mọi dữ liệu có thể được gửi tới backend AI.
k8sgpt hữu ích nhất khi nó giúp đội vận hành đặt câu hỏi đúng nhanh hơn. Kết hợp với observability, review thay đổi và kỷ luật kiểm chứng, nó có thể biến một màn hình đầy alert thành một đường điều tra rõ ràng — thay vì một câu trả lời AI được tin quá sớm.