Incident Library

IL-0469 UC Berkeley · 2019-02-25kubernetesazure

Azure 관리형 쿠버네티스의 API 서버가 응답하지 않아 data100 허브 파드가 다시 만들어지지 않았다

2019-02-25 11:21 에 data100 이 쓰는 관리형 쿠버네티스 서비스의 API 서버가 응답하지 않게 됐다. 이 시각은 나중에 클라우드 사업자의 모니터링 지표로 확인했다. 새 자원을 만드는 요청이 실패했고, 허브 파드가 멈춘 뒤 새 파드가 만들어지지 않아 사용자는 프록시 오류를 보았다. 인프라 담당자는 11:34 에 Slack 으로 장애를 알았다. 담당자는 클라우드 사업자에 티켓을 열고 에스컬레이션을 요청하는 한편, 새 클러스터를 만들어 저장소를 붙이는 방법을 검토했다. 사업자는 12:43 부터 12:49 사이에 전화로 응답했다.

12:40 에 nfs 서버를 클러스터 사이로 옮기는 대신 ZFS 풀을 새 클러스터의 새 nfs 서버로 옮기기로 하고 새 클러스터를 요청했다. 13:00 에 클러스터가 만들어졌다. 데이터 볼륨을 옛 서버에서 떼어 새 클러스터의 리소스 그룹으로 옮긴 뒤, 13:20 에 ZFS 풀을 새 nfs 서버로 가져왔다. helm 으로 staging 허브와 prod 허브를 차례로 만들며 DNS 를 바꿨다. 14:48 에 prod 의 letsencrypt 가 SSL 인증서를 받아 학생들이 접속할 수 있게 됐다. 클라우드 사업자는 2019-03-15 의 답변에서 클러스터를 호스팅하던 인프라에 문제가 있어 마스터의 kubelet 이 응답을 멈췄다고 밝혔다. 리전 안정성과는 관계가 없다고 했다.

심각도
–
영향 범위
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
영향 사용자
Students using the data100 hub
지역
–
감지까지
13m
복구까지
3h 27m

증상

data100 클러스터의 쿠버네티스 API 서버에 닿지 않아 새 자원을 만드는 요청이 실패했다. 허브 파드가 멈춘 뒤 새 파드가 만들어지지 않아 사용자들은 프록시 오류 메시지를 보았다.

11:34 에 Slack 으로 알림을 받은 인프라 담당자가 확인해 보니 허브 프록시는 살아 있었지만 kubectl 은 모든 작업에서 실패했다.

11:57 에 클라우드 사업자의 포털에서 C 티켓을 열었다. C 티켓은 응답까지 8시간이 걸린다. 사업자의 상태 페이지에는 다른 보고가 없었다. 담당자는 12:28 에 사업자 담당자에게 문제를 에스컬레이션할 수 있게 해 달라는 메일을 보냈다.

증상 컨트롤 플레인 무응답서비스 중단

원인

촉발
–

감지

11:34 에 인프라 담당자가 Slack 으로 알림을 받았다. API 서버가 멈춘 시각인 11:21 은 장애가 끝난 뒤 클라우드 사업자의 모니터링 지표로 확인했다.

조치

후속 조치

교훈

–

출처

관련 사례

내 클러스터에도 있는지 확인하기

kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이 사례와 같은 상태를 점검합니다. 이 사례의 구성 요소: AKS 컨트롤 플레인, 쿠버네티스 API 서버, kubelet. 점검 항목의 근거는 이 사례 같은 공개 보고서입니다.

AI 도구와 스크립트용

API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.