{"id":"IL-0074","org":"AirMap","date":"2018-07-19","docs":["https://github.com/kubernetes/kubernetes/issues/45419","https://github.com/kubernetes/kubernetes/issues/45419#issuecomment-405168344","https://github.com/kubernetes/kubernetes/issues/45419#issuecomment-406121274"],"title":{"en":"All AirMap platform services down as worker nodes went NotReady and pods crash-looped on network and DNS failures","ko":"워커 노드가 잇달아 Not Ready 에 빠지고 네트워크와 DNS 실패로 사이드카가 죽으면서, AirMap 플랫폼의 모든 서비스가 다섯 시간 동안 응답하지 않았다."},"domain":["kubernetes","networking"],"impact":{"scope":"all AirMap platform services, starting with logins through the pilot service","users":"unknown","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"When nodes keep falling back to NotReady after kubelet restarts and pods fail on network and DNS errors, a known upstream bug may be the cause; matching the symptoms to the upstream issue tracker, with help from the community, found the cause and the fix candidates.","ko":"AirMap 은 운영 클러스터의 증상을 오픈소스 커뮤니티의 알려진 이슈와 대조해 근본 원인과 수정 후보를 찾을 수 있었다. 업스트림 수정이 클라우드 제공자에게 반영되기 전까지는 워커 노드를 정기적으로 롤링 재시작해 같은 장애를 막는다."},"related":[],"sources":[{"url":"https://web.archive.org/web/20190601220221/https://www.airmap.com/incident-180719/","kind":"blog","license":"unknown","archived":"https://web.archive.org/web/20190601220221/https://www.airmap.com/incident-180719/"}],"summary":{"en":"AirMap's production Kubernetes cluster, on Microsoft Azure, lost a growing number of worker nodes to \"Not Ready\" while pods on them crash-looped on network and DNS failures, taking every platform service down. Restarting kubelets only helped briefly. At about 18:00 UTC the team began restarting all worker nodes, staggered. Once a quorum of the nodes behind the service agent pools had been restarted, healthy API replicas were scheduled on them and the situation cleared. After about 1.5 hours every worker node had been restarted, the 5xx responses stopped, and the incident ended at 20:00 UTC.\n\nDuring and after the incident the team matched the symptoms to the upstream Kubernetes issue 45419, whose root cause had been identified there along with candidate fixes. Until those fixes landed upstream and reached Azure, AirMap planned to restart nodes on a rolling schedule to keep nodes and kubelets healthy.","ko":"AirMap 플랫폼은 2018년 7월 19일 15:00 UTC 부터 20:00 UTC 까지 서비스가 중단되었다. 사용자 프로필을 가져오는 pilot 서비스부터 응답하지 않아 로그인이 실패했고, 결국 모든 서비스가 응답하지 않았다. 운영 쿠버네티스 클러스터에서 API 레플리카 대부분이 재시작을 반복했고 워커 노드 일부가 Not Ready 가 되었다. 로그에는 네트워크와 DNS 실패가 있었다. 내부 트래픽 관리 인프라에 붙는 사이드카 컨테이너가 이 실패로 죽으면서 워크로드 컨테이너도 함께 죽었다.\n\nkubelet 을 되살려도 노드는 곧 다시 Not Ready 가 되었고, Not Ready 노드는 늘어났다. 18:00 UTC 쯤 대응팀은 클러스터의 모든 워커 노드를 시차를 두고 재시작하기로 했다. 서비스 에이전트 풀을 받치는 워커 노드가 정족수를 채울 만큼 재시작되자 상황이 풀리기 시작했고, 재시작한 노드에 정상 레플리카가 스케줄되었다. 약 1.5시간 뒤 모든 워커 노드의 재시작이 끝났고, 5xx 응답이 사라지고 상태 표시가 초록으로 바뀌었다.\n\nAirMap 은 장애 중 조사와 사후 조사를 거쳐 증상을 쿠버네티스 이슈 #45419 와 연결했다. 이 이슈에서 근본 원인이 밝혀졌고 좋은 수정 후보도 나와 있었다. AirMap 이 쓰던 클라우드는 MS Azure 였다."},"trigger":null,"severity":"unknown","symptoms":["high-error-rate","node-not-ready","dns-resolution-failures","crash-loop","service-unavailable"],"timeline":{"detected_after":null,"resolved_after":"5h"},"date_kind":"incident","detection":{"en":"Monitoring alerted on an increase in 5xx responses from several APIs, most notably pilot and tiles.","ko":"15:00 UTC 쯤 모니터링 인프라가 일부 API, 특히 pilot 과 tiles 의 5xx 응답 증가를 알렸다."},"components":["kubelet"],"root_cause":"software-bug","remediation":[{"text":{"en":"restarted the kubelets on the stuck worker nodes, which did not last","ko":"멈춘 워커 노드의 kubelet 을 되살리려 했지만 노드는 곧 다시 Not Ready 가 되었다."}},{"text":{"en":"restarted all worker nodes in a staggered order starting at about 18:00 UTC, which took about 1.5 hours","ko":"18:00 UTC 쯤부터 클러스터의 모든 워커 노드를 시차를 두고 재시작했다. 약 1.5시간 뒤 모든 노드의 재시작이 끝나며 서비스가 안정되었다."}}],"action_items":[{"text":{"en":"Restart nodes on a rolling schedule to keep nodes and kubelets healthy until the fixes land upstream and reach the cloud provider, Microsoft Azure","ko":"수정이 업스트림에 들어가 클라우드 제공자인 MS Azure 에 반영될 때까지, 노드와 kubelet 이 정상으로 돌도록 정기적인 롤링 재시작을 적용한다."}}],"contributing":["known-bug-unpatched"],"recurrence_of":null,"symptoms_text":{"en":"At about 15:00 UTC on 19 July 2018, monitoring alerted on rising 5xx responses from several APIs, most notably pilot and tiles. Logins failed first, because the pilot service fetches the user's profile, and from there all services became unresponsive. Every affected API ran on the production Kubernetes cluster.\n\nMost API replicas were in a restart loop and could not serve traffic, and some worker nodes were reported as \"Not Ready\". The per-pod and per-container logs showed network and DNS failures. The sidecar containers that connect to AirMap's internal traffic management infrastructure failed on these, and took the workload containers down with them, which caused the restart loop.\n\nRestarting the kubelets on the stuck nodes did not hold: the nodes soon went back to \"Not Ready\", and more nodes followed.","ko":"2018년 7월 19일 15:00 UTC 쯤 모니터링 인프라가 일부 API, 특히 pilot 과 tiles 의 5xx 응답 증가를 알렸다. 사용자 프로필을 가져오는 pilot 서비스가 먼저 응답하지 않아 플랫폼 로그인이 실패했고, 문제는 거기서 퍼져 나갔다.\n\n영향을 받은 API 는 모두 운영 쿠버네티스 클러스터에서 돌고 있었다. API 레플리카 대부분이 재시작을 반복하며 트래픽을 받지 못했고, 워커 노드 일부가 Not Ready 로 보고되었다.\n\n팀은 멈춘 워커 노드의 kubelet 을 되살려 보았지만 노드는 곧 다시 Not Ready 가 되었고, 그사이 다른 워커 노드도 Not Ready 로 표시되기 시작했다.\n\n파드와 컨테이너 로그에는 네트워크와 DNS 실패가 찍혀 있었다. 내부 트래픽 관리 인프라에 연결하는 사이드카 컨테이너가 이 실패로 죽으면서 워크로드 컨테이너까지 함께 죽었고, 그래서 재시작이 반복되었다."},"updated_at":"2026-11-10T00:00:39.647753Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0074","org_slug":"airmap"}