[k8s] Application 기능으로 이해하기-Pod (probe)

Pod (probe) - 프로브 기본 개념

 

 

• Probe 란 k8s 에서 파드의 상태를 주기적으로 체크하는 진단이다.
• Probe 를 통해 컨테이너의 상태를 Api 호출을 통해 진행한다.
• probe 종류
  • startupProbe
  • readinessProbe
  • livenessProbe

Setting

• Pod 안 App 에는 /ready 라는 url 호출기능이 존재해야 한다.
• health 체크 용도의 API 면 충분하다.

startupProbe

• Pod 는 생성과 동시에 startupProbe 기능을 동작 시킨다.
• 오브젝트 속성에 있는 대로 10초에 한 번씩 (periodSeconds) /ready라는 api를 요청한다.
• 기동 중일 때는 응답을 받을 수 없으니 계속 실패가 되고, 10번 실패하기(failureThreshold) 전에 한번이라도 응답이 오면 (sucessThreshold) 성공으로 간주한다.

• startupProbe 가 성공하면 해당 기능을 중지시키고 livenessProbe 와 readinessProbe기능을  동작 시킨다.
• 설정 한대로 두 probe는 /ready라는 api를 10초 간격(periodSeconds)으로 반복해서 API 요청을 진행한다.
• App이 살아있는 동안에 계속 200 OK 결과를 리턴 해주면서 이 두 probe 동작은 반복된다.

livenessProbe / readinessProbe

• readinessProbe : 성공했을 때 외부 트래픽을  Pod가 받을 수 있는 상태로 만들어 주며, 이를 통해 서비스가 활성화 된다.
• livenessProbe : app이 살아 있는지를 계속 체크한다.
• 만약 App에 장애가 발생하게 되면, API는 실패를 하게 되고 설정에 따라 두 번(failureThreshold)을 실패하게 되면 쿠버네티스는 App을 재기동 시킨다.

 

Pod (probe) - 실습

 

 

실습 링크 (link)

 

Pod (probe) - 실습 로그 분석

 

 

 

• App 이 실행하는 동안 아직 요청이 진행될수 없어 startupProbe 는 계속 실패한다.
• 이후 Api 가 완전에 기동된 후에 요청이 처리될수 있게 되면 startupProbe 는 성공한다.

 

• 해당 Api 는 startupProbe 가 기동중에도 확인될수 있게 구성되어 있음.

 

 

• 이제 기동이 완료후, [ConfigMap data is loading]은 사용자가 App이 기동 된 후에 외부에 데이터를 가져와서 추가적으로 시스템을 초기화 시키려는 상황을 가정했다.
• 그리고 아래 livenessProbe랑 readinessProbe 요청이 시작되었다.
• 이때 readinessProbe는 실패했고, livenessProbe만 성공이 되었다.
  • 이는 일부로 Api 에서 사용자 초기화 구간에 readinessProbe가 실패하도록 구성하였기 때문이다.
• 이후 livenessProbe랑 readinessProbe는 계속 요청되고, 두 요청 모두 성공 하게된다.

Pod (probe) - Application 동작 중심의 프로브 이해

 

• 모든 App 에는 초기화 과정과 초기 데이터를 로딩하는 과정이 존재한다.
• 위 과정이 모두 끝나야 해당 App 의 동작이 정상적으로 동작할 수 있다.
• 이때 자동화 요구사항으로는 App 상태가 올바르게 올라가거나 App이 정상적으로 동작하는지에 대한 체크가 필요하다.
• 위 두 과정에서는 외부 API 에서 접근하면 안되는 상황이다.
• 또한 App 이 기동되었을 때 외부 요청을 허용시켜야 하며 예외로 App에 장애가 발생한다면 App을 재기동 해야 할 상황도 온다.
• 쿠버네티스가 아닌 환경에서는 이러한 작업을 L4 를 이용하여 물리적으로 작업하거나 nginx 와 같은 웹서버를 통해 해당 과정을 제어해야만 했다.
• 쿠버네티스는 probe 를 통해 API 접근을 허용하거나 제어하는 역할을 한다고 볼수 있다.
• startupProbe 를 통해 API 가 제대로 초기화가 되었는지 확인하고 제대로 기동되었다면 readiness 와liveness probe 를 실행한다.
• readiness 를 통해 API 의 초기데이터가 올바르게 초기화 되었는지 확인한다. 제대로 초기화가 되었다면 이때부터 서비스를 해당 pod 에 연결하여 외부 API 요청을 허용하게 된다.
• liveness 는 API가 올바르게 동작되고 있는지 확인한다. 만약 liveness 가 설정한 failureThreshold 수 만큼 실패한다면 쿠버네티스는 해당 App 을 재기동 하게 된다.

 

Pod (probe) - API 날려보며 프로브 동작 확인하기

 

Pod (probe) - 일시적 장애 상황에서의 프로브 활용

 

• liveness 와 readiness 를 동일하게 설정할 시 의도치 않게 pod 를 재기동 하게 되는 상황이 있을수 있다.
• 만약 트래픽이 몰려 조금만 기다리면 App 이 정상화가 되는 상태였는데 계속해서 probe를 통해 실패가 되어 App을 재기동하게 된다면 필요 없는 재기동이 이뤄질 수 도 있는 상황이 나타난다.
• 이때는 liveness 의 체크 주기를 readiness 주기보다 길게주어 서비스에 Pod 만 연결을 해제하여 API 요청만 제어한 후 이후 다시 요청을 연결할수 있게 할 수 있다.

 

추가 발생할 수 있는 상황들

 

• startupProbe 가 완전 실패하여 pod 가 무한 재기동 되는 경우
  • 만약 startupProbe 의 주기와 실패 횟수가 App 이 기동되는 시간 이전에 발생한다면 해당 Pod는 무한 재기동 되는 현상이 발생하게 된다.
• Pod의 오류상황에서 재기동을 제어.
  • liveness 의 반복주기를 readiness 반복주기 보다 길게 준다면 해당 Pod의 상태가 오류 상태일 지라도 Pod의 재기동 시점을 늦출 수 있다.
  • 단, readiness 의 실패횟수 이내에 pod가 정상상태로 돌아와야만 한다. (넘어간다면 재기동 진행됨)
• API 요청이 아닌 다른방법으로 probe 를 체크하는 방법
  • 위 예제 에서는 httpGet 을 통해 probe 체크를 진행했지만, 다른 방법으로도 가능하다.
  • kubelet 은 pod의 상태를 진단하기 위해 아래의 handler 를 사용한다.
    • ExecAction : 커맨드 라인을 이용한 확인방법.
    • TCPSockectAction : 지정된 포트로 Tcp 연결을 시도하여 확인하는 방법.
    • HttpGetAction : 위 예제에서 사용했던 Http api 호출을 통한 확인방법. 200~400 호출시에는 성공 나머지는 실패

# ExecAction
exec:
   command:
   - cat
   - /etc/nginx/nginx.conf
# TCPAction
tcpSocket:
    port: 8080
    initialDelaySeconds: 15
    periodSeconds: 20
# HttpGetAction
  httpGet:
    path: /healthz
    port: liveness-port