Freigeben über

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:

Architektur- und Networking-Überlegungen

  • Betriebssystemunterstützung
  • Adressräume des lokalen Netzwerks
  • Grundlegendes zum Verkehrsfluss
  • 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

Überlegungen zur Sicherheit

  • Bereitstellung von Sicherheit für den Datenverkehr innerhalb des Clusters mithilfe von Netzwerkrichtlinien
  • Netzwerksicherheitsgruppen
  • Azure-Schlüsseltresor-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
  • Beobachtbarkeit
  • Gut durchdachter Rahmen für erstklassige Betriebsprozesse

Überlegungen zur Zuverlässigkeit

  • Vereinbarungen zum Service Level
  • Redundanz über Verfügbarkeitszonen
  • Gesundheitsprüfungen und Selbstheilung
  • 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, Observability, Entwicklertools und -vorgänge bieten: Azure Kubernetes Service (AKS), AKS Automatic, Azure Container Apps und Web App for Containers. Eine vollständige Liste aller Azure-Containerdienste finden Sie auf der Produktkategorieseite für Containerdienste.

Hinweis

Einige Abschnitte unterscheiden AKS Standard von AKS Automatic. Wenn ein Abschnitt nicht zwischen den beiden unterscheidet, wird von einer Gleichheit der Funktionen ausgegangen.

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.

Hinweis

AKS Automatic ist eine meinungsstärkere Lösung als AKS Standard. Einige sofort einsatzbereite Features können nicht deaktiviert werden. In diesem Handbuch werden diese Features nicht aufgeführt. Aktuelle Informationen zu diesen Einschränkungen und zum Vergleich von Standard- und automatischen Features finden Sie unter: AKS Automatic and Standard Feature Comparison.

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 AKS Automatic Web-App für Container
Linux-Unterstützung ✅ ✅ ✅ ✅
Windows-Unterstützung ❌ ✅ ❌ ✅
Unterstützung für gemischte Betriebssysteme ❌ ✅ ❌ ❌*

*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 Funktionen für das Networking bietet, wie z.B. die Erkennung von Diensten, intern verwaltete Domänen und die Kontrolle virtueller Netzwerke.
  • AKS ist der am besten konfigurierbare der drei Dienste und bietet die größte Kontrolle über den Networking Flow. Sie stellt z. B. benutzerdefinierte Ingress-Controller und die Steuerung des Datenverkehrs innerhalb des Clusters ü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 des 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 Container
Zweckgebundene Subnetze 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 Azure-virtuelle 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.

Grundlegendes zum Verkehrsfluss

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 Container
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-Adresse beschränkt, die entweder öffentlich oder privat sein kann.

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 Container
Anzahl der Ingress-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-Adresse für alle Apps innerhalb eines App Service-Plans und mehrere unterschiedliche private IP-Adressen, die Azure Private Endpoints 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 Verdeutlichung: AKS-Knotenpools und Web App für Container in einer App Service Environment sind 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 Container
UDR-Support Nutzungsbasierter Plan: ❌
Workload-Profil-Plan: ✅		 ✅ ✅
Unterstützung für NAT-Gateways 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 Container
Privater Eingang in ein virtuelles Netzwerk ✅ ✅ Über einen privaten Endpunkt
Privater Ausgang 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 umzusetzen, müssen sich Workload-Teams mit diesen Netzwerkkonzepten 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 Hostingplattform ist, welche Netzwerkprotokolle für eingehende Anforderungen von Anwendungen (Ingress) 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 Container
Protokoll- und Port-Unterstü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 entfernt Azure die Notwendigkeit für Layer-4- und Layer-7-Load-Balancer vollständig.

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 Container
Layer-4-Lastenausgleich In Azure verwaltet Gemeinsame Verantwortung In Azure verwaltet
Layer-7-Lastenausgleich 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 Container
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 Container
Konfigurieren angepasster Domänen Vorgefertigt BYO Vorgefertigt
Verwaltetes TLS für Azure FQDNs Vorgefertigt N/V Vorgefertigt
Verwaltetes TLS für angepasste Domänen In der Vorschau 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.

Überlegungen zur Sicherheit

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.

AKS bietet unter den Diensten in diesem Leitfaden die größte Konfigurierbarkeit und Erweiterbarkeit, indem zugrunde liegende Komponenten offengelegt werden, die häufig ü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.

AKS-Automatik-Cluster sind mit einer gehärteten Standardkonfiguration ausgestattet, wobei viele Sicherheits-Einstellungen für den Cluster, die Anwendungen und die Netzwerktechnik standardmäßig aktiviert sind. Diese anfänglichen Konfigurationen reduzieren nicht nur die Bereitstellungszeit, sondern bieten Benutzern auch eine standardisierte Konfiguration, die vorab überprüft wird, und bietet benutzern somit eine solide Grundlage für die Betrieblichen Verantwortlichkeiten von Tag 2. Diese Grundlage trägt dazu bei, die Lernkurve des langfristigen Clustermanagements für Teams zu verkürzen, die neu in der Technologie sind.

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

Sicherheit des Kubernetes-Kontrollflächensystems

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 Zugriffssteuerung 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-Clusterzu verwenden, die den Azure Private Link zwischen dem privaten Netzwerk des API-Servers und dem privaten Netzwerk der AKS-Cluster 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 Sicherstellung der Sicherheit für den Cluster-internen Datenverkehr

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 Container
Network Richtlinien 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 Container
Netzwerksicherheitsgruppen Verbrauchsplan: ✅
Dedizierter Plan: ✅		 ✅ ✅ VNet-integrierte Apps: ausschließlich ausgehend

Integrierte IP-Einschränkungen für den Eingang

Container-Apps und Web-Apps für Container bieten integrierte Quell-IP-Einschränkungen für den eingehenden Netzwerkverkehr einzelner Anwendungen. AKS kann die gleiche Funktionalität erreichen, erfordert jedoch Kubernetes-native Funktionalität über die Kubernetes-Dienst-API-Ressource, in der Sie Werte für loadBalancerSourceRangesfestlegen können.

Container-Apps AKS Web-App für Container
Eingebettete Eingangs-IP-Einschränkungen ✅ ❌* ✅
Ressourcenverbrauch - Verbraucht Cluster-Ressourcen -

Hinweis

AKS bietet Beschränkungen für eingehende IP-Adressen an, aber das ist eine native Kubernetes-Funktion und nicht eine Azure-eigene, wie die anderen Dienste.

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 Container
Key Vault-Integration ✅ ✅ ✅

Weitere Informationen finden Sie unter:

Unterstützung verwalteter Identitäten

Verwaltete Identität kann von Anwendungen verwendet werden, um sich bei geschützten Microsoft Entra-ID-Diensten zu authentifizieren, ohne Schlüssel oder geheime Schlüssel verwenden zu müssen. Container-Apps und Web App für Container bieten integrierte, systemeigene Azure-Unterstützung für verwaltete Identität auf Anwendungsebene. Die Unterstützung von verwalteten Identitäten auf Anwendungsebene für AKS wird durch Entra Workload ID erreicht. AKS benötigt auch eine infrastrukturbezogene verwaltete Identität, um Cluster-Operationen für das Kubelet, die Steuerungsebene und verschiedene AKS-Add-ons zuzulassen.

Container-Apps AKS Web-App für Container
Verwaltete Identitätsunterstützung für die Infrastruktur N/V ✅ N/V
Unterstützung von verwalteter Identität durch Container-Pull ✅ ✅ ✅
Unterstützung für verwaltete Identitäten in Anwendungen ✅ ✅ ✅

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 Container
Runtime-Bedrohungsschutz ❌ ✅ ❌

Weitere Informationen finden Sie unter Unterstützungsmatrix für Container 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:

Hinweis

Automatische Cluster von AKS werden mit spezifischen Sicherheitseinstellungen festgelegt. Stellen Sie sicher, dass diese an Ihre Workloadanforderungen angepasst sind.

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 der automatischen Upgrade-Kanäle 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 AKS Automatic Web-App für Container
Aktualisierungen der Steuerungsebene Plattform Kunde Plattform Plattform
Host Updates und Patches Plattform Kunde Plattform Plattform
Container-Image-Updates und Patches Customer Customer Customer Customer

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

Vertikale Skalierung bezieht sich auf die Möglichkeit, die vorhandene Infrastruktur, d.h. CPU und Speicher, zu vergrößern oder zu verkleinern. 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 neue Infrastrukturen, 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 Skalieren (Scale-Out und Scale-In) das Neuausbalancieren von Instanzen beinhaltet, wodurch auch ein Risiko für Ausfallzeiten entsteht. Das Risiko ist kleiner als das entsprechende Risiko mit vertikaler Skalierung. Dennoch sind Arbeitsteams immer dafür verantwortlich, sicherzustellen, dass ihre Anwendungen mit Fehlern umgehen können, und ordentliche Start- und Herunterfahrvorgänge ihrer Anwendungen zu implementieren, um Ausfallzeiten zu vermeiden.

Container-Apps AKS Web-App für Container
Ab- und Aufskalieren von Infrastrukturen Verbrauchsplan: N/A
Dedizierter Plan: konfigurierbar		 Variantenkonfigurator verwenden Variantenkonfigurator verwenden
Flexible Hardware-Provisionierung 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 Container
Horizontales Skalieren von Containern HTTP, TCP oder metrikbasiert (CPU, Arbeitsspeicher, ereignisgesteuert). Metrikbasiert (CPU, Arbeitsspeicher oder benutzerdefiniert) Manuell, metrikbasiert oder automatisch (Vorschau)
Ereignisbasierte Skalierbarkeit Ja. Cloudnativer Dienst. Ja. Cloudnativer Dienst. Weitere Konfiguration erforderlich. Ja. Azure-ressourcenspezifisch.

AKS Automatic aktiviert standardmäßig den Horizontal Pod Autoscaler, Kubernetes Event-driven Autoscaling (KEDA) und Vertical Pod Autoscaler (VPA).

Beobachtbarkeit

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 Container
Automatische Instrumentierung über die Plattform ❌ ❌ Teilweise Unterstützung*
Automatische Instrumentierung über Agent ❌ Teilweise 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 und Metriken

Alle Azure-Containerdienste bieten Anwendungs- und Plattformprotokoll- und Metrikfunktionen. Anwendungsprotokolle sind Konsolenprotokolle, die von Ihrer Workload generiert werden. Plattformprotokolle erfassen Ereignisse, die auf Plattformebene auftreten, außerhalb des Gültigkeitsbereichs Ihrer Anwendung, z. B. Skalierung und Bereitstellungen. Metriken sind numerische Werte, die einen Aspekt eines Systems zu einem bestimmten Zeitpunkt beschreiben, sodass Sie die Systemleistung und -integrität überwachen und warnen können.

Azure Monitor ist der wichtigste Protokollierungs- und Metrikdienst in Azure, der in diese Dienste integriert ist. Azure Monitor verwendet Ressourcenprotokolle, um Protokolle aus verschiedenen Quellen in Kategorien zu trennen und Metriken zu sammeln, um Einblicke in die Ressourcenleistung zu erhalten. Eine Möglichkeit, zu bestimmen, welche Protokolle und Metriken von jedem Azure-Dienst verfügbar sind, besteht darin, die Ressourcenprotokollkategorien und die verfügbaren Metriken für jeden der Dienste zu betrachten.

Container-Apps AKS AKS Automatic Web-App für Container
Unterstützung für Log-Streaming ✅ ✅ ✅ ✅
Unterstützung für Azure Monitor ✅ ✅ ✅ ✅
Azure Monitor-Ressourcenprotokolle -Konsole und -System Kubernetes API-Server, Audit, Scheduler, Cluster Autoscaler und mehr Identisch mit AKS ConsoleLogs, HTTPLogs, EnvironmentPlatformLogs und mehr
Metrische Sammlung und Überwachung Metriken über Azure Monitor; angepasste Metriken über Dapr Metriken Metriken über Azure Monitor; Benutzerdefinierte Metriken über Prometheus (erfordert manuelles Setup) Vorkonfiguriertes verwaltetes Prometheus für die Metrikensammlung und verwaltetes Grafana zur Visualisierung; Metriken über Azure Monitor Metriken über Azure Monitor
Vorkonfiguriertes Prometheus und Grafana ❌ Erfordert manuelles Setup ✅ Managed Prometheus und Managed Grafana sind standardmäßig vorkonfiguriert. ❌

Container Apps fasst alle internen Kubernetes-Logs in zwei Kategorien zusammen: Konsolen-Logs, die Container-Logs für Arbeitslasten enthalten, und System-Logs, die alle plattformbezogenen Logs enthalten. Um Metriken zu erfassen, werden Container-Apps in Azure Monitor integriert, um Standardmetriken zu sammeln, und unterstützen benutzerdefinierte Metriken über die Dapr-Integration für erweiterte Szenarien.

AKS bietet Kubernetes-bezogene Protokolle und präzise Kontrolle darüber, was protokolliert wird. AKS behält die volle Kompatibilität mit Kubernetes-Clienttools für das Protokollstreaming, z. B. kubectl, bei. Für Metriken ist AKS in Azure Monitor integriert, um Cluster- und Knotenmetriken zu sammeln. Benutzerdefinierte Metriksammlung mit Prometheus und Visualisierung mit Grafana sind möglich, erfordern jedoch manuelle Einrichtung und Konfiguration.

AKS Automatic ist mit bestimmten Überwachungstools vorkonfiguriert. Es verwendet Managed Prometheus für die Metrik-Erfassung und Managed Grafana für die Visualisierung. Cluster- und Anwendungsmetriken werden automatisch erfasst und können visualisiert werden. AKS Automatic lässt sich auch in Azure Monitor für Protokoll- und Metriksammlung integrieren.

Web App für Container bietet mehrere Kategorien von Ressourcenprotokollen, da ihre Plattform (App Service) nicht ausschließlich für Containerworkloads 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. Metriken werden über Azure Monitor gesammelt, sodass Sie die Anwendungsleistung und ressourcenauslastung überwachen können.

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 Fähigkeit eines Systems, auf Ausfälle zu reagieren und voll 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 kein 100% Servicelevel, da Fehler immer in Software und Hardware sowie in der Natur, zum Beispiel bei Stürmen und Erdbeben, auftreten können. 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.

Wenn Sie mehrere Azure-Dienste verwenden, beachten Sie, dass sich die zusammengesetzten SLOs möglicherweise von den SLAs einzelner Dienste unterscheiden und niedriger sein können.

Redundanz mit Verfügbarkeitszonen

Verfügbarkeitszonen sind verschiedene Rechenzentren mit unabhängiger Stromversorgung, Kühlung usw. innerhalb einer Region. 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 Container-Instanzen zu ermöglichen, über Verfügbarkeitszonen hinweg zu operieren, 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 Container
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.

Gesundheitsprüfungen und Selbstheilung

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 Gesundheitsüberprü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 Gesundheitsprüfungssystems.

Container Apps AKS Web-App für Container
Starttests ✅ ✅ Partielle Unterstützung
Bereitschaftstests ✅ ✅ ❌
Livetests ✅ ✅ ✅
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 nicht funktionierende 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, bietet AKS die folgenden Optionen für die 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 stehen die drei Containerdienste im Vergleich:

  • 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 Gesundheitsüberprü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 Container
Null-Downtime-Strategie Paralleles Update Paralleles Update 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 Container
Ressourcenbegrenzung (CPU oder Arbeitsspeicher) Pro App/Container Pro App/Container
Pro Namensraum		 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 um die Ressourcen des gleichen App-Service-Plans. Wenn Sie Ihre Anwendungsressourcen isolieren möchten, müssen Sie zusätzliche App Service-Pläne erstellen.
  • Container Apps: Sie können CPU- und Speicherlimits 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 Architekturen angepasst werden können, wenn eine Arbeitsbelastung zunimmt und Teams bei ihren Cloud-Reisen fortschreiten, sind einige Entscheidungen, insbesondere im Hinblick auf Netzwerke, schwierig rückgängig zu machen, ohne erhebliche Ausfallzeiten oder erneute Bereitstellungen.

Im Allgemeinen erkennt man beim Vergleichen von Azure-Containerdiensten ein Muster: AKS bietet den größten Einblick in die zugrunde liegende Infrastruktur und damit die größte Kontrolle und Konfigurierbarkeit, während AKS Automatic ein Gleichgewicht zwischen Kontrolle und Einfachheit schafft, indem es viele operative Aufgaben automatisiert.

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.

Container Apps und Web App für Container sind zwar PaaS-Angebote, die ähnliche Ebenen von Microsoft-verwalteter Infrastruktur bieten, aber ein wesentlicher Unterschied besteht darin, dass Container Apps näher an Kubernetes liegen und zusätzliche cloud-native Funktionen für die Dienstentdeckung, ereignisgesteuertes Autoscaling, Dapr-Integration und vieles mehr bieten. 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:

Um nicht-öffentliche LinkedIn-Profile anzuzeigen, melden Sie sich bei LinkedIn an.

Nächste Schritte