Incident Library
Applied filters Root causeSoftware defectSymptomControl plane unresponsiveClear 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

Cases2 cases

1 to 2 of 2

  1. Symptoms

    Every service in the homelab Kubernetes cluster stopped answering: the V-Rising server, Grafana, Jellyfin and Linkding were all unreachable, and the Kubernetes API was down, so the cluster could not be managed at all. The outage was found by hand, about 3 hours after it began, when someone tried to use the services.

    Trigger

    A power outage forced the Kubernetes master node to reboot.

    Root cause
    Component
    Contributing factor
    Detection

    Manually, when someone tried to access the services; there were no automated alerts.

    Remediation
    • Connected a monitor to the master node and read the boot logs, which showed the kernel panic
    • Booted the previous kernel version, which brought the system back
    • Removed the broken Nvidia packages with sudo apt-get remove --purge '^nvidia-.*' and ran sudo dpkg --configure -a
    • Found remaining broken packages with dpkg -l | grep -v ^ii and removed them by hand
    • Ran sudo apt-get install -f and reinstalled linux-headers-$(uname -r)
    • Rebooted and confirmed the kernel panic was gone
    Action items
    • Make sure GPU driver installations fully succeed, or revert immediately when they fail
    • Move the cluster to a high-availability control plane
    • Expose the Kubernetes API through a load balancer in the HA setup
    • Set up a ticketing system to record incidents and their resolution
    • Write predefined troubleshooting workflows to shorten response time
    • Add infrastructure monitoring such as Prometheus and Grafana
    • Add blackbox HTTP and TCP checks from outside the cluster for critical services
    Lessons

    A driver installation that fails half-way can leave kernel packages broken without any visible effect until the next reboot, which may come weeks later and at the worst time. A failed DKMS build should be fixed or reverted at once. With a single master node and no monitoring from outside the cluster, one unbootable machine meant a total outage that nobody was told about; the fix itself was simple once the boot logs were seen.

  2. Symptoms

    A production EKS cluster on Kubernetes 1.30 went into read-only mode: the API server rejected every request that would change an object, such as creating pods or scaling deployments, and deleting objects to free space did not work either.

    Trigger

    Kyverno 1.12 kept creating ephemeralreports objects that piled up in etcd until the database passed EKS's size limit.

    Root cause
    Component
    Contributing factor
    Detection

    The cluster rejected writes; the audit logs carried the "etcdserver: mvcc: database space exceeded" error.

    Remediation
    • AWS raised the etcd storage limit from 8/10GB to 12GB to unlock writes
    • an AWS engineer deleted the leaked Kyverno ephemeralreports objects directly from etcd
    Action items
    • Monitor the etcd database size with apiserver_storage_size_bytes and never let it reach 8GB
    • Upgrade Kyverno 1.12 to 1.12.4, which fixes the ephemeralreports pile-up, or disable reporting for admission events and tune --aggregationWorkers
    Lessons

    On EKS, once etcd hits its size limit the cluster becomes read-only and only AWS can clean it up, so cleanup scripts must run before the limit is reached. Watch the etcd database size and object counts per resource, especially for controllers that create report objects.

Check your cluster for this

These 2 cases involve Kubernetes API server and etcd. 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.

By root cause1