Oh My Algorithm
Concept Guide빼기 vs 재시작

프로브 (Liveness · Readiness)

컨테이너가 떠 있다는 것과 요청을 받을 수 있다는 것은 다릅니다. kubelet 은 주기적으로 컨테이너에 물어보고, 같은 응답 없음에 두 가지로 답합니다. readiness 가 실패하면 서비스 엔드포인트에서 빼기만 하고, liveness 가 실패하면 컨테이너를 죽여 다시 띄웁니다. 어느 쪽을 걸었는지가 장애 때 트래픽만 끊길지 프로세스가 재시작될지를 가릅니다.

01프로브 (Liveness · Readiness)

readiness 실패 · 트래픽에서 빼기만 한다

파드 셋이 서비스 뒤에 있습니다. kubelet 이 10초마다 각 파드에 물어보고, 잘 답한 파드만 엔드포인트에 들어갑니다.

두 번째 파드가 무거운 작업을 떠안아 검사에 늦게 답합니다. 한 번 놓쳤다고 곧바로 빼지는 않습니다.

세 번 연속 실패하자 Ready 가 내려갑니다. 컨테이너는 죽지 않고 그대로 돌고 있습니다.

새 요청은 남은 둘에게만 갑니다. 빠진 파드는 죽지 않았으므로 하던 작업을 마칠 시간을 법니다.

작업이 끝나 검사에 다시 제대로 답합니다. 돌아오는 데는 한 번의 성공이면 충분합니다.

대가도 있습니다. 검사를 민감하게 잡으면 부하가 몰릴 때 멀쩡한 파드가 줄줄이 빠지고, 남은 파드가 그 몫까지 받다 함께 빠집니다.

Servicekubeletweb-1Runningweb-2Runningweb-3Running
1 / 6

liveness 실패 · 컨테이너를 끝낸다

같은 파드에 liveness 도 걸 수 있습니다. 이 검사가 묻는 것은 요청을 받을 수 있느냐가 아니라 살아 있느냐입니다.

두 번째 파드의 앱이 교착에 빠졌습니다. 프로세스는 떠 있어 저절로 되살아나지 않고, 밖에서 보면 응답만 없습니다.

세 번 연속 실패하자 kubelet 이 컨테이너를 죽입니다. 여기서 갈립니다 — readiness 는 빼기만 했고 liveness 는 끝냅니다.

같은 파드 안에서 컨테이너가 다시 뜹니다. 파드 이름과 IP 는 그대로고 재시작 횟수만 올라갑니다.

기동이 느린 앱에는 이것이 덫이 됩니다. 다 뜨기도 전에 검사가 실패해 또 죽고, 그래서 영원히 뜨지 못합니다.

startupProbe 를 두면 기동이 끝날 때까지 나머지 검사를 미룹니다. 느린 기동과 진짜 멈춤을 가르는 것이 이 프로브입니다.

원인이 그대로면 재시작이 되풀이됩니다. 다시 띄우는 간격이 배로 늘어(최대 5분) CrashLoopBackOff 로 멈춰 섭니다.

Servicekubeletweb-1Runningweb-2Runningweb-3Running
1 / 7

정리

두 프로브는 같은 응답 없음에 다르게 답합니다. readiness 는 트래픽에서 빼고 liveness 는 컨테이너를 끝냅니다. 무엇을 걸지 잘못 고르면 느린 앱이 영원히 다시 뜹니다.

직접 해보기

web-2 를 고장낸 뒤, 걸어 둔 프로브를 바꿔 가며 같은 고장을 되풀이해 보세요. 빠지기만 하는지 재시작하는지가 갈립니다.

엔드포인트에 있는 파드3 / 3
web-1Ready
web-2Ready
web-3Ready

걸어 둔 프로브 readiness · 셋 다 잘 답하고 있습니다 · web-2 를 고장내 보세요

02 쉽게 이해하기

For Everyone
🔑핵심 동작

readiness 는 트래픽에서 빼기만 하고 liveness 는 컨테이너를 죽여 다시 띄웁니다. 같은 응답 없음에 처분이 갈리므로, 무엇을 걸지 잘못 고르면 회복이 안 되거나 멀쩡한 파드가 재시작합니다.

💡쉽게 말하면

readiness 가 실패하면 엔드포인트 컨트롤러가 그 파드의 주소를 서비스 엔드포인트에서 뺍니다.

컨테이너는 죽지 않고 계속 돌므로 하던 작업이 남아 있고, 회복하면 주소가 다시 들어옵니다.

liveness 가 실패하면 kubelet 이 컨테이너를 죽이고 restartPolicy 에 따라 다시 띄웁니다 — 교착처럼 프로세스는 떠 있는데 일을 못 하는 상태를 밖에서 끊어 주는 장치입니다.

판정은 한 번으로 나지 않습니다.

periodSeconds(기본 10초)마다 검사해 failureThreshold(기본 3)번 연속 실패해야 상태가 바뀌고, 돌아오는 데는 한 번의 성공이면 됩니다.

검사 방식은 httpGet·tcpSocket·exec·grpc 네 가지입니다.

기동이 느린 앱에 liveness 를 그대로 걸면 뜨는 도중에 죽는 일이 되풀이되므로, startupProbe 가 성공할 때까지 나머지 검사를 미룹니다.

재시작이 반복되면 간격이 배로 늘어(최대 5분) CrashLoopBackOff 로 멈춰 섭니다.

대가도 분명합니다 — 검사를 민감하게 잡으면 부하가 몰릴 때 멀쩡한 파드가 줄줄이 빠져 남은 파드에 부하가 더 쏠리고, liveness 가 의존 서비스까지 확인하면 남의 장애로 내 컨테이너가 재시작합니다.

📍어디에 쓰나
  • readiness 와 liveness 중 무엇을 걸지 판단
  • 기동이 느린 앱에 startupProbe 적용
  • CrashLoopBackOff 의 원인 좁히기
  • 롤링 업데이트가 준비됨을 판정하는 기준 이해

03 자주 묻는 질문

FAQ
프로브 (Liveness · Readiness)란 무엇인가요?+

컨테이너가 떠 있다는 것과 요청을 받을 수 있다는 것은 다릅니다. kubelet 은 주기적으로 컨테이너에 물어보고, 같은 응답 없음에 두 가지로 답합니다. readiness 가 실패하면 서비스 엔드포인트에서 빼기만 하고, liveness 가 실패하면 컨테이너를 죽여 다시 띄웁니다. 어느 쪽을 걸었는지가 장애 때 트래픽만 끊길지 프로세스가 재시작될지를 가릅니다.

프로브 (Liveness · Readiness)은(는) 어디에 사용하나요?+

readiness 와 liveness 중 무엇을 걸지 판단, 기동이 느린 앱에 startupProbe 적용, CrashLoopBackOff 의 원인 좁히기, 롤링 업데이트가 준비됨을 판정하는 기준 이해

프로브 (Liveness · Readiness)를 쉽게 비유하면?+

readiness 는 트래픽에서 빼기만 하고 liveness 는 컨테이너를 죽여 다시 띄웁니다. 같은 응답 없음에 처분이 갈리므로, 무엇을 걸지 잘못 고르면 회복이 안 되거나 멀쩡한 파드가 재시작합니다.