AI-Driven Autonomous Kubernetes Operations for Self-Healing Cloud Infrastructure: A Multi-Signal Diagnostic Policy Evaluated Against Real Fault Injection

Abstract

Autonomous, self-healing infrastructure is a stated goal of modern cloud operations, yet most published evaluations of "AI-driven" remediation either simulate the underlying system or evaluate against a narrow set of easily-detected faults such as process crashes. We present a controlled, three-condition empirical evaluation of automated fault remediation for a containerized service, run against a real Kubernetes control plane (unmodified upstream apiserver, scheduler, and controller-manager) rather than a simulated one. Because the sandboxed evaluation environment could not execute kubelet's own container-sandbox path, a purpose-built, kubelet-substitute node agent -- architecturally the same virtual-kubelet pattern used in production Kubernetes provider integrations -- backs real API objects with real Docker containers; the diagnostic process that identified this environmental constraint, and the reasoning for the substitution, are reported in full rather than elided. Against this substrate we define a six-class fault taxonomy spanning both process-visible failures (crash, out-of-memory kill, a crash-inducing bad rollout) and failures invisible to a process-level check alone (a silent application hang, a network partition, and severe CPU starvation under load), and compare three remediation layers: no automation, a single blind restart-on-crash rule representative of common current practice, and a deterministic, multi-signal diagnostic policy that fuses container runtime state, an independent application-level health probe, and short-window failure history. Across 186 independently-timed trials, overall recovery rates were 14.6% (no automation), 47.9% (restart-on-crash), and 96.7% (multi-signal policy); a chi-square test of condition against recovery outcome was highly significant (χ² = 96.6, p < 0.001). The blind restart rule fully resolved the two process-visible faults it targets (100% recovery, ~1-2 s) but never resolved either fault class invisible to a process check (0% recovery for silent hang and network partition) and, for a bad rollout, restarted the same broken container indefinitely without ever recovering it -- detecting the fault but never fixing it. The multi-signal policy resolved five of six fault classes at 100% and the sixth (bad rollout, via an explicit rollback action rather than a blind restart) at 80%, at recovery latencies ranging from 0.7 s (network partition) to 9.5 s (CPU starvation under sustained load). We report the one node-heartbeat and one thread-safety defect discovered and fixed during harness development, since both are realistic operational failure modes in their own right. The proposed policy is a fully inspectable rule-and-score engine, not a trained model or live language-model agent, and the study is a single-node, single-service reference implementation rather than a claim about production, multi-service scale; both limitations are discussed alongside the practical implication that the value of "AI-driven" self-healing in this setting comes primarily from fusing signals a blind restart rule never consults, not from any specific learning method.