상태 프로브(startup, liveness, readiness)란 무엇인가?

참고

• 파드 라이프사이클 - kuberneted docs
• Kubernetes Readiness Probes - Examples & Common Pitfalls - Levent Ogut

세줄 요약

• livenessProbe : container가 비정상인 경우 container를 죽여서 pod 재 시작
• readinessProbe : container가 비정상인 경우 pod가 속한 service의 endpoint에서 제거
• startupProbe : container시작 시점에만 검사하며 비정상인 경우 container죽여서 pod 재 시작, startupProbe가 성공해야 liveness, readiness가 동작하기 시작

---

반응형

 

상태 프로브를 알아보기 전에 먼저 kube-proxy 종류와 차이에 대해 조금 알고 가면 좋습니다.

kube-proxy에는 세 가지 유형이 있습니다.

• userspace
• iptables
• ipvs

k8s 초기에는 userspace가 기본모드 였고, 현재는 iptables가 기본모드 이며, 향후에는 ipvs가 기본모드로 되려 한다고 합니다.

userspace 모드와 iptables 모드에서의 중요한 차이점 중 하나가 바로 특정 pod에 요청이 실패 했을 때의 처리 방식입니다.

하나의 pod에 대한 요청이 실패 했을 때

• userspace : 자동으로 다른 pod로 연결을 재시도
• iptables : 그냥 실패 리턴

현재 기본모드로 사용되고 있는 iptables모드에서 특정 pod에 대한 요청이 실패하면 그냥 그대로 리턴하게 됩니다.

만약 10개의 pod중 어떠한 이유가 되었던 1개의 pod만 정상인 상황이라면 90%의 요청 실패이며 이는 정상적인 환경이라 볼 수 없습니다.

이 때 상태 프로브를 사용하여 건강한 환경을 유지할 수 있도록 구성할 수 있습니다.

 

참고

kube-proxy userspace에서는 pod 하나로의 요청이 실패하면 자동으로 다른 pod로 연결을 재시도 하지만

iptables모드에서는 pod 하나로 가는 요청이 실패하면 재시도를 하지 않고 그냥 요청이 실패 합니다.

 

pod가 2개인경우 서비스는 100% 가동시간을 보장하지 않습니다.

 

 

상태 프로브의 역할

참고

• 컨테이너 프로브 - k8s docs
• liveness, readiness란 무엇인가? - k8s docs
• 상태 확인 유형 - Google Cloud <-문서 중간 부분에 두 probe 동작방식에 대한 animation 있어서 이해하기 좋습니다.

pod에 실행중인 container들의 상태를 감지하여 건강하지 못한 pod에게는 트래픽이 전달되지 않도록 pod의 상태를 확인하기 위해 kubelet이 프로브를 실행합니다.

상태 프로브는 pod에 정의 할 수 있고 세 가지 유형으로 사용할 수 있습니다.

• liveness probe
  • 컨테이너가 정상적으로 동작 중인지 여부를 확인합니다.
  • 만약 liveness probe가 실패한다면, kubelet은 컨테이너를 죽이고, 해당 컨테이너는 재시작 정책의 대상이 됩니다.
    • 컨테이너가 죽고, pod는 재시작 되어 컨테이너가 다시 생성됩니다. (pod가 다시 생성되는게 아닙니다.)
  • 만약 컨테이너가 liveness probe를 제공하지 않는 경우 기본 상태는 success 입니다.
• readiness probe
  • 컨테이너가 트래픽을 받을 준비가 되었는지 여부를 나타냅니다.
  • 만약 readiness probe가 실패한다면, 엔드포인트 컨트롤러는 pod에 연관된 모든 서비스들의 엔드포인트에서 pod의 ip주소를 제거 합니다.
    • endpoint에서 제거만 할 뿐 liveness probe처럼 다시 시작해주는 기능은 없습니다.
  • readiness probe의 초기지연 이전의 기본상태는 Failure 이고, readiness probe 설정이 없는경우 기본 상태는 Success 입니다.
• startup probe
  • 컨테이너 내의 애플리케이션이 시작 되었는지를 나타냅니다.
  • startup probe가 주어진 경우 성공할 때 까지 다른 나머지 프로브는 활성화 되지 않습니다.
    • 반드시 startup probe가 성공해야 liveness, readiness 프로브가 동작하기 시작합니다.
  • 만약 startup probe가 실패하면 kubelet이 컨테이너를 죽이고, 컨테이너는 재시작 정책에 따라 처리 됩니다.
    • 정해진 시간을 초과 하지 않는 범위에서 probe action이 성공해야 합니다.
  • startup probe 설정이 없는경우 기본 상태는 Success 입니다.

참고하는 문서들마다 container가 재시작 된다. pod가 재시작 된다 라는 내용이 혼재되어 있어 이는 따로 테스트를 해봐야 할 것 같습니다.

• liveness probe, readiness probe 기능의 차이는? 문서에 테스트 내용이 있습니다.

각 상태 프로브는 공통적인 설정값이 있습니다.

• initialDelaySeconds : 컨테이너가 시작되고 initialDelaySeconds 후 프로브 실행이 시작됩니다. (기본값 : 0)
• periodSeconds : 프로브 실행 빈도 (기본값 : 10)
• timeoutSeconds : 프로브 시간 초과 (기본값 : 1)
• successThreshold : 정상/준비로 표시하는데 필요한 성공 프로브 수 (기본값 : 1)
• failureThreshold : 비정상/준비되지 않은 것으로 간주하기위한 실패 수 (기본값 : 3)

또한 상태 프로브는 세 가지 유형의 컨테이너 프로브 핸들러를 지원합니다.

• ExecAction : 명령 실행 확인, 명령의 종료 상태가 0이면 성공으로 간주 합니다.
• TCPSocketAction : TCP 포트가 열려 있는지 확인하고 열려 있으면 성공으로 간주 합니다.
• HTTPGetAction : get 요청을 수행하여 상태코드가 200이상 400미만이면 성공으로 간주 합니다.

컨테이너 프로브는 아래 세 가지 결과 중 한가지를 갖습니다.

• Success : 컨테이너가 진단을 통과
• Failure : 컨테이너가 진단에 실패
• Unknown : 진단 자체가 실패 하였으므로 아무런 액션도 수행하지 않음

 

각 probe 핸들러의 기본 예시

 

Exec Action

하나의 필드만 있고 command 명령의 종료 상태를 확인하여 상태가 0이면 정상 다른값은 비정상을 의미합니다.

readinessProbe: 
  initialDelaySeconds: 1 
  periodSeconds: 5 
  timeoutSeconds: 1 
  successThreshold: 1 
  failureThreshold: 1 
  exec: 
    command: 
    - cat 
    - /etc/nginx/nginx.conf

TCPSocket Action

host와 port를 정의 합니다. host의 기본값은 pod 내부 ip인 cluster-ip입니다.

readinessProbe: 
  initialDelaySeconds: 1 
  periodSeconds: 5 
  timeoutSeconds: 1 
  successThreshold: 1 
  failureThreshold: 1 
  tcpSocket: 
    host: 
    port: 80

HTTPGet Action

httpGet action은 구성해야 하는 추가 옵션이 있습니다.

• host : 연결할 호스트/IP (기본값 : pod ip)
• scheme : 요청 시 사용할 Scheme (기본값 : http)
• path : 헬스 체크할 경로
• httpHeaders : 헤더/값 맵으로 정의 된 헤더 배열
• port : 연결할 포트

팁 : HTTP의 Host header를 설정해야 하는 경우 host 매개 변수 대신 httpHeaders에서 설정하십시오.

readinessProbe: 
  initialDelaySeconds: 1 
  periodSeconds: 2 
  timeoutSeconds: 1 
  successThreshold: 1 
  failureThreshold: 1 
  httpGet: 
    host: 
    scheme: HTTP 
    path: / 
    httpHeaders: 
    - name: Host 
      value: myapplication1.com 
    port: 80 
  initialDelaySeconds: 5 
  periodSeconds: 5

상태 프로브 조합

컨테이너가 실행 되더라도 정상 동작하기 까지 오래 걸리는앱이 있는 경우 - k8s docs

• livenessProbe에 initDelaySeconds 를 사용하는 대신
• livenessProbe와 startupProbe를 같이 사용할 수 있습니다.

startupProbe가 성공하면 livenessProbe에 인계 됩니다.

startupProbe가 성공하지 못하면 pod의 restartPolicy에 의해 재시작 됩니다.

readiness probe와 liveness probe는 병행하여 사용할 수 있습니다. - k8s docs

• readiness : 준비되지 않은 컨테이너에 트래픽이 도달하지 않도록
• liveness : 컨테이너가 실패할 때 다시 시작될 수 있도록

위 와 같이 병행 사용이 가능하다고 합니다.

요약하면

1. livenessProbe only (initDelaySeconds)
2. livenessProbe & readinessProbe
3. livenessProbe & startupProbe

이렇다는건데

음....

1번은 뭐 단순히 지연시간만 설정

2번은 readinessProbe가 성공해야 트래픽을 받기 시작한다. 트래픽을 받기 시작하면 livenessProbe가 상태 감시 시작

3번은 startupProbe가 성공해야  livenessProbe가 활성화 되어 상태 감시를 시작

startupProbe를 사용하는 목적으로

단순히 container가 시작 되었어도 로드해야 하는 데이터가 많거나 초기화 과정이 오래 걸리는 앱 들에 사용된다고 하는데

뭐가 다른거죠? 또 테스트 케이스 만들어서 테스트 해보고 추리해야 할까요?

livenessProbe에 startupProbe가 붙어 있을 때랑 readinessProbe가 붙어 있을 때랑 뭐가 다른데에~~~~~~~~~~~~

상태머신 관점에서 보면 세 개 프로브 다 있어야 할거 같은데

• startupProbe 데이터 로드 완료
• readinessProbe 트래픽 수신 준비 완료
• livenessProbe 러닝 상태 감시

이것저것 사용해 보면서 무언가 알게 되면 좀 더 내용을 정리 해봐야겠습니다.