프로브 및 로드 밸런서 상태 확인 구성

Kubernetes는 로드 밸런서 상태 확인 외에도 애플리케이션 상태 확인을 수행하는 여러 가지 방법을 제공합니다. 다음 Kubernetes 내장 프로브를 로드 밸런서 상태 확인과 함께 포드의 컨텍스트에서 명령으로 실행하거나 kubelet 또는 호스트 IP 주소에 대한 HTTP/TCP 프로브로 실행할 수 있습니다.

Liveness 프로브와 준비 프로브는 서로 다르고 독립적이어야 합니다(또는 최소한 다른 제한 시간 값을 가져야 함). 애플리케이션에 일시적인 문제가 있는 경우 문제가 해결될 때까지 준비 프로브는 포드를 준비되지 않음으로 표시합니다. livenss 프로브 설정이 올바르지 않으면 liveness 프로브가 포드를 종료할 수 있습니다.

시작 프로브

시작 프로브를 사용하여 초기화 주기가 긴 애플리케이션을 보호합니다. 시작 프로브가 성공할 때까지 다른 프로브는 비활성화됩니다.

Kubernetes가 애플리케이션 시작을 기다려야 하는 최대 시간을 정의할 수 있습니다. 최대 구성 시간 후에도 포드가 여전히 시작 프로브에 실패하면 애플리케이션이 종료되고 새 포드가 생성됩니다.

애플리케이션의 시작 시간을 예측할 수 없는 경우 시작 프로브를 사용합니다. 애플리케이션을 시작하는 데 10초가 필요하다는 것을 알고 있는 경우 라이브니스 프로브 또는 준비 프로브를 initialDelaySeconds 대신와 함께 사용합니다.

Liveness 프로브

라이브니스 프로브를 사용하여 애플리케이션 문제 또는 프로세스가 문제 없이 실행 중인지 여부를 감지합니다. 라이브니스 프로브는 프로세스가 계속 실행되지만 애플리케이션이 응답하지 않는 교착 상태를 감지할 수 있습니다. 라이브니스 프로브를 사용하는 경우 다음을 수행합니다.

• initialDelaySeconds를 사용하여 첫 번째 프로브를 지연합니다.

• 라이브니스 및 준비 프로브에 대해 동일한 사양을 설정하지 마십시오.

• 포드 외부의 요인(예: 데이터베이스)에 의존하도록 Liveness 프로브를 구성하지 마십시오.

• 특정에 대한 라이브니스 프로브를 설정합니다terminationGracePeriodSeconds. 자세한 내용은 Kubernetes 설명서를 참조하세요.

준비 프로브

준비 프로브를 사용하여 다음을 감지합니다.

• 애플리케이션이 트래픽을 수락할 준비가 되었는지 여부

• 부분 가용성 - 애플리케이션을 일시적으로 사용할 수 없지만 특정 작업이 완료된 후 다시 정상일 것으로 예상됨

준비 프로브는 애플리케이션이 트래픽을 처리할 수 있도록 애플리케이션 구성 및 종속성이 문제나 오류 없이 실행되도록 하는 데 도움이 됩니다. 그러나 잘못 구성된 준비 프로브는 이를 방지하는 대신 중단을 일으킬 수 있습니다. 데이터베이스 연결과 같은 외부 요인에 의존하는 준비 프로브로 인해 모든 포드가 프로브에 실패할 수 있습니다. 이러한 장애로 인해 중단이 발생할 수 있으며, 이로 인해 백엔드 서비스에서 장애가 발생한 포드를 사용한 다른 서비스로 계단식 장애가 발생할 수 있습니다.

수신 리소스 및 로드 밸런서 상태 확인

Application Load Balancer 및 Kubernetes는 상태 확인 기능을 ingress 제공합니다. Application Load Balancer 상태 확인의 경우 대상 포트와 경로를 지정합니다.

참고: Kubernetes의 경우 등록 취소 지연 시간이 ingress있습니다. Application Load Balancer의 기본값은 300초입니다. 준비 프로브에 사용한 것과 동일한 값을 사용하여 수신 리소스 또는 로드 밸런서 상태 확인을 설정하는 것이 좋습니다. 

NGINX는 상태 확인도 제공합니다. 자세한 내용은 NGINX 설명서를 참조하세요.

Istio 수신 및 송신 게이트웨이에는 NGINX의 HTTP 상태 확인과 유사한 상태 확인 메커니즘이 없습니다. 그러나 Istio 회로 차단기 또는 DestinationRule 이상치 감지를 사용하여 유사한 기능을 달성할 수 있습니다.

자세한 내용은 EKS 모범 사례 - 로드 밸런싱(가용성 및 포드 수명 주기)을 참조하세요.