Oblivion Sentinel: Giải pháp tự động hóa Self-Healing và cảnh báo lỗi cho Kubernetes

Keyword: ⚔️ Oblivion Sentinel: Self-Healing Automation and Error Alert Solution for Kubernetes

Sau một khoảng thời gian dài AI chiếm lĩnh thị trường công nghệ và hỗ trợ khá nhiều, mình cũng ít viết blog dần vì mình biết mọi người giờ sẽ ưa chuộng tìm kiếm và tiếp thu kiến thức thông qua AI nhanh hơn là ngồi đọc một bài blog dài dòng. Đến cả chính bản thân mình cũng đang dùng và học hỏi từ AI mỗi ngày mà, haha!

Vậy nên, thay vì viết các bài hướng dẫn cài đặt chi tiết như trước đây, hôm nay mình xin phép đổi gió, giới thiệu sơ qua về một công cụ do chính tay mình tạo ra. Nó đã hỗ trợ cực kỳ tốt cho mình trong công việc hiện tại, và mình tin rằng nó cũng sẽ gãi đúng chỗ ngứa của nhiều bạn.

 

Chuyện là, quản lý các Pod bị kẹt lỗi (CrashLoopBackOff, ImagePullBackOff) hay các Helm Release hỏng hóc luôn là một "cực hình" ngốn thời gian. Hơn nữa, việc nhận hàng trăm email cảnh báo rác từ các hệ thống giám sát đôi khi khiến team DevOps bị "lờn" cảnh báo.

Nhưng thật ra động lực chính sâu xa hơn bắt nguồn từ thực tế phũ phàng trong các project mình đang quản lý: Có những app đã không còn sử dụng nữa, chết lăn lóc đâu gần 3 - 4 tháng trời mà chẳng ai hỏi thăm hay ngó ngàng tới. Nói tới đây chắc nhiều bạn sẽ vặn lại: "Thế là ông không thèm monitoring rồi!". Không hề nha! Mình có monitor đầy đủ, nhưng ngặt nỗi đó là các app không quan trọng nằm ở môi trường Dev. Mỗi lần app "tèo", mình lại réo gọi các bạn Developer vào fix, nhưng thường chỉ nhận lại "những sự im lặng thầm kín". Đến lúc mình gắt gao hỏi cho ra nhẽ thì mới nhận được câu chốt xanh rờn: "À, app đó team bỏ lâu rồi anh".

Chưa dừng lại ở đó, những lúc app thực sự lỗi, các bạn Dev lại cứ réo mình xin log, trong khi mình đã cấp sẵn account Graylog để mọi người tự search từ đời nào rồi!

Từ sự "bất lực" muốn dọn sạch rác dự án và lười đi copy log hộ của một thằng DevOps đơn độc quản lý khá nhiều app của vài project, Oblivion Sentinel đã ra đời! Đây là một Kubernetes self-healing và cleanup controller được đóng gói dưới dạng Helm chart. Nó sẽ tự động quét, dọn dẹp các ứng dụng kẹt trạng thái lỗi quá lâu, đồng thời tự động "bắt log gửi tận tay" người cần một cách vô cùng thông minh.

* Oblivion Sentinel So Với Các Công Cụ Trên Thị Trường 

Nếu bạn đang thắc mắc "Công cụ này giống và khác gì so với những thứ tôi đang dùng?", thì đây là câu trả lời:

1. Nó giống với các ứng dụng nào?

• Giống Kube-janitor: Ở khả năng tự động dọn dẹp (cleanup) các tài nguyên dư thừa hoặc hết hạn (TTL) trên cụm Kubernetes. 
• Giống Robusta.dev: Ở khả năng kết hợp giữa Cảnh báo lỗi (Alerting) và Tự động khắc phục (Remediation).
• Giống BotKube / Alertmanager: Ở tính năng gửi thông báo lỗi Pod về Teams, Slack hoặc Email.

2. Sự khác biệt cốt lõi (Tại sao nên chọn Oblivion Sentinel?)

Dù có điểm tương đồng, Oblivion Sentinel giải quyết được những "nỗi đau" cực kỳ cụ thể (như câu chuyện mình kể ở trên):

• 🪶 Siêu nhẹ & Không cần Agent (Agentless): Thay vì phải chạy các DaemonSet ngốn RAM 24/7 trên mọi Node hay yêu cầu cài đặt cụm Prometheus nặng nề, Oblivion Sentinel chỉ là một CronJob Bash script nhỏ gọn. Tới giờ quét -> chạy -> tự động thoát sạch sẽ (Đây là vấn đề mình mong muốn ở nó).
• 🎯 Dọn dẹp tận gốc (Phase 2): Đa số các tool tự động (như Descheduler hay Kube-janitor) chỉ biết xóa Pod. Nhưng nếu cấu hình bị sai, Pod sinh ra lại tiếp tục lỗi. Oblivion Sentinel có Phase 2 "Hard Remediation": Đánh giá tỷ lệ lỗi của toàn bộ Helm Release và tự động "helm uninstall" nếu nó hỏng quá lâu (như cái app bỏ xó 4 tháng của team mình), trả lại tài nguyên sạch cho cluster.
• 🛑 Hệ thống Cảnh báo "Biết điều" (Smart Anti-Spam): Prometheus Alertmanager rất dễ dội bom email nếu Pod liên tục restart. Oblivion Sentinel (qua module Nexus) sử dụng bộ đếm maxSend. Nếu bạn set maxSend: 3, nó sẽ gửi đúng 3 email đính kèm 50 dòng log (cách nhau một khoảng trễ), sau đó ngừng làm phiền hoàn toàn cho đến khi Pod được team fix và tạo mới. Dev có log để debug, DevOps không bị spam mail!

* Cơ Chế Hoạt Động Cốt Lõi

Công cụ hoạt động dựa trên các mốc kích hoạt rõ ràng để đảm bảo không xóa nhầm workload đang ổn định:

• Giai đoạn 1 (Phase 1 - Soft remediation): Nhằm loại bỏ các lỗi pod tạm thời bằng cách xóa các pod có thời gian bad-since lớn hơn hoặc bằng POD_TTL_DAYS.
• Giai đoạn 2 (Phase 2 - Hard remediation): Reset các release bị hỏng vĩnh viễn bằng cách chạy lệnh helm uninstall khi bad-since lớn hơn hoặc bằng HELM_TTL_DAYS và tỷ lệ lỗi đạt ngưỡng ERROR_RATIO_THRESHOLD.
• Cảnh báo lỗi (Nexus): Tự động báo cho team về các pod bị lỗi sau thời gian ân hạn khởi động "startupGraceMinutes: 10" (startup grace period) tức là nó sẻ chờ app khởi động trong vòng 10 phút nếu sau giai đoạn này mà app chưa chịu Ready thì chứng tỏ nó lỗi và nó sẻ gửi kèm log thực tế thay vì bắt Dev phải tự chui vào server tìm kiếm. 

* Hướng Dẫn Cài Đặt Nhanh (Quickstart)

Mặc định, công cụ được bật chế độ an toàn (DRY_RUN=true) để bạn có thể xem trước các hành động (in ra terminal) mà không tác động thực tế đến hệ thống. 

Bạn có thể cài đặt thông qua YellowBox Helm Repository:

# 1️⃣ Thêm repo YellowBox vào Helm của bạn
helm repo add yellowbox https://yellowbox.itblognote.com/charts/
helm repo update

# 2️⃣ Cài đặt (mặc định DRY_RUN=true để đảm bảo an toàn)
helm install oblivion-sentinel yellowbox/oblivion-sentinel \
  --version 2026.7.30 \
  -n devops-manager --create-namespace

# 3️⃣ Chạy thử thủ công một lần (không cần đợi CronJob)
kubectl -n devops-manager create job \
  --from=cronjob/oblivion-sentinel \
  oblivion-sentinel-once

# 4️⃣ Xem log để kiểm tra các hành động giả lập
kubectl -n devops-manager logs -f job/oblivion-sentinel-once

# 5️⃣ Tắt dry-run khi đã xác nhận cấu hình chuẩn xác
helm upgrade oblivion-sentinel yellowbox/oblivion-sentinel \
  --version 2026.7.30 \
  -n devops-manager --reuse-values --set config.DRY_RUN=false

Các bạn quản lý bằng cấu trúc GitOps giống mình thì tinh chỉnh cấu hình thông qua file (values.yaml) cho tiện.

Để hệ thống hoạt động đúng ý đồ, bạn có thể điều chỉnh file cấu hình:

1. Lên Lịch Tự Động (Schedule)

• Reaper (Dọn dẹp rác): Thiết lập chạy mặc định vào lúc 8h và 22h hàng ngày (schedule: "0 8,22 * * *").
• Nexus (Gửi log cảnh báo): Chạy 30 phút một lần (schedule: "*/30 * * * *"). Nếu phát hiện lỗi, đợi 120 phút giữa các lần gửi liên tiếp (retryDelayMinutes: 120), khi test với dryRun đang là true thì mình sẽ hạ time xuống để dễ dàng test ví dụ 1 phút chẳng hạn, xong sau đó mình sẻ trả về /15 hoặc /30 tuỳ vào nhu cầu của các bạn.

2. Định tuyến Cảnh Báo Cho Từng Dev Team

Để chỉ định team nào nhận email (kèm log) khi app nào đó hỏng, chỉ cần thêm annotation này vào Pod/Deployment:

metadata:
  annotations:
    # Gửi song song đa kênh cực kỳ dễ dàng (Email, Azure Email, Teams)
    oblivion/error-notify: "[email protected],[email protected],teams=https://webhook-url"

Phía Chart của mình phần values.yaml mình đã có cấu hình phần sau để khi add cho dễ

podAnnotations: #{}
  oblivion/error-notify: "[email protected]"

Thành ra cũng tuỳ vào việc Chart bạn chỗ file values.yaml có nơi add không? nếu không có thì buộc phải chỉnh sữa lại Chart của bạn để có thể gắn vào annotations trong metadata.

3. Phân Quyền An Toàn (RBAC)

Để tuân thủ bảo mật, công cụ hỗ trợ tắt quyền clusterAdmin và thay thế bằng các phân quyền cấp độ thấp hơn (Scoped RBAC). Công cụ chỉ cần quyền read/patch trên pods, logs, deployments, statefulsets... đủ để thực thi nhiệm vụ dọn dẹp và lấy log.

Nếu bạn thấy Oblivion Sentinel hữu ích cho cụm Kubernetes của bạn thì bạn có thể thử trải nghiệm, hoặc góp ý cũng như update thêm để mình nâng cấp nó lên nhé, để tránh lãng phí tài nguyên cho những app "đã chết trong tim Developer" và chấm dứt chuỗi ngày đi copy/paste log hộ team hehe!

Nguồn: www.itblognote.com