2017-04-12 11 views
0

저는 minikube (kubernetes) 개발 환경의 도커 컨테이너에 호스트 된 범용 반응 앱을 보유하고 있습니다. 나는 virtualbox를 사용하고 실제로이 VM에 더 많은 마이크로 서비스를 가지고있다.왜 로컬에서 작동하는 서비스가 도커에서 신호를 자주 죽이게됩니까?

이 반응 앱에서는 서버 코드 변경시 pm2을 사용하여 앱을 다시 시작하고 클라이언트 코드 변경시 클라이언트 코드를 새로 고치려면 webpack hmr을 사용합니다.

1530 초마다 pm2이 (가) SIGKILL으로 앱이 종료되었음을 나타내는 아래 메시지를 나에게 로깅합니다.

App [development] with id [0] and pid [299], exited with code [0] via signal [SIGKILL] 

나는 왜 그런 일이 일어나고 있는지 알지 못합니다. 비교적 빈번하지만 빈번하지 않아 매 초마다 발생합니다. 그럴 때마다 webpack 번들을 다시 컴파일해야하기 때문에 매우 짜증나기도합니다.

pm2이 이러한 유형의 개발 환경에서 SIGKILL을 수신하는 데는 어떤 이유가 있을까요? 또한 이것을 디버깅 할 수있는 방법은 무엇입니까?

pm2를 사용하여 서버 변경시 다시 시작하는 서비스가 단지 백엔드 서비스 일 때이 문제가 발생하지 않는 것으로 나타났습니다. 나는. webpack이없는 경우 또한, 나는 애플 리케이션의 내 찌르다 버전에서 이러한 SIGKILL 문제가 표시되지 않습니다. Webpack hmr setup, pm2 및 minikube/docker의 조합에 문제가 있음을 나에게 알립니다.

로컬에서 (docker/minikube가 아닌) 응용 프로그램을 사용해 보았지만 sigkills가 없어도 정상적으로 작동하므로 자체적으로 webpack hmr을 수행 할 수 없습니다. kubernetes는 많은 메모리를 사용하는 서비스를 중단합니까? (아마 내 애플 리케이션이 많은 메모리를 사용하고 있다고 생각한다). 그런 경우가 아니라면 kubernetes 또는 docker가 SIGKILL을 보내는 이유는 무엇입니까? 어떤 방법으로 이것을 디버깅 할 수 있습니까?

모든 안내를 크게 듣습니다. 고마워요

+0

포드가 실행중인 네임 스페이스에서'kubectl get events'의 결과는 무엇입니까? 상대적으로 빈번하다면'kubectl get events --watch'를 실행하는 것이 가치가 있습니다. – jaxxstorm

답변

1

당신이 게시 한 오류 메시지에서 알 수는 없지만 일반적으로 커널 OOM Killer (Out of Memory Killer)가 프로세스를 실행 한 결과입니다. 프로세스가 지나치게 많은 메모리를 사용하고 있거나 컨테이너에 cgroup 설정이있어 과도하게 공격적이어서 해당 프로세스가 종료 될 수 있습니다. VirtualBox 인스턴스에 대한 메모리 할당량이 부족할 수도 있습니다.

는 일반적으로 당신은 도커는 컨테이너가 커널의 OOM 킬러 출력을 표시 할 수 있습니다 docker ps -a

dmesg 또는 문제의 노드에서 당신의 syslog 코드 137로 종료 것을보고 확인할 수 있습니다.

+0

당신이 자리를 잡았습니다. dmesg를 사용하여 나는 프로세스를 죽인 범인 이었다는 것을 알 수있었습니다. 이제 내가 직감을 가지고있는 OOM을 일으키는 것을 디버깅합니다. 당신의 제안을 위해 타이! –