Readiness Probe
Overview
- 컨테이너가 요청을 처리할 준비가 되었는지 확인하는 역할
- 만약 readiness probe가 실패한다면, 엔드포인트 컨트롤러는 파드에 연관된 모든 서비스들의 엔드포인트에서 파드의 IP주소를 제거
- readiness probe의 기본 상태는 Failure인데, 만약 컨테이너가 준비성 프로브를 지원하지 않는다면, 기본 상태는 Success 이다.
필요한 이유
- replicas에 2로 정의되어 두개의 파드가 뜨는 서비스가 있다고 가정하며, 트래픽은 50% 씩 분배된다고 가정한다.
- 그중 하나의 노드에 문제가 생겨 파드가 축출 된다.
- replicas에 기술된대로 다른 노드에 새 파드가 생기게 된다.
- 이때 파드 및 컨테이너가 기동이 되었지만 컨테이너 내 실제로 동작하는 app은 기동중이라고 가정한다면, 해당 서비스에 접근하는 사용자는 절반의 확률로 에러페이지(404 not found 등)를 보게 될 것이다.
- 리소스 메타데이터(yaml)에 readiness probe를 기술해둔다면 app이 뜬 후에야 서비스와 연결이 되게 되므로 이를 방지할 수 있다.
Liveness Probe
Overview
- 컨테이너가 동작 중인지 확인하는 역할
- 만약 liveness probe가 실패한다면, kubelet은 컨테이너를 죽이고, 해당 컨테이너는 재시작 정책의 대상이 된다.
- 기본 상태는 Success 이다.
필요한 이유
- 위와 같이 2개의 파드가 있는 서비스라 가정한다.
- 파드에는 문제가 없지만 컨테이너가 동작 도중 장애가 생기는 경우 역시 해당 서비스에 접근하는 사용자는 50%의 확률로 에러페이지를 만나게 된다.
- liveness probe를 통해 장애가 발견된 파드는 재시작을 하여 장애를 복구한다.
속성
- 두 probe는 속성이 동일하다.
- 필수 속성: 적어도 하나는 필수로 정의해야한다.
- httpGet: port, host, path, httpHeader, scheme 를 체크한다.
- exec: 특정 명령어를 날려서 결과를 체크한다.
- tcpSocket: port, host 를 체크한다
- 추가 속성
- initialDelaySeconds:
- 컨테이너 상태가 running이 될 때, 프로브가 시작되기 전에 delay 시간.
- default: 0초
- 최소값은 0초
- periodSeconds:
- 프로브를 수행하는 빈도.
- default: 10초
- 최소값: 1초
- timeoutSeconds:
- 프로브가 수행된 후 결과를 리턴받아야 하는 시간.
- default: 1초
- 최소값: 1초
- successThreshold:
- 프로브가 성공한 것으로 간주되기 위한 최소 연속 성공횟수.
- default: 1
- 최소값: 1
- failureThreshold:
- 프로브가 실패로 간주하기 전까지 시도하는 횟수.
- default: 3
- 최소값: 1
예시
readinessProbe:
exec:
command:
- cat
- /tmp/healthy
initialDelaySeconds: 5
periodSeconds: 5
- 컨테이너가 구동되면 커맨드로 /tmp/healty 파일을 조회하는 명령어를 수행한다.
- 최초 5초를 기다렸다 실행을하며 5초마다 시도하여 총 3회 시도를하고 그 안에 해당파일을 조회할 수 없으면 readineess probe는 실패로 인식하게 된다.
- 최초 파드가 만들어지고 이미지를 pull 받아 컨테이너를 기동시면서 파드와 컨테이너의 상태는 Running이 되지만 프로브가 성공하기 전까지 pod의 container ready와 ready 속성은 false 상태이다.
- 이 상태가 지속되어 실패를 하게될 경우, 서비스의 endpoint는 NotReadyAddr이란 상태로 변경되며 서비스를 하지 않는다.
- 실패로 정의되기 전에 성공할 경우, container ready와 ready 속성은 true가 되며, endpoint도 연결되어 서비스가 연결된다.
