Incident Library
  • Root cause
  • Component
  • Symptom
  • Contributing factor
  • Case

Cases12 cases

12 to 12 of 12

  1. Symptoms

    On 10 September 2019 the Kubernetes API server of Wikimedia's Toolforge cluster did not come back after the maintain-kubeusers process restarted it at 18:30. To monitoring and to users the whole cluster looked down: Toolforge users could not launch tools with the webservice command on the Kubernetes backend or use kubectl, and an Icinga check against the "All k8s nodes healthy" endpoint started alerting at 18:45.

    Trigger

    At 18:30 the maintain-kubeusers process restarted the Kubernetes API server, which forced it to reconnect to etcd with a CA certificate that Puppet changes the night before had left mismatched with the etcd servers.

    Root cause
    Component
    Contributing factor
    Detection

    Automated monitoring: an Icinga alert on the toolschecker check http://checker.tools.wmflabs.org/k8s/nodes/ready, about "All k8s nodes healthy", fired at 18:45.

    Remediation
    • Rebooted the Kubernetes master and the etcd cluster, which did not help
    • Took a backup of etcd and reduced the etcd cluster to one node to rule out raft election flaps
    • Brought etcd back to full capacity through a full disaster recovery from the backup
    • Swapped the API server's CA certificate for the one from the etcd servers, which restored services until Puppet reverted it
    • Placed the etcd Puppet CA certificate in /var/lib/puppet/client/ssl/certs/ca.pem so Puppet kept the right CA
    Action items
    • Document the etcd cluster processes
    • Upgrade Toolforge Kubernetes to improve etcd and Kubernetes error reporting and stop needing an API server restart to add a tool
    • Make kube2proxy more resilient to API server failures
    • Audit the Puppet CA certificates so the tools project has no more than one
    • Make the Kubernetes control plane highly available
    Lessons

    Components that often misbehave, such as etcd, drew the responders to the wrong fix, and working on etcd instead of the CA certificates made the outage worse. Puppet-managed certificates are risky, and very old Kubernetes versions log errors that are hard to read. The failure was hard to find because it surfaced at an API server restart rather than at the Puppet change, because the etcd cluster had long-standing undocumented quirks, and because no disaster recovery or node replacement procedure was written down for etcd.

Check your cluster for this

These 12 cases involve Database and Helm. 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 cause7

Breaking change in an upgrade1 case

Contributing factor
  1. IL-0236 After an Istio 1.15 to 1.24 upgrade, half of Wikimedia's ML model servers returned 5XX for about a day

Configuration change5 cases

  1. IL-0299 About 60 indices of Wikimedia's CirrusSearch OpenSearch clusters went red and unwritable during a host decommission
  2. IL-0392 MariaDB replication of section x1 between eqiad and codfw broke on a missing heartbeat row during a cookbook run
  3. IL-0459 MediaWiki on Kubernetes terminated TLS with a wrong certificate after a deployment, and 1% of requests failed
  4. IL-0266 Eqiad routers looped traffic between each other after a BGP MED change and could not reach other sites' public IPs
  5. IL-0458 Toolforge Kubernetes API server failed to start after a restart, logging "etcd cluster is unavailable or misconfigured"

Capacity exhaustion2 cases

  1. IL-0298 Wikimedia edits failed for 38 minutes when sessionstore Cassandra nodes in both data centres crashed on full disks
  2. IL-0232 Calico pods in the codfw WikiKube cluster hit their resource limits and crash-looped, taking nodes out one by one

Faulty deployment1 case

  1. IL-0324 Three MediaWiki deployments lost Memcached after a PHP 8.1 rollout and overloaded the External Storage database cluster

Software defect1 case

  1. IL-0216 Wikimedia on-wiki search was slow or rejected after a datacenter switchover overloaded one Elasticsearch node in codfw

Dependency failure1 case

  1. IL-0267 Wikimedia's eqsin cache site went unreachable when both of its transport links to the core data centers were down

Hardware failure1 case

  1. IL-0323 A RAID battery backup unit failure crashed db1075, the MariaDB primary of section s3, and every s3 wiki went read-only