Incident Library
Applied filters Root causeunknownDomainKubernetesOrganisationUC BerkeleyClear 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

Cases1 case

1 to 1 of 1

  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

This case involves Container runtime. 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 cause1