Incident Library
Applied filters Root causeConfiguration changeFactorUnverified assumptionOrganisationAdGuard VPNClear allEvery case under the filters, with no sentence; newest first.
Suggested filters Search, and the values found in your words appear here.

Graph

  • Root cause
  • Component
  • Symptom
  • Contributing factor
  • Case

Cases1 case

1 to 1 of 1

  1. IL-0063 VPN outage after recreating a Redis StatefulSet restarted the whole Redis cluster without readiness checks
    AdGuard VPN2025
    Symptoms

    The day began with an alert that several instances of the Redis cluster were running out of disk space. That part was fixed quickly. The outage came an hour later: right after the Redis StatefulSet was deleted and recreated at 8:10 UTC, Kubernetes restarted every Redis pod within about five minutes, and problems started to appear.

    Service outageOOMKilledProbe failuresHigh latency
    Trigger

    To make Git match the volumes that had been resized by hand, the Redis StatefulSet was deleted with orphan (non-cascading) deletion and recreated with the new storage template; Kubernetes reconciled the new spec by restarting the entire Redis cluster.

    Root cause
    Configuration change
    Component
    Persistent volumes and stateful setsIn-memory cacheContainer memory limit
    Contributing factor
    No health probesUnverified assumptionSingle point of failureRetry stormNo headroom
    Detection

    An alert about Redis instances running out of disk space started the work; the outage itself showed up as backend errors about Redis connections right after the StatefulSet was recreated.

    Remediation
    • made the Redis masters forget obsolete node identities, reset the affected replicas and rejoined them, then waited for replication to catch up
    • identified the component that was actually running out of memory, scaled the backend service and raised memory limits for that component
    • temporarily relaxed probes so backend instances took traffic immediately instead of flapping between ready and not ready
    • reverted the temporary workarounds at 10:00 UTC
    Action items
    • Add startup probes so a Redis pod is not marked ready until its dataset is loaded
    • Build an own control plane for Redis that handles restarted pods stuck to an old master address
    • Reduce dependence on the single Redis cluster: move some important data to other stores, such as a separate Redis cluster per server, and use Kafka for some backend components
    Lessons

    The disk resize was not the problem; the cleanup afterwards was. An immutable field pushes operators toward deleting and recreating the controller, and that can set off a full reconcile. Startup and readiness probes are what slow a rolling restart down to a safe pace; without them a distributed store restarts in the most fragile way. Recovery plans must expect a cluster to heal slowly, and dependent services need to degrade gracefully while it does.

    View case
Check your cluster for this

This case involves In-memory cache and Container memory limit. kubegap audits a Kubernetes cluster for gaps like these, read-only, from Claude Code or Codex; its checks cite public reports like the ones in this library.

Open kubegap

By root cause1

Configuration change1 case

Component
In-memory cacheContainer memory limitPersistent volumes and stateful sets
Contributing factor
Unverified assumptionNo health probesNo headroomRetry stormSingle point of failure
Organisation
AdGuard VPN
  1. IL-0063 VPN outage after recreating a Redis StatefulSet restarted the whole Redis cluster without readiness checks
    AdGuard VPN2025