Incident Library

IL-0442 LIFULL · 2021-09-22 (게시일)kubernetesaws

운영 중인 KEEL 쿠버네티스 클러스터에서 priority 0 파드가 한꺼번에 선점되어 istio-ingressgateway 를 비롯한 파드가 재시작되고 서비스가 잠시 끊겼다

LIFULL 의 KEEL 팀은 쿠버네티스 클러스터 KEEL 의 파드 대부분을 AWS 스폿 인스턴스에서 돌리려고 여러 가지를 만들어 왔다. 스폿 플릿을 도입했고, 스폿 인스턴스 용량이 바닥났을 때의 폴백 기능과 스폿 인스턴스 위 파드를 안전하게 종료하는 처리를 개발했다. 스케줄링 대기를 줄이려고 팀은 PriorityClass 세 개를 만들어 적용했다. 선점해도 되는 파드에 붙일 value: 100 인 low, 표준 파드에 붙일 globalDefault: true 이고 value: 1000 인 medium, 우선순위가 높은 파드에 붙일 value: 10000 인 high 였다.

파드의 priority 는 Admission Controller 가 파드를 배포할 때 넣는다. 그래서 PriorityClass 를 도입하기 전에 배포된 파드는 모두 priority: 0 으로 남아 있었다. globalDefault: true 때문에 새로 배포되는 파드는 priority: 1000 을 받았다. 리소스가 모자란 노드에 이런 파드가 배포되자 kube-scheduler 가 기존 파드를 한꺼번에 선점했다. 선점은 kube-scheduler 가 파드를 종료하는 것이고, 보통의 종료 순서를 그대로 따른다. preStop 을 실행하고 SIGTERM 을 보낸 뒤, terminationGracePeriodSeconds 가 지나도 끝나지 않으면 SIGKILL 을 보낸다. istio-ingressgateway 를 비롯한 많은 파드가 재시작했고, 리버스 프록시 대수가 줄어 클러스터 밖에서 들어오는 요청의 오류율이 급격히 올랐다.

KEEL 의 파드에는 거의 모두 PodDisruptionBudget 이 있었지만 선점을 막지 못했다. 쿠버네티스 문서에 따르면 선점은 PodDisruptionBudget 을 되도록 지키려 할 뿐이고, 지킬 수 있는 희생 파드를 찾지 못하면 PodDisruptionBudget 을 어기고도 낮은 우선순위 파드를 내린다. 팀은 globalDefault: true 인 PriorityClass 의 value 가 0 이 되도록 PriorityClass 정의를 바꿨다. 글쓴이는 이 PriorityClass 도입 작업을 맡은 사람이었고, 장애 2주 전에 같은 종류의 장애를 다룬 Grafana 의 포스트모템을 팀에 공유했었다.

심각도
–
영향 범위
Requests from outside the KEEL cluster failed at a sharply higher rate while istio-ingressgateway and many other pods restarted; services were briefly down
영향 사용자
–
지역
–
감지까지
–
복구까지
–

증상

새 PriorityClass 를 적용하고 low PriorityClass 파드의 선점을 확인한 직후 팀에 알림이 대량으로 왔다. 알림은 외부 모니터링에서 왔고, 클러스터 밖에서 들어오는 요청의 오류율이 급격히 올라가 있었다.

조사해 보니 클러스터 밖의 요청을 받는 리버스 프록시 istio-ingressgateway 를 비롯해 많은 파드에 재시작한 흔적이 있었다.

클러스터 안의 요청은 서비스 메시인 Istio 가 재시도해서 큰 영향이 없었다. 클러스터 밖의 요청은 리버스 프록시 대수가 줄어든 탓에 오류율이 급격히 올랐다.

KEEL 의 파드에는 거의 모두 PodDisruptionBudget 이 설정되어 있었으므로, 팀은 파드가 한꺼번에 내려가는 일은 막혀 있다고 생각하고 있었다.

증상 파드 축출오류율 상승

원인

원인 설정 변경

구성 요소 파드 우선순위와 선점인그레스 컨트롤러
기여 요인 미검증 가정
촉발
운영 중인 KEEL 클러스터에 globalDefault: true 이고 value: 1000 인 medium PriorityClass 를 배포했다.

감지

외부 모니터링에서 클러스터 밖 요청의 오류율이 급격히 올랐다는 알림이 팀에 대량으로 왔다.

조치

–

후속 조치

교훈

운영 중인 클러스터에 PriorityClass 를 설정할 때는 조심해야 한다. 모든 파드의 기본 priority 는 0 이어서 PriorityClass 설정이 의도하지 않은 선점을 일으킬 수 있다. globalDefault: true 인 PriorityClass 의 값이 0 을 넘으면 도입 전의 모든 파드가 선점 대상이 된다. 멀티 테넌시 클러스터라면 사용자가 PriorityClass 를 마음대로 배포하지 못하게 권한을 좁히고, ResourceQuota 나 OPA Gatekeeper 로 쓸 수 있는 PriorityClass 를 세밀하게 통제해야 한다.

출처

관련 사례

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

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

kubegap 열기

AI 도구와 스크립트용

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