IL-0062 Ravelin · 2019-07-26 (게시일)kubernetesgcpnetworking

GKE Ingress 뒤의 파드가 SIGTERM 을 받자마자 새 연결을 받지 않고 정상 종료해서 API 에 가끔 502 오류가 났다

Ravelin 은 GKE 의 쿠버네티스로 옮기는 작업의 마지막 단계로 API 계층을 기존 VM 에서 클러스터로 옮기고, 외부에서 API 에 접근할 수 있도록 Ingress 를 설정했다. 설정은 순조로웠지만 통합 테스트가 가끔 502 오류를 받았다. 글쓴이 Phil Pearl 은 원인을 찾아간 과정은 건너뛰고 결론만 정리했다.

흔히 파드 제거는 이런 순서로 일어난다고 생각한다. 레플리케이션 컨트롤러가 파드를 지우기로 하고, 파드의 엔드포인트가 서비스나 로드 밸런서에서 빠져 새 트래픽이 끊긴다. 그다음 파드가 preStop 훅이나 SIGTERM 을 받아 새 연결을 받지 않고, 기존 연결이 모두 끝나면 종료한다. 실제로는 엔드포인트 제거와 SIGTERM 이 순서 없이 동시에 일어난다. 일반 서비스는 엔드포인트가 아주 빨리 빠져 문제가 드러나지 않지만, Ingress 는 반응이 꽤 느려서 파드가 SIGTERM 을 받고 한참 뒤에야 엔드포인트 변경이 반영될 수 있다. 그동안 파드가 새 연결을 처리하지 않으면 클라이언트는 오류를 받는다.

글쓴이는 쿠버네티스에서는 흔히 배운 방식의 정상 종료를 하지 말라고 권한다. 파드는 SIGTERM 을 거의 무시하고 계속 새 연결을 처리해야 한다. 가능하면 클라이언트에게 다른 곳으로 연결을 옮기라고 알리고, HTTP 라면 응답 헤더에 "Connection": "close" 를 넣을 수 있다. 파드는 종료 유예 시간이 끝나 SIGKILL 을 받을 때 비로소 종료하고, 유예 시간은 로드 밸런서에 변경이 반영되는 시간보다 길게 잡는다. 동작을 바꿀 수 없는 외부 코드라면 유예 시간만큼 잠드는 preStop 훅을 넣어 파드가 아무 일 없다는 듯 계속 요청을 처리하게 한다. 글은 Ravelin 이 실제로 무엇을 바꿨는지는 적지 않았다.

심각도

–

영향 범위

occasional 502 errors on the API behind the GKE Ingress, seen in integration tests

영향 사용자

–

지역

–

감지까지

–

복구까지

–