Freigeben über

Netzwerk in der Azure Container Apps-Umgebung

  • Artikel

Azure Container-Apps werden im Kontext einer Umgebung mit einem eigenen virtuellen Netzwerk (VNet) ausgeführt.

Die Container-App-Umgebung wird standardmäßig mit einem automatisch erzeugten VNET erstellt. Wenn Sie Ihr Netzwerk präziser steuern möchten, können Sie beim Erstellen einer Umgebung ein vorhandenes VNET angeben. Nach der Erstellung der Umgebung, ob mit erzeugtem oder vorhandenem VNET, können Sie den Netzwerktyp nicht mehr ändern.

Generierte VNets übernehmen die folgenden Merkmale.

Sie lauten wie folgt:

  • für Sie nicht zugänglich, da sie im Mandanten von Microsoft erstellt werden
  • Öffentlich zugänglich über das Internet
  • nur in der Lage, internetfähige Endpunkte zu erreichen

Darüber hinaus unterstützen sie nur eine begrenzte Teilmenge von Netzwerkfunktionen, z. B. eingehende IP-Einschränkungen und Eingangssteuerelemente auf Container-App-Ebene.

Verwenden Sie ein vorhandenes VNet, wenn Sie weitere Azure-Netzwerkfeatures benötigen, z. B.:

  • Integration in Application Gateway
  • Netzwerksicherheitsgruppen
  • Kommunikation mit Ressourcen hinter privaten Endpunkten in Ihrem virtuellen Netzwerk

Die verfügbaren VNet-Features hängen von Ihrer Umgebungsauswahl ab.

Umgebungsauswahl

Container-Apps verfügen über zwei verschiedene Umgebungstypen, die viele der gleichen Netzwerkmerkmale mit einigen wichtigen Unterschieden aufweisen.

Umgebungstyp Beschreibung Unterstützte Plantypen
Workloadprofile Unterstützt benutzerdefinierte Routen (UDR) und den Ausgang über das NAT-Gateway. Die minimale erforderliche Subnetzgröße ist /27. Verbrauch, dediziert
Nur Verbrauch Unterstützt keine benutzerdefinierten Routen (User Defined Routes, UDR), den Ausgang über NAT-Gateway, Peering über ein Remotegateway oder einen anderen benutzerdefinierten Ausgang. Die minimale erforderliche Subnetzgröße ist /23. Verbrauch

Zugriffsebenen

Sie können auf der Umgebungsebene konfigurieren, ob Ihre Container-App einen öffentlichen Eingang oder einen Eingang nur aus Ihrem VNet zulässt.

Zugriffsebene Beschreibung
Extern Ermöglicht Ihrer Container-App, öffentliche Anforderungen zu akzeptieren. Externe Umgebungen werden mit einer virtuellen IP-Adresse unter einer externen, öffentlichen IP-Adresse bereitgestellt.
Intern Interne Umgebungen haben keine öffentlichen Endpunkte und werden mit einer virtuellen IP-Adresse (VIP) bereitgestellt, die einer internen IP-Adresse zugeordnet ist. Der interne Endpunkt ist ein interner Azure Load Balancer (ILB); IP-Adressen werden aus der Liste der privaten IP-Adressen des benutzerdefinierten VNet ausgegeben.

Benutzerdefinierte VNet-Konfiguration

Wenn Sie ein benutzerdefiniertes Vnet erstellen, berücksichtigen Sie die folgenden Situationen:

  • Wenn Sie möchten, dass Ihre Container-App den gesamten externen Zugriff einschränken soll, erstellen Sie eine interne Container Apps-Umgebung.

  • Wenn Sie Ihr eigenes VNet nutzen, müssen Sie ein Subnetz bereitstellen, das ausschließlich der Container-App-Umgebung zugeordnet ist, die Sie bereitstellen. Dieses Subnetz steht anderen Diensten nicht zur Verfügung.

  • Netzwerkadressen werden aus einem Subnetzbereich zugewiesen, den Sie beim Erstellen der Umgebung definieren.

    • Sie können den Subnetzbereich definieren, der von der Container Apps-Umgebung verwendet wird.

    • Sie können eingehende Anforderungen an die Umgebung ausschließlich auf das Vnet beschränken, indem Sie die Umgebung als intern bereitstellen.

Hinweis

Wenn Sie Ihr eigenes virtuelles Netzwerk bereitstellen, werden zusätzliche verwaltete Ressourcen erstellt. Diese Ressourcen verursachen Kosten zu ihren zugeordneten Tarifen.

Wenn Sie mit dem Entwerfen des Netzwerks für Ihre Container-App beginnen, lesen Sie Planen virtueller Netzwerke.

Diagram, wie Azure Container Apps-Umgebungen ein bestehendes V NET verwenden, oder Sie können Ihr eigenes angeben.

Hinweis

Das Verschieben von VNets zwischen verschiedenen Ressourcengruppen oder Abonnements wird nicht erlaubt, wenn das VNet von einer Container Apps-Umgebung verwendet wird.

Verhalten des HTTP-Edgeproxys

Azure Container Apps verwendet den Envoy Proxy als HTTP-Edgeproxy. Transport Layer Security (TLS) endet am Edge, und Anforderungen werden gemäß ihren Datenverkehrs-Aufteilungsregeln weitergeleitet, und der Datenverkehr wird an die richtige Anwendung weitergeleitet.

HTTP-Anwendungen werden basierend auf der Anzahl der HTTP-Anforderungen und -Verbindungen skaliert. Envoy leitet den internen Datenverkehr innerhalb von Clustern weiter.

Downstreamverbindungen unterstützen HTTP1.1 und HTTP2, und Envoy erkennt und aktualisiert Verbindungen automatisch, falls für die Clientverbindung ein Upgrade erforderlich ist.

Die Upstreamverbindungen werden durch Festlegen der transport-Eigenschaft im Eingangs-Objekt definiert.

Konfiguration des eingehenden Datenverkehrs

Im Abschnitt ingress (Eingang) können Sie die folgenden Einstellungen konfigurieren:

  • Zugriffsebene: Sie können Ihre Container-App als extern oder intern zugänglich in der Umgebung festlegen. Die Umgebungsvariable CONTAINER_APP_ENV_DNS_SUFFIX wird verwendet, um das vollqualifizierte Domänennamen FQDN-Suffix (fully qualified domain name) für Ihre Umgebung automatisch aufzulösen. Bei der Kommunikation zwischen Container-Apps innerhalb derselben Umgebung können Sie auch den App-Namen verwenden. Weitere Informationen zum Zugreifen auf Ihre Apps finden Sie unter Eingang in Azure Container Apps.

  • Datenverkehrs-Aufteilungsregeln: Sie können Datenverkehrs-Aufteilungsregeln zwischen verschiedenen Revisionen Ihrer Anwendung definieren. Weitere Informationen finden Sie unter Datenverkehrsaufteilung.

Weitere Informationen zu verschiedenen Netzwerkszenarien finden Sie unter Eingang in Azure Container Apps.

Portalabhängigkeiten

Für jede App in Azure Container Apps gibt es zwei URLs.

Die Container-Apps-Laufzeit generiert zunächst einen vollqualifizierten Domänennamen (Fully Qualified Domain Name, FQDN), der für den Zugriff auf Ihre App verwendet wird. Sehen Sie sich die Anwendungs-URL im Übersichtsfenster Ihrer Container-App im Azure-Portal für den FQDN Ihrer Container-App an.

Eine zweite URL wird auch für Sie generiert. Dieser Speicherort gewährt Zugriff auf den Protokollstreamingdienst und die Konsole. Falls erforderlich, müssen Sie möglicherweise https://azurecontainerapps.dev/ der Zulassungsliste Ihrer Firewall oder Ihres Proxys hinzufügen.

Ports und IP-Adressen

Die folgenden Ports werden für eingehende Verbindungen verfügbar gemacht.

Protokoll Port(s)
HTTP/HTTPS 80, 443

IP-Adressen werden in die folgenden Typen unterteilt:

type Beschreibung
Öffentliche IP-Adresse für eingehenden Datenverkehr Wird für den Anwendungsdatenverkehr in einer externen ASE und für den Verwaltungsdatenverkehr sowohl in externen als auch in internen Bereitstellungen verwendet.
Öffentliche IP-Adresse für ausgehenden Datenverkehr Wird als „von“-IP-Adresse für ausgehende Verbindungen verwendet, die das virtuelle Netzwerk verlassen. Diese Verbindungen werden nicht über ein VPN weitergeleitet. Ausgehende IPs können sich im Laufe der Zeit ändern. Die Verwendung eines NAT-Gateways oder eines anderen Proxys für ausgehenden Datenverkehr aus einer Container-Apps-Umgebung wird nur in einer Workloadprofilumgebung unterstützt.
IP-Adresse des internen Lastenausgleichs Diese Adresse ist nur in einer internen Bereitstellung vorhanden.

Subnet

Die Integration virtueller Netzwerke hängt von der Verwendung eines dedizierten Subnetzes ab. Wie IP-Adressen in einem Subnetz zugeordnet werden und welche Subnetzgrößen unterstützt werden, hängt davon ab, welchen Plan Sie in Azure-Container-Apps verwenden.

Wählen Sie Ihre Subnetzgröße sorgfältig aus. Subnetzgrößen können nicht geändert werden, nachdem Sie eine Container-Apps-Umgebung erstellt haben.

Unterschiedliche Umgebungstypen weisen unterschiedliche Subnetzanforderungen auf:

  • /27 ist die minimale Subnetzgröße, die für die Integration des virtuellen Netzwerks erforderlich ist.

  • Ihr Subnetz muss an Microsoft.App/environments delegiert werden.

  • Wenn Sie eine externe Umgebung mit externem Eingang verwenden, wird der eingehende Datenverkehr über die öffentliche IP-Adresse der Infrastruktur und nicht über Ihr Subnetz geleitet.

  • Container-Apps reserviert automatisch 12 IP-Adressen für die Integration in das Subnetz. Die Anzahl der für die Infrastrukturintegration erforderlichen IP-Adressen variiert nicht basierend auf den Skalierungsanforderungen der Umgebung. Zusätzliche IP-Adressen werden nach den folgenden Regeln zugewiesen, je nach Art des von Ihnen verwendeten Workloadprofils werden je nach Workloadprofil Ihrer Umgebung mehr IP-Adressen zugewiesen:

    • Dediziertes Workloadprofil: Wenn Ihre Container-App skaliert wird, weist jeder Knoten eine IP-Adresse zu.

    • Arbeitsauslastungsprofil: Jede IP-Adresse kann für mehrere Replikate freigegeben werden. Wenn Sie planen, wie viele IP-Adressen für Ihre Anwendung benötigt werden, planen Sie 1 IP-Adresse pro 10 Replikate ein.

  • Wenn Sie eine Änderung an einer Überarbeitung im Einzelrevisionsmodus vornehmen, wird der erforderliche Adressraum für einen kurzen Zeitraum verdoppelt, um Bereitstellungen ohne Ausfallzeiten zu unterstützen. Dies wirkt sich auf die tatsächlichen, verfügbaren unterstützten Replikate oder Knoten für eine bestimmte Subnetzgröße aus. Die folgende Tabelle zeigt sowohl die maximal verfügbaren Adressen pro CIDR-Block als auch die Auswirkungen auf die horizontale Skalierung.

    Subnetzgröße Verfügbare IP-Adressen1 Max. Knoten (Dediziertes Workloadprofil)2 Max. Replikate (Verbrauchs-Workloadprofil)2
    /23 500 250 2\.500
    /24 244 122 1.220
    /25 116 58 580
    /26 52 26 260
    /27 20 10 100

    1 Die verfügbaren IP-Adressen sind die Größe des Subnetzes abzüglich der 12 IP-Adressen, die für die Azure-Container-Apps-Infrastruktur erforderlich sind.
    2 Dies ist die Rechnung für Apps im Einzelrevisionsmodus.

Einschränkungen des Subnetzadressbereichs

Subnetzadressbereiche können sich nicht mit den folgenden Bereichen überschneiden, die von Azure Kubernetes Services reserviert sind:

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

Darüber hinaus behält sich eine Workloadprofil-Umgebung die folgenden Adressen vor:

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

Subnetzkonfiguration mit CLI

Wenn eine Container Apps-Umgebung erstellt wird, geben Sie Ressourcen-IDs für ein einzelnes Subnetz an.

Wenn Sie die CLI verwenden, ist infrastructure-subnet-resource-id der Parameter zum Definieren der Subnetzressourcen-ID. Das Subnetz hostet Infrastrukturkomponenten und Benutzer-App-Container.

Wenn Sie die Azure CLI mit einer Nur-Verbrauchs-Umgebung verwenden und der platformReservedCidr-Bereich definiert ist, dürfen sich die Subnetze nicht mit dem in platformReservedCidr definierten IP-Adressbereich überschneiden.

Routen

Benutzerdefinierte Routen (UDR)

Benutzerdefinierte Routen (UDR) und kontrollierter Ausgang über das NAT Gateway werden in der Workload-Profilumgebung unterstützt. In der verbrauchsorientierten Umgebung werden diese Funktionen nicht unterstützt.

Hinweis

Wenn Sie UDR mit Azure Firewall in Azure Container Apps verwenden, müssen Sie bestimmte FQDNs und Service-Tags zur Erlaubnisliste für die Firewall hinzufügen. Weitere Informationen finden Sie unter Konfigurieren von UDR mit Azure Firewall.

  • Sie können UDR mit Workload-Profilumgebungen verwenden, um ausgehenden Datenverkehr von Ihrer Container-App über Azure Firewall oder andere Netzwerkgeräte einzuschränken.

  • Das Konfigurieren von UDR erfolgt außerhalb des Bereichs „Container Apps“.

Diagramm der Implementierung von UDR für Container-Apps.

Azure erstellt beim Erstellen eine Standardroutentabelle für Ihre virtuellen Netzwerke. Durch die Implementierung einer benutzerdefinierten Routentabelle können Sie steuern, wie Datenverkehr innerhalb Ihres virtuellen Netzwerks weitergeleitet wird. Sie können z. B. ein UDR erstellen, das den gesamten Datenverkehr an die Firewall weiterleitet.

Konfigurieren von UDR mit Azure Firewall

Benutzerdefinierte Routen werden nur in einer Workloadprofilumgebung unterstützt. Die folgenden Anwendungs- und Netzwerkregeln müssen der Zulassungsliste für Ihre Firewall hinzugefügt werden, je nachdem, welche Ressourcen Sie verwenden.

Hinweis

Eine Anleitung zum Einrichten von UDR mit Container-Apps, um ausgehenden Datenverkehr mit Azure Firewall einzuschränken, finden Sie unter Vorgehensweise für Container-Apps und Azure-Firewall.

Anwendungsregeln

Anwendungsregeln erlauben oder verweigern Datenverkehr basierend auf der Anwendungsschicht. Die folgenden Regeln für ausgehende Firewallanwendungen sind basierend auf einem Szenario erforderlich.

Szenarien FQDNs Beschreibung
Alle Szenarien mcr.microsoft.com, *.data.mcr.microsoft.com Diese FQDNs für die Microsoft Container Registry (MCR) werden von Azure-Container-Apps verwendet, und es müssen entweder diese Anwendungsregeln oder die Netzwerkregeln für MCR der Zulassungsliste hinzugefügt werden, wenn Sie Azure Container-Apps mit Azure Firewall verwenden.
Azure Container Registry (ACR) Your-ACR-address, *.blob.core.windows.net, login.microsoft.com Diese FQDNs sind erforderlich, wenn Sie Azure-Container-Apps mit ACR und Azure Firewall verwenden.
Azure Key Vault Your-Azure-Key-Vault-address, login.microsoft.com Diese FQDNs sind zusätzlich zu dem Diensttag erforderlich, das für die Netzwerkregel für Azure Key Vault erforderlich ist.
Verwaltete Identität *.identity.azure.net, login.microsoftonline.com, *.login.microsoftonline.com, *.login.microsoft.com Diese FQDNs sind erforderlich, wenn sie eine verwaltete Identität mit Azure Firewall in Azure-Container-Apps verwenden.
Docker Hub-Registrierung hub.docker.com, registry-1.docker.io, production.cloudflare.docker.com Wenn Sie die Docker Hub-Registrierung verwenden und über die Firewall darauf zugreifen möchten, müssen Sie diese FQDNs zur Firewall hinzufügen.
Netzwerkregeln

Netzwerkregeln ermöglichen oder verweigern Datenverkehr basierend auf der Netzwerk- und Transportschicht. Die folgenden Regeln für ausgehende Firewallnetzwerke sind basierend auf einem Szenario erforderlich.

Szenarien Diensttag Beschreibung
Alle Szenarien MicrosoftContainerRegistry, AzureFrontDoorFirstParty Diese Servicetags für die Microsoft Container Registry (MCR) werden von Azure-Container-Apps verwendet, und es müssen entweder diese Netzwerkregeln oder die Anwendungsregeln für MCR der Zulassungsliste hinzugefügt werden, wenn Sie Azure Container-Apps mit Azure Firewall verwenden.
Azure Container Registry (ACR) AzureContainerRegistry, AzureActiveDirectory Wenn Sie ACR mit Azure-Container-Apps verwenden, müssen Sie diese Anwendungsregeln konfigurieren, die von der Azure Container Registry verwendet werden.
Azure Key Vault AzureKeyVault, AzureActiveDirectory Diese Servicetags sind zusätzlich zum FQDN für die Anwendungsregel für Azure Key Vault erforderlich.
Verwaltete Identität AzureActiveDirectory Wenn Sie Managed Identity mit Azure-Container-Apps verwenden, müssen Sie diese Anwendungsregeln konfigurieren, die von der Managed Identity verwendet werden.

Hinweis

Für Azure-Ressourcen, die Sie mit Azure Firewall verwenden, die nicht in diesem Artikel aufgeführt sind, finden Sie in der Dokumentation zu Servicetags.

NAT-Gatewayintegration

Sie können das NAT-Gateway verwenden, um die ausgehende Konnektivität für Ihren ausgehenden Internetdatenverkehr in Ihrem virtuellen Netzwerk in einer Workloadprofilumgebung zu vereinfachen.

Wenn Sie ein NAT-Gateway in Ihrem Subnetz konfigurieren, stellt das NAT-Gateway eine statische öffentliche IP-Adresse für Ihre Umgebung bereit. Der gesamte ausgehende Datenverkehr aus Ihrer Container-App wird über die statische öffentliche IP-Adresse des NAT-Gateways weitergeleitet.

Umgebungssicherheit

Diagramm, wie Sie Ihr Netzwerk für Container-Apps vollständig sperren.

Sie können Ihre Umgebung für den Eingangs- und Ausgangs-Netzwerkdatenverkehr vollständig schützen, indem Sie die folgenden Aktionen ausführen:

Peer-to-Peer-Verschlüsselung in der Azure-Container-Apps-Umgebung

Azure-Container-Apps unterstützen die Peer-to-Peer-TLS-Verschlüsselung innerhalb der Umgebung. Durch Aktivieren dieses Features wird der gesamte Netzwerkdatenverkehr innerhalb der Umgebung mit einem privaten Zertifikat verschlüsselt, das innerhalb des Azure-Container-Apps-Umgebungsbereichs gültig ist. Diese Zertifikate werden automatisch von Azure Container-Apps verwaltet.

Hinweis

Standardmäßig ist die Peer-to-Peer-Verschlüsselung deaktiviert. Das Aktivieren der Peer-to-Peer-Verschlüsselung für Ihre Anwendungen kann die Antwortlatenz erhöhen und den maximalen Durchsatz in Szenarien mit hoher Auslastung verringern.

Das folgende Beispiel zeigt eine Umgebung mit aktivierter Peer-to-Peer-Verschlüsselung. Diagramm, wie Datenverkehr mit aktivierter Peer-zu-Peer-Verschlüsselung verschlüsselt/entschlüsselt wird.

1 Eingehender TLS-Datenverkehr wird am Eingangsproxy am Rand der Umgebung beendet.

2 Datenverkehr zum und vom Eingangsproxy innerhalb der Umgebung wird mit einem privaten Zertifikat TLS-verschlüsselt und vom Empfänger entschlüsselt.

3 Aufrufe von App A an den FQDN von App B werden zuerst an den Edge-Eingangsproxy gesendet und sind TLS verschlüsselt.

4 Aufrufe von App A an App B mithilfe des App-B-App-Namens werden direkt an App B gesendet und TLS verschlüsselt.

Anwendungen in einer Container-Apps-Umgebung werden automatisch authentifiziert. Die Container-Apps-Laufzeit unterstützt jedoch keine Autorisierung für die Zugriffssteuerung zwischen Anwendungen, welche die integrierte Peer-to-Peer-Verschlüsselung verwenden.

Wenn Ihre Apps mit einem Client außerhalb der Umgebung kommunizieren, wird die bidirektionale Authentifizierung mit mTLS unterstützt. Weitere Informationen finden Sie unter Konfigurieren von Clientzertifikaten.

Sie können die Peer-to-Peer-Verschlüsselung mit den folgenden Befehlen aktivieren.

Beim Erstellen:

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

Für eine vorhandene Container-App:

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

Domain Name System

  • Benutzerdefiniertes DNS: Wenn Ihr VNet anstelle des standardmäßigen von Azure bereitgestellten DNS-Servers einen benutzerdefinierten DNS-Server verwendet, konfigurieren Sie Ihren DNS-Server so, dass nicht aufgelöste DNS-Abfragen an 168.63.129.16 weitergeleitet werden. Rekursive Resolver von Azure verwendet diese IP-Adresse, um Anforderungen aufzulösen. Wenn Sie Ihre NSG oder Firewall konfigurieren, blockieren Sie die 168.63.129.16-Adresse nicht, andernfalls funktioniert Ihre Container-Apps-Umgebung nicht ordnungsgemäß.

  • VNet-Eingangsbereich: Wenn Sie den eingehenden VNet-Bereich in einer internen Umgebung verwenden möchten, konfigurieren Sie Ihre Domänen auf eine der folgenden Arten:

    1. Nicht benutzerdefinierte Domänen: Wenn Sie nicht planen, eine benutzerdefinierte Domäne zu verwenden, erstellen Sie eine private DNS-Zone, die die Standarddomäne der Container Apps-Umgebung in die statische IP-Adresse der Container Apps-Umgebung auflöst. Sie können das private Azure-DNS oder Ihren eigenen DNS-Server verwenden. Wenn Sie Azure Private DNS verwenden, erstellen Sie eine private DNS-Zone, die als die Standarddomäne der Container-App (<UNIQUE_IDENTIFIER>.<REGION_NAME>.azurecontainerapps.io) mit einem A-Eintrag bezeichnet wird. Der A-Datensatz enthält den Namen *<DNS Suffix> und die statische IP-Adresse der Container-Apps-Umgebung.

    2. Benutzerdefinierte Domänen: Wenn Sie benutzerdefinierte Domänen verwenden und eine externe Container-Apps-Umgebung verwenden möchten, verwenden Sie eine öffentlich auflösbare Domäne, um der Container-App eine benutzerdefinierte Domäne und ein Zertifikat hinzuzufügen. Bei Verwendung einer internen Container Apps-Umgebung wird die DNS-Bindung nicht validiert, weil der Zugriff auf den Cluster nur innerhalb des virtuellen Netzwerks möglich ist. Erstellen Sie außerdem eine private DNS-Zone, die die apex-Domäne in die statische IP-Adresse der Container Apps-Umgebung auflöst. Sie können das private Azure-DNS oder Ihren eigenen DNS-Server verwenden. Wenn Sie privates Azure-DNS verwenden, erstellen Sie eine private DNS Zone mit demselben Namen wie die apex-Domäne und einen A-Datensatz, der auf die statische IP-Adresse der Container Apps-Umgebung verweist.

Die statische IP-Adresse der Container-Apps-Umgebung ist im Azure-Portal im benutzerdefinierten DNS-Suffix der Container-App-Seite oder mit dem Azure CLI-Befehl az containerapp env list verfügbar.

Verwaltete Ressourcen

Wenn Sie eine interne oder externe Umgebung in Ihrem eigenen Netzwerk bereitstellen, wird im Azure-Abonnement, in dem Ihre Umgebung gehostet wird, eine neue Ressourcengruppe erstellt. Diese Ressourcengruppe enthält Infrastrukturkomponenten, die von der Azure Container Apps-Plattform verwaltet werden. Ändern Sie nicht die Dienste in dieser Gruppe oder die Ressourcengruppe selbst.

Arbeitsauslastungsprofile-Umgebungen

Der Name der Ressourcengruppe, die im Azure-Abonnement erstellt wurde, in dem Ihre Umgebung gehostet wird, ist standardmäßig mit ME_ präfixiert, und der Ressourcengruppenname kann angepasst werden, wenn Sie Ihre Container-App-Umgebung erstellen.

Für externe Umgebungen enthält die Ressourcengruppe eine öffentliche IP-Adresse, die speziell für eingehende Verbindungen mit Ihrer externen Umgebung und einem Lastenausgleich verwendet wird. Für interne Umgebungen enthält die Ressourcengruppe nur einen Lastenausgleich.

Zusätzlich zur standardmäßigen Azure Container Apps-Abrechnung werden Ihnen folgende Abrechnungen in Rechnung gestellt:

  • Eine statische öffentliche Standard-IP für den Ausgang, wenn eine interne oder externe Umgebung verwendet wird, sowie eine statische öffentliche Standard-IP für den Ausgang bei Verwendung einer externen Umgebung. Wenn Sie aufgrund von SNAT-Problemen zusätzliche ausgehende öffentliche IP-Adressen benötigen, erstellen Sie ein Supportticket, um eine Außerkraftsetzung anzufordern.

  • Kein Standard-Load Balancer.

  • Die Kosten der verarbeiteten Daten (in GBs) umfassen sowohl den Eingang als auch den Ausgang für Verwaltungsvorgänge.

Verbrauchsumgebung

Der Name der Ressourcengruppe, die im Azure-Abonnement erstellt wurde, in dem Ihre Umgebung gehostet wird, ist standardmäßig mit MC_ präfixiert, und der Ressourcengruppenname kann nicht angepasst werden, wenn Sie eine Container-App erstellen. Die Ressourcengruppe enthält öffentliche IP-Adressen, die speziell für ausgehende Verbindungen aus Ihrer Umgebung sowie einen Lastenausgleich verwendet werden.

Zusätzlich zur standardmäßigen Azure Container Apps-Abrechnung werden Ihnen folgende Abrechnungen in Rechnung gestellt:

  • Eine statische öffentliche Standard-IP für den Ausgang. Wenn Sie aufgrund von Problemen mit der Quellnetzwerkadressübersetzung (Source Network Address Translation, SNAT) zusätzliche ausgehende IPs benötigen, öffnen Sie ein Supportticket, um eine Außerkraftsetzung anzufordern.

  • Zwei standardmäßige Load Balancers, wenn eine interne Umgebung verwendet wird, oder ein standardmäßiger Load Balancer, wenn eine externe Umgebung verwendet wird. Jeder Lastenausgleich hat weniger als sechs Regeln. Die Kosten der verarbeiteten Daten (in GBs) umfassen sowohl den Eingang als auch den Ausgang für Verwaltungsvorgänge.

Nächste Schritte