Cases3 cases
1 to 3 of 3
IL-0029Slow user-facing services from CPU throttling on containers that used far less CPU than their limitBuffer2020- 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.
IL-0030Most nodes of a cluster went NotReady together for 15 minutes while the API server sat behind an AWS ELBZalando2019- 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
IL-0074All AirMap platform services down as worker nodes went NotReady and pods crash-looped on network and DNS failuresAirMap2018- 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.
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
Software defect3 cases
- Component
- Contributing factor
IL-0029Slow user-facing services from CPU throttling on containers that used far less CPU than their limitBuffer2020IL-0030Most nodes of a cluster went NotReady together for 15 minutes while the API server sat behind an AWS ELBZalando2019IL-0074All AirMap platform services down as worker nodes went NotReady and pods crash-looped on network and DNS failuresAirMap2018