Incident Library
Applied filters ComponentIngress controllerSymptomService outageFactorChange with a delayed effectClear 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

    Event ingestion and the Honeycomb UI in EU1 became unavailable at 22:00:10 UTC on April 9, 2024, and the status page reported that the EU1 instance was down. Both the ingestion service and the service behind the web UI stopped at roughly the same moment.

    Trigger

    A routine system update to the Kubernetes cluster, rolled out earlier on April 9, followed by a regular deployment that replaced pods one at a time.

    Root cause
    Component
    Contributing factor
    Detection

    The first status post, saying the EU1 instance was down, went up at 15:08 PDT (22:08 UTC), about 8 minutes after the outage began. There was no alerting on the AWS Load Balancer Controller.

    Remediation
    • Restarted the AWS Load Balancer Controller
    • Rolled back the Kubernetes cluster system update
    Action items
    • Find the exact cause of the failure so the system update can be deployed safely
    • Add monitoring and alerting on the AWS Load Balancer Controller so on-call engineers learn of a failure quickly and can pause deployments
    Lessons

    A rolling deployment can look healthy while the component that wires new pods into the load balancer is broken; the failure only shows when the last old pod goes away. Honeycomb now treats the AWS Load Balancer Controller as a critical component that needs its own alerting, so deployments can be paused before they remove the last pods that still receive traffic. Extensive testing in development and staging did not reveal the bad interaction.

  2. Symptoms

    At 08:00 UTC on 2021-09-06 every service in DFDS's Kubernetes cluster answered with 404. Investigation started five minutes later.

    Trigger

    The automated Kubernetes node rollover on 2021-09-06 restarted all the Traefik v2 pods, five days after a malformed IngressRoute manifest had been applied.

    Root cause
    Component
    Contributing factor
    Detection

    All services returned 404 from 08:00 UTC and root cause investigation started at 08:05. Time to detection was 5 minutes.

    Remediation
    • changed the ALB health check path, which made the targets healthy but did not stop the 404s
    • rolled back by hand to Traefik v1 as the main ingress controller
    • deleted the malformed IngressRoute by hand and confirmed the Traefik v2 bug
    • applied the changes upstream
    Action items
    • Upgrade Traefik to v2.5, where the bug is fixed, and verify that it removes the bug
    • Change the Traefik v2 health check path to something more robust
    • Set up an external liveness probe on the ingress controller
    • Consider workload segmentation to limit the blast zone
    • Look into monitoring the Traefik v2 API for rapid changes
    • Look into smoke testing during and after node rollover
    Lessons

    A malformed IngressRoute did nothing visible for five days and then took down all ingress when every Traefik v2 pod had restarted during a node rollover. Because Traefik v2 failed gracefully, the first signals pointed at the ALB health checks instead of at Traefik. On incident handling, the team concluded that appointing an incident manager could have helped, that the war room meeting should be recorded and a log book kept, that people not involved should only make suggestions in writing, and that a short first round of sharing thoughts and gut feelings is useful.

Check your cluster for this

These 2 cases involve Cloud load balancer and Ingress controller. 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 cause2