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

Cases6 cases

6 to 6 of 6

  1. Symptoms

    On 10 October 2017 at 10:45 AM, a post on the course Piazza reported that two students could not start their servers on UC Berkeley's DataHub, and the /hub/admin interface could not start them either. At first it was thought the students might have run out of memory.

    Root cause
    Component
    Contributing factor
    –
    Detection

    Students reported on the course Piazza at 10:45 AM, and later in the course Slack, that their servers would not start.

    Remediation
    • Force-deleted the stuck user pods with kubectl --namespace=prod delete pod jupyter-<name> --grace-period=0 --force
    • Cordoned node k8s-pool1-19522833-13
    • Force-deleted the stuck pods on k8s-pool2-19522833-9 and cordoned that node
    • Stopped and started k8s-pool1-19522833-13 from the Azure portal, after which Docker responded, and uncordoned it
    • Stopped and started k8s-pool2-19522833-9 from the Azure portal
    Action items
    • When several student servers fail to start or stop, check whether their pods ran on the same nodes
    • Find out how many nodes do not mount /var/lib/docker on sdb1
    • Watch for elevated counts of pods stuck in Terminating
Check your cluster for this

These 6 cases involve kubelet and Node pool. 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 cause5

Software defect1 case

Contributing factor
–
Organisation
  1. IL-0139 Pods on GKE clusters with Calico network policy got stuck Terminating or Pending after upgrading to 1.22 or later because of a race condition in the Calico component

Cloud provider outage1 case

Contributing factor
  1. IL-0514 PyPI's backends stopped responding for 7 minutes as rescheduled pods could not start while Consul and Vault were down

Breaking change in an upgrade1 case

Organisation
  1. IL-0449 Pods on Enigmo's new EKS managed node groups kept restarting or stuck Terminating and the nodes became unusable
    Enigmo2020

Capacity exhaustion1 case

Organisation
  1. IL-0401 Prow jobs on the k8s-prow-build GKE cluster failed and merges stalled as nodes hit IOPS throttling and kernel panics

unknown2 cases

Contributing factor
  1. IL-0402 mybinder.org launches dropped to zero for hours because a JupyterHub pod on a lost GKE node kept its hub database PVC
  2. IL-0507 Student pods on UC Berkeley DataHub got stuck in Terminating or would not start because Docker hung on two Azure nodes