Sharan Kumar Reddy

Kubernetes tells you a pod is failing only once it already has. By the time OOMKill or CrashLoopBackOff fires, the incident is live and the on-call engineer is reacting, not preventing. The signal to see it coming is in the metrics — memory pressure trends, restart cadence, request-latency drift — but nobody's watching it early enough.

Built a forecasting pipeline on pod-level Prometheus metrics: LightGBM for the core classifier, PyTorch for sequence features, Optuna for tuning, SHAP for per-prediction explanations. Strict leakage detection and Great Expectations data checks keep the training set honest. Serving is a BentoML gRPC sidecar tuned for p95 < 50ms, with Evidently drift detection triggering champion/challenger retrains through Prefect. Validated on chaos-mesh synthetic traces and real Alibaba 2018 production data.

A 30-minute horizon trades lead time for confidence — predict too early and precision collapses into alert fatigue; too late and there's no time to act. The decision threshold is the real knob: it's calibrated per-cluster, not hardcoded.

Kubernetes incident response is a human-bottleneck job: when a CrashLoopBackOff fires at 3am, the on-call engineer is running through the same root-cause checklist they ran last week. The LLM cost of just asking 'why is this pod failing?' is < $0.01.

Built a detection + analysis loop that hooks into cluster events, runs root-cause against multiple LLM providers (GPT, Anthropic, local Ollama for air-gapped clusters), and either auto-remediates known patterns or routes to ChatOps (Slack / Discord / Teams). RBAC-gated auto-remediation, with PagerDuty + Jira integrations and an ML-based pattern-learning layer.

LLM cost vs human time saved is non-obvious for low-volume clusters. Ollama path means air-gapped operation but lower analysis quality — explicit tier selection per environment.