Automatic self-healing
The Kuberns backend includes layered container recovery:
| Layer | Backend name | Purpose |
|---|---|---|
| L1 | Swarm Restart | Use container-orchestrator restart behavior. |
| L2 | Intelligent Healing | Classify a failure and select a recovery action. |
| L3 | Real-Time Listener | Receive health-agent events for active detection. |
Detection and classification
Health events and probes can identify container crashes or missing service replicas. Kuberns can use AI classification, with a rule-based fallback when AI classification is unavailable.
Backend classifications include out-of-memory, memory pressure, database unreachable, application error, port conflict, disk full, CPU throttling, missing variables, segmentation fault, unavailable image, expiring SSL, startup loop, Swarm restart, and unclassified incidents.
Recovery
Depending on topology and classification, recovery can include:
- Force-updating a Docker Swarm service.
- Recreating a single-node Docker Compose application.
- Recalculating and updating memory limits for an out-of-memory case.
- Checking whether the application recovered.
- Recording a healing event and notifying users or administrators.
Healing events move through detected, healing, healed, failed, or skipped states. Default backend policy enables healing, limits restart attempts to five per hour, and uses three failed health probes as a threshold.
Automatic healing is a best-effort recovery path, not a guarantee that every application or infrastructure failure can be repaired.