Udostępnij za pośrednictwem

Sieć w środowisku usługi Azure Container Apps

  • Artykuł

Usługa Azure Container Apps działa w kontekście środowiska z własną siecią wirtualną.

Domyślnie środowisko aplikacji kontenera jest tworzone przy użyciu sieci wirtualnej, która jest automatycznie generowana. W przypadku precyzyjnej kontroli nad siecią można podać istniejącą sieć wirtualną podczas tworzenia środowiska. Po utworzeniu środowiska z wygenerowaną lub istniejącą siecią wirtualną nie można zmienić typu sieci.

Wygenerowane sieci wirtualne przyjmują następujące cechy.

Są to:

  • niedostępny dla Ciebie podczas tworzenia ich w dzierżawie firmy Microsoft
  • publicznie dostępny za pośrednictwem Internetu
  • tylko dostęp do punktów końcowych z dostępem do Internetu

Ponadto obsługują tylko ograniczony podzestaw funkcji sieciowych, takich jak ograniczenia adresów IP ruchu przychodzącego i kontrolki ruchu przychodzącego na poziomie aplikacji kontenera.

Użyj istniejącej sieci wirtualnej, jeśli potrzebujesz większej liczby funkcji sieciowych platformy Azure, takich jak:

  • Integracja z usługą Application Gateway
  • Grupy zabezpieczeń sieci
  • Komunikacja z zasobami za prywatnymi punktami końcowymi w sieci wirtualnej

Dostępne funkcje sieci wirtualnej zależą od wybranego środowiska.

Wybór środowiska

Usługa Container Apps ma dwa różne typy środowisk, które mają wiele takich samych właściwości sieciowych z pewnymi kluczowymi różnicami.

Typ środowiska opis Obsługiwane typy planów
Profile obciążeń Obsługuje trasy zdefiniowane przez użytkownika (UDR) i ruch wychodzący za pośrednictwem bramy translatora adresów sieciowych. Minimalny wymagany rozmiar podsieci to /27. Zużycie, dedykowane
Tylko zużycie Nie obsługuje tras zdefiniowanych przez użytkownika (UDR), wychodzących za pośrednictwem bramy translatora adresów sieciowych, komunikacji równorzędnej za pośrednictwem bramy zdalnej ani innego niestandardowego ruchu wychodzącego. Minimalny wymagany rozmiar podsieci to /23. Zużycie

Poziomy ułatwień dostępu

Możesz skonfigurować, czy aplikacja kontenera zezwala na publiczny ruch przychodzący lub przychodzący tylko z poziomu sieci wirtualnej na poziomie środowiska.

Poziom ułatwień dostępu opis
Zewnętrzne Umożliwia aplikacji kontenera akceptowanie publicznych żądań. Środowiska zewnętrzne są wdrażane przy użyciu wirtualnego adresu IP na zewnętrznym, publicznym adresie IP.
Wewnętrzny Środowiska wewnętrzne nie mają publicznych punktów końcowych i są wdrażane przy użyciu wirtualnego adresu IP (VIP) zamapowanego na wewnętrzny adres IP. Wewnętrzny punkt końcowy jest wewnętrznym modułem równoważenia obciążenia (ILB) platformy Azure, a adresy IP są wystawiane z listy prywatnych adresów IP niestandardowej sieci wirtualnej.

Niestandardowa konfiguracja sieci wirtualnej

Podczas tworzenia niestandardowej sieci wirtualnej należy pamiętać o następujących sytuacjach:

  • Jeśli chcesz, aby aplikacja kontenera ograniczyła cały dostęp zewnętrzny, utwórz wewnętrzne środowisko usługi Container Apps.

  • Jeśli używasz własnej sieci wirtualnej, musisz podać podsieć przeznaczoną wyłącznie dla wdrażanego środowiska aplikacji kontenera. Ta podsieć nie jest dostępna dla innych usług.

  • Adresy sieciowe są przypisywane z zakresu podsieci zdefiniowanego podczas tworzenia środowiska.

    • Zakres podsieci używany przez środowisko Container Apps można zdefiniować.

    • Możesz ograniczyć żądania przychodzące do środowiska wyłącznie do sieci wirtualnej, wdrażając środowisko jako wewnętrzne.

Uwaga

Po podaniu własnej sieci wirtualnej tworzone są dodatkowe zasoby zarządzane. Te zasoby generują koszty według powiązanych stawek.

Podczas projektowania sieci wokół aplikacji kontenera zapoznaj się z tematem Planowanie sieci wirtualnych.

Diagram przedstawiający sposób, w jaki środowiska usługi Azure Container Apps korzystają z istniejącej platformy V NET lub możesz udostępnić własne.

Uwaga

Przenoszenie sieci wirtualnych między różnymi grupami zasobów lub subskrypcjami nie jest dozwolone, jeśli sieć wirtualna jest używana przez środowisko usługi Container Apps.

Zachowanie serwera proxy usługi HTTP Edge

Usługa Azure Container Apps używa serwera proxy usługi Envoy jako brzegowego serwera proxy HTTP. Protokół Transport Layer Security (TLS) jest przerywany na krawędzi, a żądania są kierowane na podstawie reguł podziału ruchu i kierowania ruchu do właściwej aplikacji.

Aplikacje HTTP są skalowane na podstawie liczby żądań i połączeń HTTP. Usługa Envoy kieruje ruch wewnętrzny wewnątrz klastrów.

Połączenia podrzędne obsługują połączenia HTTP1.1 i HTTP2 i Envoy automatycznie wykrywa i uaktualnia połączenia, jeśli połączenie klienta wymaga uaktualnienia.

Połączenia nadrzędne są definiowane przez ustawienie transport właściwości obiektu przychodzącego.

Konfiguracja ruchu przychodzącego

W sekcji ruchu przychodzącego można skonfigurować następujące ustawienia:

  • Poziom ułatwień dostępu: możesz ustawić aplikację kontenera jako zewnętrznie lub wewnętrznie dostępną w środowisku. Zmienna środowiskowa CONTAINER_APP_ENV_DNS_SUFFIX służy do automatycznego rozpoznawania sufiksu w pełni kwalifikowanej nazwy domeny (FQDN) dla danego środowiska. Podczas komunikacji między aplikacjami kontenerów w tym samym środowisku możesz również użyć nazwy aplikacji. Aby uzyskać więcej informacji na temat uzyskiwania dostępu do aplikacji, zobacz Ruch przychodzący w usłudze Azure Container Apps.

  • Reguły podziału ruchu: można zdefiniować reguły podziału ruchu między różnymi wersjami aplikacji. Aby uzyskać więcej informacji, zobacz Podział ruchu.

Aby uzyskać więcej informacji na temat różnych scenariuszy sieciowych, zobacz Ruch przychodzący w usłudze Azure Container Apps.

Zależności portalu

Dla każdej aplikacji w usłudze Azure Container Apps istnieją dwa adresy URL.

Środowisko uruchomieniowe usługi Container Apps początkowo generuje w pełni kwalifikowaną nazwę domeny (FQDN) używaną do uzyskiwania dostępu do aplikacji. Zobacz adres URL aplikacji w oknie Przegląd aplikacji kontenera w witrynie Azure Portal, aby uzyskać nazwę FQDN aplikacji kontenera.

Drugi adres URL jest również generowany dla Ciebie. Ta lokalizacja udziela dostępu do usługi przesyłania strumieniowego dzienników i konsoli. W razie potrzeby może być konieczne dodanie https://azurecontainerapps.dev/ do listy dozwolonych zapory lub serwera proxy.

Porty i adresy IP

Następujące porty są uwidocznione dla połączeń przychodzących.

Protokół Porty
HTTP/HTTPS 80, 443

Adresy IP są podzielone na następujące typy:

Type Opis
Publiczny adres IP dla ruchu przychodzącego Służy do obsługi ruchu aplikacji we wdrożeniu zewnętrznym i ruchu zarządzania zarówno we wdrożeniach wewnętrznych, jak i zewnętrznych.
Wychodzący publiczny adres IP Używany jako adres IP "from" dla połączeń wychodzących, które opuszczają sieć wirtualną. Te połączenia nie są kierowane w dół sieci VPN. Adresy IP ruchu wychodzącego mogą ulec zmianie w czasie. Używanie bramy translatora adresów sieciowych lub innego serwera proxy dla ruchu wychodzącego ze środowiska usługi Container Apps jest obsługiwane tylko w środowisku profilów obciążeń.
Wewnętrzny adres IP modułu równoważenia obciążenia Ten adres istnieje tylko w środowisku wewnętrznym.

Podsieć

Integracja sieci wirtualnej zależy od dedykowanej podsieci. Sposób przydzielania adresów IP w podsieci i obsługiwanych rozmiarów podsieci zależy od tego, który plan jest używany w usłudze Azure Container Apps.

Starannie wybierz rozmiar podsieci. Nie można modyfikować rozmiarów podsieci po utworzeniu środowiska usługi Container Apps.

Różne typy środowisk mają różne wymagania dotyczące podsieci:

  • /27 to minimalny rozmiar podsieci wymagany do integracji sieci wirtualnej.

  • Podsieć musi być delegowana do .Microsoft.App/environments

  • W przypadku korzystania ze środowiska zewnętrznego z zewnętrznymi ruchami przychodzącymi kieruje ruch przychodzący za pośrednictwem publicznego adresu IP infrastruktury, a nie za pośrednictwem podsieci.

  • Usługa Container Apps automatycznie rezerwuje 12 adresów IP na potrzeby integracji z podsiecią. Liczba adresów IP wymaganych do integracji infrastruktury nie różni się w zależności od wymagań skalowania środowiska. Dodatkowe adresy IP są przydzielane zgodnie z następującymi regułami w zależności od typu profilu obciążenia, który używasz więcej adresów IP, są przydzielane w zależności od profilu obciążenia środowiska:

    • Profil dedykowanego obciążenia: w miarę skalowania aplikacji kontenera w poziomie każdy węzeł ma przypisany jeden adres IP.

    • Profil obciążenia zużycie: każdy adres IP może być współużytkowany między wieloma replikami. Podczas planowania liczby adresów IP wymaganych dla aplikacji zaplanuj 1 adres IP na 10 replik.

  • Jeśli wprowadzisz zmianę w trybie pojedynczej poprawki , wymagana przestrzeń adresowa zostanie podwoina przez krótki czas w celu zapewnienia obsługi wdrożeń bez przestojów. Ma to wpływ na rzeczywiste, dostępne obsługiwane repliki lub węzły dla danego rozmiaru podsieci. W poniższej tabeli przedstawiono zarówno maksymalne dostępne adresy na blok CIDR, jak i wpływ na skalę poziomą.

    Rozmiar podsieci Dostępne adresyIP 1 Maksymalna liczba węzłów (profil dedykowanego obciążenia)2 Maksymalna liczba replik (profil obciążenia zużycie)2
    /23 500 250 2500
    /24 244 122 1,220
    /25 116 58 580
    /26 52 26 260
    /27 20 10 100

    1 Dostępne adresy IP to rozmiar podsieci minus 12 adresów IP wymaganych dla infrastruktury usługi Azure Container Apps.
    2 Dotyczy to aplikacji w trybie pojedynczej poprawki.

Ograniczenia zakresu adresów podsieci

Zakresy adresów podsieci nie mogą nakładać się na następujące zakresy zarezerwowane przez usługi Azure Kubernetes Services:

  • 169.254.0.0/16
  • 172.30.0.0/16
  • 172.31.0.0/16
  • 192.0.2.0/24

Ponadto środowisko profilów obciążeń rezerwuje następujące adresy:

  • 100.100.0.0/17
  • 100.100.128.0/19
  • 100.100.160.0/19
  • 100.100.192.0/19

Konfiguracja podsieci z interfejsem wiersza polecenia

W miarę tworzenia środowiska usługi Container Apps należy podać identyfikatory zasobów dla jednej podsieci.

Jeśli używasz interfejsu wiersza polecenia, parametrem do zdefiniowania identyfikatora zasobu podsieci jest infrastructure-subnet-resource-id. Podsieć hostuje składniki infrastruktury i kontenery aplikacji użytkownika.

Jeśli używasz interfejsu wiersza polecenia platformy Azure z użyciem tylko środowiska, a zakres platformyReservedCidr jest zdefiniowany, podsieć nie może pokrywać się z zakresem adresów IP zdefiniowanym w elemencie platformReservedCidr.

Trasy

Trasy zdefiniowane przez użytkownika (UDR)

Trasy definiowane przez użytkownika (UDR) i ruch wychodzący kontrolowany za pośrednictwem usługi NAT Gateway są obsługiwane w środowisku profilów obciążeń. W środowisku tylko do użycia te funkcje nie są obsługiwane.

Uwaga

W przypadku korzystania z trasy zdefiniowanej przez użytkownika z usługą Azure Firewall w usłudze Azure Container Apps należy dodać pewne tagi FQDN i usługi do listy dozwolonych zapory. Aby dowiedzieć się więcej, zobacz Konfigurowanie trasy zdefiniowanej przez użytkownika za pomocą usługi Azure Firewall.

  • Tras definiowanych przez użytkownika można używać wraz ze środowiskami profilów obciążeń, aby ograniczyć ruch wychodzący z aplikacji kontenera za pośrednictwem usługi Azure Firewall lub innych urządzeń sieciowych.

  • Konfigurowanie tras definiowanych przez użytkownika odbywa się poza zakresem środowiska usługi Container Apps.

Diagram przedstawiający sposób implementowania trasy zdefiniowanej przez użytkownika dla usługi Container Apps.

Platforma Azure tworzy domyślną tabelę tras dla sieci wirtualnych podczas tworzenia. Implementując tabelę tras zdefiniowaną przez użytkownika, możesz kontrolować sposób kierowania ruchu w sieci wirtualnej. Można na przykład utworzyć trasę zdefiniowaną przez użytkownika, która kieruje cały ruch do zapory.

Konfigurowanie trasy zdefiniowanej przez użytkownika za pomocą usługi Azure Firewall

Trasy zdefiniowane przez użytkownika są obsługiwane tylko w środowisku profilów obciążeń. Następujące reguły aplikacji i sieci należy dodać do listy dozwolonych zapory w zależności od używanych zasobów.

Uwaga

Aby zapoznać się z przewodnikiem dotyczącym konfigurowania trasy zdefiniowanej przez użytkownika za pomocą usługi Container Apps w celu ograniczenia ruchu wychodzącego za pomocą usługi Azure Firewall, zapoznaj się z instrukcjami dotyczącymi usługi Container Apps i Azure Firewall.

Reguły aplikacji

Reguły aplikacji zezwalają na ruch lub odmawiają go na podstawie warstwy aplikacji. Następujące reguły aplikacji zapory dla ruchu wychodzącego są wymagane na podstawie scenariusza.

Scenariusze Nazwy FQDN opis
Wszystkie scenariusze mcr.microsoft.com, *.data.mcr.microsoft.com Te nazwy FQDN dla usługi Microsoft Container Registry (MCR) są używane przez usługę Azure Container Apps, a te reguły aplikacji lub reguły sieciowe dla mcR muszą zostać dodane do listy dozwolonych podczas korzystania z usługi Azure Container Apps z usługą Azure Firewall.
Azure Container Registry (ACR) Twój adres ACR, , *.blob.core.windows.netlogin.microsoft.com Te nazwy FQDN są wymagane w przypadku korzystania z usługi Azure Container Apps z usługami ACR i Azure Firewall.
Azure Key Vault Your-Azure-Key-Vault-address, login.microsoft.com Te nazwy FQDN są wymagane oprócz tagu usługi wymaganego dla reguły sieciowej dla usługi Azure Key Vault.
Tożsamość zarządzana *.identity.azure.net, , login.microsoftonline.com, , *.login.microsoftonline.com*.login.microsoft.com Te nazwy FQDN są wymagane w przypadku korzystania z tożsamości zarządzanej z usługą Azure Firewall w usłudze Azure Container Apps.
Rejestr usługi Docker Hub hub.docker.com, , registry-1.docker.ioproduction.cloudflare.docker.com Jeśli używasz rejestru usługi Docker Hub i chcesz uzyskać do niego dostęp za pośrednictwem zapory, musisz dodać te nazwy FQDN do zapory.
Reguły sieci

Reguły sieci zezwalają na ruch lub odmawiają go na podstawie warstwy sieci i transportu. Następujące reguły sieciowe zapory dla ruchu wychodzącego są wymagane na podstawie scenariusza.

Scenariusze Tag usługi opis
Wszystkie scenariusze MicrosoftContainerRegistry, AzureFrontDoorFirstParty Te tagi usługi dla usługi Microsoft Container Registry (MCR) są używane przez usługę Azure Container Apps, a te reguły sieci lub reguły aplikacji dla mcR muszą zostać dodane do listy dozwolonych podczas korzystania z usługi Azure Container Apps z usługą Azure Firewall.
Azure Container Registry (ACR) AzureContainerRegistry, AzureActiveDirectory W przypadku korzystania z usługi ACR z usługą Azure Container Apps należy skonfigurować te reguły aplikacji używane przez usługę Azure Container Registry.
Azure Key Vault AzureKeyVault, AzureActiveDirectory Te tagi usługi są wymagane oprócz nazwy FQDN dla reguły aplikacji dla usługi Azure Key Vault.
Tożsamość zarządzana AzureActiveDirectory W przypadku korzystania z tożsamości zarządzanej z usługą Azure Container Apps należy skonfigurować te reguły aplikacji używane przez tożsamość zarządzaną.

Uwaga

W przypadku zasobów platformy Azure używanych z usługą Azure Firewall, których nie wymieniono w tym artykule, zapoznaj się z dokumentacją tagów usług.

Integracja bramy translatora adresów sieciowych

Brama translatora adresów sieciowych umożliwia uproszczenie łączności wychodzącej dla wychodzącego ruchu internetowego w sieci wirtualnej w środowisku profilów obciążeń.

Podczas konfigurowania bramy translatora adresów sieciowych w podsieci brama translatora adresów sieciowych udostępnia statyczny publiczny adres IP dla danego środowiska. Cały ruch wychodzący z aplikacji kontenera jest kierowany przez statyczny publiczny adres IP bramy translatora adresów sieciowych.

Zabezpieczenia środowiska

Diagram przedstawiający sposób pełnego blokowania sieci dla usługi Container Apps.

Możesz w pełni zabezpieczyć środowisko profilów obciążeń ruchu sieciowego ruchu przychodzącego i wychodzącego, wykonując następujące akcje:

Szyfrowanie równorzędne w środowisku usługi Azure Container Apps

Usługa Azure Container Apps obsługuje szyfrowanie TLS komunikacji równorzędnej w środowisku. Włączenie tej funkcji powoduje szyfrowanie całego ruchu sieciowego w środowisku przy użyciu certyfikatu prywatnego, który jest ważny w zakresie środowiska usługi Azure Container Apps. Te certyfikaty są automatycznie zarządzane przez usługę Azure Container Apps.

Uwaga

Domyślnie szyfrowanie równorzędne jest wyłączone. Włączenie szyfrowania równorzędnego dla aplikacji może zwiększyć opóźnienie odpowiedzi i zmniejszyć maksymalną przepływność w scenariuszach wysokiego obciążenia.

W poniższym przykładzie pokazano środowisko z włączonym szyfrowaniem równorzędnym. Diagram przedstawiający sposób szyfrowania/odszyfrowywania ruchu z włączonym szyfrowaniem równorzędnym.

1 Ruch przychodzący TLS jest przerywany na serwerze proxy ruchu przychodzącego na brzegu środowiska.

2 Ruch do i z serwera proxy ruchu przychodzącego w środowisku jest szyfrowany przy użyciu certyfikatu prywatnego i odszyfrowywane przez odbiornik.

3 Wywołania wykonywane z aplikacji A do nazwy FQDN aplikacji B są najpierw wysyłane do serwera proxy ruchu przychodzącego brzegowego i są szyfrowane przy użyciu protokołu TLS.

4 Wywołania wykonywane z aplikacji A do aplikacji B przy użyciu nazwy aplikacji B są wysyłane bezpośrednio do aplikacji B i są szyfrowane przy użyciu protokołu TLS.

Aplikacje w środowisku usługi Container Apps są automatycznie uwierzytelniane. Jednak środowisko uruchomieniowe usługi Container Apps nie obsługuje autoryzacji do kontroli dostępu między aplikacjami przy użyciu wbudowanego szyfrowania równorzędnego.

Gdy aplikacje komunikują się z klientem spoza środowiska, obsługiwane jest uwierzytelnianie dwukierunkowe za pomocą biblioteki mTLS. Aby dowiedzieć się więcej, zobacz konfigurowanie certyfikatów klienta.

Szyfrowanie równorzędne można włączyć przy użyciu następujących poleceń.

Podczas tworzenia:

az containerapp env create \
    --name <environment-name> \
    --resource-group <resource-group> \
    --location <location> \
    --enable-peer-to-peer-encryption

W przypadku istniejącej aplikacji kontenera:

az containerapp env update \
    --name <environment-name> \
    --resource-group <resource-group> \
    --enable-peer-to-peer-encryption

DNS

  • Niestandardowy system DNS: jeśli sieć wirtualna używa niestandardowego serwera DNS zamiast domyślnego serwera DNS dostarczonego przez platformę Azure, skonfiguruj serwer DNS, aby przekazywać nierozwiązane zapytania DNS do usługi 168.63.129.16. Rekursywne narzędzia rozpoznawania nazw platformy Azure używają tego adresu IP do rozwiązywania żądań. Podczas konfigurowania sieciowej grupy zabezpieczeń lub zapory nie blokuj 168.63.129.16 adresu, w przeciwnym razie środowisko usługi Container Apps nie będzie działać poprawnie.

  • Ruch przychodzący w zakresie sieci wirtualnej: jeśli planujesz używać ruchu przychodzącego w zakresie sieci wirtualnej w środowisku wewnętrznym, skonfiguruj domeny na jeden z następujących sposobów:

    1. Domeny inne niż niestandardowe: jeśli nie planujesz używania domeny niestandardowej, utwórz prywatną strefę DNS, która rozpoznaje domyślną domenę środowiska Container Apps na statyczny adres IP środowiska Container Apps. Możesz użyć usługi Azure Prywatna strefa DNS lub własnego serwera DNS. Jeśli używasz usługi Azure Prywatna strefa DNS, utwórz prywatną strefę DNS o nazwie jako domenę domyślną środowiska aplikacji kontenera (<UNIQUE_IDENTIFIER>.<REGION_NAME>.azurecontainerapps.io) z rekordemA. Rekord A zawiera nazwę *<DNS Suffix> i statyczny adres IP środowiska Container Apps.

    2. Domeny niestandardowe: jeśli planujesz używać domen niestandardowych i używasz zewnętrznego środowiska usługi Container Apps, użyj publicznie rozpoznawalnej domeny, aby dodać domenę niestandardową i certyfikat do aplikacji kontenera. Jeśli używasz wewnętrznego środowiska usługi Container Apps, nie ma weryfikacji powiązania DNS, ponieważ dostęp do klastra można uzyskać tylko z poziomu sieci wirtualnej. Ponadto utwórz prywatną strefę DNS, która rozpoznaje domenę wierzchołka na statyczny adres IP środowiska Container Apps. Możesz użyć usługi Azure Prywatna strefa DNS lub własnego serwera DNS. Jeśli używasz usługi Azure Prywatna strefa DNS, utwórz strefę Prywatna strefa DNS o nazwie jako domenę wierzchołka z rekordem A wskazującym statyczny adres IP środowiska usługi Container Apps.

Statyczny adres IP środowiska Container Apps jest dostępny w witrynie Azure Portal w niestandardowym sufiksie DNS strony aplikacji kontenera lub za pomocą polecenia interfejsu wiersza polecenia az containerapp env list platformy Azure.

Zasoby zarządzane

Podczas wdrażania środowiska wewnętrznego lub zewnętrznego w sieci zostanie utworzona nowa grupa zasobów w subskrypcji platformy Azure, w której jest hostowane środowisko. Ta grupa zasobów zawiera składniki infrastruktury zarządzane przez platformę Azure Container Apps. Nie należy modyfikować usług w tej grupie ani samej grupie zasobów.

Środowisko profilów obciążeń

Nazwa grupy zasobów utworzonej w subskrypcji platformy Azure, w której hostowane jest środowisko, jest domyślnie poprzedzona prefiksem ME_ , a nazwa grupy zasobów można dostosować podczas tworzenia środowiska aplikacji kontenera.

W przypadku środowisk zewnętrznych grupa zasobów zawiera publiczny adres IP używany specjalnie do łączności przychodzącej ze środowiskiem zewnętrznym i modułem równoważenia obciążenia. W przypadku środowisk wewnętrznych grupa zasobów zawiera tylko moduł równoważenia obciążenia.

Oprócz standardowych rozliczeń usługi Azure Container Apps opłaty są naliczane za:

Środowisko tylko do użycia

Nazwa grupy zasobów utworzonej w subskrypcji platformy Azure, w której jest hostowane środowisko, jest domyślnie poprzedzona prefiksem MC_ , a nazwa grupy zasobów nie może być dostosowywana podczas tworzenia aplikacji kontenera. Grupa zasobów zawiera publiczne adresy IP używane specjalnie do łączności wychodzącej ze środowiska i modułu równoważenia obciążenia.

Oprócz standardowych rozliczeń usługi Azure Container Apps opłaty są naliczane za:

  • Jeden standardowy statyczny publiczny adres IP dla ruchu wychodzącego. Jeśli potrzebujesz więcej adresów IP dla ruchu wychodzącego z powodu problemów z tłumaczeniem adresów sieciowych (SNAT), otwórz bilet pomocy technicznej, aby zażądać zastąpienia.

  • Dwa standardowe moduły równoważenia obciążenia w przypadku korzystania ze środowiska wewnętrznego lub jeden standardowy moduł równoważenia obciążenia w przypadku korzystania ze środowiska zewnętrznego. Każdy moduł równoważenia obciążenia ma mniej niż sześć reguł. Koszt przetwarzanych danych (w GB) obejmuje zarówno ruch przychodzący, jak i wychodzący na potrzeby operacji zarządzania.

Następne kroki