일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 | 31 |
- tomcat db connection
- scouter 설치
- LivenessProbe
- readinessprobe
- cka
- JNDI
- apache
- APM
- scouter 사용방법
- cka시험
- Probe
- 쿠버네티스
- jdbc
- Scouter
- dbcp
- 스카우터
- tomcat scouter
- cloud
- cka후기
- Tomcat
- Today
- Total
EDEN10 엔지니어 업무일지
livenessprobe, Readnessprobe 본문
probe : 컨테이너에서 kubelet에 의해 주기적으로 수행되는 진단.
LivenessProbe : 컨테이너 상태가 비정상이라고 판단하면, 해당 Pod를 재시작.
ReadnessProbe : 컨테이너 상태가 비정상이라고 판단하면, 해당 Pod를 사용할 수 없다고 판단하여 서비스에서 제외
Node2에 있는 Pod2가 Failed이 되면, Pod2는 다른 노드에서 실행 되려 노력한다. 이때, Pod2가 Node3에서 Running이 되고 Container도 Running 상태 이지만, App이 Booting 중일 경우, Service에 접속하는 유저들은 50%확률로 Pod1에 접속하면 서비스를 정상적으로 이용하겠으나 Pod2에 접속 시 Error 화면을 보게 될 것이다. 이를 방지하기 위하여 ReadinessProbe를 사용하며! 이는 App 구동 순간에 트래픽 실패를 없애 Pod1으로만 연결을 시켜주는 역할을 한다. 이후 App이 Running이 다 되었다면 Pod2는 Service와 다시 연결이 되며 트래픽을 Pod2로도 보내주는 역할을 한다. 갑자기 App에 문제가 발생하여 Down이 발생하는 경우가 생길 수 있는데 이를 위해 LivenessProbe를 이용한다. App 장애 시 Pod를 Restart 시켜줌으로써 일시적으로 서비스 장애 현상을 볼 순 있겠으나, 지속적인 트래픽 실패를 없애주는 역할을 해준다.
ReadnessProbe와 LivenessProbe는 사용 목적이 다를 뿐, 설정 방법은 같다.
httpGet, Exec, tcpSocket -> 셋 중 하나는 무조건 설정을 해줘야 한다.
위 세가지 외 부가적인 옵션은 아래와 같다.
initalDelaySeconds : 최초 Probe를 하기 전 딜레이 시간
peridSeconds : Probe를 체크하는 시간 간격
timeoutSeconds : 정해준 시간 안에 결과 값을 받아야 함
successThreshold : 몇 번 성공 결과를 받아야 정말 성공으로 인정 할건지
failureThreshold : 몇 번 실패를 받아야 정말 실패로 인정 할건지
위의 프로세스 대로 ReadinessProbe와 LivenessProbe가 진행된다.