Kubernetes의 활동성 프로브는 위험할 수 있습니다.

메모. 번역: Zalando의 수석 엔지니어인 Henning Jacobs는 Kubernetes 사용자들 사이에서 활성(및 준비) 프로브의 목적과 올바른 사용을 이해하는 데 문제가 있음을 반복적으로 발견했습니다. 따라서 그는 이 방대한 노트에 자신의 생각을 정리했고, 이는 결국 K8s 문서의 일부가 될 것입니다.

Kubernetes에서 다음과 같이 알려진 상태 확인 활성 프로브 (즉, 문자 그대로 "생존 가능성 테스트" - 대략 번역), 꽤 위험할 수 있습니다. 가능하면 이러한 기능을 피하는 것이 좋습니다. 유일한 예외는 해당 기능이 정말 필요하고 해당 기능 사용의 세부 사항과 결과를 완전히 알고 있는 경우입니다. 이 간행물에서는 활성 상태 및 준비 상태 확인에 대해 설명하고 어떤 경우에도 알려줄 것입니다. 비용 그리고 당신은 그것을 사용해서는 안됩니다.

내 동료 Sandor는 최근 준비/활성 프로브 사용과 관련된 오류를 포함하여 자신이 직면하는 가장 일반적인 오류를 Twitter에서 공유했습니다.

잘못 구성됨 livenessProbe 고부하 상황(눈덩이 종료 + 잠재적으로 긴 컨테이너/애플리케이션 시작 시간)을 악화시키고 종속성 저하와 같은 다른 부정적인 결과를 초래할 수 있습니다. (또한보십시오 내 최근 기사 K3s+ACME 조합의 요청 수 제한에 대해). 활성 프로브가 외부 데이터베이스인 상태 확인과 결합되면 상황은 더욱 악화됩니다. 단일 DB 오류로 인해 모든 컨테이너가 다시 시작됩니다.!

일반 메시지 "활성 프로브를 사용하지 마세요" 이 경우에는 별로 도움이 되지 않으므로 준비 상태 및 활성 상태 확인의 목적이 무엇인지 살펴보겠습니다.

참고: 아래 테스트의 대부분은 원래 Zalando의 내부 개발자 문서에 포함되었습니다.

준비 상태 및 활동성 확인

Kubernetes는 다음과 같은 두 가지 중요한 메커니즘을 제공합니다. 활성 프로브 및 준비 프로브. HTTP 요청 보내기, TCP 연결 열기, 컨테이너에서 명령 실행 등의 작업을 주기적으로 수행하여 애플리케이션이 예상대로 작동하는지 확인합니다.

쿠버네티스는 준비 상태 프로브컨테이너가 트래픽을 수용할 준비가 된 시기를 이해합니다. 모든 컨테이너가 준비되면 포드를 사용할 준비가 된 것으로 간주됩니다. 이 메커니즘의 한 가지 용도는 Kubernetes 서비스(특히 Ingress)의 백엔드로 사용되는 Pod를 제어하는 ​​것입니다.

활동성 프로브 Kubernetes가 컨테이너를 다시 시작할 시기를 이해하도록 도와주세요. 예를 들어, 이러한 검사를 통해 애플리케이션이 한 위치에 멈춰 있을 때 교착 상태를 차단할 수 있습니다. 이 상태에서 컨테이너를 다시 시작하면 오류에도 불구하고 애플리케이션을 시작하는 데 도움이 되지만 계단식 오류가 발생할 수도 있습니다(아래 참조).

활성/준비 확인에 실패한 애플리케이션 업데이트를 배포하려고 하면 Kubernetes가 상태를 기다리면서 해당 롤아웃이 중단됩니다. Ready 모든 포드에서.

예

다음은 경로를 확인하는 준비 프로브의 예입니다. /health 기본 설정으로 HTTP를 통해(간격: 10 초, 시간 제한: 1 초, 성공 기준점: 1, 실패 임계값: 삼):

# часть общего описания deployment'а/стека
podTemplate:
  spec:
    containers:
    - name: my-container
      # ...
      readinessProbe:
        httpGet:
          path: /health
          port: 8080

추천

1. HTTP 엔드포인트(REST 등)가 있는 마이크로서비스의 경우 항상 준비 상태 프로브를 정의하십시오., 애플리케이션(포드)이 트래픽을 수락할 준비가 되었는지 확인합니다.
2. 준비 상태 프로브를 확인하세요. 실제 웹 서버 포트의 가용성을 다룹니다.:
   • "admin" 또는 "management"(예: 9090)라고 하는 관리 목적으로 포트를 사용하는 경우 readinessProbe, 기본 HTTP 포트(예: 8080)가 트래픽을 허용할 준비가 된 경우에만 엔드포인트가 OK를 반환하는지 확인하세요*.

     *저는 Zalando에서 이런 일이 발생하지 않은 사례를 최소 한 건 이상 알고 있습니다. readinessProbe '관리' 포트를 확인했는데, 캐시 로딩 문제로 인해 서버 자체가 작동을 시작하지 않았습니다.

   • 준비 상태 프로브를 별도의 포트에 연결하면 기본 포트의 과부하가 상태 확인에 반영되지 않을 수 있습니다. 즉, 서버의 스레드 풀이 가득 찼지만 상태 확인에서는 여전히 모든 것이 정상이라고 표시됩니다. ).
3. 확인 준비 상태 프로브를 통해 데이터베이스 초기화/마이그레이션 가능;
   • 이를 달성하는 가장 쉬운 방법은 초기화가 완료된 후에만 HTTP 서버에 연결하는 것입니다(예: 플라이웨이 등등.); 즉, 상태 확인 상태를 변경하는 대신 데이터베이스 마이그레이션이 완료될 때까지 웹 서버를 시작하지 마세요*.

     * 포드 외부의 초기화 컨테이너에서 데이터베이스 마이그레이션을 실행할 수도 있습니다. 나는 여전히 독립형 애플리케이션, 즉 애플리케이션 컨테이너가 외부 조정 없이 데이터베이스를 원하는 상태로 만드는 방법을 알고 있는 애플리케이션의 팬입니다.

4. 사용 httpGet 일반적인 상태 확인 엔드포인트를 통한 준비 상태 확인(예: /health).
5. 기본 검사 매개변수 이해 (interval: 10s, timeout: 1s, successThreshold: 1, failureThreshold: 3):
   • 기본 옵션은 포드가 준비되지 않은 약 30초 후(3번의 온전성 검사 실패).
6. 기술 스택(예: Java/Spring)에서 허용하는 경우 "관리" 또는 "관리"에 대해 별도의 포트를 사용하여 상태 및 메트릭 관리를 일반 트래픽과 분리합니다.
   • 하지만 포인트 2를 잊지 마세요.
7. 필요한 경우 준비 상태 프로브를 사용하여 캐시를 워밍업/로드하고 컨테이너가 워밍업될 때까지 503 상태 코드를 반환할 수 있습니다.
   • 나는 또한 당신이 새로운 수표를 읽어 보는 것이 좋습니다 startupProbe, 버전 1.16에 등장 (우리는 그것에 대해 러시아어로 썼습니다 여기에 - 대략. 번역).

주의 사항

1. 외부 의존성에 의존하지 마세요 (예: 데이터 웨어하우스) 준비/활성 테스트를 실행할 때 - 이로 인해 계단식 오류가 발생할 수 있습니다.
   • 예를 들어 하나의 Postgres 데이터베이스에 따라 10개의 포드가 있는 상태 저장 REST 서비스를 살펴보겠습니다. 검사가 DB에 대한 작동 중인 연결에 따라 달라지는 경우 네트워크/DB 측에 지연이 있으면 10개의 포드가 모두 실패할 수 있습니다. 일반적으로 모든 것이 가능한 것보다 더 나쁘게 끝난다.
   • Spring Data는 기본적으로 데이터베이스 연결을 확인합니다*.

     * 이는 Spring Data Redis의 기본 동작(적어도 내가 마지막으로 확인한 것임)으로 인해 "치명적인" 오류가 발생했습니다. Redis를 잠시 사용할 수 없게 되면 모든 포드가 "충돌"했습니다.

   • 이러한 의미에서 "외부"는 동일한 애플리케이션의 다른 포드를 의미할 수도 있습니다. 즉, 연속적인 충돌을 방지하기 위해 검사는 동일한 클러스터의 다른 포드 상태에 의존해서는 안 됩니다.
     • 분산 상태(예: 포드의 인메모리 캐싱)가 있는 애플리케이션의 경우 결과가 다를 수 있습니다.
2. 활성 프로브를 사용하지 마세요 포드의 경우(정말 필요하고 귀하가 포드 사용의 세부 사항과 결과를 완전히 알고 있는 경우는 예외입니다):
   • 활동성 프로브는 정지된 컨테이너를 복구하는 데 도움이 될 수 있지만 애플리케이션을 완전히 제어할 수 있으므로 정지된 프로세스 및 교착 상태와 같은 일은 이상적으로 발생하지 않아야 합니다. 가장 좋은 대안은 의도적으로 애플리케이션을 충돌시키고 이전의 안정된 상태로 되돌리는 것입니다.
   • 활성 여부 프로브가 실패하면 컨테이너가 다시 시작되고 이로 인해 로드 관련 오류의 결과가 악화될 가능성이 있습니다. 컨테이너를 다시 시작하면 가동 중지 시간(적어도 애플리케이션 시작 기간 동안, 예를 들어 30초 이상)이 발생하여 새로운 오류가 발생합니다. , 다른 컨테이너의 부하 증가 및 실패 가능성 증가 등
   • 외부 종속성과 결합된 활성 검사는 연쇄 실패를 위협하는 최악의 조합입니다. 데이터베이스 측에서 약간의 지연이 발생하면 모든 컨테이너가 다시 시작됩니다!
3. 활성 및 준비 상태 확인 매개변수 달라야합니다:
   • 상태 확인은 동일하지만 응답 임계값이 더 높은 활성 프로브를 사용할 수 있습니다(failureThreshold), 예를 들어 상태를 할당합니다. 준비되지 않은 3번의 시도 후, 10번의 시도 후에 활성 여부 프로브가 실패한 것으로 간주합니다.
4. 실행 검사를 사용하지 마세요, 이는 좀비 프로세스의 출현으로 이어지는 알려진 문제와 연관되어 있기 때문입니다.
   • 세부정보: 참조 Datadog 전문가의 프레젠테이션.

개요

• 준비 상태 프로브를 사용하여 포드가 트래픽을 수신할 준비가 된 시기를 확인합니다.
• 실제로 필요한 경우에만 활성 프로브를 사용하십시오.
• 준비 상태/활성 상태 프로브를 부적절하게 사용하면 가용성이 감소하고 연속적인 오류가 발생할 수 있습니다.

주제에 대한 추가 자료

• Kubernetes 문서: 활성 및 준비 프로브 구성;
• Kubernetes 활동성 및 준비 상태 프로브 재검토: 다른 발에 갇히지 않는 방법;
• NRE Labs 사후 분석 중단 (그는 livenessProbe에 대해서도 이야기합니다).

1년 2019월 09일 29차 업데이트

데이터베이스 마이그레이션을 위한 초기화 컨테이너 정보: 각주가 추가되었습니다.

EJ가 나한테 상기시켜줬어 PDB 정보: 활성 확인의 문제 중 하나는 Pod 간의 조정이 부족하다는 것입니다. 쿠버네티스는 포드 중단 예산(PDB) 애플리케이션에서 발생할 수 있는 동시 오류 수를 제한하기 위해 검사는 PDB를 고려하지 않습니다. 이상적으로는 K8s에 "테스트가 실패하면 하나의 포드를 다시 시작하되 상황이 더 악화되지 않도록 포드를 모두 다시 시작하지 마세요"라고 지시할 수 있습니다.

브라이언이 완벽하게 표현했어요: “무엇이 무엇인지 정확히 알고 있는 경우 활성도 조사를 사용하십시오. 가장 좋은 방법은 응용 프로그램을 종료하는 것입니다"(다시 말하지만, 너무 흥분하지 마세요).

2년 2019월 09일 29차 업데이트

사용 전 설명서 읽기에 대해: 해당 요청을 작성했습니다(기능 요청) 활성 프로브에 대한 문서를 추가합니다.

번역가의 추신

블로그에서도 읽어보세요.

• «Kubernetes: 포드 수명";
• «Google이 제시하는 컨테이너 사용에 대한 7가지 모범 사례";
• «컨테이너 기반 애플리케이션 설계를 위한 7가지 원칙".

출처 : habr.com