intro

지난 포스트에 이어 k8s 노드 셧다운을 어떻게 우아하게(?) 처리할지에 대해 마저 이야기한다. 이미 얘기했듯 Spot Instance 를 노드로 사용하면 언제든지 노드 셧다운이 일어날 수 있다는 이유에서 시작하였다. 그런더 큰 부분을 간과하고 있었으니..

Spot Instance interruption notice

Spot Intance 의 경우 셧다운 발생 2분 전에 Spot Instance interruption 이벤트를 노드에 보낸다. 참고
이벤트를 수신한 노드가 이를 적절하게 처리한다면 Graceful 한 셧다운을 기대할 수 있는데 이를 위해선 각 노드에 AWS Node Termination Handler 가 설치되어 있어야 한다. 참고
다행인건, EKS managed node group 을 사용하는 경우엔 별도로 핸들러를 설치할 필요없이 이미 다 설정되어 있다!

어플리케이션 레벨에서의 고려사항

노드가 셧다운 2분 전에 이벤트를 수신하면 해당 노드의 각 어플리케이션에는 SIGTERM 이 전달된다. 이때 어플리케이션 레벨에서 SIGTERM 수신시 어떻게 처리할 것인지 구현되어 있어야 한다. 그렇지 않다면 어플리케이션은 바로 종료될 것이고 아직 처리 중인 요청이 남아있다면 해당 요청들은 모두 500 에러를 응답하게 된다.

Spring 어플리케이션과 같은 경우라면 아래와 같은 Property 설정으로 Graceful Shutdown 를 설정할 수 있다. 참고

server.shutdown=graceful

해당 설정이 적용되면 어플리케이션은 SIGTERM 수신시 신규 요청은 받지 않고 기존 요청은 처리 완료될 때까지 대기한다.
하지만 어플리케이션이 하루 종일 기다려줄 순 없다. Spot Instance interruption 의 경우라면 최대 2분 정도의 여유 시간을 갖게 될 것이다. 이를 적절히 판단하여 Pod 레벨에서 terminationGracePeriodSeconds 값을 알맞게 설정한다면 좀 더 안정적인 셧다운 처리를 기대할 수 있다.

outro

k8s 을 사용한다면 잦은 Pod/어플리케이션 종료는 항상 염두해 두어야 하는 부분이다. 본 포스트에서 다룬 Spot Instance interruption 경우 이 외에도 기본 배포인 롤링 업데이트 진행시에도 Pod/어플리케이션 종료가 발생된다.
불필요한 에러 발생을 방지하기 위해선 Pod 종료 또는 노드 셧다운의 경우를 최대한 예상하고 이를 대응하기 위한 적절한 처리 구현이 필요할 것이다.