분산 시스템의 경우 장애 처리가 핵심입니다. Kubernetes는 시스템 상태를 감시하고 중지 된 서비스를 다시 시작할 수있는 컨트롤러를 활용하여이를 지원합니다. 반면에 Kubernetes는 시스템의 정상적인 작동의 일부로 애플리케이션을 강제로 종료 할 수 있습니다.

이 "Kubernetes Best Practices"에피소드에서는 Kubernetes가 작업을보다 효율적으로 수행하고 애플리케이션의 다운 타임을 줄이는 데 어떻게 도움이되는지 살펴 보겠습니다.

프리 컨테이너 세계에서 대부분의 애플리케이션은 VM 또는 물리적 머신에서 실행되었습니다. 응용 프로그램이 충돌하면 대체 장치를 부팅하는 데 꽤 오랜 시간이 걸렸습니다. 응용 프로그램을 실행할 시스템이 하나 또는 두 대뿐이라면 이러한 종류의 복구 시간은 용납 할 수 없습니다.

대신 프로세스 수준 모니터링을 사용하여 애플리케이션이 충돌했을 때 다시 시작하는 것이 일반적이되었습니다. 애플리케이션이 충돌하면 모니터링 프로세스가 종료 코드를 캡처하고 즉시 애플리케이션을 다시 시작할 수 있습니다.

Kubernetes와 같은 시스템의 출현으로 Kubernetes는 충돌 된 애플리케이션 자체를 다시 시작하므로 프로세스 모니터링 시스템이 더 이상 필요하지 않습니다. Kubernetes는 이벤트 루프를 사용하여 컨테이너 및 노드와 같은 리소스가 정상인지 확인합니다. 이는 더 이상 이러한 모니터링 프로세스를 수동으로 실행할 필요가 없음을 의미합니다. 리소스가 상태 확인에 실패하면 Kubernetes는 자동으로 교체를 시작합니다.

서비스에 대한 사용자 정의 상태 확인을 설정하는 방법을 보려면이 에피소드를 확인하십시오 .

Kubernetes 종료 수명주기

Kubernetes는 애플리케이션의 충돌을 모니터링하는 것 이상을 수행합니다. 더 많은 애플리케이션 사본을 생성하여 여러 컴퓨터에서 실행하고, 애플리케이션을 업데이트하고, 애플리케이션의 여러 버전을 동시에 실행할 수도 있습니다!

이는 Kubernetes가 완벽하게 정상적인 컨테이너를 종료하는 데는 여러 가지 이유가 있음을 의미합니다. 롤링 업데이트로 배포를 업데이트하는 경우 Kubernetes는 새 포드를 회전하면서 이전 포드를 천천히 종료합니다. 노드를 드레 이닝하는 경우 Kubernetes는 해당 노드의 모든 포드를 종료합니다. 노드에 리소스가 부족한 경우 Kubernetes는 해당 리소스를 해제하기 위해 포드를 종료합니다 (리소스 에 대해 자세히 알아 보려면이 이전 게시물 확인 ).

최종 사용자에게 미치는 영향을 최소화하고 복구 시간 이 최대한 빨리 되도록 애플리케이션이 종료를 정상적으로 처리하는 것이 중요 합니다!

실제로 이는 애플리케이션이 SIGTERM 메시지 를 처리하고 수신시 종료를 시작 해야 함을 의미합니다 . 즉, 저장해야하는 모든 데이터를 저장하고, 네트워크 연결을 닫고, 남은 작업을 완료하고, 기타 유사한 작업을 수행합니다.

Kubernetes가 포드를 종료하기로 결정하면 일련의 이벤트가 발생합니다. Kubernetes 종료 수명주기의 각 단계를 살펴 보겠습니다.

1-포드가 "종료 중"상태로 설정되고 모든 서비스의 엔드 포인트 목록에서 제거됩니다.

이 시점에서 포드는 새로운 트래픽을 가져 오는 것을 중지합니다. 포드에서 실행중인 컨테이너는 영향을받지 않습니다.

2-preStop Hook이 실행됩니다.

preStop 후크는 포드의 컨테이너로 전송되는 특수 명령 또는 HTTP 요청입니다.

SIGTERM을 수신 할 때 애플리케이션이 정상적으로 종료되지 않으면이 후크를 사용하여 단계적 종료를 트리거 할 수 있습니다. 대부분의 프로그램은 SIGTERM을 수신 할 때 정상적으로 종료되지만 타사 코드를 사용하거나 제어 할 수없는 시스템을 관리하는 경우 preStop 후크는 응용 프로그램을 수정하지 않고 정상 종료를 트리거하는 좋은 방법입니다.

3-SIGTERM 신호가 포드로 전송됩니다.

이 시점에서 Kubernetes는 포드의 컨테이너에 SIGTERM 신호를 보냅니다. 이 신호를 통해 컨테이너는 곧 종료 될 것임을 알 수 있습니다.

코드는이 이벤트를 수신하고이 시점에서 완전히 종료되어야합니다. 여기에는 오래 지속되는 연결 (예 : 데이터베이스 연결 또는 WebSocket 스트림) 중지, 현재 상태 저장 또는 이와 유사한 것이 포함될 수 있습니다.

preStop 후크를 사용하는 경우에도 SIGTERM 신호를 보내면 애플리케이션에 어떤 일이 발생하는지 테스트하는 것이 중요하므로 프로덕션에서 놀라지 않습니다!

4-Kubernetes가 유예 기간을 기다립니다.

이 시점에서 Kubernetes는 종료 유예 기간이라는 지정된 시간 동안 대기합니다. 기본적으로 30 초입니다. 이것은 preStop 후크 및 SIGTERM 신호와 병렬로 발생한다는 점에 유의하는 것이 중요합니다. Kubernetes는 preStop 후크가 완료 될 때까지 기다리지 않습니다.

종료 GracePeriod가 완료되기 전에 앱이 종료되고 종료되면 Kubernetes는 즉시 다음 단계로 이동합니다.

포드가 일반적으로 종료되는 데 30 초 이상 걸리는 경우 유예 기간을 늘려야합니다. Pod YAML에서 terminateGracePeriodSeconds 옵션을 설정하여이를 수행 할 수 있습니다. 예를 들어 60 초로 변경하려면 :

5-SIGKILL 신호가 포드로 전송되고 포드가 제거됩니다.

컨테이너가 유예 기간 후에도 계속 실행 중이면 SIGKILL 신호가 전송되고 강제로 제거됩니다. 이 시점에서 모든 Kubernetes 객체도 정리됩니다.

결론

Kubernetes는 다양한 이유로 포드를 종료 할 수 있으며, 애플리케이션이 이러한 종료를 정상적으로 처리하는지 확인하는 것이 안정적인 시스템을 만들고 훌륭한 사용자 경험을 제공하는 핵심입니다.


  • No labels
Write a comment…