상태 확인 구성

Google Distributed Cloud (GDC) 에어갭은 백엔드 인스턴스가 트래픽에 적절하게 응답하는지 확인하는 상태 점검 메커니즘을 제공합니다. 이 문서에서는 부하 분산기의 상태 점검을 만들고 사용하는 방법을 설명합니다.

달리 명시되지 않는 한 Google Cloud 상태 점검은 상태 점검 리소스에 지정된 매개변수에 따라 백엔드에 연결되는 전용 소프트웨어 태스크로 구현됩니다. 각 연결 시도를 프로브라고 합니다. Google Cloud 는 각 프로브의 성공 또는 실패를 기록합니다.

각 백엔드의 상태는 연속으로 성공 또는 실패한 구성 가능 프로브 수에 따라 결정됩니다. 즉, 백엔드를 정상으로 표시하는 데 필요한 연속 프로브 성공 횟수와 비정상으로 표시하는 데 필요한 연속 실패 횟수를 구성합니다.

이 상태는 백엔드가 새 요청 또는 연결을 수신할 수 있는지 여부를 나타냅니다. 상태 점검에서 비정상으로 식별된 백엔드는 부하 분산기를 통해 트래픽을 수신하지 않습니다. 성공적인 프로브의 기준을 정의합니다. 자세한 내용은 상태 점검 작동 방식 섹션을 참고하세요.

참고: 여기에 설명된 상태 점검 메커니즘은 VM 워크로드 백엔드에만 적용되며 포드에는 적용되지 않습니다. Kubernetes 컨테이너 프로브를 사용하여 포드의 HTTP(S) 상태 확인을 구성할 수 있습니다.

상태 확인 프로토콜

상태 점검은 다음 프로토콜을 지원합니다.

• TCP
• HTTP
• HTTPS

상태 점검을 선택합니다.

상태 점검이 부하 분산기 유형 및 백엔드 유형과 호환되어야 합니다. 상태 점검을 선택할 때 다음 요소를 고려하세요.

• 프로토콜: GDC가 백엔드를 프로브하는 데 사용하는 프로토콜입니다. 지원되는 프로토콜은 TCP, HTTP, HTTPS입니다. TCP 프로토콜은 백엔드에 대한 연결을 검증하는 기본 상태 점검에 유용하며, HTTP 및 HTTPS 프로토콜은 이미 HTTP 또는 HTTPS 워크로드를 실행 중인 VM에 대해 더 세부적인 상태 점검 메커니즘을 제공합니다.
• 포트 사양: GDC가 프로토콜과 함께 사용하여 백엔드의 상태를 프로브하는 포트입니다. 상태 점검에 사용할 포트를 지정해야 합니다.
• 카테고리: 상태 점검은 전역 또는 영역일 수 있습니다. 전역 상태 점검은 GDC 배포의 모든 영역에 걸쳐 확장되는 반면 영역 상태 점검은 하나의 영역에 해당합니다.

상태 확인 작동 방법

다음 섹션에서는 상태 점검의 작동 방법을 설명합니다.

프로브

상태 점검을 설정할 때 각 프로브가 연결된 엔드포인트의 상태를 평가하는 빈도를 관리하는 기본 설정을 정의하거나 수락합니다. 이러한 설정은 부하 분산기가 구성된 기준을 사용하여 비정상으로 간주되는 백엔드로의 요청 라우팅을 중지하므로 매우 중요합니다. 프로브는 평가를 지속하고 다시 정상으로 간주되면 백엔드로 트래픽 전송을 재개합니다.

상태 점검 설정은 백엔드 서비스 또는 대상 풀의 모든 백엔드에 균일하게 적용되며 백엔드별로 구성할 수 없습니다.

구성 플래그	설명	기본값
확인 간격 check-interval	한 프로버에서 실행한 한 프로브의 시작부터 같은 프로버에서 실행한 다음 프로브의 시작까지의 시간 (단위: 초)입니다.	5s(5초)
timeoutSec timeoutSec	실패를 선언하기 전에 프로브를 기다리는 시간 (초)입니다.	5s(5초)
healthyThreshold healthyThreshold	엔드포인트가 정상으로 간주되도록 하기 위해 성공해야 하는 순차적 프로브의 수입니다.	2
unhealthyThreshold unhealthyThreshold	엔드포인트가 비정상으로 간주되도록 하기 위해 실패해야 하는 순차적 프로브의 수입니다.	2

HTTP 및 HTTPS 상태 점검의 성공 기준

HTTP 및 HTTPS 상태 점검의 경우 상태 점검이 시간 초과되기 전에 HTTP 200 (OK) 상태 코드가 응답에 성공해야 합니다. 리디렉션 (예: 301, 302)을 포함한 다른 HTTP 응답 코드는 비정상으로 간주됩니다.

HTTP 200 (OK) 응답 코드를 요구하는 것 외에도 다음을 수행할 수 있습니다.

• 각 상태 점검 프로버를 구성하여 기본 요청 경로인 / 대신 특정 요청 경로로 HTTP 요청을 전송합니다.
• HTTP 응답 본문에 예상 응답 문자열이 있는지 확인하도록 각 상태 확인 프로버를 구성합니다. 예상 응답 문자열은 HTTP 응답 본문의 처음 1,024바이트 내에 있는 단일 바이트 인쇄 가능한 ASCII 문자로만 구성되어야 합니다.

다음 표에는 HTTP 및 HTTPS 상태 확인에 사용할 수 있는 유효한 requestPath 및 response 필드 조합이 나와 있습니다.

구성 플래그	프로버 동작	성공 기준
RequestPath도 Response도 지정되지 않음	프로버는 /를 요청 경로로 사용합니다.	HTTP 200 (OK) 응답 코드만 해당합니다.
RequestPath와 Response가 모두 지정됨	프로버는 구성된 요청 경로를 사용합니다.	HTTP 200 (OK) 응답 코드 및 HTTP 응답 본문의 처음 1,024 ASCII 문자가 예상 응답 문자열과 일치해야 합니다.
Response만 지정됨	프로버는 /를 요청 경로로 사용합니다.	HTTP 200 (OK) 응답 코드 및 HTTP 응답 본문의 처음 1,024 ASCII 문자가 예상 응답 문자열과 일치해야 합니다.
RequestPath만 지정됨	프로버는 구성된 요청 경로를 사용합니다.	HTTP 200 (OK) 응답 코드만 해당합니다.

TCP 상태 점검의 성공 기준

TCP 상태 점검에는 다음과 같은 기본 성공 기준이 있습니다.

• TCP 상태 점검의 경우 상태 점검 프로버가 상태 점검 제한 시간 전에 백엔드에 대한 TCP 연결을 성공적으로 열어야 합니다.
• TCP 상태 점검의 경우 다음 방법 중 하나로 TCP 연결을 닫아야 합니다.
  • 상태 확인 프로버가 FIN 또는 RST (재설정) 패킷을 전송합니다.
  • 백엔드에서 FIN 패킷을 전송합니다.
  • 백엔드가 TCP RST 패킷을 전송하는 경우 상태 확인 프로버가 이미 FIN 패킷을 전송한 경우 프로브가 실패한 것으로 간주될 수 있습니다.

시작하기 전에

상태 점검 프로브를 구성하려면 다음이 필요합니다.

• 부하 분산기를 구성할 프로젝트를 소유해야 합니다. 자세한 내용은 프로젝트 만들기를 참조하세요.

• 필요한 ID 및 액세스 역할:

  • 조직 IAM 관리자에게 부하 분산기 관리자 (load-balancer-admin) 역할을 부여해 달라고 요청하세요.
  • 전역 ILB의 경우 조직 IAM 관리자에게 전역 부하 분산기 관리자 (global-load-balancer-admin) 역할을 부여해 달라고 요청하세요. 자세한 내용은 사전 정의된 역할 설명을 참고하세요.

참고: HealthCheck 객체는 VM 엔드포인트에 연결된 부하 분산기에만 적용됩니다.

상태 점검 만들기 및 관리

GDC는 전역 및 영역 상태 점검을 지원합니다.

HealthCheck API

HealthCheck 객체를 전역 또는 영역으로 구성할 수 있습니다. 전역 HealthCheck 객체는 전역 부하 분산기 구성에 사용되고, 영역 HealthCheck 객체는 영역 부하 분산기 구성에 사용됩니다. 두 유형의 이름과 사양은 동일합니다. 하지만 apiVersion 값과 API 서버는 다릅니다.

• 영역 apiVersion: networking.gdc.goog
• 전역 apiVersion: networking.global.gdc.goog

gdcloud CLI를 사용하여 상태 점검을 만들고 관리할 수도 있습니다.

전역 HealthCheck 만들기

다음 예에서는 API를 사용하여 HealthCheck를 만드는 방법을 보여줍니다.

  kubectl --kubeconfig GLOBAL_ORG_ADMIN_CLUSTER_KUBECONFIG apply -f - <<EOF 
  apiVersion: networking.global.gdc.goog/v1 
  kind: HealthCheck 
  metadata: 
    namespace: PROJECT 
    name: my-hc 
  spec: 
    httpHealthCheck: 
      port: PORT 
      host: HOST 
      requestPath: requestPath 
      response: responseT 
  EOF

영역별 HealthCheck 만들기

다음 예에서는 API를 사용하여 HealthCheck를 만드는 방법을 보여줍니다.

  kubectl --kubeconfig MANAGEMENT_API_SERVER_KUBECONFIG apply -f - <<EOF 
  apiVersion: networking.gdc.goog/v1
  kind: HealthCheck
  metadata:
    namespace: PROJECT
    name: my-hc
  spec:
    httpHealthCheck:
      port: PORT
      host: HOST
      requestPath: requestPath 
      response: response 
  EOF 

상태 점검을 부하 분산기에 연결하려면 다음을 참고하세요.

• 내부 부하 분산기 구성
• 외부 부하 분산기 구성

구성 확인

구성이 올바른지 확인하려면 HealthCheck 객체의 Ready 조건을 확인하세요. 이 조건은 구성 오류를 나타냅니다. 또한 필드가 필요한 HealthCheck 설정을 정확하게 반영하는지 확인합니다.

추가 사용법 참고사항:

다음 섹션에는 Google Cloud에서 상태 점검을 사용하는 방법에 대한 추가 참고사항이 포함되어 있습니다.

인증서 및 상태 확인

백엔드에서 인증서를 요구하는 HTTPS와 같은 프로토콜의 경우

• 인증서는 자체 서명하거나 인증 기관 (CA)에서 발급받을 수 있습니다.
• 만료되었거나 미래 날짜가 지정된 인증서도 허용됩니다.

헤더

HTTP 또는 HTTPS 프로토콜의 상태 점검을 구성할 때 --host 플래그를 사용하여 HTTP Host 헤더를 지정할 수 있습니다.

부하 분산기는 구성한 맞춤 요청 헤더를 상태 점검 프로브가 아닌 클라이언트 요청에만 추가합니다. 따라서 백엔드에 상태 점검 패킷에 없는 특정 승인 헤더가 필요한 경우 상태 점검이 실패할 수 있습니다.

상태 확인 예시

다음 매개변수로 상태 점검이 구성된 경우

• 간격: 30초
• 제한 시간: 5초
• 프로토콜: HTTP
• 비정상 기준: 2(기본값)
• 정상 기준: 2(기본값)

상태 점검은 다음과 같이 작동합니다.

• 각 상태 점검 프로버는 다음을 수행합니다.
  1. 소스 IP 주소에서 백엔드 인스턴스로의 HTTP 연결을 30초 간격으로 시작합니다.
  2. HTTP 200 (OK) 상태 코드 (HTTP 및 HTTPS 프로토콜의 지정된 성공 기준)가 반환될 때까지 최대 5초 동안 기다립니다.
• 하나 이상의 상태 점검 프로브 시스템이 다음을 수행하면 백엔드가 비정상으로 간주됩니다.
  1. 연결 거부, 연결 시간 초과 또는 소켓 시간 초과로 인해 연속된 두 프로브에 대해 HTTP 200 (OK) 응답을 수신하지 않습니다.
  2. 프로토콜 특정 성공 기준과 일치하지 않는 응답이 두 번 연속으로 수신됩니다.
• 상태 점검 프로브 시스템 중 하나 이상이 프로토콜 특정 성공 기준을 충족하는 응답을 두 번 연속으로 수신하면 백엔드가 정상으로 간주됩니다.

이 예시에서 각 프로버는 연결을 30초 마다 시작합니다. 제한 시간 기간에 관계없이 (연결 제한 시간이 초과되었는지 여부에 관계없이) 30초 간격으로 프로버 연결이 시도됩니다. 즉, 제한 시간이 이 간격보다 작거나 같아야 하고, 제한 시간을 늘려도 간격은 절대로 늘어나지 않습니다.

제한사항

1. GDC 상태 점검은 VM 엔드포인트만 서비스합니다.
2. 상태 점검이 있는 부하 분산기는 포드와 VM을 혼합 백엔드로 구성할 수 없습니다. 부하 분산기의 엔드포인트는 포드 또는 VM으로만 구성되어야 합니다. 현재 부하 분산기는 엔드포인트로 포드 또는 VM만으로 구성되어야 합니다.
3. 부하 분산기 및 연결된 상태 점검의 변경 가능성은 아직 지원되지 않습니다.