Cases13 cases

12 to 13 of 13

1. IL-0088 A validating admission webhook added by a new ingress controller module version made the live-1 cluster reject every new Ingress with an x509 error

   UK Ministry of Justice2020

   Symptoms

   At 12:39 on 7 September 2020 the Cloud Platform team found that the Ingress API of the live-1 cluster was refusing every POST request. A user who provisioned a new service could not create an ingress into the cluster. The incident was declared at 12:54.

   Deploys failing

   Trigger

   Version 0.1.0 of the team's ingress controller module started creating a ValidatingWebhookConfiguration resource, and one new 0.1.0 ingress controller in the live-1 cluster failed to be created because of AWS resource limits.

   Root cause

   Faulty deployment

   Component

   Admission webhookIngress controller

   Contributing factor

   Single point of failure

   Detection

   The Ingress API was found refusing 100% of POST requests at 12:39; the incident was declared at 12:54.

   Remediation

   • removed by hand all the additional admission controllers created by module version 0.1.0
   • removed the admission webhook from the ingress controller module and released version 0.1.1
   • upgraded every ingress module on version 0.1.0 to 0.1.1

   Lessons

   Turning on the validating webhook in the shared ingress controller module made the webhook a single point of failure for every ingress controller pod in the ingress-controllers namespace: when one controller could not come up, no team could create an ingress.

   View case
2. IL-0505 kubectl logs failed on GKE with "No SSH tunnels currently open" and mybinder.org build logs stopped reaching users

   Binder Project2019

   Symptoms

   On 20 February 2019 at 08:03 CET, `kubectl logs -f <pod>` stopped working for every pod in the mybinder.org cluster on GKE. Because pod logs could not be read, build logs were no longer forwarded to users, although the builds themselves ran normally.

   Monitoring outageDeploys failing

   Root cause

   Cloud provider outage

   Component

   GKE control planeKubernetes API server

   Contributing factor

   Limited debug access

   Remediation

   • Cordoned node gke-prod-a-users-b921bb88-rd5d so it would be removed from the pool once empty
   • Drained the node and removed it from the pool, after which kubectl logs worked again

   Action items

   • Test that kubectl logs works and notify when it does not
   • Add the command for retrieving API server logs to the SRE guide
   • Describe in the SRE guide how to identify suspicious node networking status

   Lessons

   The root cause was very difficult to identify, partly because it appears to sit in the Kubernetes master or the GKE service itself. Capturing `kubectl describe node` for the suspicious node would have allowed a comparison with healthy nodes, and a node that reports no ExternalIP or InternalIP in its status was likely a direct symptom of the problem and can be used as a diagnostic in the future.

   View case

By root cause7