Incident Library
Applied filters SymptomNetwork unreachableDomainKubernetesClear 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

Cases8 cases

8 to 8 of 8

  1. Symptoms

    In the early morning of 8 January 2019 Tinder's platform had a persistent outage. Communication from nodes to pods failed, and so did DNS lookups, because DNS ran inside the Kubernetes cluster.

    Trigger

    Earlier that morning, pod and node counts on the cluster were scaled up in response to an unrelated increase in platform latency.

    Root cause
    Component
    Contributing factor
    Remediation
    • Raised gc_thresh1, gc_thresh2 and gc_thresh3 on the nodes
    • Restarted Flannel so it re-registered the missing networks
    Lessons

    Tinder lists the outage among its learnings about network fabric limits: with Flannel over VXLAN, every node, and every pair of nodes that exchange pod traffic, adds entries to each node's ARP table, so at 605 nodes the default gc_thresh3 hard cap was exceeded on all nodes.

Check your cluster for this

These 8 cases involve Network control plane (SDN) and BGP routing. 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 cause6

Cloud provider outage1 case

Contributing factor
–
Organisation
  1. IL-0463 Secure Connect connectors timed out after a GKE control plane upgrade left Harness's internal load balancer unreachable

Capacity exhaustion2 cases

  1. IL-0350 Hosts in an IONOS TXL cluster lost connectivity when an InfiniBand fabric resweep failed on a full multicast table
  2. IL-0472 Node-to-pod traffic and DNS failed on Tinder's 605-node Flannel cluster when every node's ARP cache passed gc_thresh3
    Tinder2019

Software defect2 cases

Organisation
  1. IL-0233 A VPC control plane release broke IP alias routes in Nebius eu-west1, and Managed Kubernetes pods lost connectivity
    Nebius2025
  2. IL-0347 About 25% of Scaleway FR-PAR-1 hypervisors lost VPC connectivity when both VPC BGP route reflectors got stuck

Operator error1 case

  1. IL-0244 A queued pull request destroyed the EKS subnet route table associations and Cloud Platform services went offline

Faulty deployment1 case

Organisation
  1. IL-0530 Virtual router controllers in us-central1 ran out of memory in a loop, cutting networking for new and migrated VMs

Configuration change1 case

Organisation
  1. IL-0473 Jenkins infrastructure went fully down after a pod IP range fix deleted every AKS node pool and could not recreate them