Incident Library
Applied filters ComponentNode launch templateFactorHarmful manual actionClear 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. 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.

Check your cluster for this

This case involves Container runtime and Node launch template. 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