Składniki usługi Application Gateway dla kontenerów

Ten artykuł zawiera szczegółowe opisy i wymagania dotyczące składników usługi Application Gateway for Containers. Informacje o sposobie akceptowania żądań przychodzących w usłudze Application Gateway dla kontenerów i kierowania ich do obiektu docelowego zaplecza. Aby zapoznać się z ogólnym omówieniem usługi Application Gateway dla kontenerów, zobacz Co to jest usługa Application Gateway dla kontenerów.

Podstawowe składniki

• Zasób usługi Application Gateway for Containers to zasób nadrzędny platformy Azure, który wdraża płaszczyznę sterowania.
• Płaszczyzna sterowania jest odpowiedzialna za organizowanie konfiguracji serwera proxy na podstawie intencji klienta.
• Usługa Application Gateway dla kontenerów ma dwa zasoby podrzędne; skojarzenia i frontony.
  • Zasoby podrzędne są wyłączne tylko dla nadrzędnej usługi Application Gateway dla kontenerów i mogą nie być przywołyne przez inną usługę Application Gateway dla zasobu kontenera.

Frontony usługi Application Gateway dla kontenerów

• Zasób frontonu usługi Application Gateway for Containers to zasób podrzędny platformy Azure zasobu nadrzędnego usługi Application Gateway for Containers.
• Fronton usługi Application Gateway for Containers definiuje ruch klienta punktu wejścia powinien być odbierany przez daną usługę Application Gateway for Containers.
  • Nie można skojarzyć frontonu z wieloma usługami Application Gateway for Containers.
  • Każdy fronton udostępnia unikatową nazwę FQDN, do których można odwoływać się rekord CNAME klienta.
  • Prywatne adresy IP są obecnie nieobsługiwane.
• Pojedyncza usługa Application Gateway dla kontenerów może obsługiwać wiele frontonów.

Skojarzenia usługi Application Gateway dla kontenerów

• Zasób skojarzenia usługi Application Gateway for Containers to zasób podrzędny platformy Azure zasobu nadrzędnego usługi Application Gateway for Containers.
• Skojarzenie usługi Application Gateway for Containers definiuje punkt połączenia z siecią wirtualną. Skojarzenie to mapowanie zasobu skojarzenia 1:1 na podsieć platformy Azure, która została delegowana.
• Usługa Application Gateway for Containers została zaprojektowana tak, aby zezwalała na wiele skojarzeń.
  • Obecnie bieżąca liczba skojarzeń jest obecnie ograniczona do 1.
• Podczas tworzenia skojarzenia podstawowa płaszczyzna danych jest aprowizowana i połączona z podsiecią zdefiniowanej sieci wirtualnej.
• Każde skojarzenie powinno zakładać, że co najmniej 256 adresów jest dostępnych w podsieci podczas aprowizacji.
  • Minimalna maska podsieci /24 dla każdego wdrożenia (przy założeniu, że żadne zasoby nie zostały wcześniej aprowidowane w podsieci).
    • Jeśli aprowizowana jest n liczba usługi Application Gateway dla kontenerów, przy założeniu, że każda usługa Application Gateway dla kontenerów zawiera jedno skojarzenie, a intencją jest współużytkowania tej samej podsieci, dostępne wymagane adresy powinny mieć wartość n*256.
  • Wszystkie zasoby skojarzenia usługi Application Gateway dla kontenerów powinny być zgodne z tym samym regionem co zasób nadrzędny usługi Application Gateway for Containers.

Usługa Application Gateway dla kontenerów kontroler usługi ALB

• Kontroler usługi Application Gateway dla kontenerów usługi ALB to wdrożenie platformy Kubernetes, które organizuje konfigurację i wdrażanie usługi Application Gateway dla kontenerów, obserwując platformę Kubernetes zarówno w przypadku niestandardowych zasobów, jak i konfiguracji zasobów, takich jak, ruch przychodzący, brama i moduł ApplicationLoadBalancer. Używa on interfejsów API konfiguracji usługi ARM/Application Gateway for Containers do propagowania konfiguracji do wdrożenia usługi Application Gateway for Containers platformy Azure.
• Kontroler usługi ALB jest wdrażany/instalowany za pośrednictwem programu Helm.
• Kontroler usługi ALB składa się z dwóch uruchomionych zasobników.
  • Zasobnik alb-controller jest odpowiedzialny za organizowanie intencji klienta w usłudze Application Gateway dla kontenerów równoważenia obciążenia.
  • zasobnik alb-controller-bootstrap jest odpowiedzialny za zarządzanie crDs.

Pojęcia ogólne dotyczące platformy Azure

Prywatny adres IP

• Prywatny adres IP nie jest jawnie zdefiniowany jako zasób usługi Azure Resource Manager. Prywatny adres IP odnosi się do określonego adresu hosta w podsieci danej sieci wirtualnej.

Delegowanie podsieci

• Microsoft.ServiceNetworking/trafficControllers to przestrzeń nazw przyjęta przez usługę Application Gateway for Containers i może być delegowana do podsieci sieci wirtualnej.
• W przypadku delegowania aprowizacja zasobów usługi Application Gateway for Containers nie jest wykonywana ani nie istnieje wyłączne mapowanie zasobu skojarzenia usługi Application Gateway for Containers.
• Dowolna liczba podsieci może mieć delegowanie podsieci, które jest takie samo lub inne niż usługa Application Gateway for Containers. Po zdefiniowaniu żadne inne zasoby, inne niż zdefiniowana usługa, można aprowizować w podsieci, chyba że jawnie zdefiniowane przez implementację usługi.

Tożsamość zarządzana przypisana przez użytkownika

• Tożsamości zarządzane dla zasobów platformy Azure eliminują konieczność zarządzania poświadczeniami w kodzie.
• Tożsamość zarządzana użytkownika jest wymagana dla każdego kontrolera usługi Azure Load Balancer w celu wprowadzenia zmian w usłudze Application Gateway for Containers.
• AppGw for Containers Configuration Manager to wbudowana rola RBAC, która umożliwia kontrolerowi usługi ALB dostęp i konfigurowanie zasobu usługi Application Gateway for Containers.

Uwaga

Rola AppGw for Containers Configuration Manager ma uprawnienia do akcji danych, których nie mają role Właściciel i Współautor. Ważne jest, aby delegować odpowiednie uprawnienia, aby zapobiec problemom z wprowadzaniem zmian w usłudze Application Gateway for Containers przez kontroler usługi ALB.

Jak usługa Application Gateway dla kontenerów akceptuje żądanie

Każdy fronton usługi Application Gateway for Containers udostępnia wygenerowaną w pełni kwalifikowaną nazwę domeny zarządzaną przez platformę Azure. Nazwa FQDN może być używana jako jest lub klienci mogą zdecydować się na maskowanie nazwy FQDN przy użyciu rekordu CNAME.

Zanim klient wyśle żądanie do usługi Application Gateway for Containers, klient rozpozna rekord CNAME wskazujący nazwę FQDN frontonu; lub klient może bezpośrednio rozpoznać nazwę FQDN dostarczaną przez usługę Application Gateway for Containers przy użyciu serwera DNS.

Program rozpoznawania nazw DNS tłumaczy rekord DNS na adres IP.

Gdy klient inicjuje żądanie, określona nazwa DNS jest przekazywana jako nagłówek hosta do usługi Application Gateway dla kontenerów na zdefiniowanym frontonie.

Zestaw reguł routingu ocenia sposób inicjowania żądania dla tej nazwy hosta do zdefiniowanego obiektu docelowego zaplecza.

Jak usługa Application Gateway dla kontenerów kieruje żądanie

Żądania HTTP/2

Usługa Application Gateway for Containers w pełni obsługuje protokół HTTP/2 na potrzeby komunikacji z klienta do frontonu. Komunikacja z usługi Application Gateway dla kontenerów do obiektu docelowego zaplecza używa protokołu HTTP/1.1. Ustawienie HTTP/2 jest zawsze włączone i nie można go zmienić. Jeśli klienci wolą używać protokołu HTTP/1.1 do komunikacji z frontonem usługi Application Gateway for Containers, mogą nadal negocjować odpowiednio.

Modyfikacje żądania

Usługa Application Gateway for Containers wstawia trzy dodatkowe nagłówki do wszystkich żądań przed zainicjowaniem żądań z usługi Application Gateway dla kontenerów do obiektu docelowego zaplecza:

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

x-forwarded-for to oryginalny adres IP klienta osoby żądającej. Jeśli żądanie przechodzi przez serwer proxy, wartość nagłówka dołącza odebrany adres rozdzielany przecinkami. Na przykład: 1.2.3.4,5.6.7.8; gdzie 1.2.3.4 jest adresem IP klienta serwera proxy przed usługą Application Gateway dla kontenerów, a 5.6.7.8 jest adresem przekazywania ruchu serwera proxy do usługi Application Gateway for Containers.

Funkcja x-forwarded-proto zwraca protokół odebrany przez usługę Application Gateway for Containers od klienta. Wartość to http lub https.

x-request-id to unikatowy identyfikator GUID generowany przez usługę Application Gateway dla kontenerów dla każdego żądania klienta i przedstawiony w przesłanym dalej żądaniu do obiektu docelowego zaplecza. Identyfikator GUID składa się z 32 znaków alfanumerycznych oddzielonych kreskami (na przykład: aaaa0000-bb11-2222-33cc-444444dddd). Za pomocą tego identyfikatora GUID można skorelować żądanie odebrane przez usługę Application Gateway dla kontenerów i zainicjowane do obiektu docelowego zaplecza zgodnie z definicją w dziennikach dostępu.

Limity czasu żądania

Usługa Application Gateway dla kontenerów wymusza następujące limity czasu, gdy żądania są inicjowane i obsługiwane między klientem, usługą Application Gateway for Containers i zapleczem.

Timeout	Czas trwania	opis
Limit czasu żądania	60 s	czas oczekiwania usługi Application Gateway dla kontenerów na odpowiedź docelową zaplecza.
Limit czasu bezczynności HTTP	5 min	limit czasu bezczynności przed zamknięciem połączenia HTTP.
Limit czasu bezczynności strumienia	5 min	limit czasu bezczynności przed zamknięciem pojedynczego strumienia przenoszonego przez połączenie HTTP.
Limit czasu połączenia nadrzędnego	5 s	czas ustanawiania połączenia z obiektem docelowym zaplecza.