Allgemeine Architekturüberlegungen für die Auswahl eines Azure-Containerdiensts

  • Artikel

Dieser Artikel führt Sie durch den Prozess der Auswahl eines Azure-Containerdiensts. Er bietet eine Übersicht über Überlegungen auf Feature-Ebene, die für einige Workloads häufig und kritisch sind. Es kann Ihnen helfen, Entscheidungen zu treffen, um sicherzustellen, dass Ihre Workload die Anforderungen für Zuverlässigkeit, Sicherheit, Kostenoptimierung, erstklassige Betriebsprozesse und Leistungseffizienz erfüllt.

Hinweis

Dieser Artikel ist Teil 2 einer Reihe, die mit der Auswahl eines Azure-Containerdiensts beginnt. Es wird dringend empfohlen, diesen Übersichtsartikel zuerst zu lesen, um einen Kontext für diese architektonischen Überlegungen zu erhalten.

Übersicht

Die Überlegungen in diesem Artikel sind in vier Kategorien unterteilt:

Überlegungen zu Architektur und Netzwerk

  • Betriebssystemunterstützung
  • Adressräume des lokalen Netzwerks
  • Verständnis des Verkehrsflusses
  • Planen von Subnetzen
  • Anzahl der verfügbaren Eingangs-IPs
  • Benutzerdefinierte Routen und NAT-Gateway-Unterstützung
  • Integration privater Netzwerke
  • Protokollabdeckung
  • Lastenausgleich
  • Dienstermittlung
  • Benutzerdefinierte Domänen und verwaltete TLS
  • Gegenseitiges TLS
  • Netzwerkkonzepte für bestimmte Azure-Dienste

Sicherheitshinweise

  • Bereitstellen von Sicherheit für den datenverkehrsinternen Cluster mithilfe von Netzwerkrichtlinien
  • Netzwerksicherheitsgruppen
  • Azure Key Vault-Integration
  • Unterstützung verwalteter Identitäten
  • Bedrohungsschutz und Sicherheitsrisikobewertungen mit Defender für Container
  • Sicherheitsbaselines
  • Azure Well-Architected Frameworkfür Sicherheit

Überlegungen zur Verwendung

  • Updates und Patches
  • Aktualisierungen von Containerabbildungen
  • Skalierbarkeit der vertikalen Infrastruktur
  • Horizontale Skalierbarkeit der Infrastruktur
  • Skalierbarkeit der Anwendung
  • Einblick
  • Gut durchdachter Rahmen für erstklassige Betriebsprozesse

Überlegungen zur Verlässlichkeit

  • Vereinbarungen zum Service Level
  • Redundanz über Verfügbarkeitszonen
  • Integritätsprüfungen und Selbstreparatur
  • Anwendungsbereitstellung ohne Ausfallzeiten
  • Ressourceneinschränkungen
  • Gut durchdachter Rahmen für Zuverlässigkeit

Beachten Sie, dass sich dieser Artikel auf eine Teilmenge von Azure-Containerdiensten konzentriert, die einen ausgereiften Featuresatz für Webanwendungen und APIs, Netzwerk, Beobachtbarkeit, Entwicklertools und -vorgänge bieten: Azure Kubernetes Service (AKS), Azure Container Apps und Web App für Container. Eine vollständige Liste aller Azure-Containerdienste finden Sie auf der Produktkategorieseite für Containerdienste.

Hinweis

In diesem Leitfaden bezieht sich der Begriff Workload auf eine Sammlung von Anwendungsressourcen, die ein Geschäftsziel oder die Ausführung eines Geschäftsprozesses unterstützen. Eine Workload verwendet mehrere Komponenten wie APIs und Datenspeicher, die zusammenarbeiten, um bestimmte End-to-End-Funktionen bereitzustellen.

Architekturaspekte

In diesem Abschnitt werden Architekturentscheidungen beschrieben, die nur schwer rückgängig gemacht oder korrigiert werden können, ohne dass erhebliche Ausfallzeiten oder eine erneute Bereitstellung erforderlich sind. Es ist besonders notwendig, diese Überlegungen für grundlegende Komponenten wie Netzwerk und Sicherheit zu berücksichtigen.

Diese Überlegungen gelten nicht speziell für die Säulen des Well-Architected Framework. Sie verdienen jedoch eine zusätzliche Prüfung und Bewertung gegenüber den Anforderungen von Unternehmen, wenn Sie einen Azure-Containerdienst auswählen.

Betriebssystemunterstützung

Die meisten containerisierten Anwendungen werden in Linux-Containern ausgeführt, die von allen Azure-Containerdiensten unterstützt werden. Ihre Optionen sind für Workload-Komponenten eingeschränkter, für die Windows-Container erforderlich sind.

Container-Apps AKS Web App für Containers
Linux-Unterstützung ✅ ✅ ✅
Windows-Unterstützung ❌ ✅ ✅
Gemischte Betriebssystemunterstützung ❌ ✅ ❌*

*Gemischte Betriebssystemunterstützung für Web-App für Container erfordert separate Azure App Service-Pläne für Windows und Linux.

Überlegungen zum Netzwerkbetrieb

Es ist wichtig, das Netzwerkdesign frühzeitig in Ihren Planungsprozessen aufgrund von Sicherheits- und Compliance-Einschränkungen und auferlegten Richtlinien zu verstehen. Im Allgemeinen hängen die Hauptunterschiede zwischen den in diesem Leitfaden behandelten Azure-Diensten von den Präferenzen ab:

  • Container-Apps ist ein PaaS-Angebot, das viele von Azure verwaltete Netztechnologie-Features bereitstellt, z. B. Dienstermittlung und interne verwaltete Domänen. Workload-Teams, die eine etwas höhere Konfigurierbarkeit benötigen, können Workload-/dedizierte Profile nutzen, bevor sie Alternativen zur Maximierung ihrer Netztechnologieoptionen in Betracht ziehen.
  • AKS ist die konfigurierbarste der drei Dienste und bietet die meiste Kontrolle über den Netzwerkfluss. Sie stellt z. B. benutzerdefinierte Eingangsdatencontroller und die Steuerung des Datenverkehrs zwischen Clustern über Kubernetes-Netzwerkrichtlinien bereit. Workload-Teams können die Vorteile verschiedener von Azure verwalteter Netzwerk-Add-ons nutzen sowie beliebige Add-ons aus dem breiteren Kubernetes-Ökosystem installieren und betreiben.
  • Web-App für Container ist eine Funktion von App Service. Daher sind die Netzwerkkonzepte, insbesondere die Integration privater Netzwerke, sehr spezifisch für App Service. Dieser Dienst ist -Workload-Teams vertraut, die bereits App Service verwenden. Teams, die keine Erfahrung mit App Service haben und eine vertrautere Azure Virtual Network-Integration wünschen, sollten Container Apps in Betracht ziehen.

Denken Sie daran, dass das Netzwerk eine grundlegende Infrastrukturebene ist. Häufig ist es schwierig, Änderungen am Entwurf vorzunehmen, ohne die Workload erneut bereitzustellen, was zu Ausfallzeiten führen kann. Wenn Ihre Workload daher bestimmte Netztechnologieanforderungen aufweist, lesen Sie diesen Abschnitt sorgfältig, bevor Sie Ihre Azure Container Service-Auswahl einschränken.

Adressräume des lokalen Netzwerks

Wenn Sie Anwendungen in virtuelle Netzwerke integrieren, müssen Sie eine IP-Adressplanung durchführen, um sicherzustellen, dass genügend IP-Adressen für Containerinstanzen verfügbar sind. Planen Sie während dieses Prozesses zusätzliche Adressen für Updates, blaue/grüne Bereitstellungen und ähnliche Situationen, in denen zusätzliche Instanzen bereitgestellt werden, die zusätzliche IP-Adressen nutzen.

Container-Apps AKS Web App für Containers
Dediziertes Subnetz Verbrauchsplan: optional
Dedizierter Plan: erforderlich		 Erforderlich Optional
Anforderungen an die IP-Adresse Verbrauchsplan: Siehe Nur-Verbrauch-Umgebung.
Dedizierter Plan: Anzeigen der Umgebung für Workload-Profile.		 Siehe virtuelle Azure-Netzwerke für AKS. Siehe App Service-Subnetzanforderungen.

Beachten Sie, dass die AKS-Anforderungen vom ausgewählten Netzwerk-Plug-In abhängen. Einige Netzwerk-Plug-Ins für AKS erfordern umfassendere IP-Reservierungen. Details sind nicht Gegenstand dieses Artikels. Weitere Informationen finden Sie in den Netzwerkkonzepten für AKS.

Verständnis des Verkehrsflusses

Die für eine Lösung erforderlichen Arten des Datenverkehrsflusses können sich auf das Netzwerkdesign auswirken.

Die folgenden Abschnitte enthalten Informationen zu verschiedenen Netztechnologie-Constraints. Diese Einschränkungen wirken sich auf ihre Notwendigkeit aus, zusätzliche Subnetze bereitzustellen, je nachdem, was Sie benötigen:

  • Mehrere eingerichtete Workloads.
  • Privater und/oder öffentlicher Eingang.
  • Ein zugriffsgesteuerter Fluss des Ost-West-Datenverkehrs in einem Cluster (für Container-Apps und AKS) oder innerhalb eines virtuellen Netzwerks (für alle Azure-Containerdienste).

Subnetzplanung

Stellen Sie sicher, dass Sie über ein Subnetz verfügen, das groß genug ist, um Instanzen Ihrer Anwendung einzuschließen, den Ihr Workload ist nicht der einzige Faktor, der den Netzwerkspeicherbedarf bestimmt, in dem diese Anwendungen bereitgestellt werden.

Container-Apps AKS Web App für Containers
Unterstützung für eingerichtete Workloads in einem Subnetz* ❌* ✅ Nicht zutreffend*

*Dies beschreibt eine bewährte Methode, keine technische Einschränkung.

Bei Container Apps gilt Subnetzintegration nur für eine einzelne Container Apps-Umgebung. Jede Container Apps-Umgebung ist auf eine einzelne Eingehende IP, öffentliche oder private Umgebung beschränkt.

Jede Container Apps-Umgebung ist nur für eine einzelne Workload gedacht, in der abhängige Anwendungen eingerichtet werden. Daher müssen Sie zusätzliche Azure-Netzwerk-Anwendung für den Eingangslastenausgleich einführen, wenn Sie sowohl einen öffentlichen als auch einen privaten Eingang benötigen. Beispiele umfassen Azure Application Gateway und Azure Front Door. Wenn Sie über mehrere Workloads verfügen, die getrennt werden müssen, sind zusätzliche Container Apps-Umgebungen erforderlich, sodass für jede Umgebung ein zusätzliches Subnetz zugewiesen werden muss.

AKS bietet eine präzise Ost-West-Netzwerkflusssteuerung innerhalb des Clusters in Form von Kubernetes-Netzwerkrichtlinien. Mit dieser Flusssteuerung können Sie mehrere Workloads mit unterschiedlichen Netzwerksicherheitsgrenzen innerhalb desselben Clusters segmentieren.

Für Web-App für Container gibt es keine Einschränkungen für die Anzahl der Apps, die Sie in ein einzelnes Subnetz integrieren können, solange das Subnetz groß genug ist. Es gibt keine bewährten Methoden für die Zugriffssteuerung zwischen Web-Apps im selben virtuellen Netzwerk. Jede Web-App verwaltet unabhängig die Zugriffssteuerung für Ost-West- oder Nord-Süd-Datenverkehr aus dem virtuellen Netzwerk bzw. Internet.

Hinweis

Sie können die Größe von Subnetzen, für die Ressourcen bereitgestellt wurden, nicht ändern. Gehen Sie bei der Planung Ihres Netzwerks besonders sorgfältig vor, um zu vermeiden, dass Sie ganze Workload-Komponenten neu verteilen müssen, was zu Downtime führen kann.

Anzahl der verfügbaren Eingangs-IPs

In der folgenden Tabelle wird der vorherige Abschnitt zur Subnetzplanung berücksichtigt, um zu definieren, wie viele IPs für eine beliebige Anzahl von Anwendungen verfügbar gemacht werden können, die in einer einzigen Bereitstellung eines Azure Container Service gehostet werden.

Container-Apps AKS Web App für Containers
Anzahl der Eingangs-IPs Eine Mehrere App Service-Umgebung: Eins
Keine App Service-Umgebung: Viele

Container Apps ermöglichen eine IP pro Umgebung, öffentlich oder privat. AKS ermöglicht eine beliebige Anzahl von IPs, öffentlich oder privat. Web-App für Container, außerhalb einer App Service-Umgebung, ermöglicht eine öffentliche IP für alle Apps innerhalb eines App Service-Plans und mehrere, verschiedene private IPs, die private Azure-Endpunkte verwenden.

Es ist wichtig zu beachten, dass Web-Apps, die in eine App Service-Umgebung integriert sind, nur Datenverkehr über die einzelne Eingangs-IP empfangen, die der App Service-Umgebung zugeordnet ist, unabhängig davon, ob sie öffentlich oder privat ist.

Benutzerdefinierte Routen und NAT-Gateway-Unterstützung

Wenn eine Workload benutzerdefinierte Routen (UDRs) und NAT-Gateway-Funktionen für die granulare Netzwerksteuerung erfordert, erfordert Container Apps die Verwendung von Workload-Profilen. Die UDR- und NAT-Gateway-Kompatibilität ist im nutzungsbasierten Plan für ACA nicht verfügbar.

AKS und Web-App für Container implementieren diese beiden Netzwerk-Features über standardmäßige virtuelle Netzwerkfunktionen bzw. die Integration virtueller Netzwerke. Zur Ausarbeitung sind AKS-Knotenpools und Web-App für Container in einer App Service-Umgebung bereits direkte virtuelle Netzwerkressourcen. Web-App für Container, die sich nicht in einer App Service-Umgebung befinden, unterstützen UDRs und NAT-Gateway über die Integration des virtuellen Netzwerks. Bei der Integration des virtuellen Netzwerks befindet sich die Ressource technisch nicht direkt im virtuellen Netzwerk, aber alle ausgehenden Zugriffe fließen über das virtuelle Netzwerk, und die zugehörigen Regeln des Netzwerks wirken sich auf den erwarteten Datenverkehr aus.

Container-Apps AKS Web App für Containers
UDR-Unterstützung Nutzungsbasierter Plan: ❌
Workload-Profil-Plan: ✅		 ✅ ✅
NAT Gateway-Unterstützung Nutzungsbasierter Plan: ❌
Workload-Profil-Plan: ✅		 ✅ ✅

Integration privater Netzwerke

Für Workloads, die strenge private Ebene 4-Netztechnologie sowohl für den Eingang als auch für Egress erfordern, sollten Sie Container Apps, AKS und die Einzel-Mandanten-App Service-Umgebung SKU in Betracht ziehen, in denen Workloads in einem selbstverwalteten virtuellen Netzwerk bereitgestellt werden und die üblichen granularen privaten Netzwerksteuerelemente bereitstellen.

Container-Apps AKS Web App für Containers
Privater Eingang in ein virtuelles Netzwerk ✅ ✅ Über einen privaten Endpunkt
Privater Egress aus einem virtuellen Netzwerk ✅ ✅ Über Integration eines virtuellen Netzwerks
Vollständig unterdrückter öffentlicher Endpunkt ✅ ✅ Nur App Service-Umgebung
Private Netzwerke mit Web-App für Container

Web-App für Container bietet zusätzliche Netzwerk-Features, die von den anderen in diesem Artikel beschriebenen Azure-Diensten nicht auf die gleiche Weise angezeigt werden. Um strenge Anforderungen an private Netzwerke zu implementieren, müssen sich Workload-Teams mit diesen Netztechnologiekonzepten vertraut machen. Überprüfen Sie diese Netztechnologie-Features sorgfältig:

Wenn Sie eine PaaS-Lösung wünschen und Netztechnologiekonzepte bevorzugen, die für mehrere Azure-Lösungen freigegeben werden, sollten Sie Container Apps in Betracht ziehen.

Protokollabdeckung

Eine wichtige Überlegung für die Hosting-Plattform sind Netztechnologieprotokolle, die für eingehende Anwendungsanforderungen (Eingang) unterstützt werden. Web-App für Container ist die strengste Option, die nur HTTP und HTTPS unterstützt. Container Apps ermöglichen zusätzlich eingehende TCP-Verbindungen. AKS ist die flexibelste Option, die uneingeschränkte Verwendung von TCP und UDP auf selbst ausgewählten Ports unterstützt.

Container-Apps AKS Web App für Containers
Protokoll- und Portunterstützung HTTP (Port 80)*
HTTPS (Port 443)*
TCP (Ports 1-65535, außer 80 und 443)		 TCP (Jeder Port)
UDP (Jeder Port)		 HTTP (Port 80)
HTTPS (Port 443)
WebSocket-Unterstützung ✅ ✅ ✅
HTTP/2-Unterstützung ✅ ✅ ✅

*In der Container Apps-Umgebung kann HTTP/S für jeden Port für die Kommunikation innerhalb des Clusters verfügbar gemacht werden. In diesem Szenario gelten integrierte HTTP-Features von Container Apps wie CORS und Sitzungsaffinität nicht.

Sowohl Container Apps als auch Web-App für Container unterstützen TLS 1.2 für den integrierten HTTPS-Eingang.

Lastenausgleich

Mit Container-Apps und Web-App für Container abstrahiert Azure vollständig den Layer 4- und Layer 7-Lastenausgleich.

Im Gegensatz dazu verwendet AKS ein Modell der geteilten Verantwortung, bei dem Azure die zugrunde liegende Azure-Infrastruktur verwaltet, die das Workload-Team über eine Schnittstelle mit der Kubernetes-API konfiguriert. Sie können für den Layer 7-Lastenausgleich in AKS eine Azure-verwaltete Option auswählen, wie z. B. das Add-On für AKS-verwaltetes Anwendungsrouting oder das Application Gateway für Container. Sie können aber auch einen Eingangsdatencontroller Ihrer Wahl bereitstellen und selbst verwalten.

Container-Apps AKS Web App für Containers
Ebene 4-Load Balancer In Azure verwaltet Gemeinsame Verantwortung In Azure verwaltet
Ebene 7-Load Balancer In Azure verwaltet Freigegeben oder selbstverwaltet In Azure verwaltet

Dienstermittlung

In Cloud-Architekturen können Runtimes jederzeit entfernt und neu erstellt werden, um Ressourcen neu auszugleichen, sodass sich IP-Adressen von Instanzen regelmäßig ändern. Diese Architekturen verwenden vollqualifizierte Domänennamen (FQDNs) für eine zuverlässige und konsistente Kommunikation.

Container-Apps AKS Web App für Containers
Dienstermittlung Azure-verwaltete FQDN Kubernetes–konfigurierbar Azure-verwaltete FQDN

Web-Apps für Container stellt öffentliche Eingangs-FQDNs (Nord-Süd-Kommunikation) vorkonfiguriert bereit. Es ist keine zusätzliche DNS-Konfiguration erforderlich. Es gibt jedoch keinen integrierten Mechanismus zum Vereinfachen oder Einschränken des Datenverkehrs zwischen anderen Apps (Ost-West-Kommunikation).

Container Apps bieten auch öffentliche Eingangs-FQDNs. Container Apps gehen jedoch weiter, indem das App-FQDN verfügbar gemacht und Datenverkehr nur innerhalb der Umgebung eingeschränkt werden kann. Diese Funktionalität erleichtert die Verwaltung der Ost-West-Kommunikation und ermöglicht Komponenten wie Dapr.

Kubernetes-Bereitstellungen sind anfänglich nicht innerhalb oder außerhalb des Clusters auffindbar. Sie müssen Kubernetes-Dienste gemäß der Definition der Kubernetes-API erstellen, die dann Anwendungen auf adressierbare Weise dem Netzwerk zugänglich machen.

Wichtig

Nur Container Apps und AKS stellen die Dienstermittlung über interne DNS-Schemas in ihren jeweiligen Umgebungen bereit. Diese Funktionalität kann DNS-Konfigurationen in Entwicklungs-/Test- und Produktionsumgebungen vereinfachen. Sie können z. B. diese Umgebungen mit beliebigen Dienstnamen erstellen, die nur innerhalb der Umgebung oder im Cluster eindeutig sein müssen, sodass sie in Entwicklungs-/Test- und Produktionsumgebungen identisch sein können. Mit Web-App für Container müssen Dienstnamen in verschiedenen Umgebungen eindeutig sein, um Konflikte mit Azure DNS zu vermeiden.

Benutzerdefinierte Domänen und verwaltete TLS

Sowohl Container Apps als auch Web-App für Container bieten sofort einsatzbereite Lösungen für benutzerdefinierte Domänen und Zertifikatverwaltung.

Container-Apps AKS Web App für Containers
Konfigurieren benutzerdefinierter Domänen Vorgefertigt BYO Vorgefertigt
Verwaltetes TLS für Azure-FQDNs Vorgefertigt N/V Vorgefertigt
Verwaltetes TLS für benutzerdefinierte Domänen In der Vorschauphase BYO Vorkonfiguriert oder selbsterstellt

AKS-Benutzer sind für die Verwaltung von DNS, Clusterkonfigurationen und TLS-Zertifikaten für ihre benutzerdefinierten Domänen verantwortlich. Obwohl AKS kein verwaltetes TLS anbietet, können Kunden Software aus dem Kubernetes-Ökosystem nutzen, zum Beispiel den beliebten cert-manager zur Verwaltung von TLS-Zertifikaten.

Gegenseitiges TLS

Eine weitere Alternative zum Einschränken des eingehenden Datenverkehrs ist gegenseitiges TLS (mTLS). Gegenseitiges TLS ist ein Sicherheitsprotokoll, das sicherstellt, dass sowohl der Client als auch der Server in der Kommunikation authentifiziert werden. Um die Authentifizierung zu erreichen, tauschen beide Parteien Zertifikate aus und überprüfen sie, bevor Daten übertragen werden.

Web-App für Container verfügt über integrierte mTLS-Unterstützung für eingehende Client-Verbindungen. Die Anwendung muss das Zertifikat jedoch überprüfen, indem auf den X-ARR-ClientCert-HTTP-Header zugegriffen wird, den die App Service-Plattform weiterleitet.

Container Apps verfügen auch über integrierte Unterstützung für mTLS. Es leitet das Clientzertifikat an die Anwendung im HTTP-Header X-Forwarded-Client-Cert weiter. Sie können auch einfach automatische mTLS für die interne Kommunikation zwischen Apps in einer einzigen Umgebung aktivieren.

Mutual TLS in AKS kann über das Istio-basierte Service Mesh als verwaltetes Add-on implementiert werden, das mTLS-Fähigkeiten für eingehende Client-Verbindungen und die Kommunikation innerhalb des Clusters zwischen den Diensten beinhaltet. Workload-Teams könnten auch ein anderes Dienstnetz-Angebot aus dem Kubernetes-Ökosystem installieren und verwalten. Dank dieser Optionen stellt die mTLS-Implementierung in Kubernetes die flexibelste Option dar.

Dienstspezifische Netztechnologiekonzepte

In den vorherigen Abschnitten werden einige der häufigsten Überlegungen beschrieben, die berücksichtigt werden müssen. Weitere Details und weitere Informationen zu Netztechnologie-Features, die für einzelne Azure-Containerdienste spezifisch sind, finden Sie in den folgenden Artikeln:

Die vorherigen Abschnitte konzentrieren sich auf das Netzwerkdesign. Fahren Sie mit dem nächsten Abschnitt fort, um mehr über die Netztechnologiesicherheit und das Sichern von Netzwerkdatenverkehr zu erfahren.

Sicherheitshinweise

Fehler bei der Behebung von Sicherheitsrisiken können zu unbefugtem Zugriff, Datenpannen oder Verlusten vertraulicher Informationen führen. Container bieten eine gekapselte Umgebung für Ihre Anwendung. Die Hosting-Systeme und die zugrunde liegenden Netzwerküberlagerungen erfordern jedoch zusätzlichen Schutz. Ihre Wahl des Azure Container Services muss Ihre spezifischen Anforderungen für die Sicherung jeder Anwendung einzeln unterstützen und geeignete Sicherheitsmaßnahmen bereitstellen, um unbefugten Zugriff zu verhindern und das Risiko von Angriffen zu verringern.

Übersicht über den Sicherheitsvergleich

Die meisten Azure-Dienste, einschließlich Container Apps, AKS und Web-App für Container, sind in wichtige Sicherheitsangebote integriert, einschließlich Key Vault und verwalteter Identitäten.

Von den in diesem Leitfaden vorgestellten Diensten bietet AKS die beste Konfigurierbarkeit und Erweiterbarkeit, da die zugrundeliegenden Komponenten oft über Konfigurationsoptionen gesichert werden können. So können Kunden beispielsweise lokale Konten für den Kubernetes-API-Server deaktivieren oder automatische Updates für die zugrunde liegenden Knoten über Konfigurationsoptionen aktivieren.

Überprüfen Sie für einen detaillierten Vergleich sorgfältig die folgenden Überlegungen, um sicherzustellen, dass Ihre Workload-Sicherheitsanforderungen erfüllt werden können.

Kubernetes-Steuerungsebenensicherheit

AKS bietet die größte Flexibilität der drei Optionen, die in diesem Artikel berücksichtigt werden, und bietet Vollzugriff auf die Kubernetes-API, sodass Sie die Container-Orchestrierung anpassen können. Dieser Zugriff auf die Kubernetes-API stellt jedoch auch eine erhebliche Angriffsfläche dar, die Sie schützen müssen.

Wichtig

Beachten Sie, dass dieser Abschnitt für Web-App für Container nicht relevant ist, das die Azure Resource Manager-API als Steuerungsebene verwendet.

Identitätsbasierte Sicherheit

Kunden sind für die Sicherung des identitätsbasierten Zugriffs auf die API verantwortlich. Standardmäßig bietet Kubernetes ein eigenes Authentifizierungs- und Autorisierungsmanagementsystem, das auch mit Zugriffssteuerungen gesichert werden muss.

Um eine einzelne Glasebene für die Identitäts- und Zugriffsverwaltung in Azure zu nutzen, empfiehlt es sich, Kubernetes-spezifische lokale Konten zu deaktivieren und stattdessen die AKS-verwaltete Microsoft Entra-Integration zusammen mit Azure RBAC für Kubernetes zu implementieren. Wenn Sie diese bewährte Methode implementieren, müssen Administratoren keine Identitäts- und Zugriffsverwaltung auf mehreren Plattformen durchführen.

Container-Apps AKS
Kubernetes-API-Zugriffssteuerungen Kein Zugriff Vollzugriff

Kunden, die Container Apps verwenden, haben keinen Zugriff auf die Kubernetes-API. Microsoft bietet Sicherheit für diese API.

Netzwerkbasierte Sicherheit

Wenn Sie den Netzwerkzugriff auf die Kubernetes-Steuerungsebene einschränken möchten, müssen Sie AKS verwenden, was zwei Optionen bietet. Die erste Option besteht darin, private AKS-Cluster zu verwenden, die Azure Private Link zwischen dem privaten Netzwerk des API-Servers und dem privaten Netzwerk des AKS-Clusters verwenden. Die zweite Option ist die API-Server-VNet-Integration (Vorschau), bei der der API-Server in ein delegiertes Subnetz integriert ist. Weitere Informationen finden Sie in der Dokumentation.

Es gibt Folgen für die Implementierung des netzwerkeingeschränkten Zugriffs auf die Kubernetes-API. So kann insbesondere die Verwaltung nur innerhalb des privaten Netzwerks durchgeführt werden. In der Regel bedeutet dies, dass Sie selbstgehostete Agents für Azure DevOps oder GitHub-Aktionen bereitstellen müssen. Weitere Informationen zu anderen Einschränkungen finden Sie in der produktspezifischen Dokumentation.

Container-Apps AKS
Kubernetes-API-Netzwerksicherheit In PaaS nicht konfigurierbar Konfigurierbar: öffentliche IP oder private IP

Diese Überlegungen gelten nicht für Container Apps. Da es sich um PaaS handelt, entfernt Microsoft die zugrunde liegende Infrastruktur.

Sicherheit des Datenebenennetzwerks

Die folgenden Netztechnologie-Features können verwendet werden, um den Zugriff auf, von und innerhalb einer Workload zu steuern.

Verwenden von Netzwerkrichtlinien zur Bereitstellung der Sicherheit für den Datenverkehr zwischen Clustern

Einige Sicherheitsstatus erfordern eine Netzwerkdatenverkehrstrennung innerhalb einer Umgebung, z. B. wenn Sie mehrinstanzenfähige Umgebungen verwenden, um mehrere oder mehrstufige Anwendungen zu hosten. In diesen Szenarien sollten Sie AKS auswählen und Netzwerkrichtlinien implementieren, eine cloudnative Technologie, die eine granulare Konfiguration von Ebene 4-Netztechnologien in Kubernetes-Clustern ermöglicht.

Container-Apps AKS Web App für Containers
Netzwerkrichtlinien Verbrauchsplan: ❌
Dedizierter Plan: ❌		 ✅ ❌

Von den drei in diesem Artikel beschriebenen Azure-Diensten ist AKS die einzige, die eine weitere Workload-Isolation innerhalb des Clusters unterstützt. Netzwerkrichtlinien werden in Container Apps oder Web-App für Container nicht unterstützt.

Netzwerksicherheitsgruppen

In allen Szenarien können Sie die Netztechnologiekommunikation innerhalb des breiteren virtuellen Netzwerks mithilfe von Netzwerksicherheitsgruppen regeln, sodass Sie Ebene 4-Datenverkehrsregeln verwenden können, die den Eingang und Egress auf der Ebene des virtuellen Netzwerks regeln.

Container-Apps AKS Web App für Containers
Netzwerksicherheitsgruppen Verbrauchsplan: ✅
Dedizierter Plan: ✅		 ✅ ✅ VNet-integrierte Apps: nur Egress

IP-Beschränkungen für den Zutritt

Normalerweise werden Beschränkungen des Netzverkehrs über die oben beschriebenen Schicht-4-Regeln angewendet. In PaaS-Szenarien von Anwendungen ohne virtuelle Netzwerkintegration kann es jedoch sinnvoll sein, den Datenverkehr auf der Anwendungsschicht zu beschränken.

Container-Apps und Web-App für Container bieten für einzelne Anwendungen integrierte IP-Einschränkungen für eingehenden Datenverkehr.

Container-Apps AKS Web App für Containers
IP-Eingangsbeschränkungen auf der Anwendungsebene Vorgefertigt Selbstverwaltet oder über ein verwaltetes Add-on Vorgefertigt
Ressourcenverbrauch - Verbraucht Cluster-Ressourcen -

Bei AKS-Workloads hängt die Implementierung von dem gewählten Ingress-Controller ab. Sowohl das selbstverwaltete als auch das von Azure verwaltete Add-on zum Anwendungsrouting verbrauchen Cluster-Ressourcen.

Sicherheit auf Anwendungsebene

Sie müssen Workloads nicht nur auf Netzwerk- und Infrastrukturebene, sondern auch auf Workload- und Anwendungsebene sichern. Azure-Containerlösungen werden in Azure-Sicherheitsangebote integriert, um die Sicherheitsimplementierung und -kontrollen für Ihre Anwendungen zu standardisieren.

Key Vault-Integration

Es empfiehlt sich, geheime Schlüssel, Schlüssel und Zertifikate in einer Schlüsselverwaltungslösung wie Key Vault zu speichern und zu verwalten, die erhöhte Sicherheit für diese Komponenten bietet. Anstatt geheime Schlüssel im Code oder in einem Azure-Compute Service zu speichern und zu konfigurieren, sollten alle Anwendungen in Key Vault integriert werden.

Die Key Vault-Integration ermöglicht Anwendungsentwicklern, sich auf ihren Anwendungscode zu konzentrieren. Alle drei in diesem Artikel beschriebenen Azure-Containerdienste können geheime Schlüssel automatisch vom Key Vault-Dienst synchronisieren und der Anwendung bereitstellen, in der Regel als Umgebungsvariablen oder bereitgestellte Dateien.

Container-Apps AKS Web App für Containers
Key Vault-Integration ✅ ✅ ✅

Weitere Informationen finden Sie unter:

Unterstützung verwalteter Identitäten

Anwendungen mit zugewiesenen verwalteten Identitäten können ohne Passwörter auf Azure-Ressourcen zugreifen. Alle in diesem Leitfaden erwähnten Containerdienste unterstützen verwaltete Identitäten.

Container-Apps AKS Web App für Containers
Unterstützung verwalteter Identitäten ✅ ✅ ✅

Weitere Informationen finden Sie unter:

Bedrohungsschutz und Sicherheitsrisikobewertungen mit Defender für Container

Der Bedrohungsschutz vor Sicherheitsrisiken ist ebenfalls wichtig. Es empfiehlt sich, Defender for Containers zu verwenden. Verwundbarkeitsbewertungen werden in Azure Container Registries unterstützt, sodass sie von jedem Azure Container Service verwendet werden können, nicht nur von denen in diesem Artikel beschriebenen. Defender für Container-Runtime-Schutz ist jedoch nur für AKS verfügbar.

Da AKS die native Kubernetes-API offenlegt, kann die Clustersicherheit auch mit Kubernetes-spezifischen Sicherheitswerkzeugen aus dem Kubernetes-Ökosystem bewertet werden.

Container-Apps AKS Web App für Containers
Runtime-Bedrohungsschutz ❌ ✅ ❌

Weitere Informationen finden Sie in der Unterstützungsmatrix für Containerfunktionen in Defender for Cloud.

Beachten Sie, dass Verwundbarkeitsbewertungen für Containerimages keine Echtzeitüberprüfungen sind. Das Azure Container Registry wird in regelmäßigen Abständen gescannt.

Sicherheitsbaselines

Im Allgemeinen integrieren die meisten Azure Container Services Azure-Sicherheitsangebote. Denken Sie insgesamt daran, dass ein Sicherheitsfeaturesatz nur ein kleiner Teil der Implementierung von Cloudsicherheit ist. Weitere Informationen zur Implementierung von Sicherheit für Containerdienste finden Sie in den folgenden dienstspezifischen Sicherheitsbaselines:

Die Sicherheitsbaselines decken andere Azure-Integrationen ab, einschließlich Hardware-Verschlüsselung und Protokollierung, die in diesem Artikel nicht behandelt werden.

Well-Architected Framework für Sicherheit

Dieser Artikel konzentriert sich auf die Hauptunterschiede zwischen den hier beschriebenen Funktionen der Containerdienste.

Ausführlichere Sicherheitsleitfaden zu AKS finden Sie unter Well-Architected Framework-Bewertung - AKS.

Überlegungen zur Verwendung

Um eine Workload in der Produktion erfolgreich auszuführen, müssen Teams erstklassige Betriebsprozesse implementieren, einschließlich zentralisierter Protokollierung, Überwachung, Skalierbarkeit, regelmäßiger Updates und Patching sowie Imageverwaltung.

Updates und Patches

Es ist wichtig, dass das einer Anwendung zugrunde liegende Betriebssystem aktualisiert und regelmäßig gepatcht wird. Bedenken Sie jedoch, dass bei jedem Update ein Fehlerrisiko besteht. In diesem Abschnitt und im nächsten werden die Standardüberlegungen für die drei Containerdienste in Bezug auf die gemeinsame Zuständigkeit zwischen dem Kunden und der Plattform beschrieben.

Als verwalteter Kubernetes-Dienst stellt AKS die aktualisierten Images für das Knotenbetriebssystem und für die Steuerungsebenenkomponenten bereit. Die Workload-Teams sind jedoch für die Anwendung von Updates auf ihre Cluster verantwortlich. Sie können Updates manuell auslösen oder die Funktion cluster auto-upgrade channels nutzen, um sicherzustellen, dass Ihre Cluster auf dem neuesten Stand sind. Weitere Informationen zum Patchen und Aktualisieren von AKS-Clustern finden Sie im AKS Day-2-Betriebshandbuch.

Container Apps und Web-App für Container sind PaaS-Lösungen. Azure ist für die Verwaltung von Updates und Patches verantwortlich, sodass Kunden die Komplexität der AKS-Upgrade-Verwaltung vermeiden können.

Container-Apps AKS Web App für Containers
Steuerungsebene der Aktualisierungen Plattform Kunde Plattform
Hosten Sie Updates und Patches Plattform Kunde Plattform
Containerimage-Updates und -Patches Debitor Kunde Debitor

Aktualisierungen von Containerabbildungen

Unabhängig von der Azure-Containerlösung sind Kunden immer für ihre eigenen Containerimages verantwortlich. Wenn Sicherheitspatches für Containerbasisimages vorhanden sind, liegt es in Ihrer Verantwortung, Ihre Images neu zu erstellen. Um Warnungen zu diesen Sicherheitsrisiken zu erhalten, verwenden Sie Defender for Containers für Container, die in der Containerregistrierung gehostet werden.

Skalierbarkeit

Die Skalierung wird verwendet, um die Ressourcenkapazität an Anforderungen anzupassen und mehr Kapazität hinzuzufügen, um die Leistung sicherzustellen und nicht verwendete Kapazität zur Kosteneinsparung zu entfernen. Wenn Sie eine Containerlösung auswählen, müssen Sie Infrastruktur-Constraints und Skalierungsstrategien berücksichtigen.

Skalierbarkeit der vertikalen Infrastruktur

Die vertikale Skalierung bezieht sich auf die Fähigkeit, die vorhandene Infrastruktur zu erhöhen oder zu verringern, d. h. CPU und Arbeitsspeicher zu berechnen. Für unterschiedliche Workloads sind unterschiedliche Compute-Ressourcen erforderlich. Wenn Sie eine Azure-Containerlösung auswählen, müssen Sie sich über Hardware-SKU-Angebote informieren, die für einen bestimmten Azure-Dienst verfügbar sind. Sie variieren und können zusätzliche Einschränkungen bedeuten.

Lesen Sie für AKS die Größen für virtuelle Computer in der Azure-Dokumentation und die AKS-Einschränkungen pro Region.

Diese Artikel enthalten Details zu SKU-Angeboten für die anderen beiden Dienste:

Horizontale Skalierbarkeit der Infrastruktur

Horizontale Skalierung bezieht sich auf die Möglichkeit, die Kapazität über eine neue Infrastruktur wie VM-Knoten zu erhöhen oder zu verringern. Während der Erhöhung oder Verringerung der Skalierung abstrahiert die Container-Apps-Verbrauchsebene die zugrunde liegenden virtuellen Maschinen. Für die verbleibenden Azure Container Services verwalten Sie die horizontale Skalierungsstrategie mithilfe der standardmäßigen Azure Resource Manager-API.

Beachten Sie, dass das Aus- und Einskalieren einen Neuabgleich der Instanzen beinhaltet und somit auch das Risiko von Ausfallzeiten mit sich bringt. Das Risiko ist kleiner als das entsprechende Risiko mit vertikaler Skalierung. Dennoch sind Workload-Teams immer dafür verantwortlich, sicherzustellen, dass ihre Anwendungen Fehler bewältigen können, und verantwortlich für die Implementierung von ordnungsgemäßen Startups und das Herunterfahren ihrer Anwendungen, um Ausfallzeiten zu vermeiden.

Container-Apps AKS Web App für Containers
Infrastruktur-Scale in und out Verbrauchsplan: N/A
Dedizierter Plan: konfigurierbar		 Konfigurierbar Konfigurierbar
Flexible Hardware-Bereitstellung Verbrauchsplan: N/A
Dedizierter Plan: abstrahiert mit Workload-Profilen		 Jede VM-SKU Abstrahiert. Der App Service-Plan.

Wichtig

Die Hardware-Bereitstellungsoptionen, die über den Dedizierten Plan für Container Apps (Workload-Profile) und Web-App für Container (App Service-Pläne) verfügbar sind, sind nicht so flexibel wie AKS. Sie müssen sich mit den in jedem Dienst verfügbaren SKUs vertraut machen, um sicherzustellen, dass Ihre Anforderungen erfüllt werden.

Skalierbarkeit der Anwendung

Das typische Maß für die Auslösung der Skalierung von Infrastruktur und Anwendungen ist der Ressourcenverbrauch: CPU und Arbeitsspeicher. Einige Containerlösungen können die Anzahl der Containerinstanzen auf Metriken mit anwendungsspezifischem Kontext skalieren, z. B. HTTP-Anforderungen. Beispielsweise können AKS und Container Apps Containerinstanzen basierend auf Nachrichtenwarteschlangen über KEDA und viele andere Metriken über seine Scaler skalieren. Diese Funktionen bieten Flexibilität, wenn Sie die Skalierbarkeitsstrategie für Ihre Anwendung auswählen. We-App für Container basiert auf den Skalierbarkeitsoptionen von Azure. (Siehe die folgende Tabelle.) Web-App für Container unterstützt keine benutzerdefinierten Scaler-Konfigurationen wie KEDA.

Container-Apps AKS Web App für Containers
Scale out von Containern HTTP, TCP oder metrikenbasiert (CPU, Arbeitsspeicher, Ereignisgesteuert). Metrikenbasiert (CPU, Arbeitsspeicher oder benutzerdefiniert) Manuell, metrikbasiert oder automatisch (Vorschau)
Ereignisgesteuerte Skalierbarkeit Ja. Cloudnativer Dienst. Ja. Cloudnativer Dienst. Weitere Konfiguration erforderlich. Ja. Azure-ressourcenspezifisch.

Einblick

Workload-Instrumentierung

Das Sammeln von Metriken für komplexe oder mehrstufige Anwendungen kann eine Herausforderung darstellen. Um Metriken zu erhalten, können Sie containerisierte Workloads auf zwei Arten in Azure Monitor integrieren:

  • Automatische Instrumentierung. Codeänderungen sind nicht erforderlich.
  • Manuelle Instrumentierung. Minimale Codeänderungen, die erforderlich sind, um das SDK und/oder den Client zu integrieren und zu konfigurieren.
Container-Apps AKS Web App für Containers
Automatische Instrumentierung über die Plattform ❌ ❌ Partielle Unterstützung*
Automatische Instrumentierung über Agent ❌ Partielle Unterstützung* N/V
Manuelle Instrumentierung Via SDK oder OpenTelemetry Via SDK oder OpenTelemetry Via SDK oder OpenTelemetry

*AKS und Web-App für Container unterstützen die automatische Instrumentierung für bestimmte Konfigurationen von Linux- und Windows-Workloads, abhängig von der Anwendungssprache. Weitere Informationen finden Sie in folgenden Artikeln:

Die Instrumentierung innerhalb des Anwendungscodes liegt in der Verantwortung von Anwendungsentwicklern, sodass sie unabhängig von jeder Azure-Containerlösung ist. Ihre Workload kann Lösungen verwenden wie:

Protokolle

Alle Azure Container Services bieten Anwendungs- und Plattformprotokollfunktionen. Anwendungsprotokolle sind Konsolenprotokolle, die von Ihrer Workload generiert werden. Plattformprotokolle erfassen Ereignisse, die auf Plattformebene auftreten und sich außerhalb des Gültigkeitsbereichs Ihrer Anwendung befinden, z. B. Skalierung und Bereitstellungen.

Die Standardunterschiede zwischen den Protokollierungsfunktionen für Containerdienste beziehen sich auf die Plattformprotokollierung: Was protokolliert wird und wie Protokolle intern organisiert werden. Azure Monitor ist der Standard Protokollierungsdienst in Azure, der in diese Dienste integriert ist. Monitor verwendet Ressourcenprotokolle, um Protokolle in Kategorien zu separieren, die aus verschiedenen Quellen stammen. Eine Möglichkeit, zu bestimmen, welche Protokolle von jedem Azure-Dienst verfügbar sind, besteht darin, die Ressourcenprotokollkategorien zu betrachten, die für jeden der Dienste verfügbar sind.

Container-Apps AKS Web App für Containers
Unterstützung für Protokollstreaming (Echtzeitstreaming) ✅ ✅ ✅
Unterstützung für Azure Monitor ✅ ✅ ✅
Azure Monitor-Ressourcenprotokolle Konsole und System Kubernetes-API-Server, Audit, Scheduler, Cluster Autoscaler und mehr ConsoleLogs, HTTPLogs, EnvironmentPlatformLogs und mehr

Um eine detaillierte Beschreibung der einzelnen Ressourcenprotokolle in der Tabelle anzuzeigen, wählen Sie die Verknüpfungen in der Tabelle aus.

Hier ist eine kurze Zusammenfassung der Protokollierungsfunktionen der Containerdienste:

  • Container-Apps abstrahiert alle internen Kubernetes-Protokolle in zwei Kategorien. Eine Kategorie, die als Konsolen-Protokolle bezeichnet wird, enthält die Workload-Containerprotokolle. Eine zweite Kategorie, die System-Kategorie enthält alle plattformbezogenen Protokolle.
  • AKS bietet alle Kubernetes-bezogenen Protokolle und präzise Kontrolle darüber, was protokolliert werden kann. Außerdem bleibt die vollständige Kompatibilität mit Kubernetes-Client-Tools für das Protokollstreaming wie kubectl erhalten.
  • Web-App für Container stellt viele Kategorien von Ressourcenprotokollen bereit, da ihre Plattform (App Service) nicht ausschließlich für Container-Workloads bestimmt ist. Für containerspezifische Vorgänge, die die interne Docker-Plattform verwalten, stellt sie die Protokollkategorie „AppServicePlatformLogs“ bereit. Eine weitere wichtige Kategorie ist AppServiceEnvironmentPlatformLogs, die Ereignisse wie Skalierung und Konfigurationsänderungen protokolliert.

Gut durchdachter Rahmen für erstklassige Betriebsprozesse

Dieser Artikel konzentriert sich auf die Hauptunterschiede zwischen den hier beschriebenen Funktionen der Containerdienste. Lesen Sie die folgenden Artikel, um den vollständigen Leitfaden zu erstklassigen Betriebsprozessen für die folgenden Dienste zu studieren:

Zuverlässigkeit

Zuverlässigkeit: Bezieht sich auf die Möglichkeit eines Systems, auf Ausfälle reagieren zu können und vollständig funktionsfähig zu bleiben. Auf Anwendungssoftwareebene sollten Workloads bewährte Methoden wie Zwischenspeicherung, Wiederholen, Schaltkreistrennmuster und Integritätsprüfungen implementieren. Auf Infrastrukturebene ist Azure für die Behandlung von physischen Fehlern wie Hardwarefehlern und Stromausfällen in Rechenzentren verantwortlich. Fehler können weiterhin auftreten. Workload-Teams sollten die entsprechende Azure-Dienstebene auswählen und erforderliche Konfigurationen für die Mindestinstanz anwenden, um automatische Failovers zwischen Verfügbarkeitszonen zu implementieren.

Um die entsprechende Dienstebene auszuwählen, müssen Sie verstehen, wie Vereinbarungen zum Service Level (Service Level Agreements, SLAs) und Verfügbarkeitszonen funktionieren.

Vereinbarungen zum Service Level

Zuverlässigkeit wird häufig durch geschäftsgesteuerte Metriken wie SLAs oder Wiederherstellungsmetriken wie Wiederherstellungszeitziele (RTOs) gemessen.

Azure verfügt über viele SLAs für bestimmte Dienste. Es gibt keine Art von Servicelevel von 100 %, da Fehler immer in Software und Hardware auftreten können, sowie auch in der Natur, z. B. Stürme und Erdbeben. Eine SLA ist keine Garantie, sondern eine finanziell gesicherte Vereinbarung der Serviceverfügbarkeit.

Laden Sie für die neuesten SLAs und Details das neueste SLA für Microsoft Online Services-Dokument von der Microsoft-Lizenzierungswebsite herunter.

Kostenlose im Vergleich zu kostenpflichtigen Tarifen

Im Allgemeinen bieten kostenlose Azure-Dienste keine SLA an, was sie zu kosten-effizienten Entscheidungen für Nicht-Produktionsumgebungen macht. Für Produktionsumgebungen ist es jedoch eine bewährte Methode, eine kostenpflichtige Tarife auszuwählen, die über eine SLA verfügt.

Zusätzliche Faktoren für AKS

AKS verfügt über unterschiedliche SLAs für unterschiedliche Komponenten und Konfigurationen:

  • Steuerungsebene. Der Kubernetes-API-Server verfügt über eine separate SLA.
  • Datenebene. Knotenpools verwenden die zugrunde liegenden VM-SKU-SLAs.
  • Verfügbarkeitszonen. Es gibt unterschiedliche SLAs für die beiden Ebenen, je nachdem, ob für den AKS-Cluster Verfügbarkeitszonen aktiviert sind und mehrere Instanzen über Verfügbarkeitszonen hinweg ausgeführt werden.

Beachten Sie, dass sich zusammengesetzte SLOs bei Verwendung mehrerer Azure-Dienste möglicherweise von einzelnen Dienst-SLAs unterscheiden und niedriger sind als einzelne Dienst-SLAs.

Redundanz mit Verfügbarkeitszonen

Verfügbarkeitszonen sind unterschiedliche Rechenzentren, die unabhängig über elektrische Energie, Kühlung usw. innerhalb einer einzelnen Region verfügen. Die resultierende Redundanz erhöht die Toleranz von Fehlern, ohne dass Sie multiregionsbasierte Architekturen implementieren müssen.

Azure verfügt über Verfügbarkeitszonen in jedem Land/jederRegion, in dem Azure eine Rechenzentrumsregion betreibt. Um mehreren Instanzen von Containern für übergreifende Verfügbarkeitszonen zu ermöglichen, stellen Sie sicher, dass Sie SKUs, Dienstebenen und Regionen auswählen, die Unterstützung für Verfügbarkeitszonen bieten.

Funktion Container-Apps AKS Web App für Containers
Unterstützung für Verfügbarkeitszonen Vollständig Vollständig Vollständig

Beispielsweise ist eine Anwendung oder Infrastruktur, die für die Ausführung einer einzelnen Instanz konfiguriert ist, nicht mehr verfügbar, wenn ein Problem in der Verfügbarkeitszone auftritt, in der die Hardware gehostet wird. Um Unterstützung der Verfügbarkeitszone umfassend zu verwenden, sollten Sie Workloads mit einer Mindestkonfiguration von drei Instanzen des Containers bereitstellen, die sich über Zonen erstrecken.

Integritätsprüfungen und Selbstreparatur

Integritätsprüfungsendpunkte sind für eine zuverlässige Workload von entscheidender Bedeutung. Das Erstellen dieser Endpunkte ist jedoch nur die Hälfte der Lösung. Die andere Hälfte steuert, was die Hosting-Plattform tut und wie, wenn Fehler auftreten.

Um die verschiedenen Arten von Integritätstests besser zu unterscheiden, sehen Sie sich die integrierten Typen von Tests aus Kubernetes an:

  • Startup. Überprüft, ob die Anwendung erfolgreich gestartet wurde.
  • Bereitschaft. Überprüft, ob die Anwendung bereit ist, eingehende Anforderungen zu verarbeiten.
  • Livezustand. Überprüft, ob die Anwendung noch ausgeführt wird und reaktionsfähig ist.

Ein weiterer wichtiger Aspekt ist, wie oft diese Integritätsprüfungen von der Anwendung angefordert werden (interne Granularität). Wenn ein langes Intervall zwischen diesen Anforderungen besteht, können Sie den Datenverkehr eventuell weiterhin bereitstellen, bis die Instanz als fehlerhaft eingestuft wird.

Die meisten Anwendungen unterstützen Integritätsprüfungen über das HTTP(S)-Protokoll. Einige benötigen jedoch möglicherweise andere Protokolle, z. B. TCP oder gRPC, um diese Prüfungen durchzuführen. Beachten Sie dies beim Entwerfen Ihres Integritätsprüfungssystems.

Container-Apps AKS Web App für Containers
Starttests ✅ ✅ Partielle Unterstützung
Bereitschaftstest ✅ ✅ ❌
Livetest ✅ ✅ ✅
Intervall-Granularität Sekunden Sekunden 1 Minute
Protokollunterstützung HTTP(S)
TCP		 HTTP(S)
TCP
gRPC		 HTTP(S)

Integritätsprüfungen sind am einfachsten in Web-App für Container zu implementieren. Es gibt einige wichtige Überlegungen:

  • Die Starttests sind integriert und können nicht geändert werden. Es sendet eine HTTP-Anforderung an den Startport Ihres Containers. Jede Antwort ihrer Anwendung gilt als erfolgreicher Start.
  • Es unterstützt keine Bereitschaftstest. Wenn der Starttest erfolgreich ist, wird die Containerinstanz dem Pool der fehlerfreien Instanzen hinzugefügt.
  • Sie sendet die Integritätsprüfung in Intervallen von 1 Minute. Sie können dieses Intervall nicht ändern.
  • Der Mindestschwellenwert, den Sie für eine fehlerhafte Instanz festlegen können, die aus dem internen Lastenausgleichsmechanismus entfernt werden soll, beträgt zwei Minuten. Die fehlerhafte Instanz ruft den Datenverkehr mindestens zwei Minuten ab, nachdem eine Integritätsprüfung fehlschlägt. Der Standardwert für dieseEinstellung ist 10 Minuten.

Container-Apps und AKS hingegen sind viel flexibler und bieten ähnliche Optionen. Was die spezifischen Unterschiede betrifft, so bietet AKS die folgenden Optionen zur Durchführung von Gesundheitsprüfungen, die in Container Apps nicht verfügbar sind:

Automatische Reparatur

Eine ungültige Container-Instanz zu identifizieren und keinen Datenverkehr mehr an sie zu senden, ist ein Anfang. Der nächste Schritt besteht im Implementieren von Automatischer Reparatur. Automatische Reparatur ist der Prozess des Neustarts der Anwendung mit dem Versuch, eine Wiederherstellung aus einem fehlerhaften Zustand zu erreichen. So vergleichen die drei Containerdienste:

  • In Web-App für Container gibt es keine Möglichkeit, eine Containerinstanz sofort neu zu starten, nachdem eine Integritätsprüfung fehlschlägt. Wenn die Instanz eine Stunde lang fehlschlägt, wird sie durch eine neue Instanz ersetzt. Es gibt ein weiteres Feature, das als automatisches Reparieren bezeichnet wird, das Instanzen überwacht und neu startet. Es steht nicht direkt im Zusammenhang mit Integritätsprüfungen. Es verwendet verschiedene Anwendungsmetriken, z. B. Speicherbeschränkungen, Dauer der HTTP-Anforderung und Statuscodes.
  • Container Apps und AKS versuchen automatisch, eine Containerinstanz neu zu starten, wenn der Livetest den definierten Fehlerschwellenwert erreicht.

Anwendungsbereitstellung ohne Ausfallzeiten

Die Möglichkeit, Anwendungen bereitzustellen und zu ersetzen, ohne Downtime für Benutzer zu verursachen, ist für eine zuverlässige Workload von entscheidender Bedeutung. Alle drei Containerdienste, die in diesem Artikel beschrieben werden, unterstützen Bereitstellungen ohne Downtime, aber auf unterschiedliche Weise.

Container-Apps AKS Web App für Containers
Null-Downtime-Strategie Paralleles Update Rollende Aktualisierung und alle anderen Kubernetes-Strategien Bereitstellungsslots

Bitte beachten Sie, dass die Anwendungsarchitekturen auch eine Zero-Downtime-Bereitstellung unterstützen müssen. Siehe Azure Well-Architected Framework für Anleitungen.

Ressourceneinschränkungen

Eine weitere wichtige Komponente einer zuverlässigen freigegebenen Umgebung ist ihre Kontrolle über die Ressourcennutzung (z. B. CPU oder Arbeitsspeicher) Ihrer Container. Sie müssen Szenarien vermeiden, in denen eine einzelne Anwendung alle Ressourcen einnimmt und andere Anwendungen in einem fehlerhaften Zustand verbleibt.

Container-Apps AKS Web App für Containers
Ressourcenbeschränkungen (CPU oder Arbeitsspeicher) Pro App/Container Pro App/Container
Pro Namespace		 Pro App-Serviceplan
  • Web App für Container: Sie können mehrere Anwendungen (Container) in einem einzigen App Service-Plan hosten. Sie können beispielsweise einen Plan mit zwei CPU-Kernen und 4 GiB RAM zuordnen, in dem Sie mehrere Web-Apps in Containern ausführen können. Sie können jedoch nicht eine der Apps auf eine bestimmte Menge an CPU oder Arbeitsspeicher beschränken. Sie alle konkurrieren mit den gleichen App Service-Planressourcen. Wenn Sie Ihre Anwendungsressourcen isolieren möchten, müssen Sie zusätzliche App Service-Pläne erstellen.
  • Container-Apps: Sie können CPU- und Arbeitsspeicherbeschränkungen pro Anwendung in Ihrer Umgebung festlegen. Sie sind jedoch auf eine Reihe zulässiger Kombinationen von CPU und Arbeitsspeicher beschränkt. Sie können zum Beispiel nicht eine vCPU und 1 GiB Arbeitsspeicher konfigurieren, aber Sie können eine vCPU und 2 GiB Arbeitsspeicher konfigurieren. Eine Container-Apps-Umgebung entspricht einem Kubernetes-Namespace.
  • AKS: Sie können eine beliebige Kombination aus vCPU und Arbeitsspeicher auswählen, solange Ihre Knoten über die Hardware verfügen, um sie zu unterstützen. Sie können Ressourcen auch auf Namespaceebene einschränken, wenn Sie Ihren Cluster auf diese Weise segmentieren möchten.

Gut durchdachter Rahmen für Zuverlässigkeit

Dieser Artikel konzentriert sich auf die Hauptunterschiede zwischen den Containerdienstfeatures in Azure. Wenn Sie den vollständigen Zuverlässigkeitsleitfaden für einen bestimmten Dienst überprüfen möchten, lesen Sie die folgenden Artikel:

Zusammenfassung

Gut durchdachte Lösungen setzen die Grundlagen für erfolgreiche Workloads. Obwohl die Architekturen angepasst werden können, wenn die Arbeitslast wächst und die Teams auf ihrem Weg in die Cloud vorankommen, sind einige Entscheidungen, insbesondere im Bereich der Netzwerke, nur schwer rückgängig zu machen, ohne dass es zu erheblichen Ausfallzeiten oder einer Neueinrichtung kommt.

Im Allgemeinen zeichnet sich beim Vergleich der Azure-Containerdienste eine Tendenz ab: AKS bietet die am meisten zugrunde liegende Infrastruktur und somit die größtmögliche Konfigurierbarkeit und Erweiterbarkeit. Der operationelle Aufwand und die Betriebskomplexität sind bei AKS-Workloads sehr variabel. Einige Teams können den Betriebsaufwand durch die Nutzung von von Microsoft verwalteten Add-Ons und Erweiterungen sowie Funktionen für automatische Upgrades reduzieren. Andere Kunden bevorzugen möglicherweise die komplette Kontrolle über den Cluster, um die vollständige Erweiterbarkeit von Kubernetes und des CNCF-Ökosystems zu nutzen. Obwohl Microsoft Flux beispielsweise als verwaltete GitOps-Erweiterung anbietet, entscheiden sich viele Teams stattdessen dafür, ArgoCD selbst einzurichten und zu betreiben.

Workload-Teams, die zum Beispiel keine CNCF-Anwendungen benötigen, weniger Erfahrung mit dem Betrieb haben oder sich lieber auf Anwendungsfunktionen konzentrieren, könnten ein PaaS-Angebot bevorzugen. Es wird empfohlen, zuerst Container-Apps in Betracht zu ziehen.

Obwohl Container Apps und Web App for Containers beides PaaS-Angebote sind, die ein ähnliches Maß an von Microsoft verwalteter Infrastruktur bieten, liegt der Hauptunterschied darin, dass Container Apps näher an Kubernetes ist und zusätzliche Cloud-native Funktionen für Service Discovery, ereignisgesteuerte Autoskalierung, Dapr-Integration und mehr bietet. Teams, die diese Funktionen nicht benötigen und mit App Service-Netzwerk- und Bereitstellungsmodellen vertraut sind, bevorzugen möglicherweise Web App für Container.

Generalisierungen können Ihnen helfen, die Liste der zu berücksichtigenden Azure-Containerdienste einzugrenzen. Denken Sie jedoch daran, dass Sie Ihre Wahl auch überprüfen müssen, indem Sie einzelne Anforderungen detailliert prüfen und mit dienstspezifischen Featuresätzen abgleichen.

Beitragende

Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:

Hauptautoren:

Andere Mitwirkende:

Melden Sie sich bei LinkedIn an, um nicht öffentliche LinkedIn-Profile anzuzeigen.

Nächste Schritte