kubernetes에 3가지 종류의 프로브가 필요한 이유는 무엇입니까: startupProbe, readinessProbe, livityProbe.

kubernetes에 3가지 종류의 프로브가 필요한 이유는 무엇입니까: startupProbe, readinessProbe, livityProbe.

쿠버네티에서 3가지 다른 종류의 탐침이 필요한 이유는 무엇입니까?

• 시작프로브
• 준비 상태 프로브
• 라이브 프로브

이 주제에 대한 몇 가지 질문과 기사가 있습니다. 하지만 이것은 그렇게 명확하지 않다.

• 왜 3가지 다른 종류의 탐침이 필요한가?
• 사용 사례는 무엇입니까?
• 가장 좋은 관행은 무엇입니까?

---

이러한 3가지 프로브에는 3가지 다른 사용 사례가 있습니다. 그래서 3종류의 탐침이 필요합니다.

활력 탐사선

에 실패하면 포드가 다시 시작됩니다(고장에 대한 자세한 정보 참조).임계값).

사용 사례: 포드가 비활성화된 경우 포드를 다시 시작합니다.

모범 사례: 활성 탐침에는 기본 검사만 포함합니다. 다른 서비스(예: 데이터베이스)에 대한 연결 확인을 포함하지 마십시오. 체크가 완료되는 데 그리 오래 걸리지 않을 겁니다. 포드가 비활성 상태인 경우 항상 a를 지정하여 포드가 다시 시작되도록 하십시오.

시동 프로브

시동 후 포드를 사용할 수 있는지 확인합니다.

사용 사례: 시작 후 포드를 사용할 수 있는 즉시 포드로 트래픽을 전송합니다. 초기화할 때만 해당 포드가 호출되므로 완료하는 데 시간이 더 오래 걸릴 수 있습니다. 워밍업 작업을 호출할 수 있지만 초기화를 위해 컨테이너도 고려할 수 있습니다.

모범 사례: 포드를 시작하는 데 시간이 오래 걸리는 경우 를 지정합니다. 시작 및 활성 시도는 동일한 끝점을 사용할 수 있지만 시작 시 오류를 방지하는 덜 엄격한 실패 임계값을 가집니다.

준비 상태 프로브

점검과 달리 전체 라이프사이클 동안 포드를 사용할 수 있는지 여부를 확인합니다. 이와는 대조적으로 포드로의 트래픽만 중지됩니다. 이 실패하면 다시 시작되지 않습니다.

사용 사례: 다른 서비스(예: 데이터베이스)에 대한 연결이 실패하여 포드가 일시적으로 작동할 수 없고 포드가 나중에 복구될 경우 포드로 트래픽 전송을 중지합니다.

모범 사례: 다른 서비스에 대한 연결을 포함하여 필요한 모든 검사를 포함합니다. 그럼에도 불구하고 검사를 완료하는 데 너무 오래 걸리지는 않을 것입니다. 포드가 수신 요청을 제대로 처리할 수 있는 경우 항상 a를 지정하여 포드가 트래픽만 받도록 하십시오.

문서

• 에서는 세 가지 프로브 간의 차이를 매우 잘 설명합니다.
• 에서는 모든 구성 옵션에 대한 개요를 제공합니다.
• .
• 그 책은 모범 사례에 대한 가장 상세한 통찰력을 제공한다.

---

아래 이미지는 각각에 대한 사용 사례를 설명한 것 같습니다.

---

livityProbe, ReadinessProbe 및 startupProbe의 차이점

:

 livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
      initialDelaySeconds: 3
      periodSeconds: 3

• 용기가 시작되었고 활성 상태인지 여부, 즉 사용 가능 여부를 나타내는 데 사용됩니다.
• 지정된 예에서 요청이 실패하면 컨테이너를 다시 시작합니다.
• 제공되지 않은 경우 기본 상태는 성공입니다.

:

 readinessProbe:
      httpGet:
        path: /healthz
        port: 8080
      initialDelaySeconds: 3
      periodSeconds: 3

• 컨테이너가 트래픽을 처리할 준비가 되었는지 또는 사용할 준비가 되었는지 여부를 나타내는 데 사용됩니다.
• 데이터베이스 연결 또는 컨테이너가 작업을 수행하기 위해 의존하는 다른 서비스와 같은 종속성을 검사합니다.
• 지정된 예에서는 요청이 Success를 반환할 때까지 어떠한 트래픽도 처리하지 않습니다(Pod와 일치하는 모든 서비스의 끝점에서 Pod의 IP 주소를 제거함).
• Kubernetes는 롤링 업데이트 중에 준비 상태 프로브에 의존하며, 새 서비스가 트래픽을 받을 준비가 되었다고 선언할 때까지 이전 컨테이너를 계속 가동시킵니다.
• 제공되지 않은 경우 기본 상태는 성공입니다.

:

 startupProbe:
      httpGet:
        path: /healthz
        port: 8080
      initialDelaySeconds: 3
      periodSeconds: 3

• 컨테이너 내부의 응용 프로그램이 시작되었는지 여부를 나타내는 데 사용됩니다.
• 시동 프로브가 제공되면 다른 모든 프로브가 비활성화됩니다.
• 지정된 예에서 요청이 실패하면 컨테이너를 다시 시작합니다.
• 시동 프로브가 한 번 성공하면 활성 프로브가 이어받아 용기 교착 상태에 대한 빠른 응답을 제공합니다.
• 제공되지 않은 경우 기본 상태는 성공입니다.

더 확인해 보세요.

---

여기 우리가 앱에서 사용하고 있는 구체적인 예가 있다. 단일 조잡한 HTTP 상태 점검이 있습니다.

ports:
  - containerPort: 8080
    name: web-traffic

초기화

• 시작 속도가 느린 스프링 앱 - 30~120초 사이.
• 앱이 시작될 때까지 다른 시도를 실행하지 않도록 합니다.
• k8s가 충돌 루프에 들어가기 전에 최대 180초 동안 10초마다 확인합니다.

startupProbe:
  successThreshold: 1
  failureThreshold: 18
  periodSeconds: 10
  timeoutSeconds: 5
  httpGet:
    path: /management/health
    port: web-traffic

헬스 체크

• 앱이 정상인지(즉, HTTP 요청 수락) 확인하기 위해 10초마다 ping합니다.
• 두 번의 후속 ping에 실패하면 코드를 끊습니다(계단 계단식 방지).
• 트래픽을 다시 허용하려면 두 번의 후속 상태 검사를 통과해야 합니다.

readinessProbe:
  successThreshold: 2
  failureThreshold: 2
  periodSeconds: 10
  timeoutSeconds: 5
  httpGet:
    path: /management/health
    port: web-traffic

앱 사용 중지됨

• 앱이 30초 간격으로 3회 연속 상태 점검에 실패하면 컨테이너를 재부팅합니다. 아마도 자바에 힙 메모리가 부족한 것처럼 앱이 복구 불가능한 상태가 된 것 같다.

livenessProbe:
  successThreshold: 1
  failureThreshold: 3
  periodSeconds: 30
  timeoutSeconds: 5
  httpGet:
    path: /management/health
    port: web-traffic