컨테이너 상태 점검(서비스)

신규 및 기존 Cloud Run 서비스에 대하여 HTTP 및 gRPC 활성 프로브와 더불어 HTTP, TCP, gRPC 시작 프로브를 구성할 수 있습니다. 구성은 프로브 유형에 따라 달라집니다.

TCP 시작 프로브는 새 Cloud Run 서비스에 대해 자동으로 구성됩니다. 자세한 내용은 기본 TCP 시작 프로브를 참조하세요.

중요: HTTP 프로브를 사용하는 경우 서비스에서 Cloud Run 기본값인 HTTP/1을 사용해야 합니다. HTTP/2는 HTTP 상태 점검 프로브에 지원되지 않습니다.

사용 사례

다음 두 가지 유형의 상태 점검 프로브를 구성할 수 있습니다.

• 활성 프로브는 컨테이너를 다시 시작할지 여부를 결정합니다.

  • 이 경우 컨테이너를 다시 시작하면 버그 발생 시 서비스 가용성이 증가할 수 있습니다.
  • 활성 프로브는 다른 방법으로는 복구할 수 없는 개별 인스턴스를 다시 시작하기 위한 것입니다. 예를 들어 서비스가 실행 중이지만 진행할 수 없는 교착 상태를 포착하는 경우와 같이 복구할 수 없는 인스턴스 장애에 주로 사용해야 합니다.

• 시작 프로브는 컨테이너가 시작되었고 트래픽을 수락할 준비가 되었는지 여부를 확인합니다.

  • 시작 프로브를 구성하면 서비스 시작을 간섭하지 않도록 시작 프로브에서 컨테이너가 시작되었음을 확인할 때까지 활성 확인이 중지됩니다.
  • 시작 프로브는 컨테이너가 가동 및 실행되기 전에 조기 종료를 방지하므로 느리게 시작되는 컨테이너에 활성 확인을 사용하는 경우 특히 유용합니다.

서비스에서 시작 또는 활성 프로브가 반복적으로 실패하는 경우 Cloud Run은 제어되지 않는 비정상 종료 루프를 방지하기 위해 인스턴스 재시작을 제한합니다.

기본 TCP 시작 프로브

TCP 시작 프로브는 기본값을 사용하여 새 Cloud Run 서비스에 대해 자동으로 구성됩니다. 기본 프로브는 다음과 동일합니다.

startupProbe:
  tcpSocket:
    port: CONTAINER_PORT
  timeoutSeconds: 240
  periodSeconds: 240
  failureThreshold: 1

CONTAINER_PORT를 서비스에 설정된 컨테이너 포트로 바꿉니다.

이 페이지의 프로브 구성 섹션의 안내에 따라 이러한 기본값을 변경할 수 있습니다.

청구 및 CPU 할당

• 모든 프로브에 CPU가 할당됩니다.
• 모든 프로브에는 CPU 및 메모리 사용량 소비가 청구되지만 요청 기반 요금은 없습니다.

프로브 요구사항 및 동작

프로브 유형	요구사항	동작
TCP 시작	없음	기본적으로 Cloud Run은 TCP 연결을 만들어 지정된 포트에서 TCP 소켓을 엽니다. Cloud Run에서 연결을 설정할 수 없으면 실패한 것입니다. 시작 프로브가 240초를 초과할 수 없는 지정된 시간(failureThreshold * periodSeconds) 내에 성공하지 못하면 컨테이너가 종료됩니다. TCP 기본값도 참조하세요.
HTTP 시작	HTTP 상태 점검 엔드포인트 만들기 HTTP/1 사용	프로브 구성 후 Cloud Run은 서비스 상태 점검 엔드포인트(예: /ready)에 HTTP GET 요청을 수행합니다. 200과 400 사이의 응답은 성공이고, 다른 모든 응답은 실패를 나타냅니다. 시작 프로브가 지정된 시간(failureThreshold * periodSeconds), 즉 240초 이내에 성공하지 못하면 컨테이너가 종료됩니다. HTTP 활성 프로브를 구성한 경우 지정된 시간 내에 HTTP 시작 프로브가 성공하면 HTTP 활성 프로브가 시작됩니다.
HTTP 활성	HTTP 상태 점검 엔드포인트 만들기 HTTP/1 사용	활성 프로브는 시작 프로브가 성공한 후에만 시작됩니다. 프로브가 구성되고 모든 시작 프로브가 성공하면 Cloud Run이 서비스 상태 점검 엔드포인트(예: /health)에 HTTP GET 요청을 수행합니다. 200과 400 사이의 응답은 성공이고, 다른 모든 응답은 실패를 나타냅니다. 활성 프로브가 지정된 시간(failureThreshold * periodSeconds) 내에 성공하지 못하면 컨테이너가 SIGKILL 신호를 사용하여 종료됩니다. 컨테이너에서 아직 처리 중인 나머지 요청은 HTTP 상태 코드 503으로 종료됩니다. 컨테이너가 종료되면 Cloud Run 자동 확장이 새 컨테이너 인스턴스를 시작합니다.
gRPC 시작	Cloud Run 서비스에서 gRPC 상태 점검 프로토콜 구현하기	시작 프로브가 지정된 시간(failureThreshold * periodSeconds), 즉 240초 이내에 성공하지 못하면 컨테이너가 종료됩니다.
gRPC 활성	Cloud Run 서비스에서 gRPC 상태 점검 프로토콜 구현하기	gRPC 시작 프로브를 구성하면 시작 프로브가 성공한 후에만 활성 프로브가 시작됩니다. 활성 프로브가 구성되고 모든 시작 프로브가 성공하면 Cloud Run이 서비스에 상태 점검 요청을 수행합니다. 활성 프로브가 지정된 시간(failureThreshold * periodSeconds) 내에 성공하지 못하면 컨테이너가 SIGKILL 신호를 사용하여 종료됩니다. 컨테이너가 종료되면 Cloud Run 자동 확장이 새 컨테이너 인스턴스를 시작합니다.

프로브 구성

구성을 변경하면 새 버전이 생성됩니다. 이를 변경하는 명시적 업데이트가 없으면 이후 버전에도 이 구성 설정이 자동으로 적용됩니다.

Google Cloud 콘솔, YAML, Terraform을 사용하여 HTTP, TCP, gRPC 프로브를 구성할 수 있습니다.

Console

중요: HTTP 프로브용 Cloud Run 서비스를 구성하는 경우 프로브에 응답하도록 서비스 코드에 HTTP 상태 점검 엔드포인트도 추가해야 합니다. gRPC 프로브를 구성하는 경우 Cloud Run 서비스에서 gRPC 상태 점검 프로토콜도 구현해야 합니다.

1. Google Cloud 콘솔에서 Cloud Run 페이지로 이동합니다.

   Cloud Run으로 이동

2. 새 서비스의 경우 컨테이너, 볼륨, 네트워킹, 보안을 확장하여 상태 점검 옵션을 표시합니다. 기존 서비스의 경우 구성하려는 서비스를 클릭한 후 수정 및 배포를 클릭하여 상태 점검 옵션을 표시합니다.

3. 컨테이너 섹션에서상태 점검으로 이동하고 상태 점검 추가를 클릭하여 상태 점검 추가 구성 패널을 엽니다.

4. 상태 점검 유형 선택 메뉴에서 추가하려는 상태 점검 유형(예: 시작 또는 활성)을 선택합니다.

5. 프로브 유형 선택 메뉴에서 사용할 프로브 유형을 선택합니다(예: HTTP 또는 gRPC). 그러면 프로브 구성 양식이 표시됩니다.

6. 프로브 구성은 프로브 유형에 따라 다릅니다. 프로브 설정을 구성합니다.

   • HTTP 프로브를 사용하는 경우:
     • 서비스가 HTTP/2가 아닌 HTTP/1(Cloud Run 기본값)을 사용하는지 확인합니다.
     • 경로 필드를 사용하여 엔드포인트의 상대 경로를 지정합니다(예: /).
     • HTTP 헤더 체크박스를 선택하여 선택적 커스텀 헤더를 지정합니다. 그런 다음 이름 필드에 헤더 이름을 지정하고 값 필드에 헤더 값을 지정합니다. HTTP 헤더 추가를 클릭하여 헤더를 더 지정합니다.
   • 포트의 경우 서비스에 사용되는 컨테이너 포트를 지정합니다.
   • 초기 지연의 경우 첫 번째 프로브를 수행하기 전에 컨테이너가 시작된 후 대기하는 시간(초)을 지정합니다. 0~240초 사이의 값을 지정하세요. 기본값은 0초입니다.
   • 기간에 프로브를 수행할 시간(초)을 지정합니다. 예를 들어 2초마다 프로브를 수행하는 경우 2로 바꿉니다. 1~240초 사이의 값을 지정하세요. 기본값은 10초입니다.
   • 실패 기준에 대해 컨테이너를 종료하기 전에 프로브를 재시도할 횟수를 지정합니다. 기본값은 3입니다.
   • 제한 시간에 프로브가 타임아웃될 때까지 기다릴 시간(초)을 지정합니다. 이 값은 periodSeconds에 지정된 값을 초과할 수 없습니다. 1~240 사이의 값을 지정하세요. 기본값은 1입니다.

7. 추가를 클릭하여 새 기준점을 추가합니다.

YAML

중요: HTTP 프로브용 Cloud Run 서비스를 구성하는 경우 프로브에 응답하도록 서비스 코드에 엔드포인트도 추가해야 합니다. gRPC 프로브를 구성하는 경우 Cloud Run 서비스에서 gRPC 상태 점검 프로토콜도 구현해야 합니다.

TPC 시작

1. 새 서비스를 만드는 경우에는 이 단계를 건너뜁니다. 기존 서비스를 업데이트하는 경우 YAML 구성을 다운로드합니다.

   gcloud run services describe SERVICE --format export > service.yaml

2. 다음과 같이 startupProbe 속성을 구성합니다.

   apiVersion: serving.knative.dev/v1
   kind: Service
   metadata:
    name: SERVICE
   spec:
    template:
      metadata:
      spec:
        containers:
        - image: IMAGE_URL
          startupProbe:
            tcpSocket:
              port: CONTAINER_PORT
            initialDelaySeconds: DELAY
            timeoutSeconds: TIMEOUT
            failureThreshold: THRESHOLD
            periodSeconds: PERIOD

   다음과 같이 바꿉니다.

   • SERVICE: Cloud Run 서비스 이름입니다.
   • IMAGE_URL을 컨테이너 이미지에 대한 참조(예: us-docker.pkg.dev/cloudrun/container/hello:latest)로 바꿉니다. Artifact Registry를 사용하는 경우 저장소 REPO_NAME이 이미 생성되어 있어야 합니다. URL의 형식은 LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG입니다.
   • (선택사항) CONTAINER_PORT: 서비스에 사용되는 컨테이너 포트로 설정해야 합니다.
   • DELAY: 첫 번째 프로브를 수행하기 전에 컨테이너가 시작된 후 대기하는 시간(초). 0~240초 사이의 값을 지정합니다. 기본값은 0초입니다.
   • (선택사항) TIMEOUT: 프로브가 타임아웃될 때까지 기다리는 시간(초). 이 값은 periodSeconds에 지정된 값을 초과할 수 없습니다. 1~240 사이의 값을 지정하세요. 기본값은 1입니다.
   • THRESHOLD: 컨테이너를 종료하기 전에 프로브를 재시도할 횟수입니다. 기본값은 3입니다.
   • PERIOD: 프로브를 수행할 시간(초). 예를 들어 2초마다 프로브를 수행하는 경우 2로 바꿉니다. 1~240초 사이의 값을 지정하세요. 기본값은 10초입니다.
3. 다음 명령어를 사용하여 서비스를 만들거나 업데이트합니다.

   gcloud run services replace service.yaml

HTTP 시작

1. 새 서비스를 만드는 경우에는 이 단계를 건너뜁니다. 기존 서비스를 업데이트하는 경우 YAML 구성을 다운로드합니다.

   gcloud run services describe SERVICE --format export > service.yaml

2. 서비스가 HTTP/2가 아닌 HTTP/1(Cloud Run 기본값)을 사용하는지 확인합니다.

3. 다음과 같이 startupProbe 속성을 구성합니다.

   apiVersion: serving.knative.dev/v1
   kind: Service
   metadata:
     name: SERVICE
   spec:
     template:
       metadata:
       spec:
         containers:
         - image: IMAGE_URL
           startupProbe:
             httpGet:
               path: PATH
               port: CONTAINER_PORT
               httpHeaders:
                 - name: HEADER_NAME
                   value: HEADER_VALUE
             initialDelaySeconds: DELAY
             timeoutSeconds: TIMEOUT
             failureThreshold: THRESHOLD
             periodSeconds: PERIOD

   다음과 같이 바꿉니다.

   • SERVICE: Cloud Run 서비스 이름입니다.
   • IMAGE_URL을 컨테이너 이미지에 대한 참조(예: us-docker.pkg.dev/cloudrun/container/hello:latest)로 바꿉니다. Artifact Registry를 사용하는 경우 저장소 REPO_NAME이 이미 생성되어 있어야 합니다. URL의 형식은 LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG입니다.
   • PATH: HTTP 엔드포인트의 상대 경로(예: /ready)
   • (선택사항) CONTAINER_PORT: 서비스에 사용되는 컨테이너 포트로 설정해야 합니다.
   • (선택사항) httpHeaders는 다음과 같이 HEADER_NAME 및 HEADER_VALUE 필드를 사용하여 여러 개의 또는 반복되는 커스텀 헤더를 제공할 수 있습니다.
   • (선택사항) DELAY: 첫 번째 프로브를 수행하기 전에 컨테이너가 시작된 후 대기하는 시간(초). 0~240초 사이의 값을 지정합니다. 기본값은 0초입니다.
   • (선택사항) TIMEOUT: 프로브가 타임아웃될 때까지 기다리는 시간(초). 이 값은 periodSeconds에 지정된 값을 초과할 수 없습니다. 1~240 사이의 값을 지정하세요. 기본값은 1입니다.
   • (선택사항) THRESHOLD: 컨테이너를 종료하기 전에 프로브를 재시도할 횟수입니다. 기본값은 3입니다.
   • (선택사항) PERIOD: 프로브를 수행할 시간(초). 예를 들어 2초마다 프로브를 수행하는 경우 2로 바꿉니다. 1~240초 사이의 값을 지정하세요. 기본값은 10초입니다.
4. 다음 명령어를 사용하여 서비스를 만들거나 업데이트합니다.

   gcloud run services replace service.yaml

HTTP 활성

1. 새 서비스를 만드는 경우에는 이 단계를 건너뜁니다. 기존 서비스를 업데이트하는 경우 YAML 구성을 다운로드합니다.

   gcloud run services describe SERVICE --format export > service.yaml

2. 서비스가 HTTP/2가 아닌 HTTP/1(Cloud Run 기본값)을 사용하는지 확인합니다.

3. 다음과 같이 livenessProbe 속성을 구성합니다.

   apiVersion: serving.knative.dev/v1
     kind: Service
     metadata:
       name: SERVICE
     spec:
       template:
         metadata:
         spec:
           containers:
           - image: IMAGE_URL
             livenessProbe:
               httpGet:
                 path: PATH
                 port: CONTAINER_PORT
                 httpHeaders:
                   - name: HEADER_NAME
                     value: HEADER_VALUE
               initialDelaySeconds: DELAY
               timeoutSeconds: TIMEOUT
               failureThreshold: THRESHOLD
               periodSeconds: PERIOD

   다음과 같이 바꿉니다.

   • SERVICE: Cloud Run 서비스 이름입니다.
   • IMAGE_URL을 컨테이너 이미지에 대한 참조(예: us-docker.pkg.dev/cloudrun/container/hello:latest)로 바꿉니다. Artifact Registry를 사용하는 경우 저장소 REPO_NAME이 이미 생성되어 있어야 합니다. URL의 형식은 LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG입니다.
   • PATH: HTTP 엔드포인트의 상대 경로(예: /ready)
   • (선택사항) CONTAINER_PORT: 서비스에 사용되는 컨테이너 포트로 설정해야 합니다.
   • (선택사항) httpHeaders는 다음과 같이 HEADER_NAME 및 HEADER_VALUE 필드를 사용하여 여러 개의 또는 반복되는 커스텀 헤더를 제공할 수 있습니다.
   • (선택사항) DELAY: 첫 번째 프로브를 수행하기 전에 컨테이너가 시작된 후 대기하는 시간(초). 0~240초 사이의 값을 지정합니다. 기본값은 0초입니다.
   • (선택사항) TIMEOUT: 프로브가 타임아웃될 때까지 기다리는 시간(초). 이 값은 periodSeconds에 지정된 값을 초과할 수 없습니다. 1~3,600 사이의 값을 지정하세요. 기본값은 1입니다.
   • (선택사항) THRESHOLD: 컨테이너를 종료하기 전에 프로브를 재시도할 횟수입니다. 기본값은 3입니다.
   • (선택사항) PERIOD: 프로브를 수행할 시간(초). 예를 들어 2초마다 프로브를 수행하는 경우 2로 바꿉니다. 1~3600초 사이의 값을 지정하세요. 기본값은 10초입니다.
4. 다음 명령어를 사용하여 서비스를 만들거나 업데이트합니다.

   gcloud run services replace service.yaml

gRPC 시작

1. 새 서비스를 만드는 경우에는 이 단계를 건너뜁니다. 기존 서비스를 업데이트하는 경우 YAML 구성을 다운로드합니다.

   gcloud run services describe SERVICE --format export > service.yaml

2. 다음과 같이 startupProbe 속성을 구성합니다.

   apiVersion: serving.knative.dev/v1
     kind: Service
     metadata:
       name: SERVICE
     spec:
       template:
         metadata:
         spec:
           containers:
           - image: IMAGE_URL
             startupProbe:
               grpc:
                 service: GRPC_SERVICE
                 port: CONTAINER_PORT
               initialDelaySeconds: DELAY
               timeoutSeconds: TIMEOUT
               failureThreshold: THRESHOLD
               periodSeconds: PERIOD

   다음과 같이 바꿉니다.

   • SERVICE: Cloud Run 서비스 이름입니다.
   • IMAGE_URL을 컨테이너 이미지에 대한 참조(예: us-docker.pkg.dev/cloudrun/container/hello:latest)로 바꿉니다. Artifact Registry를 사용하는 경우 저장소 REPO_NAME이 이미 생성되어 있어야 합니다. URL의 형식은 LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG입니다.
   • GRPC_SERVICE: 상태 점검을 전송할 gRPC 서비스 이름
   • (선택사항) CONTAINER_PORT: 서비스에 사용되는 컨테이너 포트로 설정해야 합니다.
   • (선택사항) DELAY: 첫 번째 프로브를 수행하기 전에 컨테이너가 시작된 후 대기하는 시간(초). 0~240초 사이의 값을 지정하세요. 기본값은 0초입니다.
   • (선택사항) TIMEOUT을 프로브가 타임아웃될 때까지 기다리는 시간(초)으로 바꿉니다. 이 값은 periodSeconds에 지정된 값을 초과할 수 없습니다. 1~240 사이의 값을 지정하세요. 기본값은 1입니다.
   • (선택사항) THRESHOLD: 컨테이너를 종료하기 전에 프로브를 재시도할 횟수입니다. 기본값은 3입니다.
   • (선택사항) PERIOD: 프로브를 수행할 시간(초). 예를 들어 2초마다 프로브를 수행하는 경우 2로 바꿉니다. 1~240초 사이의 값을 지정하세요. 기본값은 10초입니다.
3. 다음 명령어를 사용하여 서비스를 만들거나 업데이트합니다.

   gcloud run services replace service.yaml

gRPC 활성

1. 새 서비스를 만드는 경우에는 이 단계를 건너뜁니다. 기존 서비스를 업데이트하는 경우 YAML 구성을 다운로드합니다.

   gcloud run services describe SERVICE --format export > service.yaml

2. 다음과 같이 livenessProbe 속성을 구성합니다.

   apiVersion: serving.knative.dev/v1
     kind: Service
     metadata:
       name: SERVICE
     spec:
       template:
         metadata:
         spec:
           containers:
           - image: IMAGE_URL
             livenessProbe:
               grpc:
                 port: CONTAINER_PORT
                 service: GRPC_SERVICE
               initialDelaySeconds: DELAY
               timeoutSeconds: TIMEOUT
               failureThreshold: THRESHOLD
               periodSeconds: PERIOD

   다음과 같이 바꿉니다.

   • SERVICE: Cloud Run 서비스 이름입니다.
   • IMAGE_URL을 컨테이너 이미지에 대한 참조(예: us-docker.pkg.dev/cloudrun/container/hello:latest)로 바꿉니다. Artifact Registry를 사용하는 경우 저장소 REPO_NAME이 이미 생성되어 있어야 합니다. URL의 형식은 LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG입니다.
   • (선택사항) CONTAINER_PORT: 서비스에 사용되는 컨테이너 포트로 설정해야 합니다.
   • GRPC_SERVICE: 상태 점검을 전송할 gRPC 서비스 이름
   • (선택사항) DELAY를 첫 번째 프로브를 수행하기 전에 컨테이너가 시작된 후 대기하는 시간(초)으로 바꿉니다. 0~240초 사이의 값을 지정합니다. 기본값은 0초입니다.
   • (선택사항) TIMEOUT: 프로브가 타임아웃될 때까지 기다리는 시간(초). 이 값은 periodSeconds에 지정된 값을 초과할 수 없습니다. 1~3,600 사이의 값을 지정하세요. 기본값은 1입니다.
   • (선택사항) THRESHOLD: 컨테이너를 종료하기 전에 프로브를 재시도할 횟수입니다. 기본값은 3입니다.
   • (선택사항) PERIOD: 프로브를 수행할 시간(초). 예를 들어 2초마다 프로브를 수행하는 경우 2로 바꿉니다. 1~3600초 사이의 값을 지정하세요. 기본값은 10초입니다.
3. 다음 명령어를 사용하여 서비스를 만들거나 업데이트합니다.

   gcloud run services replace service.yaml

Terraform

중요: HTTP 프로브용 Cloud Run 서비스를 구성하는 경우 프로브에 응답하도록 서비스 코드에 엔드포인트도 추가해야 합니다. gRPC 프로브를 구성하는 경우 Cloud Run 서비스에서 gRPC 상태 점검 프로토콜도 구현해야 합니다.

Terraform 구성을 적용하거나 삭제하는 방법은 기본 Terraform 명령어를 참조하세요.

TCP 시작

다음과 같이 startup_probe 속성을 사용하여 Cloud Run 서비스를 구성합니다.

resource "google_cloud_run_v2_service" "default" {
  name     = "cloudrun-service-healthcheck"
  location = "us-central1"

  template {
    containers {
      image = "us-docker.pkg.dev/cloudrun/container/hello"

      startup_probe {
        failure_threshold     = 5
        initial_delay_seconds = 10
        timeout_seconds       = 3
        period_seconds        = 3

        tcp_socket {
          port = 8080
        }
      }
    }
  }
}

HTTP 시작

서비스가 HTTP/2가 아닌 HTTP/1(Cloud Run 기본값)을 사용하는지 확인합니다.

다음과 같이 startup_probe 속성을 사용하여 Cloud Run 서비스를 구성합니다.

resource "google_cloud_run_v2_service" "default" {
  name     = "cloudrun-service-healthcheck"
  location = "us-central1"

  template {
    containers {
      image = "us-docker.pkg.dev/cloudrun/container/hello"

      startup_probe {
        failure_threshold     = 5
        initial_delay_seconds = 10
        timeout_seconds       = 3
        period_seconds        = 3

        http_get {
          path = "/"
          # Custom headers to set in the request
          # https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/cloud_run_v2_service#http_headers
          http_headers {
            name  = "Access-Control-Allow-Origin"
            value = "*"
          }
        }
      }
    }
  }
}

HTTP 활성

서비스가 HTTP/2가 아닌 HTTP/1(Cloud Run 기본값)을 사용하는지 확인합니다.

다음과 같이 liveness_probe 속성을 사용하여 Cloud Run 서비스를 구성합니다.

resource "google_cloud_run_v2_service" "default" {
  name     = "cloudrun-service-healthcheck"
  location = "us-central1"

  template {
    containers {
      image = "us-docker.pkg.dev/cloudrun/container/hello"

      liveness_probe {
        failure_threshold     = 5
        initial_delay_seconds = 10
        timeout_seconds       = 3
        period_seconds        = 3

        http_get {
          path = "/"
          # Custom headers to set in the request
          # https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/cloud_run_v2_service#http_headers
          http_headers {
            name  = "Access-Control-Allow-Origin"
            value = "*"
          }
        }
      }
    }
  }
}

gRPC 시작

다음과 같이 startup_probe 속성을 사용하여 Cloud Run 서비스를 구성합니다.

resource "google_cloud_run_v2_service" "default" {
  name     = "cloudrun-service-healthcheck"
  location = "us-central1"

  template {
    containers {
      # Note: Change to the name of your image
      image = "us-docker.pkg.dev/cloudrun/container/hello"

      startup_probe {
        failure_threshold     = 5
        initial_delay_seconds = 10
        timeout_seconds       = 3
        period_seconds        = 3

        grpc {
          # Note: Change to the name of your pre-existing grpc health status service
          service = "grpc.health.v1.Health"
        }
      }
    }
  }
}

gRPC 활성

다음과 같이 liveness_probe 속성을 사용하여 Cloud Run 서비스를 구성합니다.

resource "google_cloud_run_v2_service" "default" {
  name     = "cloudrun-service-healthcheck"
  location = "us-central1"

  template {
    containers {
      # Note: Change to the name of your image
      image = "us-docker.pkg.dev/cloudrun/container/hello"

      liveness_probe {
        failure_threshold     = 5
        initial_delay_seconds = 10
        timeout_seconds       = 3
        period_seconds        = 3

        # Note: Change to the name of your pre-existing grpc health status service
        grpc {
          service = "grpc.health.v1.Health"
        }
      }
    }
  }
}

HTTP 상태 점검 엔드포인트 만들기

HTTP 시작 프로브 또는 활성 프로브를 위한 Cloud Run 서비스를 구성하는 경우 프로브에 응답하도록 엔드포인트를 서비스 코드에 추가해야 합니다. 엔드포인트의 이름은 원하는 대로 지정할 수 있지만(예: /startup 또는 /ready) 프로브 구성의 path에 지정한 값과 일치해야 합니다. 예를 들어 HTTP 시작 프로브에 /ready를 지정하면 다음과 같이 프로브 구성에 path를 지정합니다.

startupProbe:
  httpGet:
    path: /ready

HTTP 상태 점검 엔드포인트는 외부에서 액세스할 수 있으며 외부에 노출된 다른 HTTP 서비스 엔드포인트와 동일한 원칙을 따릅니다.