컨테이너용 Application Gateway 구성 요소
이 문서에는 컨테이너용 Application Gateway의 구성 요소에 대한 자세한 설명과 요구 사항이 나와 있습니다. 컨테이너용 Application Gateway가 들어오는 요청을 수락하고 백 엔드 대상으로 라우팅하는 방법에 대한 정보를 제공합니다. 컨테이너용 Application Gateway에 대한 일반적인 개요는 컨테이너용 Application Gateway란?을 참조하세요.
핵심 구성 요소
- 컨테이너용 Application Gateway 리소스는 컨트롤 플레인을 배포하는 Azure 부모 리소스입니다.
- 컨트롤 플레인은 고객 의도에 따라 프록시 구성을 오케스트레이션하는 역할을 합니다.
- 컨테이너용 Application Gateway에는 두 개의 자식 리소스가 있습니다. 연결 및 프런트 엔드.
- 자식 리소스는 컨테이너에 대한 부모 Application Gateway만 사용할 수 있으며 다른 Application Gateway for Container 리소스에서 참조할 수 없습니다.
컨테이너용 Application Gateway 프런트 엔드
- 컨테이너용 Application Gateway 프런트 엔드 리소스는 컨테이너용 Application Gateway 부모 리소스의 Azure 자식 리소스입니다.
- 컨테이너용 Application Gateway 프런트 엔드는 지정된 Application Gateway for Containers에서 수신해야 하는 진입점 클라이언트 트래픽을 정의합니다.
- 프런트 엔드는 컨테이너용 여러 Application Gateway에 연결할 수 없습니다.
- 각 프런트 엔드는 고객의 CNAME 레코드에서 참조할 수 있는 고유한 FQDN을 제공합니다.
- 개인 IP 주소는 현재 지원되지 않습니다.
- 컨테이너용 단일 Application Gateway는 여러 프런트 엔드를 지원할 수 있습니다.
컨테이너용 Application Gateway 연결
- 컨테이너 연결 리소스에 대한 Application Gateway는 컨테이너용 Application Gateway 부모 리소스의 Azure 자식 리소스입니다.
- 컨테이너용 Application Gateway 연결은 가상 네트워크에 대한 연결 지점을 정의합니다. 연결은 위임된 Azuer 서브넷에 연결 리소스를 1:1로 매핑하는 것입니다.
- 컨테이너용 Application Gateway는 여러 연결을 허용하도록 설계되었습니다.
- 현재 연결 수는 현재 1로 제한됩니다.
- 연결을 만드는 동안 기본 데이터 평면이 프로비전되고 정의된 가상 네트워크의 서브넷 내의 서브넷에 연결됩니다.
- 각 연결은 프로비전 시 서브넷에서 256개 이상의 주소를 사용할 수 있다고 가정해야 합니다.
- 각 배포에 대한 최소 /24 서브넷 마스크(이전에 서브넷에 프로비전된 리소스가 없다고 가정).
- n개의 컨테이너용 Application Gateway가 프로비전된 경우 각각의 컨테이너용 Application Gateway에 하나의 연결이 포함되어 있고 동일한 서브넷을 공유할 의도가 있다고 가정하면 사용 가능한 필수 주소는 n*256개여야 합니다.
- 컨테이너 연결 리소스에 대한 모든 Application Gateway는 컨테이너용 Application Gateway 부모 리소스와 동일한 지역과 일치해야 합니다.
- 각 배포에 대한 최소 /24 서브넷 마스크(이전에 서브넷에 프로비전된 리소스가 없다고 가정).
컨테이너용 Application Gateway ALB 컨트롤러
- 컨테이너용 Application Gateway ALB 컨트롤러는 Kubernetes에서 사용자 지정 리소스와 리소스 구성(예: 수신, 게이트웨이, ApplicationLoadBalancer 등)을 모두 확인하여 컨테이너용 Application Gateway의 구성과 배포를 오케스트레이션하는 Kubernetes 배포입니다. 이는 ARM/컨테이너용 Application Gateway 구성 API를 모두 사용하여 컨테이너용 Application Gateway Azure 배포에 구성을 전파합니다.
- ALB 컨트롤러는 Helm을 통해 배포/설치됩니다.
- ALB 컨트롤러는 두 개의 실행 중인 Pod로 구성됩니다.
- alb-controller Pod는 컨테이너 부하 분산 구성을 위해 Application Gateway에 대한 고객 의도를 오케스트레이션하는 역할을 담당합니다.
- alb-controller-bootstrap Pod는 CRD 관리 작업을 담당합니다.
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 역할입니다.
참고 항목
컨테이너용 AppGw 구성 관리자 역할은 소유자 및 기여자 역할에는 없는 데이터 작업 권한을 보유하고 있습니다. ALB 컨트롤러에서 컨테이너용 Application Gateway 서비스를 변경하는 문제를 방지하려면 적절한 권한을 위임하는 것이 중요합니다.
컨테이너용 Application Gateway가 요청을 수락하는 방법
각각의 컨테이너용 Application Gateway 프런트 엔드는 Azure에서 관리하는, 생성된 정규화된 도메인 이름을 제공합니다. FQDN을 있는 그대로 사용하거나, 고객이 CNAME 레코드로 FQDN을 마스킹하도록 선택할 수 있습니다.
클라이언트는 컨테이너용 Application Gateway에 요청을 보내기 전에 프런트 엔드의 FQDN을 가리키는 CNAME을 확인하거나, DNS 서버를 사용하여 컨테이너용 Application Gateway에서 제공하는 FQDN을 직접 확인할 수 있습니다.
DNS 확인자는 DNS 레코드를 IP 주소로 변환합니다.
클라이언트가 요청을 시작하면 지정된 DNS 이름이 정의된 프런트 엔드의 컨테이너용 Application Gateway에 호스트 헤더로 전달됩니다.
회람 규칙 세트는 해당 호스트 이름의 요청이 정의된 백 엔드 대상으로 시작되는 방법을 평가합니다.
컨테이너용 Application Gateway에서 요청을 라우팅하는 방법
HTTP/2 요청
컨테이너용 Application Gateway는 클라이언트에서 프런트 엔드로의 통신을 위한 HTTP/2 프로토콜을 완벽하게 지원합니다. 컨테이너용 Application Gateway에서 백 엔드 대상으로의 통신은 HTTP/1.1 프로토콜을 사용합니다. HTTP/2 설정은 항상 사용하도록 설정되며 변경할 수 없습니다. 클라이언트가 컨테이너용 Application Gateway의 프런트 엔드에 대한 통신에 HTTP/1.1을 사용하려는 경우 그에 따라 계속 협상할 수 있습니다.
요청에 대한 수정
Application Gateway for Containers는 컨테이너용 Application Gateway에서 백 엔드 대상으로 요청을 시작하기 전에 모든 요청에 세 개의 추가 헤더를 삽입합니다.
- 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-444444ddddddd). 이 GUID는 컨테이너용 Application Gateway에서 수신하고 액세스 로그에 정의된 대로 백 엔드 대상으로 시작된 요청의 상관 관계를 지정하는 데 사용할 수 있습니다.
요청 시간 초과
컨테이너용 Application Gateway는 클라이언트, 컨테이너용 Application Gateway 및 백 엔드 간에 요청이 시작되고 유지 관리될 때 다음과 같은 시간 제한을 적용합니다.
시간 제한 | Duration | 설명 |
---|---|---|
Request Timeout | 60초 | 컨테이너용 Application Gateway가 백 엔드 대상 응답을 기다리는 시간입니다. |
HTTP 유휴 시간 제한 | 5분 | HTTP 연결을 닫기 전에 유휴 시간 제한입니다. |
스트림 유휴 시간 제한 | 5분 | HTTP 연결로 전달되는 개별 스트림을 닫기 전에 유휴 시간 제한입니다. |
업스트림 연결 시간 제한 | 5초 | 백 엔드 대상에 대한 연결을 설정하는 데 걸리는 시간입니다. |