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. Wyjaśniono, jak usługa Application Gateway dla kontenerów przyjmuje przychodzące żądania i kieruje je do celu w zapleczu. 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 koordynuje konfigurację serwera proxy na podstawie intencji użytkownika.
• Usługa Application Gateway for Containers ma dwa zasoby podrzędne: powiązania i frontendów.
  • Zasoby podrzędne należą wyłącznie do nadrzędnej usługi Application Gateway for Containers i nie mogą być udostępniane innym zasobom usługi Application Gateway for Containers.

Frontony usługi Application Gateway dla kontenerów

• Zasób frontonu w Application Gateway for Containers to zasób podrzędny w usłudze Application Gateway for Containers w platformie Azure.
• Frontend usługi Application Gateway for Containers definiuje punkt wejścia, przez który ruch klienta przechodzi do danej usługi Application Gateway for Containers.
  • Nie można skojarzyć frontonu z więcej niż jedną usługą Application Gateway for Containers.
  • Rekord CNAME można utworzyć przy użyciu unikatowej nazwy FQDN, którą zapewnia każdy fronton.
  • Prywatne adresy IP nie są obecnie obsługiwane.
• Jedna usługa Application Gateway dla kontenerów może obsługiwać więcej niż jeden fronton.

Skojarzenia usługi Application Gateway dla kontenerów

• Zasób skojarzenia Application Gateway for Containers to podrzędny zasób platformy Azure, należący do nadrzędnej usługi Application Gateway for Containers.
• Powiązanie Application Gateway for Containers definiuje punkt połączenia z siecią wirtualną. Skojarzenie to mapowanie zasobu powiązania 1:1 do delegowanej podsieci Azure.
• Usługa Application Gateway dla kontenerów została zaprojektowana tak, aby zezwalała na więcej niż jedno skojarzenie.
  • Obecnie bieżąca liczba skojarzeń jest ograniczona do 1.
• Podczas tworzenia skojarzenia podstawowa płaszczyzna danych jest konfigurowana i połączona z podsiecią w obrębie zdefiniowanej sieci wirtualnej.
• Każde stowarzyszenie powinno zakładać, że co najmniej 256 adresów jest dostępnych w podsieci podczas konfiguracji.
  • Minimalna maska podsieci /24 dla każdego wdrożenia (zakładając, że żadne zasoby nie są wcześniej przydzielone w podsieci).
    • Jeśli planujesz wdrożyć wiele zasobów usługi Application Gateway for Containers, które współużytkujące tę samą podsieć, oblicz wymagane adresy n×256, gdzie n jest równa liczbie zasobów usługi Application Gateway for Containers. Zakłada się, że każdy z nich zawiera jedno skojarzenie.
  • Wszystkie zasoby powiązane usługi Application Gateway for Containers powinny być w takim samym regionie jak zasób nadrzędny usługi Application Gateway for Containers.

Kontroler ALB dla usługi Application Gateway dla kontenerów

• Kontroler ALB dla Application Gateway dla kontenerów to wdrożenie na platformie Kubernetes, które organizuje konfigurację i wdrażanie Application Gateway dla kontenerów, obserwując zarówno niestandardowe zasoby, jak i konfiguracje zasobów w Kubernetes, takie jak Ingress, Gateway i ApplicationLoadBalancer. Używa interfejsów API konfiguracji zarówno ARM, jak i Application Gateway for Containers, aby propagować konfigurację do wdrożenia Application Gateway for Containers na platformie Azure.
• Wdrażanie lub instalowanie kontrolera usługi ALB za pomocą programu Helm.
• Kontroler ALB składa się z dwóch działających podów.
  • Pod alb-controller zarządza zamierzeniami klienta w konfiguracji równoważenia obciążenia Application Gateway for Containers.
  • Zasobnik alb-controller-bootstrap zarządza definicjami zasobów niestandardowych (CRD).

Zasady zabezpieczeń usługi Application Gateway for Containers

• Zasady zabezpieczeń dla Application Gateway for Containers definiują konfiguracje zabezpieczeń, takie jak zapora aplikacji (WAF), do wykorzystania przez kontroler ALB.
• Pojedynczy zasób usługi Application Gateway for Containers może odwoływać się do więcej niż jednej zasady zabezpieczeń.
• Obecnie jedynym oferowanym typem zasad zabezpieczeń jest waf funkcja zapory aplikacji internetowej.
• Zasady waf zabezpieczeń to odpowiadające sobie odwzorowanie między zasobem zasad zabezpieczeń a polityką zapory aplikacji internetowej.
  • Można odwoływać się tylko do jednej zasady zapory aplikacji internetowej w dowolnej liczbie zasad zabezpieczeń dla zdefiniowanego zasobu usługi Application Gateway for Containers.

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żna ją delegować do podsieci sieci wirtualnej.
• Podczas delegowania nie aprowizujesz zasobów usługi Application Gateway dla kontenerów 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 nie można przydzielać innych zasobów w podsieci, chyba że jest to wyraźnie określone przez implementację usługi.

Tożsamość zarządzana przypisana użytkownikowi

• Tożsamości zarządzane dla zasobów platformy Azure eliminują konieczność zarządzania poświadczeniami w kodzie.
• Aby wprowadzić zmiany w usłudze Application Gateway for Containers, potrzebna jest tożsamość zarządzana przypisana przez użytkownika dla każdego kontrolera usługi Azure Load Balancer.
• 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.

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. Możesz użyć nazwy FQDN w niezmienionej formie lub zamaskować ją 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 bezpośrednio rozpoznaje 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, jak inicjować żądanie dla tej nazwy hosta do określonego celu w zapleczu.

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

Żądania HTTP/2

Usługa Application Gateway for Containers obsługuje protokoły HTTP/2 i HTTP/1.1 na potrzeby komunikacji między klientem a frontonem. 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.

Komunikacja między usługą Application Gateway dla kontenerów a obiektem docelowym zaplecza jest zawsze za pośrednictwem protokołu HTTP/1.1, z wyjątkiem protokołu gRPC, który używa protokołu HTTP/2.

Modyfikacje żądania

Usługa Application Gateway for Containers wstawia trzy dodatkowe nagłówki do wszystkich żądań, zanim inicjuje żądania do obiektu docelowego zaplecza:

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

x-forwarded-for to adres IP klienta, od którego pochodzi oryginalne żądanie. Jeśli żądanie jest przekazywane przez serwer proxy, wartość nagłówka dołącza adres, który otrzymuje, 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ół Application Gateway for Containers odbierany od klienta. Wartość to http lub https.

x-request-id to unikatowy identyfikator GUID generowany przez usługę Application Gateway for Containers dla każdego żądania klienta i przedstawiany 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-444444dddddd). Za pomocą tego identyfikatora GUID można skorelować żądanie odbierane przez usługę Application Gateway for Containers i inicjujące obiekt docelowy zaplecza zgodnie z definicją w dziennikach dostępu.

Limity czasu żądania

Usługa Application Gateway dla kontenerów wymusza następujące limity czasu podczas inicjowania i obsługi żądań między klientem, usługą Application Gateway dla kontenerów i backendem.