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

Cases3 cases

1 to 3 of 3

  1. Symptoms

    At 09:33 UTC on 14 February 2023 end users told the platform team that Kubernetes logs were not arriving in CloudWatch as expected. The investigation went through fluentd and found that the nodes were running containerd as their container runtime instead of docker-shim. A scheduled node rollover the day before, at 07:30 UTC on 13 February, had set containerd as the default runtime by accident.

    Trigger

    A scheduled node rollover had accidentally made containerd the default container runtime, which stopped log shipping to CloudWatch; the unscheduled rollover to revert it timed out, and the pipeline run that followed reduced the Auto Scaling group from 30 to 15 instances.

    Root cause
    Component
    Contributing factor
    Detection

    End users reported the missing CloudWatch logs that started the work. The postmortem lists 2 minutes as the time to detection of the node failure.

    Remediation
    • ran the node rollover script to add new nodes, which failed on a timeout from Docker Hub
    • ran the node rollover script a second time, which added new nodes that the load balancer marked healthy at 11:01 UTC
    Action items
    • Document the rollover process, especially what can be done when it goes wrong
    • Investigate options for improving the rollover process
    • Add fluentd log collection to the QA test suite so logs are covered end to end
    • Add alarms for fluentd when too little or no log data is sent
    • Implement a staging environment
    • Implement guards against selecting an invalid container runtime
    Lessons

    When a change goes wrong, rolling back to a known working configuration is safer than rushing a fix, which can make the damage worse. Launching new worker nodes depends on the cloud-init script not failing in any way. The QA configuration differed from production, there was no staging environment, the QA tests did not cover fluentd log collection, and the rollover process had no documentation for when it fails.

  2. Symptoms

    After the switch to Traefik v2, functional tests indicated that everything was fine, and this was reported on Slack at 08:44 UTC. The first sign of trouble came at 09:26 UTC, when a developer reported a high count of HTTP 307 redirects, especially on the Okta service. At 09:32 UTC the team learned that the online booking system was down.

    Trigger

    At 08:22 UTC the AWS load balancers were updated to send requests to the new Traefik v2 reverse proxy as part of the migration away from Traefik v1.

    Root cause
    Component
    Contributing factor
    Detection

    A developer reported a high count of HTTP 307 redirects, in particular on the Okta service, at 09:26 UTC, 64 minutes after the change; six minutes later the team was told the online booking system was down. The functional tests run after the switch had not caught it.

    Remediation
    • Rolled back the switch to Traefik v2, putting rollback ahead of investigation because of how critical the booking system is
    Action items
    • Consider how critical announcements can be made more visible
    • Consider whether the ALBs used for testing should have been shared with the teams so they could test their own scenarios
    Lessons

    Cloud Engineering cannot test every application scenario on its own, even after testing its own applications for weeks. A header that changes value behind a new ingress controller, here x-forwarded-proto going from https to http, can break an authentication flow while basic functional tests still pass. DFDS asks whether diffing request headers before and after the migration would have shown the problem in advance.

  3. Symptoms

    At 08:29 UTC on 22 June 2021 alerts fired because all services in the Kubernetes cluster were returning 503. No inbound traffic was reaching the cluster. A customer reported the problem at 08:32.

    Trigger

    The pipeline replaced the AWS VPC CNI as part of a refactoring that moved EKS add-ons from kubectl to native Terraform management.

    Root cause
    Component
    Contributing factor
    Detection

    Alerts fired at 08:29 UTC, eight minutes after the VPC CNI was replaced; a customer reported the issue at 08:32.

    Remediation
    • committed a fix that reverted the infrastructure-modules reference
    • re-triggered the pipeline after it failed on an AWS API timeout
    • let the pipeline reattach the target groups to the ALB
    Action items
    • Revert the ALB de-registration delay to the default of 300 seconds
    • Update the roll-over script to set the ALB de-registration delay to zero temporarily before a roll-over
    • Create an ingress test suite
    Lessons

    The change to the de-registration delay had been weighed mainly for performance. Critical pipeline runs should be watched while they run. Everyone should receive the alerts and react to them, and alert messages that were unclear should be reworded.

Check your cluster for this

These 3 cases involve Cloud load balancer and Terraform. 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