7.5강 livenessProbe exec 방식에 관한 질문입니다

그림으로 배우는 쿠버네티스(v1.30) - {{ x86-64, arm64 }}

7.5.애플리케이션 상태 탐사(startupProbe, livenessProbe, readinessProbe)

작성

426

수정됨

livenessProbe는 실행 중 애플리케이션에 문제가 발생하면 애플리케이션이 재기동되는 탐사라고 하셨습니다.

탐사 체크 조건을 exec 방식으로 cat /tmp/healthy-on 하도록 했을 때, periodSeconds를 10초 간격으로 주면 아직 애플리케이션 실행이 완료되지 않아 탐사에 실패하여 Unhealthy상태 -> killing상태 -> 앱의 재기동이 반복되는 프로세스는 이해를 했습니다.

그런데 periodSeconds 를 30초 간격으로 주었을 때에도 cat /tmp/healthy-on 을 하지 못해 Unhealthy가 떴는데요(livenessProbe failed 됨).

그럼 애플리케이션이 재기동되어야 하는 게 아닌가요? 탐사에 실패했는데도 unhealthy 상태를 그대로 유지하는 까닭이 무엇인가요?

그리고 아래 분의 질문에 덧붙여 한 가지 더 질문드리고 싶습니다.

livenessProbe일 경우, initialDelaySeconds가 10초이고, periodSeconds가 30초이면, 첫 탐사 체크는 파드 running 후 40초(10초+30초)쯤 이루어진다고 보면 되나요?

아직 이해가 부족한 듯하여 부끄럽네요..

답변 미리 감사드립니다.

docker kubernetes

답변 2

mihyeondev

질문자

자세한 설명 감사합니다.

당시 진행했던 데이터는 다음과 같습니다.

아래가 말씀드린 실습 부분인데, 헬스 체크했을 때 unhealthy가 2번 발생했고 killing은 발생하지 않은 모습입니다.

[root@m-k8s ~]# k apply -f _Lecture_k8s_learning.kit/ch7/7.5/livenessProbe-exec-periodSeconds30.yaml
pod/liveness-exec created

[root@m-k8s ~]# watch "kubectl describe po liveness-exec | tail"
Every 2.0s: kubectl describe po liveness-exec | tail                                                                                                  Fri Mar 10 09:05:49 2023

                             node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
  Type     Reason     Age                 From               Message
  ----     ------     ----                ----               -------
  Normal   Scheduled  2m21s               default-scheduler  Successfully assigned default/liveness-exec to w2-k8s
  Normal   Pulling    2m17s               kubelet            Pulling image "sysnet4admin/tardy-nginx"
  Normal   Pulled     2m15s               kubelet            Successfully pulled image "sysnet4admin/tardy-nginx" in 2.442951756s
  Normal   Created    2m14s               kubelet            Created container tardy-nginx
  Normal   Started    2m14s               kubelet            Started container tardy-nginx
  Warning  Unhealthy  81s (x2 over 111s)  kubelet            Liveness probe failed: cat: /tmp/healthy-on: No such file or directory

조훈(Hoon Jo)

지식공유자

해당 부분은 이미 동작하였기 때문에 더이상 counter(x2)가 늘어나지 않는 것입니다.

그리고 기록된 로그에 대해서 시간이 늘어나는 것입니다.

조훈(Hoon Jo)

지식공유자

안녕하세요

1.Unhealty 부분

해당 부분에 애플리케이션은 계속 다시 시작한게 맞습니다.

예를 들면 다음과 같이 pid 1번을 강제로 죽이면 restart 합니다.

영상을 다시 보시고, 3가지의 개념에 대해서 다시 이해해 보시면 아마 현재 상황이 이해되시리라고 생각됩니다.

2.livenessProbe timing
애플리케이션이 정상적으로 Running하는지 체크하는것이기 때문에 Running한 후에 동작하는게 아닙니다.
따라서 질문 주신 것은 아마 약간 오해가 있으셨던거 같은데... 애플리케이션의 동작 그리고 서비스(엔드포인트 생성)과 연관지어 각각의 Probe를 이해하시면 좋으실 것 같습니다.

또는 괜찮으시다면 영상을 1-2회 정도 더 보시면서 관련 문서를 보시는 것도 좋을 것 같습니다.

경우에 따라서는 다양한 방법과 설명을 통해서 이해되고 습득 되는 경우가 있어서요.

mihyeondev

질문자

답변 감사합니다.

killing 시 재시작이 되는 부분은 이해하고 있습니다.
그런데 periodSeconds을 30초 주게 되면 unhealthy 상태로 멈춰있고 killing은 되지 않기 때문에 애플리케이션이 재구동되지 않는데, 영상에서 말씀하시기로 periodSeconds를 충분히 줬기 때문에 그런 것이라고 하셨거든요. describe를 하여 events 부분을 확인해 보면 unhealthy 상태로 liveness prove failed 라고 출력되는데 이것을 실패한 상태로 보지 않는 건가요? 상태 메시지만 보면 실패한 것처럼 보여서 애플리케이션이 재기동이 되어야 할 것 같은데 말이죠..
질문이 너무 길어질 듯하여 넣지 않았는데, 사실 readinessProbe에서도 동일한 의문이 들었습니다. 처음 readinessProbe를 하고 나서 describe를 보면 unhealthy 상태로 Readiness probe failed: 로 출력된 채로 유지되는데, 파드 상태를 보면 정상적으로 Ready에 올라간 상태입니다. 심지어 내부에 들어가서 보면 /tmp/healthy-on 파일도 있더라구요? 이 파일을 수동으로 삭제하면 그제야 진짜 서비스를 중단하고 endpoint가 내려가는 것을 볼 수 있었어요.

그렇다면 헬스 체크를 위해 사용한 exec 방식은 unhealthy가 떠도 괜찮은 거라고 봐야 하는 건지 모르겠네요..ㅠㅠ

조훈(Hoon Jo)

지식공유자

안녕하세요

영상 어느 부분을 얘기하시는지는 정확하게 알 수 없으나...
describe에 나오는 Events 부분에 Age를 보시면 2번 반복 발생하는 경우 x2로 표시합니다.

#3
Probe는 trigger 방식이 아니라 주기적인 polling 방식이기 때문에 시간이 필요합니다.
또한 Events는 과거의 데이터를 기록하기 위한 목적이기 때문에 발생한 시점과 내용을 모두 알아야 합니다.

Events는 log 또는 진행했던 데이터로 보시는게 좋으실 것 같습니다.
현재 내용을 좀 더 정확하게 알기 위해서는 같은 시점에 아래의 내용들에 대한 모든 캡처 또는 (tmux 또는 멀티 세션)으로 구성된 캡처 화면들로 설명이 되어야 좀 더 구체적으로 설명이 가능할 것 같습니다.

조훈(Hoon Jo)

지식공유자

서비스의 상태를 주기적으로 확인하고자 한다면

프로메테우스등을 활용하는게 나을 수도 있습니다. (물론 이것도 수집 주기 / scrape 가 있습니다.)

인프런 커뮤니티 질문&답변

7.5강 livenessProbe exec 방식에 관한 질문입니다