Kubernetes의 여러 Probe들

hyeongjun Jo·2024년 4월 14일

데브옵스 쿠버네티스

DevOps

목록 보기

9/11

이 글을 쓰게 된 계기

저희 DevOps팀에 하나의 문의사항이 왔습니다.

"원래 새 버전 파드가 정상이어야 전 버전의 파드가 삭제되는 것 아닌가요? 새로운 버전의 파드가 비정상인데 이전 버전의 파드가 지워져서 서버가 내려갔습니다."

그래서 저는 probe를 둬야 할 것 같다고 답변했으나 정확히 어떤 probe를 둬야할지 바로 떠오르지 않았습니다. 그래서 이번 기회에 probe에 대해 공부하고 확실히 내 것으로 만들자는 생각이 들었습니다.

Pod의 상태

Ready와 Running은 kubectl get 명령어를 치면 쉽게 볼 수 있습니다.

혹시 Pod의 Ready상태와 Running상태의 차이점을 알고계신가요? Ready 다음이 Running이라고 생각하시는 분은 없으시겠죠?

일단 Ready와 Running은 같은 범주에 있는 상태값은 아닙니다.

Ready

Ready에 해당하는 범주는 파드의 컨디션(상태)입니다.

각 컨디션의 자세한 정보는 파드의 컨디션에서 확인 가능합니다.

컨디션을 결정하는 방법은 kubelet이 직접 검사해야 합니다. 이는 아래의 container probe에서 자세히 다루겠습니다.

Running

Running은 파드의 단계를 나타내는 값입니다. 파드의 라이프사이클 중에서 어디 쯤에 있느냐를 나타내는 값이죠

각 단계의 정확한 정보는 파드의 단계(phase)에서 확인 가능합니다.

Ready 와 Running

Ready 상태가 나타내는 정보는 조건을 검사하여 파드가 사용할 수 있는지입니다.

Running 단계가 나타내는 정보는 컨테이너를 실행했다는 것만 담고 있습니다.

위의 정보로 미루어보아 Running 단계이지만 Ready 상태가 아니면 파드(정확히는 컨테이너)가 정상이 아니라는 말이겠죠.

Container Probe

Ready가 되려면 어떤 검사를 해야할까?

자 이제 Probe 얘기를 해봅시다. 위에서 Ready 상태가 되려면 필요한게 kubelet에 의한 검사라했는데 여기서 말하는 검사가 Container Probe 입니다. Container Probe에 설정된 값에 따라 kubelet은 주기적으로 진단을 수행합니다.

Probe의 종류

kubelet은 실행 중인 컨테이너들에 대해 선택적으로 세 가지 종류의 프로브를 수행하고 그에 반응할 수 있습니다.

LivenessProbe(활성 프로브)
- 컨테이너가 살아있는지를 나타냅니다.
- 만약 활성 프로브가 실패하면 kubelet은 해당 컨테이너를 재시작정책에 맞게 재시작합니다.
ReadinessProbe(준비성 프로브)
- 컨테이너가 요청을 처리할 준비가 됐는지를 나타냅니다.
- 만약 준비성 프로브가 실패하면 파드에 연관된 모든 서비스들의 엔드포인트에서 파드를 제외합니다.
StartupProbe(스타트업 프로브)
- 컨테이너 내의 애플리케이션이 시작되었는지를 나타냅니다.
- 스타트업 프로브가 주어진 경우엔 성공할 때 까지 다른 프로브들은 활성화되지 않습니다.
- 이외에는 활성 프로브와 동일합니다.

Probe의 옵션

예시와 주석으로 살펴봅시다

	livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
      initialDelaySeconds: 30 # 첫 번째 프로브를 실행하기 전에 주는 Delay (default 0)
      periodSeconds: 10 # kubelet이 얼마나 자주 진단을 할 지 나타냄 (default 10)
	  failureThreshold: 3 # 연속으로 몇 번 실패 시 실패인지 (default 3)
      successThreshold: 1 # 연속으로 몇 번 성공 시 성공인지 (default 1)

자세한 내용은 Configure Probe에서 확인 가능합니다.

결론

세 가지 Probe들의 기본값 (설정하지 않았을 때의 값)은 Success입니다. 즉 Probe를 설정하지 않으면 검사하지않고 Ready 상태를 나타내며 정상적이지 않은 파드로 교체될 수 있다는 뜻입니다. 결국 처음 문의받은 정상적이지 않은 파드로 교체된 이유는 Probe를 설정하지 않아서라고 할 수 있고 설정해야하는 Probe는 ReadinessProbe입니다.

그 이유는 업데이트한 새 버전의 파드에 LivenessProbe나 StartupProbe가 설정되어 있었다면 이전 버전의 파드는 교체되고 새 파드의 Probe가 실패한 이후 계속 파드가 재시작되었을 것이기 때문입니다. ReadinessProbe를 줌으로써 Deployment의 ReaplicaSet이 파드가 Ready 상태가 되지 않은 것을 확인하고 새 파드로 교체하지 않을 것입니다.