Incident Library
Applied filters Root causeSoftware defectSymptomNode NotReadyFactorUnpatched known bugClear 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

Cases3 cases

1 to 3 of 3

  1. Symptoms

    Services on Buffer's kops-managed cluster on AWS (about 60 nodes and 1500 containers) answered more slowly than they should have. The container throttling metric showed that many containers were being throttled whatever their CPU usage was, including containers that never came close to their CPU limit.

    Trigger

    CPU limits on user-facing services, enforced through CFS quota by a Linux kernel with a bug that throttled containers even when they were well under their limit.

    Root cause
    Component
    Contributing factor
    Detection

    While reviewing the container throttling metric, the team noticed many containers being throttled even though their CPU usage stayed far below their limits.

    Remediation
    • removed CPU limits from all services directly or indirectly on the users' critical path
    • moved those services to dedicated tainted nodes and gave them matching tolerations
    • set each service's CPU request to its peak usage over a few months plus a margin of more than 20%, and set memory requests the same way
    Action items
    • Move nodes to a kernel that contains the CFS throttling fix (4.19 or later), which for Buffer means a kops version whose host image is Ubuntu 20.04
    • After the kernel upgrade, check whether throttling is fully gone and update the post
    Lessons

    A CPU limit can slow a service down even when the service uses a small part of it, because of how the kernel enforces CFS quota on older kernels; the throttling metric shows it, the CPU usage graph does not. Upgrading the kernel is the safer fix. Removing limits works for latency, but only together with honest CPU and memory requests, isolation of the unbounded services, and monitoring of node usage, since unbounded containers can starve the kubelet.

  2. Symptoms

    Fewer than 20% of the nodes in one Zalando cluster were available. Most nodes reported NotReady at the same moment, and only a handful stayed Ready.

    Root cause
    Component
    Contributing factor
    Remediation
    • none; the nodes recovered on their own after about 15 minutes
  3. 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

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