{"id":"IL-0469","org":"UC Berkeley","date":"2019-02-25","docs":[],"title":{"en":"The managed Azure Kubernetes API server for the data100 hub stopped answering, so the stopped hub pod was not recreated","ko":"Azure 관리형 쿠버네티스의 API 서버가 응답하지 않아 data100 허브 파드가 다시 만들어지지 않았다"},"domain":["kubernetes","azure"],"impact":{"scope":"The data100 hub: requests to create resources failed and, once the hub pod stopped, users saw a proxy error until the hub was rebuilt on a new cluster and could get its SSL certificate","users":"Students using the data100 hub","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":null,"related":[],"sources":[{"url":"https://github.com/berkeley-dsep-infra/datahub/blob/staging/docs/incidents/2019-02-25-k8s-api-server-down.qmd","kind":"github","archived":null}],"summary":{"en":"At 11:21 on 25 February 2019 the API server of the managed Kubernetes cluster on Azure that ran UC Berkeley's data100 hub stopped answering. The hub proxy stayed up, but kubectl failed for all operations, and when the hub pod was stopped Kubernetes could not create a replacement, so users got a proxy error. At 11:57 staff opened a C ticket in the cloud provider's portal. C tickets have 8-hour response times, so at 12:28 staff emailed contacts at the cloud provider to ask for escalation, and the provider called back between 12:43 and 12:49.\n\nMeanwhile staff moved the hub to a new cluster. At 12:40 they decided to import the ZFS pool into a new NFS server in the new cluster instead of moving the old NFS server between clusters. The cluster was created at 13:00, the data volumes were detached from the old server and moved into the new cluster's resource group at 13:10, and the ZFS pool was imported at 13:20. helm brought up the staging hub by 13:34 and the prod hub by 13:41, with DNS updated after each, and at 14:48 the prod hub obtained an SSL certificate from letsencrypt so students could connect. On 15 March the cloud provider replied that problems with the infrastructure hosting the cluster had made the kubelet on the master stop responding, and that this was not related to region stability.","ko":"2019-02-25 11:21 에 data100 이 쓰는 관리형 쿠버네티스 서비스의 API 서버가 응답하지 않게 됐다. 이 시각은 나중에 클라우드 사업자의 모니터링 지표로 확인했다. 새 자원을 만드는 요청이 실패했고, 허브 파드가 멈춘 뒤 새 파드가 만들어지지 않아 사용자는 프록시 오류를 보았다. 인프라 담당자는 11:34 에 Slack 으로 장애를 알았다. 담당자는 클라우드 사업자에 티켓을 열고 에스컬레이션을 요청하는 한편, 새 클러스터를 만들어 저장소를 붙이는 방법을 검토했다. 사업자는 12:43 부터 12:49 사이에 전화로 응답했다.\n\n12:40 에 nfs 서버를 클러스터 사이로 옮기는 대신 ZFS 풀을 새 클러스터의 새 nfs 서버로 옮기기로 하고 새 클러스터를 요청했다. 13:00 에 클러스터가 만들어졌다. 데이터 볼륨을 옛 서버에서 떼어 새 클러스터의 리소스 그룹으로 옮긴 뒤, 13:20 에 ZFS 풀을 새 nfs 서버로 가져왔다. helm 으로 staging 허브와 prod 허브를 차례로 만들며 DNS 를 바꿨다. 14:48 에 prod 의 letsencrypt 가 SSL 인증서를 받아 학생들이 접속할 수 있게 됐다. 클라우드 사업자는 2019-03-15 의 답변에서 클러스터를 호스팅하던 인프라에 문제가 있어 마스터의 kubelet 이 응답을 멈췄다고 밝혔다. 리전 안정성과는 관계가 없다고 했다."},"trigger":null,"severity":"unknown","symptoms":["control-plane-unresponsive","service-unavailable"],"timeline":{"detected_after":"13m","resolved_after":"3h 27m"},"date_kind":"incident","detection":{"en":"Infrastructure staff were notified in Slack at 11:34 and found that kubectl failed for all operations while the hub proxy was up.","ko":"11:34 에 인프라 담당자가 Slack 으로 알림을 받았다. API 서버가 멈춘 시각인 11:21 은 장애가 끝난 뒤 클라우드 사업자의 모니터링 지표로 확인했다."},"components":["aks-control-plane","kube-apiserver","kubelet"],"root_cause":"cloud-provider","remediation":[{"text":{"en":"Created a new cluster and requested a new NFS server in its resource group","ko":"13:00 에 새 클러스터를 만들고, 그 클러스터의 리소스 그룹에 새 nfs 서버를 요청했다."}},{"text":{"en":"Detached the data volumes from the old NFS server and moved them to the new cluster's resource group","ko":"데이터 볼륨을 옛 nfs 서버에서 떼어 옛 클러스터의 리소스 그룹에서 새 클러스터의 리소스 그룹으로 옮겼다."}},{"text":{"en":"Imported the ZFS pool into the new NFS server","ko":"ZFS 풀을 새 nfs 서버로 가져왔다."}},{"text":{"en":"Created the staging hub with helm and updated DNS","ko":"helm 으로 staging 허브를 띄우고 DNS 를 바꿨다."}},{"text":{"en":"Created the prod hub with helm and updated DNS","ko":"helm 으로 prod 허브를 띄우고 DNS 를 바꿨다."}}],"action_items":[{"text":{"en":"Monitor the API server endpoint remotely and alert when it is down","ko":"API 서버 엔드포인트를 외부에서 감시하고, 응답하지 않으면 알림을 보낸다."}}],"contributing":["limited-debug-access"],"recurrence_of":null,"symptoms_text":{"en":"On 25 February 2019 the Kubernetes API server of the managed Azure cluster running the data100 hub became unreachable. kubectl failed for every operation and requests to create new resources failed, so when the hub pod stopped, no new one was created and users saw a proxy error message.\n\nInfrastructure staff were notified in Slack at 11:34 and found the hub proxy still up while the API server could not be reached. The cloud provider's status page showed no other reports. The start time, 11:21, was worked out only afterwards from the cloud provider's monitoring metrics.","ko":"data100 클러스터의 쿠버네티스 API 서버에 닿지 않아 새 자원을 만드는 요청이 실패했다. 허브 파드가 멈춘 뒤 새 파드가 만들어지지 않아 사용자들은 프록시 오류 메시지를 보았다.\n\n11:34 에 Slack 으로 알림을 받은 인프라 담당자가 확인해 보니 허브 프록시는 살아 있었지만 kubectl 은 모든 작업에서 실패했다.\n\n11:57 에 클라우드 사업자의 포털에서 C 티켓을 열었다. C 티켓은 응답까지 8시간이 걸린다. 사업자의 상태 페이지에는 다른 보고가 없었다. 담당자는 12:28 에 사업자 담당자에게 문제를 에스컬레이션할 수 있게 해 달라는 메일을 보냈다."},"updated_at":"2026-11-14T12:34:11.694752Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0469","org_slug":"uc-berkeley"}