HealthCheck

• [C183] 애플리케이션에 HTTP 500과 같은 에러가 발생한 경우, 컨테이너를 다시 실행해야 할 것입니다. HTTP 에러가 발생했다는 것을 어떻게 알 수 있을까요? 어떻게 해야 쿠버네티스가 에러가 발생한 컨테이너를 자동으로 재시작하게 만들 수 있을까요? (힌트: liveness probe 키워드를 검색하세요)

프로브(Probe)는 컨테이너에서 kubelet에 의해 주기적으로 수행되는 진단(diagnostic)이다.
진단을 수행하기 위해서, kubelet은 컨테이너에 의해서 구현된 핸들러를 호출한다.

핸들러에는 다음과 같이 세 가지 타입이 있다.
ExecAction : 컨테이너 내에서 지정된 명령어를 실행한다. 명령어 상태 코드 0으로 종료되면 진단이 성공한 것으로 간주한다.
TCPSocketAction : 지정된 포트에서 컨테이너의 IP 주소에 대해 TCP 검사를 수행한다. 연결이 성공하면 진단이 성공한 것으로 간주한다.
HTTPGetAction : 지정된 포트 및 경로에서 컨테이너의 IP 주소에 대한 HTTP Get 요청을 수행한다. 응답의 상태코드가 200 보다 크고 400 보다 작으면 진단이 성공한 것으로 간주한다.

각 프로브(Probe)는 다음 세 가지 결과 중 하나를 가진다.
Success : 컨테이너가 진단을 통과함.
Failure : 컨테이너가 진단에 실패함.
UnKnown : 진단 자체가 실패하였으므로 아무런 액션도 수행되면 안 됨.

 

 

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

livenessProbe : 컨테이너가 동작 중인지 여부를 나타낸다. 만약 활성 프로브(liveness probe)에 실패한다면, kubelet은 컨테이너를 죽이고, 해당 컨테이너는 재시작 정책의 대상이 된다. 만약 컨테이너가 활성 프로브를 제공하지 않는 경우, 기본 상태는 Success이다.

readinessProbe : 컨테이너가 요청을 처리할 준비가 되었는지 여부를 나타낸다. 만약 준비성 프로브(readiness probe)가 실패한다면, 엔드포인트 컨트롤러는 파드에 연관된 모든 서비스들의 엔드포인트에서 파드의 IP 주소를 제거한다. 준비성 프로브의 초기 지연 이전의 기본 상태는 Failure이다. 만약 컨테이너가 준비성 프로브를 지원하지 않는다면, 기본 상태는 Success이다.

startupProbe : 컨테이너 내의 애플리케이션이 시작되었는지를 나타낸다. 스타트업 프로브(startup probe)가 주어진 경우, 성공할 때까지 다른 나머지 프로브는 활성화되지 않는다. 만약 스타트업 프로브가 실패하면, kubelet이 컨테이너를 죽이고, 컨테이너는 재시작 정책에 따라 처리된다. 컨테이너에 스타트업 프로브가 없는 경우, 기본 상태는 Success이다.

 

 

언제 활성 프로브(liveness probe)를 사용해야 하는가?

만약 컨테이너 속 프로세스가 어떠한 이슈에 직면하거나 건강하지 못한 상태(unhealthy)가 되는 등 프로세스 자체의 문제로 중단될 수 있더라도, 활성 프로브가 반드시 필요한 것은 아니다.
이러한 경우에는 kubelet이 파드의 재시작 정책(restart policy)에 따라서 올바른 대처를 자동적으로 수행한다. 프로브가 실패한 후 컨테이너가 종료되거나 재시작되기를 원한다면, 활성 프로브를 지정하고, 재시작 정책을 항상(Always) 또는 실패 시(OnFailure)로 지정한다.

[출처] https://bcho.tistory.com/1264

쿠버네티스 #9 - HealthCheck

 

활성 프로브(liveness probe) 예시

언제 Readiness probe를 사용해야 하는가?

Configuration을 로딩하거나, 많은 데이터를 로딩하거나, 외부 서비스를 호출하는 경우에는 일시적으로 서비스가 불가능한 상태가 될 수 있다. 이런 경우에는 컨테이너를 재시작한다 하더라도 정상적으로 서비스가 불가능할 수 있다.

이런 경우에는 컨테이너를 일시적으로 서비스가 불가능한 상태로 마킹해 주면 되는데, 이러한 기능은 쿠버네티스의 서비스와 함께 사용하면 유용하게 이용할 수 있다.

[출처] https://bcho.tistory.com/1264

쿠버네티스 #9 - HealthCheck

 

Q. 왜 파드와 PV를 직접 연결하는 것이 좋지 않은가요?
1. 파드의 이식성 문제: 파드는 여러 노드 사이에서 스케줄링될 수 있습니다. 직접적으로 PV에 연결된 파드는 특정 노드에 의존하게 되어 이식성이 저하됩니다. 노드 장애 또는 리소스 부족으로 인해 파드를 이동시켜야 할 때 문제가 발생할 수 있습니다.
2. 스토리지 유연성 부족: PV는 스토리지의 추상화 계층으로 작동하여 다양한 스토리지 프로바이더와 통합될 수 있습니다. PV와 파드를 직접 연결하면 특정 스토리지 프로바이더에 종속되게 됩니다. 이로 인해 스토리지 유연성이 제한되며, 스토리지 프로바이더를 변경하거나 업그레이드하는 것이 어려워집니다.
3. 동시에 여러 파드 사용 문제: PV는 여러 파드에서 동시에 사용될 수 있습니다. PV를 직접 파드에 연결하면 해당 PV를 단 하나의 파드만 사용할 수 있게 됩니다. 그러나 PV를 볼륨 클레임(VolumeClaim)을 통해 동적으로 할당하면 여러 파드에서 동시에 사용할 수 있습니다.