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. Es bietet eine Übersicht über Überlegungen auf Featureebene, die für einige Workloads häufig und kritisch sind. Es kann Ihnen helfen, Entscheidungen zu treffen, um sicherzustellen, dass Ihre Workload Anforderungen für Zuverlässigkeit, Sicherheit, Kostenoptimierung, operative Exzellenz und Leistungseffizienz erfüllt.

Anmerkung

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

Überblick

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

Überlegungen zu Architektur und Netzwerk

  • Betriebssystemunterstützung
  • Netzwerkadressräume
  • Grundlegendes zum Verkehrsfluss
  • Planen von Subnetzen
  • Anzahl der verfügbaren Eingangs-IPs
  • Benutzerdefinierte Routen und NAT-Gatewayunterstützung
  • Integration privater Netzwerke
  • Protokollabdeckung
  • Lastenausgleich
  • Dienstermittlung
  • Benutzerdefinierte Domänen und verwaltetes TLS
  • Gegenseitiges TLS
  • Netzwerkkonzepte für bestimmte Azure-Dienste

Sicherheitsüberlegungen

  • Bereitstellung von Sicherheit für den Datenverkehr innerhalb des Clusters mithilfe von Netzwerkrichtlinien
  • Netzwerksicherheitsgruppen
  • Azure Key Vault-Integration
  • Unterstützung verwalteter Identitäten
  • Bedrohungsschutz und Sicherheitsrisikobewertungen mit Defender für Container
  • Sicherheitsgrundwerte
  • Azure Well-Architected Framework für Sicherheit

Betriebliche Überlegungen

  • Updates und Patches
  • Aktualisierungen von Containerabbildungen
  • Skalierbarkeit der vertikalen Infrastruktur
  • Horizontale Infrastrukturskalierbarkeit
  • Anwendungsskalierbarkeit
  • Beobachtbarkeit
  • Well-Architected Framework für operative Exzellenz

Überlegungen zur Zuverlässigkeit

  • Vereinbarungen auf Serviceebene
  • Redundanz über Verfügbarkeitszonen
  • Gesundheitsprüfungen und Selbstheilung
  • Bereitstellungen von Anwendungen ohne Ausfallzeiten
  • Ressourcenbeschränkungen
  • Well-Architected Framework 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), Azure Container Apps und Web App für Container. Eine vollständige Liste aller Azure-Containerdienste finden Sie auf der Produktkategorieseite für Containerdienste.

Anmerkung

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.

Überlegungen zur Architektur

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 beziehen sich nicht auf Well-Architected Rahmenpfeiler. 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 Workloadkomponenten eingeschränkter, für die Windows-Container erforderlich sind.

Container Apps AKS Web App für Container
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 Netzwerk

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

  • Container-Apps ist ein PaaS-Angebot, das viele von Azure verwaltete Netzwerkfunktionen bereitstellt, z. B. Dienstermittlung, interne verwaltete Domänen und Steuerelemente für virtuelle Netzwerke.
  • AKS ist die konfigurierbarste der drei Dienste und bietet die größte Kontrolle über den Netzwerkfluss. Sie stellt z. B. benutzerdefinierte Ingress-Controller und die Steuerung des Datenverkehrs innerhalb des Clusters über Kubernetes-Netzwerkrichtlinien bereit. Workloadteams können verschiedene von Azure verwaltete Netzwerk-Add-Onsnutzen sowie Add-Ons aus dem umfassenderen 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 Netzwerkanforderungen aufweist, lesen Sie diesen Abschnitt sorgfältig, bevor Sie Ihre Azure-Containerdienstauswahl einschränken.

Netzwerkadressräume

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
Dedizierte Subnetze Verbrauchsplan: optional
Dedizierter Plan: erforderlich		 Erforderlich Wahlfrei
IP-Adressanforderungen 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 liegen außerhalb des Umfangs dieses Artikels. Weitere Informationen finden Sie unter Netzwerkkonzepte 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 Netzwerkeinschränkungen. Diese Einschränkungen wirken sich auf ihre Notwendigkeit aus, zusätzliche Subnetze bereitzustellen, je nachdem, ob Sie Folgendes benötigen:

  • Mehrere eingerichtete Workloads.
  • Privater und/oder öffentlicher Eingangseingang.
  • 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-Netzwerkgeräte für den Eingangslastenausgleich einführen, wenn Sie sowohl einen öffentlichen als auch einen privaten Eingangsvorgang benötigen. Beispiele sind Azure-Anwendungsgateway 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 Ablaufsteuerung 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.

Anmerkung

Sie können die Größe von Subnetzen, für die Ressourcen bereitgestellt wurden, nicht ändern. Achten Sie besonders darauf, wenn Sie Ihr Netzwerk planen, um zu vermeiden, dass ganze Workloadkomponenten erneut bereitgestellt werden müssen, was zu Ausfallzeiten 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-Containerdiensts gehostet werden.

Container Apps AKS Web App für Container
Anzahl der Eingangs-IPs Eins Mehrere App-Dienstumgebung: Eine
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-Dienstumgebung integriert sind, nur Datenverkehr über die einzelne Eingangs-IP empfangen, die der App-Dienstumgebung zugeordnet ist, unabhängig davon, ob sie öffentlich oder privat ist.

Benutzerdefinierte Routen und NAT-Gatewayunterstü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 Netzwerkfeatures ü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-Unterstützung Nutzungsbasierter Plan: ❌
Workload-Profil-Plan: ✅		 ✅ ✅
Unterstützung für NAT-Gateways Nutzungsbasierter Plan: ❌
Arbeitsbelastungsprofilplan: ✅		 ✅ ✅

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 Netzwerkfeatures, 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 Netzwerkfeatures sorgfältig:

Wenn Sie eine PaaS-Lösung wünschen und Netzwerkkonzepte 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, die nicht eingeschränkte Verwendung von TCP und UDP auf selbst ausgewählten Ports unterstützt.

Container Apps AKS Web App für Container
Protokoll- und Portunterstützung HTTP (Port 80)*
HTTPS (Port 443)*
TCP (Ports 1-65535, außer 80 und 443)		 TCP (beliebiger Port)
UDP (beliebiger 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.

Lastverteilung

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 für gemeinsame Verantwortung, in dem Azure die zugrunde liegende Azure-Infrastruktur verwaltet, die das Workloadteam durch Interfacing mit der Kubernetes-API konfiguriert. Für den Lastenausgleich in Layer 7 in AKS können Sie eine von Azure verwaltete Optionen auswählen, z. B. das von AKS verwalteten Anwendungsrouting-Add-On oder das Anwendungsgateway für Container, oder einen Eingangscontroller Ihrer Wahl bereitstellen und selbst verwalten.

Container Apps AKS Web App für Container
Layer-4-Lastenausgleich Von Azure verwaltet Gemeinsame Verantwortung Von Azure verwaltet
Layer-7-Lastenausgleich Von Azure verwaltet Freigegeben oder selbstverwaltet Von Azure verwaltet

Dienstentdeckung

In Cloudarchitekturen können Laufzeiten jederzeit entfernt und neu erstellt werden, um Ressourcen neu auszubalancieren, sodass sich Instanzen-IP-Adressen 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 für das Netzwerk verfügbar 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 verwaltetes TLS

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

Container Apps AKS Web App für Container
Konfigurieren von benutzerdefinierten Domänen Vorgefertigt BYO Vorgefertigt
Verwaltetes TLS für Azure-FQDNs- Vorgefertigt N/A Vorgefertigt
Verwaltetes TLS für benutzerdefinierte 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, z. B. die beliebte Cert-Manager- zum Verwalten von TLS-Zertifikaten.

Gegenseitiges TLS

Eine weitere Alternative zum Einschränken des eingehenden Datenverkehrs ist gegenseitiges TLS (mTLS). Mutual 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 Clientverbindungen. 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-Certweiter. Sie können auch problemlos automatischen mTLS für die interne Kommunikation zwischen Apps in einer einzigen Umgebung aktivieren.

Gegenseitiges TLS in AKS kann über das Istio-basiertes Dienstgitter als verwaltetes Add-On-implementiert werden, das mTLS-Funktionen für eingehende Clientverbindungen und intraclusterbasierte Kommunikation zwischen Diensten umfasst. Workload-Teams könnten auch ein anderes Service-Mesh-Angebot aus dem Kubernetes-Ökosystem installieren und verwalten. Diese Optionen machen die mTLS-Implementierung in Kubernetes zum flexibelsten.

Dienstspezifische Netzwerkkonzepte

In den vorherigen Abschnitten werden einige der häufigsten Überlegungen beschrieben, die berücksichtigt werden müssen. Weitere Details und weitere Informationen zu Netzwerkfeatures, 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 Netzwerksicherheit und das Sichern von Netzwerkdatenverkehr zu erfahren.

Sicherheitsüberlegungen

Fehler bei der Behebung von Sicherheitsrisiken können zu unbefugtem Zugriff, Datenschutzverletzungen oder Verlusten vertraulicher Informationen führen. Container bieten eine gekapselte Umgebung für Ihre Anwendung. Die Hostingsysteme und die zugrunde liegenden Netzwerküberlagerungen erfordern jedoch zusätzliche Schutzschienen. Ihre Wahl des Azure-Containerdiensts 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. Beispielsweise können Kunden lokale Konten auf den Kubernetes-API-Server deaktivieren oder automatische Updates für zugrunde liegende Knoten über Konfigurationsoptionen aktivieren.

Überprüfen Sie für einen detaillierten Vergleich sorgfältig die folgenden Überlegungen, um sicherzustellen, dass Ihre Workloadsicherheitsanforderungen 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, und Sie müssen sie schützen.

Wichtig

Beachten Sie, dass dieser Abschnitt für Web App für Container nicht relevant ist, das die Azure Resource Manager-API als Kontrollebene 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 Autorisierungsverwaltungssystem, 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-Steuerebene einschränken möchten, müssen Sie AKS verwenden, die 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 API Server VNet-Integration (Vorschau), wobei der API-Server in ein delegiertes Subnetz integriert ist. Weitere Informationen finden Sie in der Dokumentation.

Es gibt Folgen für die Implementierung des netzwerkgeschränkten Zugriffs auf die Kubernetes-API. Vor allem kann die Verwaltung nur innerhalb des privaten Netzwerks durchgeführt werden. Dies bedeutet in der Regel, dass Sie selbst gehostete 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 ist, entfernt Microsoft die zugrunde liegende Infrastruktur.

Sicherheit des Datenebenennetzwerks

Die folgenden Netzwerkfeatures 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 Netzwerkrichtlinienimplementieren, eine cloudeigene Technologie, die eine granulare Konfiguration von Layer 4-Netzwerken in Kubernetes-Clustern ermöglicht.

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

Von den drei in diesem Artikel beschriebenen Azure-Diensten ist AKS die einzige, die eine weitere Workloadisolation 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 Netzwerkkommunikation innerhalb des breiteren virtuellen Netzwerks mithilfe von Netzwerksicherheitsgruppen regeln, sodass Sie Layer 4-Datenverkehrsregeln verwenden können, die den Eingangs- und Ausgang auf der Ebene des virtuellen Netzwerks regeln.

Container-Anwendungen AKS Web App für Container
Netzwerksicherheitsgruppen Verbrauchsplan: ✅
Dedizierter Plan: ✅		 ✅ ✅ VNet-integrierte Apps: ausschließlich ausgehend

IP-Einschränkungen für eingehenden Datenverkehr

In der Regel werden Einschränkungen für den Netzwerkdatenverkehr über oben beschriebene Layer 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-Apps für Container bieten integrierte Quell-IP-Beschränkungen für eingehenden Datenverkehr für einzelne Anwendungen.

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

Bei AKS-Workloads hängt die Implementierung vom ausgewählten Eingangscontroller 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-Computedienst 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

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

Container Apps AKS Web App für Container
Unterstützung für verwaltete Identität ✅ ✅ ✅

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. Sicherheitsrisikenbewertungen werden in Azure-Containerregistrierungen unterstützt, sodass sie von jedem Azure-Containerdienst verwendet werden können, nicht nur die in diesem Artikel beschriebenen. Defender für Container-Runtime-Schutz ist jedoch nur für AKS verfügbar.

Da AKS die systemeigene Kubernetes-API verfügbar macht, kann die Clustersicherheit auch mit Kubernetes-spezifischen Sicherheitstools aus dem Kubernetes-Ökosystem ausgewertet werden.

Containeranwendungen 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 Sicherheitsrisikobewertungen für Containerimages keine Echtzeitüberprüfungen sind. Die Azure-Containerregistrierung wird in regelmäßigen Abständen gescannt.

Sicherheitsgrundwerte

Im Allgemeinen integrieren die meisten Azure-Containerdienste 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 Sicherheitsgrundwerte decken andere Azure-Integrationen ab, einschließlich Hardwareverschlüsselung und Protokollierung, die außerhalb des Umfangs dieses Artikels liegen.

Well-Architected Framework für Sicherheit

Dieser Artikel konzentriert sich auf die wichtigsten Unterschiede zwischen den hier beschriebenen Containerdienstfeatures.

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

Betriebliche Überlegungen

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

Updates und Patches

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

Als verwalteter Kubernetes-Dienst stellt AKS die aktualisierten Images für das Knotenbetriebssystem und die Steuerungsebenenkomponenten bereit. Arbeitsauslastungsteams 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-Upgradeverwaltung vermeiden können.

Container Apps AKS Web App für Container
Aktualisierungen der Steuerungsebene Plattform Kunde Plattform
Hostupdates und Patches Plattform Kunde Plattform
Container-Image-Updates und Patches Kunde Kunde Kunde

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 für Container 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 zu entfernen, um Geld zu sparen. Wenn Sie eine Containerlösung auswählen, müssen Sie Infrastruktureinschränkungen und Skalierungsstrategien berücksichtigen.

Skalierbarkeit der vertikalen Infrastruktur

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 Computeressourcen erforderlich. Wenn Sie eine Azure-Containerlösung auswählen, müssen Sie die Hardware-SKU-Angebote kennen, die für einen bestimmten Azure-Dienst verfügbar sind. Sie variieren und können zusätzliche Einschränkungen auferlegen.

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 Infrastrukturskalierbarkeit

Horizontale Skalierung bezieht sich auf die Fähigkeit, die Kapazität über 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-Containerdienste 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		 Konfigurierbar Konfigurierbar
Flexible Hardware-Provisionierung Verbrauchsplan: N/A
Dedizierter Plan: abstrahiert mit Workloadprofilen		 Jede VM-SKU Abstrahiert. Der App Service-Plan.

Wichtig

Die Hardwarebereitstellungsoptionen, die über den Dedizierten Plan für Container-Apps (Workloadprofile) 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 sind.

Anwendungsskalierbarkeit

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. Web App für Container basiert auf den Skalierbarkeitsoptionen von Azure. (Siehe die folgende Tabelle.) Web App für Container unterstützt keine benutzerdefinierten Skalierungskonfigurationen 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)
ereignisgesteuerte Skalierbarkeit Ja. Cloudnativer Dienst. Ja. Cloudnativer Dienst. Zusätzliche Konfiguration erforderlich. Ja. Azure-ressourcenspezifisch.

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. Es sind keine Codeänderungen 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 plattform ❌ ❌ Teilweise Unterstützung*
Automatische Instrumentierung über Agent- ❌ Teilweise Unterstützung* N/A
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 den 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-Containerdienste bieten Anwendungs- und Plattformprotokollfunktionen. Anwendungsprotokolle sind Konsolenprotokolle, die von Ihrer Workload generiert werden. Plattformprotokolle Erfassen von Ereignissen, die auf Plattformebene auftreten, außerhalb des Bereichs Ihrer Anwendung, z. B. Skalierung und Bereitstellungen.

Die wichtigsten Unterschiede zwischen den Protokollierungsfunktionen für Containerdienste beziehen sich auf die Plattformprotokollierung: Was protokolliert wird und wie Protokolle intern organisiert werden. Azure Monitor ist der hauptprotokollierungsdienst in Azure, der in diese Dienste integriert ist. Monitor verwendet Ressourcenprotokolle, um Protokolle, die aus verschiedenen Quellen stammen, in Kategorien zu trennen. 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 Container
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-Clienttools für das Protokollstreaming wie kubectl erhalten.
  • Web App für Container bietet viele Kategorien von Ressourcenprotokollen, da ihre Plattform (App Service) nicht ausschließlich für Container-Workloads verwendet wird. 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.

Well-Architected Framework für operative Exzellenz

Dieser Artikel konzentriert sich auf die wichtigsten Unterschiede zwischen den hier beschriebenen Containerdienstfeatures. Lesen Sie die folgenden Artikel, um die vollständigen Operational Excellence-Anleitungen für die folgenden Dienste zu überprüfen:

Zuverlässigkeit

Zuverlässigkeit bezieht sich auf die Fähigkeit eines Systems, auf Fehler zu reagieren und voll funktionsfähig zu bleiben. Auf Anwendungssoftwareebene sollten Workloads bewährte Methoden wie Zwischenspeichern, Wiederholen, Schaltkreistrennmuster und Integritätsprüfungen implementieren. Auf Infrastrukturebene ist Azure für die Behandlung von physischen Fehlern wie Hardwareausfällen und Stromausfällen in Rechenzentren verantwortlich. Fehler können weiterhin auftreten. Workloadteams 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 auf Serviceebene (Service Level Agreements, SLAs) und Verfügbarkeitszonen funktionieren.

Vereinbarungen auf Serviceebene

Zuverlässigkeit wird häufig durch geschäftsgesteuerten 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.

Für die neuesten SLAs und Details laden 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, wodurch sie kostenwirksame Entscheidungen für Nicht-Produktionsumgebungen treffen. Für Produktionsumgebungen ist es jedoch eine bewährte Methode, eine kostenpflichtige Stufe 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 unterschiedliche Rechenzentren, die unabhängige elektrische Energie, Kühlung usw. innerhalb einer region aufweisen. 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/jeder Region, 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.

Merkmal 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 verfügbar, wenn ein Problem in der Verfügbarkeitszone auftritt, in der die Hardware gehostet wird. Um die Unterstützung der Verfügbarkeitszone vollständig zu verwenden, sollten Sie Workloads mit einer Mindestkonfiguration von drei Instanzen des Containers bereitstellen, die sich über Zonen erstrecken.

Gesundheitschecks 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 Hostingplattform tut und wie, wenn Fehler auftreten.

Um unter den Arten von Gesundheitssonden besser zu unterscheiden, sehen Sie sich die integrierten Typen von Probes von Kubernetesan:

  • 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 ✅ ✅ Teilweise 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 Aspekte:

  • Die Starttests sind integriert und können nicht geändert werden. Sie sendet eine HTTP-Anforderung an den Startport Ihres Containers. Jede Antwort ihrer Anwendung gilt als erfolgreicher Start.
  • Es unterstützt keine Bereitschaftstest. Wenn die Startsonde 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 das 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 diese Einstellung beträgt 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.

Automatisches Heilen

Eine ungültige Container-Instanz zu identifizieren und keinen Datenverkehr mehr an sie zu senden, ist ein Anfang. Der nächste Schritt besteht darin, die automatische Heilung zu implementieren. 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 die Liveness-Probe den definierten Fehlerschwellenwert erreicht.

Bereitstellungen von Anwendungen ohne Ausfallzeiten

Die Möglichkeit, Anwendungen bereitzustellen und zu ersetzen, ohne ausfallzeiten für Benutzer zu verursachen, ist für eine zuverlässige Arbeitsauslastung von entscheidender Bedeutung. Alle drei containerdienste, die in diesem Artikel beschrieben werden, unterstützen Bereitstellungen ohne Ausfallzeiten, 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

Beachten Sie, dass die Anwendungsarchitekturen auch die Bereitstellung ohne Ausfallzeiten unterstützen müssen. Siehe Azure Well-Architected Framework für Anleitungen.

Ressourcenbeschrä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
Ressourcenbeschränkungen (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 eine der Apps nicht 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 Speicherbeschrä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 z. B. keine vCPU- und 1 GiB-Speicher konfigurieren, aber Sie können eine vCPU- und 2 GiB-Speicher 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 der Namespaceebene einschränken, wenn Sie Ihren Cluster auf diese Weise segmentieren möchten.

Well-Architected Framework für Zuverlässigkeit

Dieser Artikel konzentriert sich auf die wichtigsten Unterschiede 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:

Schlussfolgerung

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 entsteht beim Vergleichen von Azure-Containerdiensten ein Muster: AKS enthüllt die zugrunde liegende Infrastruktur am stärksten und bietet daher die größtmögliche Konfigurierbarkeit und Erweiterbarkeit. Der Aufwand und die Komplexität des Betriebs sind für AKS-Workloads sehr variabel. Einige Teams können den Betriebsaufwand erheblich reduzieren, indem von Microsoft verwaltete Add-Ons und Erweiterungen sowie Features für automatische Upgrades verwendet werden. Andere Kunden bevorzugen die volle Kontrolle über den Cluster, um die vollständige Erweiterbarkeit von Kubernetes und dem CNCF-Ökosystem zu nutzen. Obwohl Microsoft Flux beispielsweise als verwaltete GitOps-Erweiterung anbietet, entscheiden sich viele Teams stattdessen dafür, ArgoCD selbst einzurichten und zu betreiben.

Arbeitsauslastungsteams, die z. B. keine CNCF-Anwendungen erfordern, weniger Betriebserfahrung haben oder sich lieber auf Anwendungsfeatures konzentrieren möchten, bevorzugen möglicherweise ein PaaS-Angebot. Es wird empfohlen, container-Apps zuerst 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 verwaltet. Sie wurde ursprünglich von den folgenden Mitwirkenden verfasst.

Hauptautoren:

Andere Mitwirkende:

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

Nächste Schritte