컨테이너 프로브란?
프로브는 컨테이너에서 kubelet에 의해 주기적으로 수행되는 진단을 이야기한다. 즉 쿠버네티스의 Pod를 진단하는 의사라고 생각하면 된다. kubelet은 컨테이너 안에서 코드를 실행하거나, 또는 네트워크 요청을 하여 진단한다.
참고로 kubelet은 컨테이너가 아니다. kubelet은 각 노드에서 실행되는데 파드에서 컨테이너가 확실하게 동작하는지 관리한다. 처음 쿠버네티스로 클러스터링 될 때 kubelet이 컨테이너면 kubelet이 제대로 동작하는지 관리할 도구가 필요할 것이다. 그래서 kubelet은 각 호스트에서 시스템 서비스로 구동된다.
프로브 종류
kubelet은 실행 중인 컨테이너들에 대해서 선택적으로 세 가지 종류의 프로브를 수행하고 그에 반응할 수 있다.
livenessProbe
- 컨테이너가 동작 중인지 여부를 나타낸다.
- 활성 프로브가 실패한다면, kubelet은 컨테이너를 죽이고, 해당 컨테이가 재시작 정책의 대상이 된다.
- 컨테이너가 livenessProbe를 제공하지 않는다면 기본 상태는 Success이다.
readinessProbe
- 컨테이너가 요청을 처리할 준비가 되었는지 여부를 나타낸다. 만약 준비성 프로브(readiness probe)가 실패한다면, 엔드포인트 컨트롤러는 파드에 연관된 모든 서비스들의 엔드포인트에서 파드의 IP주소를 제거한다. 준비성 프로브의 초기 지연 이전의 기본 상태는 Failure 이다. 만약 컨테이너가 준비성 프로브를 지원하지 않는다면, 기본 상태는 Success 이다.
startupProbe
- 컨테이너 내의 애플리케이션이 시작되었는지를 나타낸다. 스타트업 프로브(startup probe)가 주어진 경우, 성공할 때까지 다른 나머지 프로브는 활성화되지 않는다. 만약 스타트업 프로브가 실패하면, kubelet이 컨테이너를 죽이고, 컨테이너는 재시작 정책에 따라 처리된다. 컨테이너에 스타트업 프로브가 없는 경우, 기본 상태는 Success 이다.
체크 메커니즘
프로브를 사용하여 컨테이너를 체크하는 방법에는 4가지가 있다. 각 프로브는 다음의 4가지 메커니즘 중 단 하나만을 정의해야 한다.
exec
- 컨테이너 내에서 지정된 명령어를 실행한다. 명령어가 상태 코드 0으로 종료되면 진단이 성공한 것으로 간주한다.
grpc
- gRPC를 사용하여 원격 프로시저 호출을 수행한다. 체크 대상이 gRPC 헬스 체크를 구현해야 한다. 응답의 status 가 SERVING 이면 진단이 성공했다고 간주한다. gRPC 프로브는 알파 기능이며 GRPCContainerProbe 기능 게이트를 활성화해야 사용할 수 있다.
httpGet
- 지정한 포트 및 경로에서 컨테이너의 IP주소에 대한 HTTP GET 요청을 수행한다. 응답의 상태 코드가 200 이상 400 미만이면 진단이 성공한 것으로 간주한다.
tcpSocket
- 지정된 포트에서 컨테이너의 IP주소에 대해 TCP 검사를 수행한다. 포트가 활성화되어 있다면 진단이 성공한 것으로 간주한다. 원격 시스템(컨테이너)가 연결을 연 이후 즉시 닫는다면, 이 또한 진단이 성공한 것으로 간주한다.
아래의
kubectl explain pod.spec.containers.livenessProbe
kubectl explain pod.spec.containers.startupProbe
kubectl explain Pod.spec.containers.readinessProbe
를 사용하면 다른 필드값도 알 수 있다.
initialDelaySeconds
- pod의 최초 헬스체크를 시작할 때까지의 지연이며 1회성이다.
periodSeconds
- pod의 '헬스체크 간격'이다.
successThreshold
- 프로브가 성공한것으로 간주하는 최소한의 연속 성공횟수를 정의한다. 실패한 후 최소값은 1이다.
failureThreshold
- 프로브가 실패할 수 있는 횟수입니다. 기본값은 3입니다. 지정된 시도 횟수 후에는 다음이 수행됩니다.
terminationGracePeriodSeconds
- 컨테이너가 종료될 시간을 설정합니다. 0을 설정하면 비정상 종료가 됩니다. 해당 설정 시간을 넘으면 SIGKILL을 날려서 즉시로 제거합니다.
timeoutSeconds
- 프로브가 시간 초과되고 컨테이너가 실패한 것으로 간주되는 비활성 시간(초)입니다. 기본값은 1입니다. 이 값은 periodSeconds 보다 작아야 합니다.
프로브 결과
각 probe는 다음 세 가지 결과 중 하나를 가진다.
Success
컨테이너가 진단을 통과함.
Failure
컨테이너가 진단에 실패함.
Unknown
진단 자체가 실패함(아무런 조치를 수행해서는 안 되며, kubelet이 추가 체크를 수행할 것이다)
언제 livenessProbe를 사용해야 하는가?
만약 컨테이너 속 프로세스가 어떠한 이슈에 직면하거나 건강하지 못한 상태(unhealthy)가 되는 등 프로세스 자체의 문제로 중단될 수 있더라도, 활성 프로브가 반드시 필요한 것은 아니다. 그 경우에는 kubelet이 파드의 restartPolicy에 따라서 올바른 대처를 자동적으로 수행할 것이다.
프로브가 실패한 후 컨테이너가 종료되거나 재시작되길 원한다면, 활성 프로브를 지정하고, restartPolicy를 항상(Always) 또는 실패 시(OnFailure)로 지정한다.
언제 준비성 프로브를 사용해야 하는가?
프로브가 성공한 경우에만 파드에 트래픽 전송을 시작하려고 한다면, 준비성 프로브를 지정하길 바란다. 이 경우에서는, 준비성 프로브가 활성 프로브와 유사해 보일 수도 있지만, 스팩에 준비성 프로브가 존재한다는 것은 파드가 트래픽을 받지 않는 상태에서 시작되고 프로브가 성공하기 시작한 이후에만 트래픽을 받는다는 뜻이다.
만약 컨테이너가 유지 관리를 위해서 자체 중단되게 하려면, 준비성 프로브를 지정하길 바란다. 준비성 프로브는 활성 프로브와는 다르게 준비성에 특정된 엔드포인트를 확인한다.
만약 애플리케이션이 백엔드 서비스에 엄격한 의존성이 있다면, 활성 프로브와 준비성 프로브 모두 활용할 수도 있다. 활성 프로브는 애플리케이션 스스로가 건강한 상태면 통과하지만, 준비성 프로브는 추가적으로 요구되는 각 백-엔드 서비스가 가용한지 확인한다. 이를 이용하여, 오류 메시지만 응답하는 파드로 트래픽이 가는 것을 막을 수 있다.
만약 컨테이너가 시동 시 대량 데이터의 로딩, 구성 파일, 또는 마이그레이션에 대한 작업을 수행해야 한다면, 스타트업 프로브를 사용하면 된다. 그러나, 만약 failed 애플리케이션과 시동 중에 아직 데이터를 처리하고 있는 애플리케이션을 구분하여 탐지하고 싶다면, 준비성 프로브를 사용하는 것이 더 적합할 것이다.
언제 스타트업 프로브를 사용해야 하는가?
스타트업 프로브는 서비스를 시작하는 데 오랜 시간이 걸리는 컨테이너가 있는 파드에 유용하다. 긴 활성 간격을 설정하는 대신, 컨테이너가 시작될 때 프로브를 위한 별도의 구성을 설정하여, 활성 간격보다 긴 시간을 허용할 수 있다.
컨테이너가 보통 initialDelaySeconds + failureThreshold × periodSeconds 이후에 기동된다면, 스타트업 프로브가 활성화 프로브와 같은 엔드포인트를 확인하도록 지정해야 한다. periodSeconds의 기본값은 10s 이다. 이 때 컨테이너가 활성화 프로브의 기본값 변경 없이 기동되도록 하려면, failureThreshold 를 충분히 높게 설정해주어야 한다. 그래야 데드락(deadlocks)을 방지하는데 도움이 된다.
참고
https://calsoftinc.com/blogs/2019/09/why-kubelet-runs-as-a-system-service-in-k8s-cluster-and-not-as-pod-daemonsets.html
https://kubernetes.io/ko/docs/concepts/overview/components/
https://www.inflearn.com/questions/499394/initialdelayseconds%EC%99%80-periodseconds-%EC%84%A4%EC%A0%95%EC%97%90-%EB%8C%80%ED%95%B4-%EC%A7%88%EB%AC%B8%EC%9E%88%EC%8A%B5%EB%8B%88%EB%8B%A4
