이 페이지는 Cloud Translation API를 통해 번역되었습니다.

인그레스 상태 확인 문제 해결

Autopilot Standard

이 페이지에서는 Google Kubernetes Engine (GKE)에서 인그레스 상태 검사와 관련된 문제를 해결하는 방법을 설명합니다.

추가 지원이 필요하면 Cloud Customer Care에 연락합니다.

인그레스 상태 점검 작동 방식 이해하기

문제 해결 단계를 진행하기 전에 GKE에서 상태 점검이 작동하는 방식과 상태 점검을 성공적으로 실행하기 위해 유의해야 할 고려사항을 이해하는 것이 좋습니다.

기본 인그레스 컨트롤러를 사용하여 인그레스를 통해 서비스를 하나 이상 노출하면 GKE는기본 애플리케이션 부하 분산기 또는 내부 애플리케이션 부하 분산기를 만듭니다. 이러한 부하 분산기는 모두 단일 URL 맵에서 여러 백엔드 서비스를 지원합니다. 각 백엔드 서비스는 Kubernetes 서비스에 해당하며 각 백엔드 서비스가 Google Cloud 상태 점검을 참조해야 합니다. 상태 점검은 클러스터 외부에서 구현되기 때문에 Kubernetes 활성 또는 준비 프로브와 다릅니다.

부하 분산기 상태 점검은 백엔드 서비스별로 지정됩니다. 부하 분산기의 모든 백엔드 서비스에 대해 동일한 상태 점검을 사용할 수 있지만, 상태 점검 참조는 인그레스 객체 자체에서 전체 부하 분산기에 대해 지정되지 않습니다.

GKE는 다음 방법 중 하나를 기반으로 상태 점검을 만듭니다.

BackendConfig CRD: 서비스가 부하 분산기와 상호작용하는 방식을 정확하게 제어할 수 있는 커스텀 리소스 정의 (CRD)입니다. BackendConfig CRD를 사용하면 해당 백엔드 서비스와 연결된 상태 확인에 대한 맞춤 설정을 지정할 수 있습니다. 이러한 맞춤 설정을 사용하면 기존 애플리케이션 부하 분산기와 인그레스에서 만든 내부 애플리케이션 부하 분산기 모두의 상태 점검을 보다 유연하게 제어할 수 있습니다.
준비 프로브: Pod 내 컨테이너가 트래픽을 제공할 준비가 되었는지 확인하는 진단 검사입니다. GKE 인그레스 컨트롤러는 서비스의 제공 Pod에서 사용되는 준비 프로브를 기반으로 서비스의 백엔드 서비스에 대한 상태 점검을 만듭니다. 준비 프로브 정의에서 경로, 포트, 프로토콜과 같은 상태 점검 매개변수를 파생할 수 있습니다.
기본값: BackendConfig CRD를 구성하지 않거나 준비 프로브의 속성을 정의하지 않을 때 사용되는 매개변수입니다.

권장사항:

BackendConfig CRD를 사용하여 부하 분산기 상태 점검 설정을 최대한 제어합니다.

GKE는 다음 절차에 따라 Kubernetes 서비스에 해당하는 각 백엔드 서비스에 대해 상태 점검을 만듭니다.

서비스가 healthCheck 정보로 BackendConfig CRD를 참조하는 경우, GKE는 이를 사용하여 상태 점검을 만듭니다. GKE Enterprise 인그레스 컨트롤러 및 GKE 인그레스 컨트롤러 모두 이 방식으로 상태 점검을 만들 수 있습니다.
서비스가 BackendConfig CRD를 참조하지 않는 경우에는 다음과 같이 수행됩니다.
- GKE는 제공 pod가 상태 점검 매개변수로 해석될 수 있는 속성을 가진 준비 프로브가 있는 컨테이너와 함께 pod 템플릿을 사용하는 경우 상태 점검의 매개변수 일부 또는 전체를 추론할 수 있습니다. 구현 세부정보는 준비 프로브의 매개변수를, 상태 점검 매개변수를 만드는 데 사용할 수 있는 속성 목록은 기본 및 추론된 매개변수를 참조하세요. GKE 인그레스 컨트롤러만 준비 프로브의 추론 매개변수를 지원합니다.
- 서비스 서빙 포드의 포드 템플릿에 상태 점검 매개변수로 해석될 수 있는 준비 프로브가 있는 컨테이너가 없는 경우 기본값을 사용하여 상태 점검을 만듭니다. GKE Enterprise 인그레스 컨트롤러와 GKE 인그레스 컨트롤러는 기본값을 사용해서만 상태 점검을 만들 수 있습니다.

고려사항

이 섹션에서는 BackendConfig CRD를 구성하거나 준비 프로브를 사용할 때 유의해야 할 몇 가지 고려사항을 간략히 설명합니다.

`BackendConfig` CRD

BackendConfig CRD를 구성할 때는 다음 고려사항에 유의하세요.

컨테이너 기반 부하 분산을 사용하는 경우 BackendConfig 매니페스트의 상태 점검 포트가 제공 포드의 containerPort와 일치하는지 확인합니다.
인스턴스 그룹 백엔드의 경우 BackendConfig 매니페스트의 상태 확인 포트가 서비스에서 노출하는 nodePort와 일치하는지 확인합니다.
인그레스는 커스텀 상태 점검 구성에 사용되는 gRPC를 지원하지 않습니다. BackendConfig는 HTTP, HTTPS 또는 HTTP2 프로토콜을 사용한 상태 확인 생성만 지원합니다. BackendConfig CRD에서 프로토콜을 사용하는 방법의 예는 gke-networking-recipes를 참고하세요.

자세한 내용은 BackendConfig CRD를 사용해야 하는 경우를 참고하세요.

준비 프로브

HTTP 또는 HTTPS 부하 분산과 함께 GKE 인그레스를 사용하면 GKE에서 상태 확인 프로브를 전송하여 애플리케이션이 제대로 실행 중인지 확인합니다. 이러한 상태 점검 프로브는 다음 조건이 충족되는 한 Pod의 YAML 구성의 spec.containers[].readinessProbe.httpGet.port 섹션에 정의된 Pod의 특정 포트로 전송됩니다.

spec.containers[].readinessProbe.httpGet.port에 지정된 준비 프로브의 포트 번호는 애플리케이션이 컨테이너 내에서 리슨하는 실제 포트(포드 구성의 containers[].spec.ports.containerPort 필드에 정의됨)와 일치해야 합니다.
제공 포드의 containerPort는 서비스의 targetPort와 일치해야 합니다. 이렇게 하면 트래픽이 서비스에서 포드의 올바른 포트로 전달됩니다.
인그레스 서비스 백엔드 포트 사양은 서비스 구성의 spec.ports[] 섹션에서 유효한 포트를 참조해야 합니다. 다음 두 가지 방법 중 하나로 수행할 수 있습니다.
- 인그레스의 spec.rules[].http.paths[].backend.service.port.name가 해당 서비스에 정의된 spec.ports[].name와 일치합니다.
- 인그레스의 spec.rules[].http.paths[].backend.service.port.number가 해당 서비스에 정의된 spec.ports[].port와 일치합니다.

일반적인 상태 확인 문제 해결하기

다음 문제 해결 플로우 차트를 사용하여 상태 확인 문제를 식별하세요.

이 플로우 차트에서 다음 문제 해결 안내는 문제가 있는 위치를 확인하는 데 도움이 됩니다.

포드 상태 조사: 상태 점검에 실패하면 서비스의 제공 포드 상태를 검사합니다. 포드가 실행되고 있지 않고 정상적인 경우:
- 포드 로그에서 실행을 방해하는 오류나 문제가 있는지 확인합니다.
- 준비 상태 및 활성 여부 프로브의 상태를 확인합니다.
상태 점검 로깅: 상태 점검 로깅을 사용 설정했는지 확인합니다.
방화벽 구성 확인: 방화벽 규칙에서 상태 점검 프로브가 Pod에 도달하도록 허용하는지 확인합니다. 그렇지 않은 경우:
- 방화벽 규칙이 상태 점검 프로브 IP 주소 범위에서 들어오는 트래픽을 허용하는지 확인합니다.
- 이러한 IP 주소 범위를 수용하도록 필요에 따라 방화벽 규칙을 조정합니다.
패킷 캡처 분석: 방화벽이 올바르게 구성된 경우 패킷 캡처를 실행하여 애플리케이션이 상태 점검에 응답하는지 확인합니다. 패킷 캡처에 성공적인 응답이 표시되면Google Cloud 지원팀에 문의하여 추가 지원을 받으세요.
애플리케이션 문제 해결: 패킷 캡처에 성공적인 응답이 표시되지 않으면 애플리케이션이 상태 점검 요청에 올바르게 응답하지 않는 이유를 조사합니다. 상태 확인이 포드에서 올바른 경로와 포트를 타겟팅하는지 확인하고 애플리케이션 로그, 구성 파일, 종속 항목을 검사합니다. 오류를 찾을 수 없는 경우 Google Cloud 지원팀에 문의하세요.

상태 확인에 응답하지 않는 애플리케이션

구성된 경로 및 포트의 상태 확인 중에 애플리케이션이 예상되는 상태 코드 (HTTP의 경우 200 OK 또는 SYN, TCP의 경우 ACK)로 응답하지 않습니다.

애플리케이션이 상태 점검에 올바르게 응답하지 않는 경우 다음 중 하나가 원인일 수 있습니다.

네트워크 엔드포인트 그룹(NEG):
- 애플리케이션이 포드 내에서 제대로 실행되지 않습니다.
- 애플리케이션이 구성된 포트 또는 경로를 리슨하고 있지 않습니다.
- 상태 확인이 Pod에 도달하지 못하도록 하는 네트워크 연결 문제가 있습니다.
인스턴스 그룹:
- 인스턴스 그룹의 노드가 정상이 아닙니다.
- 애플리케이션이 노드에서 제대로 실행되지 않습니다.
- 상태 확인 요청이 노드에 도달하지 않습니다.

상태 점검에 실패하면 설정에 따라 다음과 같이 문제를 해결하세요.

NEG의 경우:

kubectl exec을 사용하여 포드에 액세스합니다.
```
kubectl exec -it pod-name -- command
```
플래그 -it는 대화형 터미널 세션을 제공합니다 (대화형의 경우 i, TTY의 경우 t).

다음을 바꿉니다.
- pod-name: 포드의 이름입니다.
- command: 포드 내부에서 실행할 명령어입니다. 가장 일반적인 명령어는 대화형 셸을 가져오는 bash 또는 sh입니다.
curl 명령어를 실행하여 연결 및 애플리케이션 응답성을 테스트합니다.
- curl localhost:<Port>/<Path>
- curl -v http://<POD_IP>/[Path configured in HC]
- curl http://localhost/[Path configured in HC]

인스턴스 그룹:

노드가 정상 상태이고 기본 상태 점검 프로브에 응답하는지 확인합니다.
노드는 정상이지만 애플리케이션 포드가 응답하지 않으면 애플리케이션을 자세히 조사합니다.
요청이 Pod에 도달하지 않으면 GKE 네트워킹 문제일 수 있습니다. 도움이 필요한 경우 Google Cloud 지원팀에 문의하세요.

포드에서 준비 프로브를 수정할 때 오류 발생

포드에서 준비 프로브를 수정하여 상태 확인 매개변수를 변경하려고 하면 다음과 유사한 오류가 발생합니다.

Pod "pod-name" is invalid: spec: Forbidden: pod updates may not change fields

이미 인그레스 (및 해당 부하 분산기)에 연결된 서비스와 연결된 포드의 준비 프로브를 수정해도 GKE는 부하 분산기의 상태 점검 구성을 자동으로 업데이트하지 않습니다. 이로 인해 포드의 준비 상태 확인과 부하 분산기의 상태 확인이 일치하지 않아 상태 확인에 실패합니다.

이 문제를 해결하려면 포드와 인그레스 리소스를 다시 배포합니다. 이렇게 하면 GKE에서 부하 분산기와 상태 점검을 다시 만들고 새 준비 상태 프로브 설정을 통합합니다.

배포 및 부하 분산기 시작 실패

배포가 시작되지 않고 인그레스 컨트롤러의 부하 분산기 뒤에 있는 백엔드 서비스가 비정상적으로 표시되는 경우 준비 프로브 실패가 원인일 수 있습니다.

준비 프로브 실패를 언급하는 다음과 같은 오류 메시지가 표시될 수 있습니다.

Readiness probe failed: connection refused

포드 내 애플리케이션이 포드의 YAML 구성에 구성된 준비 프로브에 올바르게 응답하지 않습니다. 이는 애플리케이션이 제대로 시작되지 않거나, 잘못된 포트를 리슨하거나, 초기화 중에 오류가 발생하는 등 다양한 이유로 인해 발생할 수 있습니다.

이 문제를 해결하려면 다음을 실행하여 애플리케이션의 구성 또는 동작에서 불일치를 조사하고 수정하세요.

애플리케이션이 올바르게 구성되어 있고 준비 프로브 매개변수에 지정된 경로와 포트에서 응답하는지 확인합니다.
애플리케이션 로그를 검토하고 시작 문제 또는 오류를 해결합니다.
포드 구성의 containerPort가 서비스의 targetPort 및 인그레스에 지정된 백엔드 포트와 일치하는지 확인합니다.

자동 인그레스 방화벽 규칙 누락

인그레스 리소스를 만들었지만 트래픽이 백엔드 서비스에 도달하지 않습니다.

일반적으로 인그레스 리소스가 생성될 때 GKE에서 만드는 자동 인그레스 방화벽 규칙이 누락되었거나 실수로 삭제되었습니다.

백엔드 서비스에 대한 연결을 복원하려면 다음 단계를 따르세요.

VPC 네트워크에 자동 인그레스 방화벽 규칙이 있는지 확인합니다.
규칙이 없는 경우 규칙을 수동으로 다시 만들거나 인그레스 리소스를 삭제한 후 다시 만들어 자동 생성을 트리거할 수 있습니다.
방화벽 규칙이 인그레스 리소스에 정의된 대로 적절한 포트와 프로토콜의 트래픽을 허용하는지 확인합니다.

`BackendConfig` 매니페스트에 잘못된 프로토콜이 사용됨

TCP 유형 프로토콜로 BackendConfig CRD를 구성하면 다음 오류가 표시됩니다.

Error syncing to GCP: error running backend syncing routine:
error ensuring health check: Protocol "TCP" is not valid, must be one of ["HTTP","HTTPS","HTTP2"]'

BackendConfig는 HTTP, HTTPS 또는 HTTP/2 프로토콜만 사용하여 상태 확인을 만드는 것을 지원합니다. 자세한 내용은 HTTP, HTTPS, HTTP/2의 성공 기준을 참고하세요.

다음 단계

단일 클러스터에서 인그레스의 맞춤 상태 점검을 설정하려면 GKE 네트워킹 레시피를 참고하세요.