[Kubernetes] Application 기능으로 이해하기 - Probe

식빵·2025년 2월 9일

kubernetes

목록 보기

5/6

이 게시물은 인프런 - 쿠버네티스 어나더 클래스 (지상편) - Sprint 1, 2
강의에 대한 복습 및 정리용 게시물입니다. 그렇기 때문에 자세한 내용은 생략됐습니다.
그리고 여기에서 나오는 모든 이미지들은 해당 강의가 출처임을 미리 말씀드립니다.

Probe

Probe 는 App(= Pod) 의 정상 기동 여부를 체크하고,
기동이 정상적이지 않다고 판단하면 그에 따른 처리를 하는 것입니다.

지금부터 Probe 에 대해서 다음 것들을 알아보겠습니다.

Probe 의 App 정상기동 체크 방식
Probe 의 종류

정상기동 확인

2가지 방식

정상 기동을 확인을 위해서 Probe 가 할 수 있는 작업의 종류는 2가지입니다.

httpGet : 을 통해 App api 호출
exec : 를 통한 쉘 명령어 사용

주의사항 : 두 방법을 동시에 사용할 수 없으며 한가지 방법만 사용할 수 있습니다.

각각의 설정 방식은 다음과 같습니다.

httpGet 방식

# startupProbe 가 뭔지 지금은 몰라도 됩니다. 그냥 Probe 종류 중 하나라는 것만 아세요.
startupProbe:
  httpGet:
    path: "/startup"
    port: 8080

Pod 내에 실행중인 App 의 /startup api 를 호출합니다.
당연하지만 App 에 /startup api 를 미리 구현해야 합니다.

exec 방식

startupProbe:
  exec:
    command: ["test", "-f", "/is/datafile/exists.txt"]

이 명령어는 /is/datafile/exists.txt 파일의 존재여부를 체크하는 겁니다.

옵션 설정값

위에서 본 것처럼 체크 방식을 지정하고 나서 옵션값들을 붙여주는 게 좋습니다.

initialDelaySeconds :
일반적으로 Pod 가 띄워지는 순간부터 Probe 검사가 수행됩니다.
즉 app 의 startup 대기 시간을 무시하고 바로 검사를 시작한다는 의미입니다.
이에 대한 대비책으로 사용되는 옵션이며, Pod 가 띄워지고 나서 몇초의
딜레이를 주고 검사를 시작할 때 사용합니다.

periodSeconds
- 검사 주기(=초)입니다.

timeoutSeconds
- httpGet, exec 를 사용할 걸리는 시간을 제한합니다.

successThreshold
- 검사에서 failed 가 나고 몇번을 더 success 해야 되는지를 결정
- 디폴트 및 최소값은 1 이다

failureThreshold
- 최대 실패 횟수이다.
- 기본값은 3 이며, 최소값은 1 이다.

참고:
위 설명은 제가 많이 생략한 겁니다.
더 자세한 내용은 쿠버네티스 공식문서 Probe 옵션 설명 을 참조해주세요.

Probe 의 종류

위에서 설명은 안했지만 사실 Probe 에는 여러 종류가 있습니다.
아래 Deployment object 의 설정 yaml 파일을 한번 훑어 봅시다.

apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: anotherclass-123
  name: api-tester-1231
  labels: ## 생략 ##
spec: ## probes 관련된 내용이 아니면 모두 생략했습니다.
  template:
    spec:
      containers:
        - name: api-tester-1231
          image: 1pro/api-tester:v1.0.0
          startupProbe:
            httpGet:
              path: "/startup"
              port: 8080
            periodSeconds: 5
            failureThreshold: 36
          readinessProbe:
            httpGet:
              path: "/readiness"
              port: 8080
            periodSeconds: 10
            failureThreshold: 3
          livenessProbe:
            httpGet:
              path: "/liveness"
              port: 8080
            periodSeconds: 10
            failureThreshold: 3

startupProbe
readinessProbe
livenessProbe

이렇게 3가지 종류의 Probe 가 있는 걸 확인할 수 있습니다.
이렇게 나누는 이유는 App 의 최종적인 정상 기동 상태를 더 세분화하고,
어떤 방식으로 App 을 동작시킬지를 결정하기 위함입니다.

지금부터 각각의 Probe 가 뭔지 알아보겠습니다.

Liveness Probe

컨테이너가 정상 기동이 됐는지 체크하는 Probe 이며,
체크를 할 때 failureThreshold 횟수만큼 실패하게 되면
kubelet 에 의해서 컨테이너가 재기동(restart)됩니다.

Liveness Probe 의 시작을 늦추는 방법 2가지

initialDelaySeconds 로 검사를 늦추거나

Startup Probe 를 설정하여, StartUp Probe 검사가 끝날 때까지 지연

Readiness Probe

container 가 traffic 을 받을 수 있는 상태인지를 검사합니다.
이게 필요한 이유는 비록 App 이 정상 기동이 됐다고 해도,
추가적인 설정 세팅 때문에 당장 요청을 받기가 애매할 때가 있습니다.

이 Probe 는 추가적인 설정이 모~두 완료되고 나서 Service 를 Pod 에
연결합니다.

만약에 failureThreshold 만큼 실패하면 Service 와 Pod 의 연결을 끊습니다.
이렇게 되면 외부 요청이 무시되겠죠?

Startup Probe

application 이 기동됐는지를 확인할 때 사용하는 Probe 입니다.
Startup Probe 가 설정되면 Readiness Probe, Liveness Probe
는 Startup Probe 가 success 상태가 될때까지 검사를 지연시킵니다.

그리고 Readiness Probe, Liveness Probe 은 계속해서
App 이 띄워져있는 동안 검사를 수행하는 대신

맨 처음 한번 success 상태로 판단되면 그 후에는 더 이상 검사를
수행하지 않습니다.

failureThreshold 횟수만큼 실패하면 Pod 를 재시작합니다.