Cases2 cases
1 to 2 of 2
- Symptoms
At 05:01 UTC on 9 October 2024 a page fired for GatewayBackendErrorsHigh, elevated 5xx errors from page-analytics_cluster in codfw, followed by a growing number of KubernetesCalicoDown alerts for WikiKube nodes not running the calico-node pod and by MediaWikiMemcachedHighErrorRate. For about an hour uncached MediaWiki requests, such as those of logged-in users, edits and API calls, saw high latency or errors.
- Trigger
An operator used the new mwscript-k8s utility to run a batch of video transcode maintenance, the TimedMediaHandler requeueTranscodes.php script. mwscript-k8s deploys a whole helm release for every script invocation, so the batch created close to 2k Calico NetworkPolicies along with many other resources over several hours.
- Root cause
- Component
- Contributing factor
- Detection
Automated monitoring detected the issue and paged the on-call SRE: GatewayBackendErrorsHigh at 05:01:36 UTC, 16 KubernetesCalicoDown alerts at 05:03:32 UTC and MediaWikiMemcachedHighErrorRate at 05:04:15 UTC.
- Remediation
- Raised the resource limits of the Calico and Typha pods and applied the change with helmfile, which redeployed all Calico pods
- Action items
- Stop mwscript-k8s from creating so many resources
- Lessons
The incident came close to a full outage. Automated monitoring caught it and many responders found the cause, but end users were affected and responders were unsure whether they could switch over to eqiad. The problem was noticed just before the hand-off from Americas to EMEA SRE shifts, a period with a long-known lack of coverage, and it helped that the transcodes were not queued on a Friday evening in the US.
IL-0106A malformed Traefik IngressRoute triggered a Traefik v2 bug once a node rollover restarted every Traefik pod, and all Kubernetes services returned 404DFDS2021- Symptoms
At 08:00 UTC on 2021-09-06 every service in DFDS's Kubernetes cluster answered with 404. Investigation started five minutes later.
- Trigger
The automated Kubernetes node rollover on 2021-09-06 restarted all the Traefik v2 pods, five days after a malformed IngressRoute manifest had been applied.
- Root cause
- Component
- Contributing factor
- Detection
All services returned 404 from 08:00 UTC and root cause investigation started at 08:05. Time to detection was 5 minutes.
- Remediation
- changed the ALB health check path, which made the targets healthy but did not stop the 404s
- rolled back by hand to Traefik v1 as the main ingress controller
- deleted the malformed IngressRoute by hand and confirmed the Traefik v2 bug
- applied the changes upstream
- Action items
- Upgrade Traefik to v2.5, where the bug is fixed, and verify that it removes the bug
- Change the Traefik v2 health check path to something more robust
- Set up an external liveness probe on the ingress controller
- Consider workload segmentation to limit the blast zone
- Look into monitoring the Traefik v2 API for rapid changes
- Look into smoke testing during and after node rollover
- Lessons
A malformed IngressRoute did nothing visible for five days and then took down all ingress when every Traefik v2 pod had restarted during a node rollover. Because Traefik v2 failed gracefully, the first signals pointed at the ALB health checks instead of at Traefik. On incident handling, the team concluded that appointing an incident manager could have helped, that the war room meeting should be recorded and a log book kept, that people not involved should only make suggestions in writing, and that a short first round of sharing thoughts and gut feelings is useful.
These 2 cases involve Calico and Cloud load balancer. 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
Capacity exhaustion1 case
- Component
- Contributing factor
- Organisation
Software defect1 case
- Contributing factor
- Organisation