오늘은 쿠버네티스의 Probe라는 개념에 대해 정리해보고자한다. 예전에 사내 dev 클러스터 구축 시 probe 라는 개념이 yaml에 적혀있어 이것이 무엇인지 궁금해서 찾아보았다.
Probe란?
Probe는 컨테이너에서 kubelet에 의해 주기적으로 수행되는 진단이다. 이 Probe를 통해 쿠버네티스는 각 컨테이너의 상태를 주기적으로 체크한 후, 문제가 있는 컨테이너를 자동으로 재시작하거나 또는 문제가 있는 컨테이너를 서비스에서 제외할 수 있다.
kubelet은 컨테이너의 상태를 진단하기 위해 핸들러를 호출하는데 핸들러는 수행하는 작업의 분류에 따라서 ExecAction, TCPSocketAction, HttpGetAction로 나뉜다.
Handler
컨테이너의 상태를 진단하기 위해 어떻게 진단할 것인지 명시한 것이 Handler이다.
- ExecAction
ExecAction은 컨테이너에서 지정된 명령어를 실행한다. 명령어를 실행했을 때 exit code가 0이면 성공, 이외의 값은 실패로 분류한다.
exec:
command:
- cat
- /etc/nginx/nginx.conf- TCPAction
TCPAction은 지정된 포트로 TCP 소켓 연결을 시도한다.
tcpSocket:
port: 8080
initialDelaySeconds: 15
periodSeconds: 20- HttpGetAction
지정된 포트와 url로 HTTP Get 요청을 전송하며, 응답 상태가 200 ~ 400 구간에 속하는 경우 성공, 이외에는 실패로 분류한다.
httpGet:
path: /healthz
port: liveness-portProbe의 종류
kubelet은 실행 중인 컨테이너에 대해 세 가지 종류의 프로브를 지정할 수 있다.
-
Liveness probe.
애플리케이션의 상태를 체크해서 서버가 제대로 응답하는지 혹은 컨테이너가 제대로 동작중인지를 검사한다. Pod은 정상적인 Running 상태이지만, 애플리케이션에 문제가 생겨서 접속이 안되는 경우를 감지한다. (메모리 오버플로우 등) 문제를 감지하면 Pod을 죽이고 재실행하여 애플리케이션의 문제를 해결한다. -
Readiness probe.
컨테이너가 요청을 처리할 준비가 되었는지 확인하는 probe이다. Pod이 새로 배포되고 Running 상태여도 처음에 로딩하는 시간이 있기 때문에 이 시간 동안은 애플리케이션에 접속하려고 하면 오류가 발생한다. Readiness probe는 어플리케이션이 구동되기 전까지 서비스와 연결되지 않게 해준다. (Readiness Probe가 실패할 때 엔드포인트 컨트롤러가 파드에 연관된 모든 서비스들의 엔드포인트에서 파드의 IP주소를 제거한다. ) Liveness Probe와 비교했을 때 어떤 차이가 있냐면, Liveness Probe는 probe 핸들러 조건 아래 fail이 나면 pod을 재실행 시키지만 Readiness Probe는 pod을 서비스로부터 제외시킨다.
- Startup probe.
컨테이너 내의 애플리케이션이 시작되었는지를 나타낸다. startup probe가 주어진 경우, 성공할 때 까지 다른 나머지 prob는 활성화 되지 않는다. 만약 startup probe가 실패하면, kubelet이 컨테이너를 죽이고, 컨테이너는 재시작 정책에 따라 처리된다.
각 probe를 언제 사용해야할까?
- Liveness Probe
사실 컨테이너 속 프로세스가 어떠한 이슈에 직면하거나 unhealty 상태가 되어(ex: out of memory) 프로세스가 중단된다면 원래는 kubelet이 파드의 restartPolicy에 따라서 올바른 대처를 자동으로 수행한다. 이와 같은 경우에는 Liveness Probe를 설정한다고 해서 큰 효과는 없고 애플리케이션이 데드락 상태에 머무르는 것을 감지하여 재시작시킬 때 유용하다.
- Readiness Probe
probe가 성공한 경우에만 파드에 트래픽 전송을 시작하려고 한다면 Readiness probe를 지정하면 된다. 왜냐하면 그전까지는 애플리케이션이 로드되지 않은 상황에서도 트래픽이 해당 애플리케이션으로 라우팅될 수 있기 때문이다.
혹은 컨테이너의 지속적인 유지 및 관리를 위해서 자체적으로 중단을 수행하는 경우는 pod을 죽이는 Liveness probe말고 Readiness probe를 사용할 수 있다.
- Startup Probe
서비스를 시작하는 데 오랜 시간이 걸리거나 불규칙적인 컨테이너에 설정하는 데 사용될 수 있다.(예를 들면 third party 에서 특정 데이터를 다운받는 등의 경우) startup probe가 성공하고 나서 liveness, readiness probe가 동작하기 때문에 기동시간이 불규칙적인 애플리케이션이 liveness probe에 의해 기동되기도 전에 재시작 되는 것을 방지할 수 있다.(Readiness probe랑 비슷하지만 방금 말한 부분은 Readiness probe로 해결하기 어렵다)
Probe의 개념에 대해서 정리해보았다. probe의 설정은 k8s에서 어떤 종류의 서비스를 운영하는지, 서비스가 어떤 수준의 QoS를 요구하는지에 따라 많이 달라질 것 같다는 생각이 들었다. 아직 사내 프로젝트의 경우 아직까지는 readiness probe 정도만 설정해도 충분하였지만, 서비스 규모가 커지고 사용자 유입이 엄청 많아짐에 따라 deadlock 발생이 감지되면, liveness probe도 도입을 고려해봐야 겠다는 생각이 들었다. (아직 까지는 없었다..)
Startup probe의 경우 혹 도입을 고려해볼만할 수도 있다고 느꼈다. 사내에서 사용하고 있는 ML orker들의 경우 사용자에게 모델 학습을 제공하기 위해 도커 이미지에 초기 데이터셋을 다운받고 있는데, 도커파일 빌드 시간 및 도커파일 경량화를 위해 초기 데이터 셋을 컨테이너가 빌드된 이후로 진행하도록 한다면 startup probe를 도입해볼 수 있다고 느꼈다.
