컨테이너용 Application Gateway 구성 요소

이 문서에는 컨테이너용 Application Gateway의 구성 요소에 대한 자세한 설명과 요구 사항이 나와 있습니다. 컨테이너용 Application Gateway가 들어오는 요청을 수락하고 백 엔드 대상으로 라우팅하는 방법을 설명합니다. 컨테이너용 Application Gateway에 대한 일반적인 개요는 컨테이너용 Application Gateway란?을 참조하세요.

핵심 구성 요소

• 컨테이너용 Application Gateway 리소스는 컨트롤 플레인을 배포하는 Azure 부모 리소스입니다.
• 컨트롤 플레인은 고객 의도에 따라 프록시 구성을 오케스트레이션합니다.
• 컨테이너용 Application Gateway는 두 가지 하위 리소스를 가집니다: 연결과 프런트엔드.
  • 자식 리소스는 부모 Application Gateway for Containers에만 속하며 다른 Application Gateway for Containers 리소스와 공유할 수 없습니다.

컨테이너용 Application Gateway 프런트 엔드

• 컨테이너용 Application Gateway 프런트 엔드 리소스는 컨테이너용 Application Gateway 부모 리소스의 Azure 자식 리소스입니다.
• 컨테이너용 Application Gateway 프런트 엔드는 지정된 Application Gateway for Containers에 사용되는 진입점 클라이언트 트래픽을 정의합니다.
  • 프런트 엔드를 둘 이상의 컨테이너용 Application Gateway와 연결할 수 없습니다.
  • 각 프런트 엔드에서 제공하는 고유한 FQDN을 사용하여 CNAME 레코드를 만들 수 있습니다.
  • 개인 IP 주소는 현재 지원되지 않습니다.
• 컨테이너용 단일 Application Gateway는 둘 이상의 프런트 엔드를 지원할 수 있습니다.

컨테이너용 Application Gateway 연결

• 컨테이너 연결 리소스에 대한 Application Gateway는 컨테이너용 Application Gateway 부모 리소스의 Azure 자식 리소스입니다.
• 컨테이너용 Application Gateway 연결은 가상 네트워크에 대한 연결 지점을 정의합니다. 연결은 위임된 Azure 서브넷에 대한 연결 리소스의 1:1 매핑입니다.
• 컨테이너용 Application Gateway는 둘 이상의 연결을 허용하도록 설계되었습니다.
  • 현재 연관 수는 1로 제한됩니다.
• 연결을 만드는 동안 기본 데이터 평면이 프로비전되고 정의된 가상 네트워크의 서브넷 내의 서브넷에 연결됩니다.
• 각 연결은 프로비전 시 서브넷에서 256개 이상의 주소를 사용할 수 있다고 가정해야 합니다.
  • 배포마다 /24 서브넷 마스크를 최소 요구 조건으로 합니다. 서브넷에 이전에 프로비전된 리소스가 없다고 가정합니다.
    • 동일한 서브넷을 공유하는 컨테이너용 Application Gateway 리소스를 여러 개 배포하려는 경우 필요한 주소를 n×256으로 계산합니다. 여기서 n 은 컨테이너용 Application Gateway 리소스의 수와 같습니다. 각각에 하나의 연결이 포함되어 있다고 가정합니다.
  • 컨테이너 연결 리소스에 대한 모든 Application Gateway는 컨테이너용 Application Gateway 부모 리소스와 동일한 지역과 일치해야 합니다.

컨테이너용 Application Gateway ALB 컨트롤러

• 컨테이너용 Application Gateway ALB 컨트롤러는 Kubernetes에서 사용자 지정 리소스와 리소스 구성(예: 수신, 게이트웨이, ApplicationLoadBalancer 등)을 모두 확인하여 컨테이너용 Application Gateway의 구성과 배포를 오케스트레이션하는 Kubernetes 배포입니다. ARM 및 Application Gateway for Containers 구성 API를 모두 사용하여 구성을 컨테이너용 Application Gateway Azure 배포에 전파합니다.
• Helm을 사용하여 ALB 컨트롤러를 배포하거나 설치합니다.
• ALB 컨트롤러는 두 개의 실행 중인 Pod로 구성됩니다.
  • alb-controller Pod는 컨테이너 부하 분산 구성을 위해 Application Gateway에 대한 고객 의도를 오케스트레이션합니다.
  • alb-controller-bootstrap Pod는 CRD를 관리합니다.

컨테이너용 Application Gateway 보안 정책

• 컨테이너용 Application Gateway 보안 정책은 ALB 컨트롤러에서 사용할 WAF와 같은 보안 구성을 정의합니다.
• 컨테이너용 단일 Application Gateway 리소스는 둘 이상의 보안 정책을 참조할 수 있습니다.
• 현재 제공되는 유일한 보안 정책 유형은 waf 웹 애플리케이션 방화벽 기능입니다.
• waf 보안 정책은 보안 정책 리소스와 웹 애플리케이션 방화벽 정책 간의 일대일 매핑입니다.
  • 정의된 Application Gateway for Containers 리소스에 대한 여러 보안 정책에서 하나의 웹 애플리케이션 방화벽 정책만 참조할 수 있습니다.

Azure/일반 개념

개인 IP 주소

• 개인 IP 주소는 Azure Resource Manager 리소스로 명시적으로 정의되지 않습니다. 개인 IP 주소는 지정된 가상 네트워크의 서브넷 내의 특정 호스트 주소를 나타냅니다.

서브넷 위임

• Microsoft.ServiceNetworking/trafficControllers는 컨테이너용 Application Gateway에서 채택한 네임스페이스이며 가상 네트워크의 서브넷에 위임할 수 있습니다.
• 위임할 때 컨테이너 리소스에 대한 Application Gateway를 프로비전하지 않으며 컨테이너용 Application Gateway 연결 리소스에 대한 단독 매핑도 없습니다.
• 여러 서브넷에 컨테이너용 Application Gateway와 같거나 다른 서브넷 위임이 있을 수 있습니다. 정의되면 서비스 구현에서 명시적으로 정의하지 않는 한 다른 리소스를 서브넷에 프로비전할 수 없습니다.

사용자 할당 관리 ID

• Azure 리소스에 대해 관리 ID를 사용하면 코드로 자격 증명을 관리할 필요가 없습니다.
• 컨테이너용 Application Gateway를 변경하려면 각 Azure Load Balancer 컨트롤러에 대해 사용자 할당 관리 ID가 필요합니다.
• 컨테이너용 AppGw 구성 관리자는 ALB 컨트롤러가 컨테이너용 Application Gateway 리소스에 액세스하고 이를 구성할 수 있도록 하는 기본 제공 RBAC 역할입니다.

컨테이너용 Application Gateway가 요청을 수락하는 방법

각 Application Gateway for Containers 프런트 엔드는 Azure에서 관리하는 생성된 정규화된 도메인 이름을 제공합니다. FQDN as-is 사용하거나 CNAME 레코드로 마스킹할 수 있습니다.

클라이언트가 Application Gateway for Containers에 요청을 보내기 전에 클라이언트는 프런트 엔드의 FQDN을 가리키는 CNAME을 확인하거나 클라이언트는 DNS 서버를 사용하여 Application Gateway for Containers에서 제공하는 FQDN을 직접 확인합니다.

DNS 확인자는 DNS 레코드를 IP 주소로 변환합니다.

클라이언트가 요청을 시작하면 지정된 DNS 이름이 정의된 프런트 엔드의 컨테이너용 Application Gateway에 호스트 헤더로 전달됩니다.

회람 규칙 세트는 해당 호스트 이름의 요청이 정의된 백 엔드 대상으로 시작되는 방법을 평가합니다.

컨테이너용 Application Gateway에서 요청을 라우팅하는 방법

HTTP/2 요청

컨테이너용 Application Gateway는 클라이언트와 프런트 엔드 간의 통신을 위해 HTTP/2 및 HTTP/1.1 프로토콜을 모두 지원합니다. HTTP/2 설정은 항상 사용하도록 설정되며 변경할 수 없습니다. 클라이언트가 컨테이너용 Application Gateway의 프런트 엔드에 대한 통신에 HTTP/1.1을 사용하는 것을 선호하는 경우 그에 따라 계속 협상할 수 있습니다.

컨테이너용 Application Gateway와 백 엔드 대상 간의 통신은 HTTP/2를 사용하는 gRPC를 제외하고 항상 HTTP/1.1을 통해서입니다.

요청에 대한 수정

Application Gateway for Containers는 백 엔드 대상에 대한 요청을 시작하기 전에 모든 요청에 세 개의 추가 헤더를 삽입합니다.

• x-forwarded-for
• x-forwarded-proto
• x-request-id

x-forwarded-for 는 원래 요청자의 클라이언트 IP 주소입니다. 요청이 프록시를 통해 오는 경우 헤더 값은 쉼표로 구분된 수신 주소를 추가합니다. 예: 1.2.3.4,5.6.7.8; 여기서 1.2.3.4는 컨테이너용 Application Gateway 앞의 프록시에 대한 클라이언트 IP 주소이고, 5.6.7.8은 컨테이너용 Application Gateway로 트래픽을 전달하는 프록시의 주소입니다.

x-forwarded-proto는 클라이언트에서 수신하는 컨테이너용 Application Gateway 프로토콜을 반환합니다. 값은 http 또는 https입니다.

x-request-id 는 컨테이너용 Application Gateway가 각 클라이언트 요청에 대해 생성하고 백 엔드 대상에 전달된 요청에 표시하는 고유한 GUID입니다. GUID는 대시로 구분된 32개의 영숫자로 구성됩니다(예: aaaa0000-bb11-2222-33cc-444444dddddd). 이 guid를 사용하여 Application Gateway for Containers가 수신 및 시작한 요청을 액세스 로그에 정의된 대로 백엔드 대상으로 연결할 수 있습니다.

요청 시간 제한

컨테이너용 Application Gateway는 클라이언트, 컨테이너용 Application Gateway 및 백 엔드 간의 요청을 시작하고 유지 관리하므로 다음 시간 제한을 적용합니다.