Cases2 cases
1 to 2 of 2
IL-0158An expired credential caused authentication failures that stopped LKE and LKE-E from deploying clusters and nodes in all regions, which also blocked node recycling and cluster autoscalingLinode2026- Symptoms
From 11:45 UTC on 16 April 2026, customers of Linode Kubernetes Engine (LKE) and Linode Kubernetes Engine Enterprise (LKE-E) could not deploy new clusters or add new nodes to existing clusters. Because no new node could be deployed, node recycling and cluster autoscaling did not work either. The problem hit every region where LKE runs.
- Trigger
A credential expired, which caused authentication failures when LKE and LKE-E deployed clusters and nodes. One status update describes it as an expired certificate.
- Root cause
- Component
- Contributing factor
- –
- Detection
The first status page update, saying the team was investigating an emerging issue affecting LKE and LKE-E in all regions, was posted at 13:20 UTC.
- Remediation
- created new credentials and deployed them, rotating the expired credential (certificate)
- Action items
- Investigate what led to the credential expiry and take preventive actions
- Lessons
One expired credential stopped every operation that needs a new node, in all regions at once: new clusters, added nodes, node recycling and autoscaling.
IL-0205The GKE cluster autoscaler could not add nodes to GitLab.com's production cluster because Google Cloud ran out of SSD persistent disks in us-east1GitLab2021- Symptoms
At 08:05 UTC on 2021-06-21 the API service's Apdex (the share of requests that finish within a target time) and Rails request queuing began trending the wrong way. At 09:01 the team found the API deployment unhealthy: it needed more pods for the day's growing traffic, but no new nodes could be added to give it pod capacity. Users saw slow responses; the review found no sign that error rates rose.
- Trigger
Google Cloud ran out of SSD persistent disk stock in us-east1, the region GitLab.com runs in, while the API service needed more nodes for rising user traffic.
- Root cause
- Component
- Contributing factor
- Detection
There was no alert on resource availability. Apdex and Rails queuing began trending the wrong way at 08:05 UTC and an engineer declared the incident in Slack at 08:43; finding the cause took a lot of log digging: cluster autoscaler errors about node pools in backoff, then ZONE_RESOURCE_POOL_EXHAUSTED at the instance-group level, and finally Google Cloud support naming SSD as the exhausted resource.
- Remediation
- added a node pool that uses pd-standard disks
- scaled the new node pool by hand across all three zones to relieve the API
- brought more pd-standard node pools online for the other blocked workloads
- stopped production deployments and opened a Google Cloud support case about the cluster autoscaler not working with the new node pools
- changed node pools and nodeSelectors so the remaining workloads ran on pd-standard nodes
- removed the SSD-backed node pools after a day without problems
- Action items
- Move Kubernetes services to pd-standard disks (delivery#1837)
- Capture resource exhaustion errors as a metric
- Lessons
A cloud region can run out of one specific resource, here SSD persistent disks, and the only error may be a generic ZONE_RESOURCE_POOL_EXHAUSTED that does not name it. GitLab could neither monitor nor reserve resource availability, so detection took 22 hours and the cause came from Google Cloud support. The workloads ran fine on pd-standard disks. A second problem found on the way, a cluster autoscaler that does not fall back to another matching node pool when one cannot scale, slowed the move to the new node pools.
These 2 cases involve Node pool and Cluster autoscaler. 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 cause2
Certificate or credential expiry1 case
- Component
- Contributing factor
- –
- Organisation
Cloud provider outage1 case
- Component
- Contributing factor
- Organisation