Incident Library
Applied filters ComponentKubernetes API serverSymptomControl plane lagFactorNo capacity planningClear 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

Cases2 cases

1 to 2 of 2

  1. IL-0084 Packet drops on a bare metal provider's vSwitch forced Namespace to rebuild its fra3 region and left global capacity short, and the next day slow NVMe writes on a control plane node drove the Kubernetes API server to very high CPU
    Namespace2024
    Symptoms

    From 17 October 2024, packets through the vSwitch that joined Namespace's bare metal machines at one provider in the fra3 region were dropped at random. Retries in TCP, QUIC and the Namespace control plane hid most of it, but the SLO error budget for latency targets on key interactions began to burn.

    Intermittent connection failuresHigh latencyControl plane lagService outage
    Trigger

    Random packet drops on the bare metal provider's vSwitch from 17 October 2024; for the second outage, a rate of Kubernetes changes that the slow NVMe on one control plane node could no longer keep up with.

    Root cause
    Cloud provider outage
    Component
    Kubernetes API server
    Contributing factor
    No capacity planningNo headroomOverlapping failures
    Detection

    SLO-based monitoring of latency targets showed the error budget burning while retries hid the individual packet drops.

    Remediation
    • diverted all customer traffic from fra3 to other regions
    • connected each provider machine to the zrh1 cluster over Wireguard instead of the vSwitch
    • repaved every fra3 machine with a new identity, certificates and encryption-at-rest keys, dropping regional caches to recover faster
    • cloned existing datasets in a more distributed way to speed up repaving the machines
    • added machines back to the new region in batches and returned the region to the compute pool
    • redirected workloads away from zrh1 during the second outage
    • cloned the failing control plane node's key state to a higher-capacity node that took over its role and IP address
    Action items
    • Credit all instances that ran during the outages back to customers
    • Build up backup regions and solutions so a similar event has options that do not affect customers
    Lessons

    Running hot with a delayed hardware delivery left no room to take a region out, so fixing a provider network fault turned into a global capacity shortage. After one outage the team was anchored on its cause and first looked for network problems in the second outage, which had a different cause: a control plane node whose disk could not keep up with the Kubernetes change rate.

    View case
  2. IL-0075 Kubernetes API servers pegged on CPU when the cluster grew to about 290 nodes, traced to Datadog agents polling the API
    Civis Analytics2019
    Symptoms

    After Civis released its new script infrastructure on Kubernetes internally in September 2018, developers reported that kubectl commands were slow, and users intermittently could not start notebooks and services.

    Control plane lagControl plane unresponsiveHigh latencyHigh error rateDNS resolution failures
    Trigger

    Migrating clients' Python, R and container scripts from the in-house Bocce system to Kubernetes (the project called Croquet) pushed the cluster to about 290 EC2 instances under a large script load.

    Root cause
    Capacity exhaustion
    Component
    Kubernetes API serverTelemetry agentetcd
    Contributing factor
    Unknown limitUnverified assumptionMonitoring blind spotNo capacity planning
    Detection

    Developer reports of slow kubectl commands and user reports of notebooks and services failing to start, then high CPU on the master nodes.

    Remediation
    • moved internal users back to the old Bocce infrastructure
    • resized the three master nodes from m4.large to m4.4xlarge
    • changed the Datadog setup so per-node agents no longer polled the API server for service metadata
    • raised max-requests-inflight for non-mutating requests from 400 to 1200
    • grew the etcd EBS volumes from 20 to 100 GB (100 to 300 IOPS)
    • switched client scripts from the ClusterFirst DNS policy to Default
    Action items
    • Upgrade etcd from 2.2.1 to 3.x once Kops supports a safe migration
    • Solve the in-cluster DNS timeouts so client scripts can talk to other workloads in the cluster
    Lessons

    Kubernetes can reach thousands of nodes only after tuning, and third-party DaemonSets are a common cause of control plane load: an agent on every node that polls or watches the API server multiplies with the cluster size. Datadog, kube2iam and the fluentd metadata filter all showed this. A small configuration change often fixes it, but finding it took load testing and the API server access logs.

    View case
Check your cluster for this

These 2 cases involve Kubernetes API server and etcd. 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.

Open kubegap

By root cause2

Cloud provider outage1 case

Component
Kubernetes API server
Contributing factor
No capacity planningNo headroomOverlapping failures
Organisation
Namespace
  1. IL-0084 Packet drops on a bare metal provider's vSwitch forced Namespace to rebuild its fra3 region and left global capacity short, and the next day slow NVMe writes on a control plane node drove the Kubernetes API server to very high CPU
    Namespace2024

Capacity exhaustion1 case

Component
etcdKubernetes API serverTelemetry agent
Contributing factor
Unverified assumptionUnknown limitMonitoring blind spotNo capacity planning
Organisation
Civis Analytics
  1. IL-0075 Kubernetes API servers pegged on CPU when the cluster grew to about 290 nodes, traced to Datadog agents polling the API
    Civis Analytics2019