Incident Library
Applied filters Root causeSoftware defectComponentkubeletOrganisationAirMapClear 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 about 15:00 UTC on 19 July 2018, monitoring alerted on rising 5xx responses from several APIs, most notably pilot and tiles. Logins failed first, because the pilot service fetches the user's profile, and from there all services became unresponsive. Every affected API ran on the production Kubernetes cluster.

    Root cause
    Component
    Contributing factor
    Detection

    Monitoring alerted on an increase in 5xx responses from several APIs, most notably pilot and tiles.

    Remediation
    • restarted the kubelets on the stuck worker nodes, which did not last
    • restarted all worker nodes in a staggered order starting at about 18:00 UTC, which took about 1.5 hours
    Action items
    • Restart nodes on a rolling schedule to keep nodes and kubelets healthy until the fixes land upstream and reach the cloud provider, Microsoft Azure
    Lessons

    When nodes keep falling back to NotReady after kubelet restarts and pods fail on network and DNS errors, a known upstream bug may be the cause; matching the symptoms to the upstream issue tracker, with help from the community, found the cause and the fix candidates.

Check your cluster for this

This case involves kubelet. 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