Probe
프로브 종류
kubelet은 실행 중인 컨테이너들에 대해서 선택적으로 세 가지 종류의 프로브를 수행하고 그에 반응할 수 있다.
livenessProbe
컨테이너가 동작 중인지 여부를 나타낸다. 만약 활성 프로브(liveness probe)에 실패한다면, kubelet은 컨테이너를 죽이고, 해당 컨테이너는 재시작 정책의 대상이 된다. 만약 컨테이너가 활성 프로브를 제공하지 않는 경우, 기본 상태는 Success 이다.
readinessProbe
컨테이너가 요청을 처리할 준비가 되었는지 여부를 나타낸다. 만약 준비성 프로브(readiness probe)가 실패한다면, 엔드포인트 컨트롤러는 파드에 연관된 모든 서비스들의 엔드포인트에서 파드의 IP주소를 제거한다. 준비성 프로브의 초기 지연 이전의 기본 상태는 Failure 이다. 만약 컨테이너가 준비성 프로브를 지원하지 않는다면, 기본 상태는 Success 이다.
startupProbe
컨테이너 내의 애플리케이션이 시작되었는지를 나타낸다. 스타트업 프로브(startup probe)가 주어진 경우, 성공할 때까지 다른 나머지 프로브는 활성화되지 않는다. 만약 스타트업 프로브가 실패하면, kubelet이 컨테이너를 죽이고, 컨테이너는 재시작 정책에 따라 처리된다. 컨테이너에 스타트업 프로브가 없는 경우, 기본 상태는 Success 이다.
Pod를 생성하면 내부에 컨테이너가 생긴다.
예시
서비스의 연결되면 서비스의 ip가 외부에 알려지면서 사용자들이 실시간으로 접근 가능해진다.
하나의 서비스에 두 개의 Pod가 연결되어 있다고 가정했을 때 각 50%씩 트래픽을 분담한다고 가정한다.
만약에, Node 2 서버가 다운되었을 시 Node 1 서버에서 100%의 트래픽을 부담한다.
다운된 Pod 2는 오토힐링 기능으로 Node 3 서버로 간다고 하였을 시 아직 App이 부팅중일 수 있다.
그렇다면 사용자는 에러를 직면할 수 있다.
하지만 readinessProbe를 사용한다면 이런 에러 문제를 해결할 수 있어진다.(부팅 전까지 사용자에게 연결 X)
다른 상황을 가정해 보자.
메모리 오버플로우 때문에 Pod 2의 App이 다운됐다고 하였을 시 사용자는 에러를 직면한다.
이때 livenessProbe를 사용한다면 이러한 에러발생 시 재부팅시킨다.
따라서 정리를 해보자면
- readinessProbe는 App 구동 시 트래픽 실패 문제 해결
- livenessProbe는 App 장애 시 트래픽 실패 문제 해결
Probes 설정
- initialDelaySeconds: 컨테이너가 시작된 후 시작, 활성 또는 준비 상태 시도가 시작되기 전까지의 시간(초)
-기본값은 0초. 최솟값은 0. - periodSeconds: 프로브를 체크하는 시간의 간격. 기본 값은 10초
- timeoutSeconds: 지정된 시간까지 결과가 와야 함. 기본 값은 1초
- successThreshold: 몇 번 결과를 받아야 진짜 성공일지. 기본 값은 1회
- failureThreshold: 몇번 실패를 받아야 진짜 실패일지. 기본 값은 3회
HTTP probes
- host: 기본 값은 pod의 IP
- port: 포트 번호 Ex) localhost:8080 일시 host는 localhost, port는 8080
- scheme: (HTTP or HTTPS). 기본 값은 HTTP.
- path: http 서버의 접근 가능한 경로 기본값은 /.
- httpHeaders: Ex) language:ko