일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- Heap
- xms
- Probe
- startup probe
- readiness probe
- properties
- Xmx
- OOM
- 티스토리챌린지
- k8s
- JVM
- Java Virtual Machine
- property
- Kubernetes
- liveness probe
- 오블완
- configmap
- spring boot
- java
- application properties
- Today
- Total
여우발개발
K8S의 Probe (Startup Probe, Readiness probe, Liveness probe) 본문
영단어 “Probe”
무엇이든 본 단어를 아는 것이 중요하다. K8S의 Probe를 알기 전에, 영단어 Probe를 먼저 이해해 보자. Probe는 한국말로 조사, 탐침, 시험, 규명 등의 뜻을 가지고 있군!
K8S의 “Probe”
영단어 probe가 조사, 규명 등의 뜻을 가지고 있다는 것을 알았다. 그렇다면 K8S의 probe는 어떤 의미를 가지고 있을까?
K8S의 probe 는 kubelet에 의해서 주기적으로 수행되는 컨테이너에 대한 진단이다.
Probe 종류
- livenessProbe
- 컨테이너가 동작 중인지 체크
- 실패 시, kubelet이 컨테이너를 죽임. restartPolicy에 의해 재시작됨
- readinessProbe
- 컨테이너가 요청을 받을 수 있는지 체크
- 실패 시, 엔드포인트에서 ip 주소 제거 (서비스 엔드포인트에 추가되지 않음)
- startupProbe
- 컨테이너가 시작되었는지 체크
- startup probe가 주어진 경우 성공 전까지 liveness/readinessProbe가 활성화되지 않음
- 실패 시, kubelet이 컨테이너를 죽임. restartPolicy 에 의해 재시작됨
각 Probe 별 사용 용법
livenessProbe
livenessProbe가 반드시 필요한 것은 아니지만, 어플리케이션 실행 중 데드락 등의 이슈가 발생한다면 재시작이 좋은 방안이 될 수 있다.
잘 못 설정하면 무한 재시작 되기 때문에, 가급적 신중히 고민하고 사용하자.
readinessProbe
어떠한 검증이 완료된 이후에만 파드에 트래픽 전송을 하려고 할 때 사용할 수 있다.
application이 backdend 서비스가 돌아가야지만 의미가 있다면, 이때 사용하는 것이 바람직하다.
예를 들어서 컨테이너는 잘 떴지만, 컨테이너 내의 spring boot 서버가 제대로 실행되어야지 애플리케이션이 잘 동작한다고 말할 수 있을 때 spring boot에 대한 검증을 readinessProbe로 사용할 수 있을 것이다.
이를 이용해서 오류를 리턴하는 컨테이너로 트래픽이 가는 것을 막을 수 있다.
backend 서버라면 컨테이너가 최초 실행될 때 서버가 미처 다 뜨지 못한 컨테이너를 서비스하지 않기 위해서라도 꼭 설정하자.
startupProbe
컨테이너 시동 시 대량 데이터 로딩, 마이그레이션 등 작업을 수행해 오랜 시간이 걸린다면, 이 probe를 사용하는 것이 바람직하다. 시작시에만 수행된다는 점을 기억하자. 그리고 startupProbe 체크 중에는 livenessProbe, readinessProbe는 활성화되지 않는다.
나의 사용 경험
최초에 Probe들에 대한 spec을 잘 모르는 상태로 기본 세팅 (당시 liveness/readiness Probe가 동일한 설정값으로 설정되어 있었다)을 그대로 사용했으나, 이를 그대로 썼던 다른 팀 서버가 무한 재시작 상태에 빠지게 되어 (이왜진ㅋㅋㅋㅠㅠ) livenessProbe 설정이 빠지게 되었다.
위 설정 가이드 문서에서도 ‘livenessProbe의 일반적인 패턴은 readinessProbe와 동일한 저비용 HTTP 엔드포인트를 사용하지만 더 높은 실패 임계값을 사용하는 것입니다.’ 라고 안내하고 있다. 이렇게 설정하게 되면 pod가 kill 되기 전 서비스에서는 빠지기 때문에 이슈가 되지 않을 수 있다. 재시작을 해서 해결이 쉬운 문제라면 적용해 볼 법하다. (아직 그런 케이스를 잘 생각하진 못하겠다. 메모리 릭?)
startupProbe는 사용해 본 적이 없긴 한데, spec처럼 ‘시작 시에만 한번 수행된다’에 초점을 맞춰서 사전 작업이 필요한 경우에 사용할 수 있을 것 같다. 항시 동일한 서비스를 제공하는 우리 서비스에서는 크게 쓸 일이 없어 보이긴 함.