Google Kubernetes Engine(GKE)의 부하 분산 문제로 인해 HTTP 502 오류와 같은 서비스 중단이 발생하거나 애플리케이션에 대한 액세스가 차단될 수 있습니다.
이 문서를 사용하여 외부 인그레스의 502 오류를 해결하는 방법과 부하 분산기 로그 및 check-gke-ingress와 같은 진단 도구를 사용하여 문제를 식별하는 방법을 알아보세요.
이 정보는 GKE에서 부하 분산 서비스를 구성하고 유지보수하는 플랫폼 관리자, 운영자, 애플리케이션 개발자에게 중요합니다. Cloud de Confiance by S3NS 콘텐츠에서 참조하는 일반적인 역할과 예시 태스크에 대한 자세한 내용은 일반 GKE 사용자 역할 및 태스크를 참조하세요.
외부 인그레스에서 HTTP 502 오류 발생
외부 인그레스 리소스에서 HTTP 502 오류를 문제 해결하려면 다음 안내를 따르세요.
- 인그레스에서 참조되는 각 GKE 서비스와 연관된 각 백엔드 서비스에 대해 로그를 사용 설정합니다.
- 상태 세부정보를 사용하여 HTTP 502 응답의 원인을 식별합니다. 백엔드에서 시작된 HTTP 502 응답을 나타내는 상태 세부정보는 부하 분산기가 아니라 제공 상태의 포드 내에서 문제 해결이 필요합니다.
비관리형 인스턴스 그룹
외부 인그레스에 비관리형 인스턴스 그룹 백엔드가 사용되는 경우 외부 인그레스 리소스에 HTTP 502 오류가 발생할 수 있습니다. 이 문제는 다음 조건 중 모두가 충족될 때 발생합니다.
- 모든 노드 풀 간에 클러스터에 대량의 노드 수가 포함되어 있습니다.
- 인그레스에서 참조되는 하나 이상의 서비스에 대한 제공 상태의 포드가 단 몇 개의 노드에만 있습니다.
- 인그레스에서 참조되는 서비스에
externalTrafficPolicy: Local이 사용됩니다.
외부 인그레스에 비관리형 인스턴스 그룹 백엔드가 사용되는지 확인하려면 다음을 수행합니다.
Cloud de Confiance 콘솔에서 인그레스 페이지로 이동합니다.
외부 인그레스의 이름을 클릭합니다.
부하 분산기 이름을 클릭합니다. 부하 분산 세부정보 페이지가 표시됩니다.
백엔드 서비스 섹션의 테이블에서 외부 인그레스에 NEG 또는 인스턴스 그룹이 사용되는지 확인합니다.
이 문제를 해결하려면 다음 솔루션 중 하나를 사용하세요.
- VPC 기반 클러스터를 사용합니다.
- 외부 인그레스에서 참조되는 각 서비스에 대해
externalTrafficPolicy: Cluster를 사용합니다. 이 솔루션을 사용하면 패킷 소스에서 원래 클라이언트 IP 주소가 손실됩니다. node.kubernetes.io/exclude-from-external-load-balancers=true주석을 사용합니다. 외부 인그레스에서 참조하는 서비스 또는 클러스터의LoadBalancer서비스에 대해 제공 상태의 포드를 실행하지 않는 노드 또는 노드 풀에 주석을 추가합니다.
L4 부하 분산기 로깅 구성
이 섹션에서는 외부 패스 스루 네트워크 부하 분산기 또는 내부 패스 스루 네트워크 부하 분산기에 로깅을 사용 설정한 경우 문제 해결 정보를 제공합니다.
로깅 구성 상태 모니터링
GKE L4LB 컨트롤러는 서비스의 status.conditions 유형을 통해 로깅 조정 상태에 관한 의견을 제공합니다. 다음 명령어를 실행하여 이 상태를 확인할 수 있습니다.
kubectl get svc SERVICE_NAME -o yaml
다음을 바꿉니다.
SERVICE_NAME: 클러스터의 이름입니다.
출력에서 LoggingConfigManaged 조건 유형을 찾습니다. 다음 표에서는 조건의 가능한 이유를 설명합니다.
| 조건 상태 | 이유 | 설명 |
|---|---|---|
| 참 | 조정됨 | 컨트롤러는 L4LBConfig CRD에 정의된 로깅 구성을 적극적으로 적용합니다. |
| 거짓 | 비관리형 | logging 섹션이 L4LBConfig CRD에서 누락되었거나 주석이 삭제되었습니다. 컨트롤러가 관리를 중지하고 백엔드 서비스를 마지막으로 알려진 상태로 두었습니다. |
| 거짓 | 누락 | 서비스 주석에서 참조된 L4LBConfig 리소스를 찾을 수 없습니다. |
| 거짓 | 잘못됨 | L4LBConfig 리소스가 optionalFields 매개변수의 교차 검증에 실패했습니다. |
| 거짓 | 오류 | 백엔드 서비스를 조정하는 중에 오류가 발생했습니다. |
관성 주행 동작 이해하기
networking.gke.io/l4lb-config 주석이 서비스 매니페스트에서 삭제되거나 참조된 L4LBConfig 리소스가 삭제되면 구성이 Coast 상태가 됩니다.
이 상태에서는 GKE 컨트롤러가 로깅 설정 관리를 중지하지만 Cloud de Confiance by S3NS 백엔드 서비스를 기본 설정으로 재설정하지는 않습니다. 대신 백엔드 서비스는 마지막으로 알려진 정상 상태로 유지됩니다. 경고 이벤트는 일반적으로 Kubernetes가 더 이상 구성을 제어하지 않음을 알리기 위해 발생합니다.
부하 분산기 로그를 사용하여 문제 해결
내부 패스 스루 네트워크 부하 분산기 로그 및 외부 패스 스루 네트워크 부하 분산기 로그를 사용하여 부하 분산기 문제를 해결하고 부하 분산기에서 GKE 리소스로 전송되는 트래픽의 상관관계를 파악할 수 있습니다.
로그는 연결별로 집계되고 거의 실시간으로 내보내집니다. 로그는 인그레스 및 이그레스 트래픽 모두에 대해 LoadBalancer 서비스의 데이터 경로와 관련된 각 GKE 노드에 대해 생성됩니다. 로그 항목에는 다음과 같은 GKE 리소스의 추가 필드가 포함됩니다.
- 클러스터 이름
- 클러스터 위치
- 서비스 이름
- 서비스 네임스페이스
- 포드 이름
- 포드 네임스페이스
진단 도구를 사용하여 문제 해결
check-gke-ingress 진단 도구는 인그레스 리소스에 일반적인 구성 오류가 있는지 검사합니다. 다음과 같은 방법으로 check-gke-ingress 도구를 사용할 수 있습니다.
- 클러스터에서
gcpdiag명령줄 도구를 실행합니다. 인그레스 결과가 확인 규칙gke/ERR/2023_004섹션에 표시됩니다. - check-gke-ingress의 안내에 따라
check-gke-ingress도구를 단독으로 사용하거나 kubectl 플러그인으로 사용합니다.