Kubenetes 배포시 5xx 이슈에 대한 해결책

쿠버네티스를 사용하여 어플리케이션을 배포 할때 5xx 에러를 만날때가 있다. 제일 처음으로 확인해볼건 probe 설정이다.

 

livenessProbe

컨테이너가 동작 중인지 여부를 나타낸다. 만약 활성 프로브(liveness probe)에 실패한다면, kubelet은 컨테이너를 죽이고,
해당 컨테이너는 재시작 정책 의 대상이 된다.

만약 컨테이너가 활성 프로브를 제공하지 않는 경우, 기본 상태는 Success 이다.

 

readnessProbe

컨테이너가 요청을 처리할 준비가 되었는지 여부를 나타낸다. 만약 준비성 프로브(readiness probe)가 실패한다면, 엔드포인트 컨트롤러는 파드에 연관된 모든 서비스들의 엔드포인트에서 파드의 IP주소를 제거한다. 준비성 프로브의 초기 지연 이전의 기본 상태는 Failure이다.

만약 컨테이너가 준비성 프로브를 지원하지 않는다면, 기본 상태는 Success이다.

 

startupProbe

서비스를 시작하는 데 오랜 시간이 걸리거나 불규칙적인 컨테이너에 설정하는 데 사용될 수 있다.(예를 들면 third party 에서 특정 데이터를 다운받는 등의 경우) startup probe가 성공하고 나서 liveness, readiness probe가 동작하기 때문에 기동시간이 불규칙적인 애플리케이션이 liveness probe에 의해 기동되기도 전에 재시작 되는 것을 방지할 수 있다.(Readiness probe랑 비슷하지만 방금 말한 부분은 Readiness probe로 해결하기 어렵다)

 

livenessProbe 와 readnessProbe 의 차이점

컨테이너의 상태 체크중에 livenessProbe 의 경우에는 컨테이너가 비정상적으로 작동이 불가능한 경우도 있지만,

Configuration을 로딩하거나, 많은 데이타를 로딩하거나, 외부 서비스를 호출하는 경우에는 일시적으로 서비스가 불가능한 상태가 될 수 있다

이런 경우에는 컨테이너를 재시작한다 하더라도 정상적으로 서비스가 불가능할 수 있다.

이런 경우에는 컨테이너를 일시적으로 서비스가 불가능한 상태로 마킹해주면 되는데, 이러한 기능을 readnessProbe 가 담당한다.

https://bcho.tistory.com/1264

쿠버네티스 #9 - HealthCheck

 

정상적으로 Probe 를 구성했음에도 배포시 5xx 에러가 발생할때

pod 가 생성될때 5xx 에러가 발생한다면 probe 설정이 잘못된건 없는지 확인한다.

AWS ALB(ingress) 를 사용하고 있다면 배포 과정에서 pod 와의 연결이 정상적으로 끊기지 전달 되었거나 또는 신규 Pod 들의 Ready 상태가 반영 되지않고 ALB Target group 에 대상이 등록된 경우가 많다.

이를 개선하기 위해선 preStop 실행 과정에서 sleep 을 사용하여 pod 의 애플리케이션이 정상적으로 기존연결을 끊는지 확인이 필요하다.

그리고 Pod 의 readniess 상태를 AWS Loadbalancer Controller 에서 TargetGroup 에 Pod IP 들을 등록하는 과정에서 Readniess probe 상태를 반영하며 작동할 수 있게 하는 Readniess gate 설정도 반드시 필요하다.

https://kubernetes-sigs.github.io/aws-load-balancer-controller/v2.1/deploy/pod_readiness_gate/

Pod Readiness Gate - AWS LoadBalancer Controller

 

다음으로 살펴볼건 Pod 의 application 의 keep alive 설정이 ALB 의 IDLE Timeout 보다 짧게 설정된건 아닌지 확인해볼것