K8S SIGTERM
Graceful Shutdown
대부분의 서버/엔진을 구현할 때, 무중단 배포시 혹은 임의 종료시에 정상적으로 종료되도록 하는 것이 좋다.
Graceful shutdown 은 프로그램이 종료될 때 최대한 Side effect 가 없도록 로직들을 잘 갈무리하고 종료하도록 하는 것을 뜻한다.
로직이 진행되고 있는 와중에 프로세스가 종료되어버리면 처리중인 데이터가 증발할 수도 있고, 어디까지 처리중에 멈추었는지 추적하기 힘들어지는 경우도 있다.
보통 SIGTERM 을 이용해서 구현한다. 아래는 graceful shutdown 을 위해 Go 에서 주로 사용하는 방법이다.
위와 같이 구현하면, SIGINT 와 SIGTERM 신호가 왔을때 바로 종료되는 것이 아니라 Catch 해서 이후 로직을 이어가겠다는 뜻이다.
최근 회사에서 EKS 환경에서 다음과 같은 상황이 있었다.
A 서버는 multi pod 로 동작하며, 일반적으로 3개의 pod가 항시 동작함.
이 때, 하나의 pod 에서만 특정 작업을 수행해야 하고, 해당 pod 가 종료되지 않는 한 다른 pod 는 그 작업을 시도하면 안됨.
이를 보장하기 위해 redis 의 SETNX 를 이용해 락을 집는 방식.
작업을 수행하는 서버는 SIGTERM 신호를 받으면 해당 락을 삭제하고
os.Exit(1)종료.
문제는 여기서 시작됐는데, pod 가 교체되면서 해당 작업을 수행하지 못하고 바로 종료되었다.
애초에 로그조차도 찍히지 않았기때문에, SIGKILL 을 받은것으로 보였다.
k8s 는 SIGTERM 을 보낸지 30초가 지나도 해당 컨테이너가 종료되지 않으면 SIGKILL을 보낸다.
서버가 SIGTERM 을 받지 못했다고 가정하고 디버깅을 시작했다.
왜 SIGTERM 을 못받았을까?
우선 아래 명령어를 이용해서 실행중인 pod 에서 상태를 체크해보기로 했다.
확인해보니 이상한 점이 보였다.
1번 프로세스가 /bin/sh ./run
1번 프로세스를 부모로 가지는 자식 프로세스 /bin/bash ./server
1번 프로세스의 손주(위의 자식 프로세스) ./server
./server 는 컴파일 후 나온 outfile (binary)
k8s 는 SIGTERM 을 1번 프로세스에 보낸다.
내 서버는 손주 프로세스가 되어있기 때문에 받지 못한 것이고, Dockerfile 을 확인해보니 회사의 모든 서버는 아래와 같이 실행되고 있었다.
run 이라는 스크립트를 CMD 를 이용해서 실행하기 때문에, 1번 프로세스가 /bin/sh 가 되는 것.
사실 해당 스크립트는 레거시에 가깝고 프로세스 실행 외에 역할이 아예 없었기 때문에 아래와 같이 바꾸고 실행해보았다.
위와 같이 ENTRYPOINT 로 실행하게 되면 1번 프로세스가 나의 서버가 되기 때문에, SIGTERM 을 받을 수 있게 된다.
사실 해결 방법으로 Helm chart 에서 preStop 등을 이용해 SIGTERM 을 전파할까도 싶었지만, 굳이 그럴 필요가 있나 싶어서 필자는 위와 같이 해결했다.
테스트 하고 싶다면 직접 배포를 다시 해봐도 되고 kubectl delete pod “…” 커맨드를 실행해서 로그를 살펴봐도 되고, deployment 를 수정하면서 테스트 하던가… 뭐 방법이야 많을 것 같다.
편한 방식대로 하자.
Last updated