전공영역 공부 기록

쿠버네티스에 설정한 probe가 어떻게 실행되는지 알아야하는 이유

악분 2025. 5. 1. 18:35
반응형

 

 

쿠버네티스에 설정한 probe가 어떻게 실행되는지 알아야하는 이유

쿠버네티스 pod가 정상적으로 동작하는 지 확인하기 위해 probe설정을 합니다. probe는 설정된 값으로 pod를 주기적으로 헬스체크합니다.

 

그런데, 헬스체크가 실패한다면 pod에 문제 있어서 실패한걸까요? pod는 정상이지만 헬스체크가 실패하는 경우가 자주 있습니다. 이런 상황에 마주칠때 pod에 설정된 헬스체크 원리를 모른다면 원인을 파악하는데 많은 시간이 걸립니다.

 

pod는 정상이지만 헬스체크가 실패한 사례

쿠버네티스는와 pod 정상이지만 pod헬스체크가 실패했던 경험이 있습니다. 쿠버네티스가 정상이라는 말은 api-service, etcd 등 control plane이 정상이라는 뜻이고 pod가 정상이라는 말은 pod 메트릭이 비정상으로 보이는게 없다는 뜻입니다. pod의 cpu, memory, network 리소스 사용률이 평상시대로였습니다. 하지만 pod 헬스체크가 실패했습니다.

 

당시 pod상태를 확인해보니 몇개의 pod가 아래처럼 Not ready상태였습니다.
![[remote/attach_files/CleanShot-2025-04-27-at-20-54-05@2x.png]]

 

다행히 헬스체크 원인을 밝히는데 많이 들지 않았고 서비스 장애시간을 단축시켰습니다. 만약 pod에 설정된 헬스체크 원리를 몰랐더라면 서비스 장애시간이 길어졌을거라고 생각합니다.

 

왜 헬스체크가 실패했을까?

쿠버네티스도 정상이고 pod리소스 사용률도 적은데 왜 헬스체크가 실패했을까요? 실패한 헬스체크는 readiness probe입니다.

 

readines probe는 pod가 요청을 받을 수 있는지 검사합니다. 애플리케이션이 요청을 받으려면 애플리케이션과 연결된 다른 리소스 상태가 정상이어야 합니다. 대표적인 예로 데이터베이스입니다.

 

만약 데이터베이스가 비정상 상태이면 어떻게 될까요? readiness probe는 데이터베이스 영향으로 pod가 검사가 실패하고 pod는 Not ready가 됩니다. 제가 겪었던 경험은 데이터베이스의 CPU부하때문에 pod readiness probe가 실패했습니다.

 

헬스체크 실패의 원인이 데이터베이스에 있다는 것을 확인한 후 데이터베이스 조치를 하여 데이터베이스 CPU부하를 해결했습니다.

애플리케이션의 헬스체크 종류

애플리케이션 헬스체크(또는 pod probe)에 설정한 헬스체크는 2종류입니다.

  1. 직접 헬스체크 로직을 개발
  2. 프레임워크에서 제공한 헬스체크를 사용

 

웹 애플리케이션은 대부분 사용하는 프레임워크에서 제공하는 헬스체크를 사용합니다. 예로 스프링 Application Availability입니다. Application Availability는 스프링 액츄레이터를 활성화하면 사용할 수 있습니다.

 

아래는 스프링에서 액츄레이터를 활성화하고 liveness API를 호출한 결과입니다.

curl http://localhost:30081/actuator/health/liveness

 

 

애플리케이션 헬스체크 설정은 정답이 없다.

상황에 따라서 readines probe에 데이터베이스 검사를 넣어도 되고 안넣어도 됩니다. 데이터베이스가 부하가 걸리더라도 트래픽은 받겠다라는 의사결정을 내렸으면 readiness probe검사에 데이터베이스를 뺄 수도 있습니다. 써킷브레이커로 트래픽을 관리하는 상황에서도 probe검사를 더 느슨하게 할 수 있습니다.

 

따라서 probe에 무조건 이 검사를 넣어야한다는게 아니라 개발자, 인프라 엔지니어 등 각 분야의 담당자들과 이야기를 해서 적절하게 설정해야 합니다.

 

보통 readiness probe에서는 외부 시스템 검사를 넣고 liveness probe에서는 외부 시스템 검사를 제외합니다.

 

실습

실습은 github 링크로 대체합니다.

 

참고자료

반응형