다음을 통해 공유

Istio 서비스 메시 추가 기능 수신 게이트웨이 문제 해결

  • 아티클

이 문서에서는 AKS(Azure Kubernetes Service)용 Istio 서비스 메시 추가 기능에서 수신 게이트웨이 문제를 해결하는 방법을 설명합니다. Istio 수신 게이트웨이는 들어오는 트래픽을 메시의 워크로드로 라우팅하는 데 사용할 수 있는 Envoy 기반 역방향 프록시입니다.

Istio 기반 서비스 메시 추가 기능의 경우 다음과 같은 수신 게이트웨이 옵션을 제공합니다.

  • 개인 IP 주소를 사용하는 내부 수신 게이트웨이입니다.

  • 공개적으로 액세스할 수 있는 IP 주소를 사용하는 외부 수신 게이트웨이입니다.

참고 항목

Microsoft는 내부 또는 외부 수신 게이트웨이에 대한 IP 주소 사용자 지정을 지원하지 않습니다. Istio 서비스 메시 추가 기능에 대한 IP 사용자 지정 변경 내용은 되돌려집니다.

추가 기능은 수정 버전당 Istio 수신 게이트웨이 Pod 및 배포를 배포합니다. 카나리아 업그레이드를 수행하고 클러스터에 두 개의 컨트롤 플레인 수정 버전을 설치한 경우 두 수정 버전에서 여러 수신 게이트웨이 Pod 문제를 해결해야 할 수 있습니다.

문제 해결 검사 목록

1단계: 방화벽 또는 NSG 규칙이 수신 게이트웨이를 차단하지 않는지 확인

수신 게이트웨이에 대한 트래픽을 차단하는 방화벽 또는 NSG(네트워크 보안 그룹) 규칙이 없는지 확인합니다. Azure Firewall을 통해 수신 게이트웨이로의 인바운드 트래픽을 허용하려면 DNAT(대상 네트워크 주소 변환) 규칙을 명시적으로 추가해야 합니다.

2단계: 게이트웨이, 가상 서비스 및 대상 규칙 올바르게 구성

수신 게이트웨이를 통한 트래픽 라우팅에 대한 게이트웨이, 가상 서비스 및 대상 규칙을 구성하는 경우 다음 단계를 수행합니다.

  1. 외부 또는 내부 게이트웨이를 각각 사용하는 경우 게이트웨이 리소스의 수신 게이트웨이 선택기가 다음 텍스트 값 중 하나로 설정되어 있는지 확인합니다.

    • istio: aks-istio-ingressgateway-external
    • istio: aks-istio-ingressgateway-internal

  2. 게이트웨이 및 가상 서비스에서 포트가 올바르게 설정되었는지 확인합니다. 게이트웨이의 경우 포트를 대상 또는 443 에 대해 httpshttp 설정 80 해야 합니다. 가상 서비스의 경우 해당 애플리케이션 서비스가 수신 대기 중인 포트로 포트를 설정해야 합니다.

  3. 서비스가 게이트웨이와 가상 서비스 모두에 hosts 대한 사양 내에서 노출되는지 확인합니다. 요청에서 헤더와 Host 관련된 문제가 발생하는 경우 이 예제 게이트웨이 구성과 같이 별표 와일드카드("*")가 포함된 모든 호스트를 허용 목록에 추가해 보세요. 그러나 허용 목록을 프로덕션 사례로 수정하지 않는 것이 좋습니다. 또한 사양을 hosts 명시적으로 구성해야 합니다.

3단계: 수신 게이트웨이 Pod의 상태 수정

수신 게이트웨이 Pod가 충돌하거나 준비 상태로 표시되지 않는 경우 Istio 디먼(istiod) 컨트롤 플레인 Pod가 준비 상태인지 확인합니다. 수신 게이트웨이는 릴리스를 준비하는 데 istiod 따라 달라집니다.

Pod가 istiod 준비 상태로 표시되지 않으면 Istio CRD(사용자 지정 리소스 정의) 및 base Helm 차트가 올바르게 설치되어 있는지 확인합니다. 이렇게 하려면 다음 명령을 실행합니다.

helm ls --all --all-namespaces

추가 기능 설치가 수신 게이트웨이에 특별히 구성되지 않은 광범위한 오류가 표시될 수 있습니다.

istiod Pod가 정상이지만 수신 게이트웨이 Pod가 응답하지 않는 경우 네임스페이스에서 aks-istio-ingress 다음 수신 게이트웨이 리소스를 검사하여 자세한 정보를 수집합니다.

  • Helm 릴리스
  • 배포
  • 서비스

또한 일반 Istio 서비스 메시 추가 기능 문제 해결에서 게이트웨이 및 사이드카 디버깅에 대한 자세한 정보를 찾을 수 있습니다.

4단계: 리소스 사용률 구성

Istiod 및 게이트웨이에 대한 기본 최소/최대 복제본 설정이 충분하지 않은 경우 높은 리소스 사용률이 발생합니다. 이 경우 가로 Pod 자동 크기 조정 구성을 변경합니다.

5단계: 보안 수신 게이트웨이 문제 해결

단순 또는 상호 TLS를 사용하여 보안 HTTPS 서비스를 노출하도록 외부 수신 게이트웨이가 구성된 경우 다음 문제 해결 단계를 수행합니다.

  1. 다음 명령의 출력에 INGRESS_HOST_EXTERNAL 따라 환경 변수 및 SECURE_INGRESS_PORT_EXTERNAL 환경 변수의 값이 유효한지 확인합니다.

    kubectl -n aks-istio-ingress get service aks-istio-ingressgateway-external

  2. 게이트웨이 컨트롤러의 로그에서 오류 메시지를 확인합니다.

    kubectl logs -n aks-istio-ingress <gateway-service-pod>

  3. 네임스페이스에 비밀이 만들어지는지 aks-istio-ingress 확인합니다.

    kubectl -n aks-istio-ingress get secrets

Azure Kubernetes Service용 Istio 서비스 메시 추가 기능에 대한 보안 수신 게이트웨이의 productpage-credential 예제에서는 비밀을 나열해야 합니다.

Azure Key Vault 비밀 공급자 추가 기능을 사용하도록 설정한 후에는 추가 기능의 사용자 할당 관리 ID에 대한 액세스 권한을 Azure Key Vault에 부여해야 합니다. Azure Key Vault에 대한 액세스를 잘못 설정하면 비밀이 productpage-credential 생성되지 않습니다.

리소스를 SecretProviderClass 만든 후 Azure Key Vault에서 클러스터로 비밀이 동기화되도록 하려면 이 리소스를 참조하는 샘플 Pod secrets-store-sync-productpage 가 성공적으로 배포되었는지 확인합니다.

참조

타사 정보 고지 사항

이 문서에 나와 있는 다른 공급업체 제품은 Microsoft와 무관한 회사에서 제조한 것입니다. Microsoft는 이들 제품의 성능이나 안정성에 관하여 명시적이든 묵시적이든 어떠한 보증도 하지 않습니다.

타사 연락처 고지

이 문서에 포함된 타사의 연락처 정보는 이 항목에 대한 추가 정보를 찾는 데 도움을 주기 위한 것입니다. 이 연락처 정보는 공지 없이 변경될 수 있습니다. Microsoft는 타사 연락처 정보의 정확성을 보증하지 않습니다.

도움을 요청하십시오.

질문이 있거나 도움이 필요한 경우 지원 요청을 생성하거나Azure 커뮤니티 지원에 문의하세요. Azure 피드백 커뮤니티에 제품 피드백을 제출할 수도 있습니다.