Wählen Sie einen Azure-Containerdienst

Azure bietet eine Reihe von Container-Hosting-Diensten, die für verschiedene Arbeitslasten, Architekturen und Geschäftsanforderungen ausgelegt sind. Dieser Leitfaden zur Auswahl des Containerdiensts kann Ihnen helfen, zu verstehen, welcher Azure-Containerdienst am besten für Ihre Arbeitslastzenarien und Anforderungen geeignet ist.

Verwendung dieses Leitfadens

Dieses Handbuch enthält zwei Artikel: diesen Einführungsartikel und einen weiteren Artikel zu für alle Workloadtypen freigegeben Übelegungen werden.

In diesem Einführungsartikel werden die Azure-Containerdienste beschrieben, die Gegenstand dieses Leitfadens sind, und es wird erläutert, wie die Servicemodelle im Hinblick auf Kompromisse zwischen Konfigurierbarkeit und meinungsbildenden Lösungen, wie z. B. von Kunden verwaltete gegenüber von Microsoft verwaltete Ansätze, verglichen werden. Nachdem Sie Kandidatendienste basierend auf Ihren Dienstmodelleinstellungen identifiziert haben, besteht der nächste Schritt darin, die Optionen für Ihre Workloadanforderungen zu bewerten, indem Sie den Artikel zu gemeinsamen Überlegungen zu Netzwerken, Sicherheit, Vorgängen und Zuverlässigkeit überprüfen.

Dieser Leitfaden berücksichtigt die Kompromisse, die Sie je nach den technischen Anforderungen, dem Umfang und der Komplexität Ihres Workloads und dem Fachwissen Ihres Workload-Teams möglicherweise eingehen müssen.

Azure-Containerdienste, die in diesem Leitfaden behandelt werden

Dieser Leitfaden konzentriert sich auf eine Teilmenge der Containerdienste, die Azure derzeit anbietet. Diese Teilmenge bietet einen ausgereiften Featuresatz für Webanwendungen und APIs, Netzwerk, Observability, Entwicklertools und -vorgänge. Folgende Containerdienste werden verglichen:

Eine vollständige Liste aller Azure-Containerdienste finden Sie auf der Produktkategorieseite für Containerdienste.

Überlegungen zum Dienstleistungsmodell

Das Dienstleistungsmodell bietet den größtmöglichen Einblick in die Flexibilität und Kontrolle, die jeder Azure-Containerdienst bietet, im Austausch für die allgemeine Einfachheit und Benutzerfreundlichkeit.

Eine allgemeine Einführung in die Terminologie und Konzepte rund um Dienstmodelle, einschließlich Infrastruktur as a Service (IaaS) und Plattform as a Service (PaaS), finden Sie unter Gemeinsame Verantwortung in der Cloud.

Vergleich der Dienstleistungsmodell von Azure-Containerlösungen

AKS

Als Hybrid von IaaS und PaaS priorisiert AKS die Kontrolle über die Einfachheit. Obwohl AKS die Verwaltung der zugrunde liegenden Kerninfrastruktur optimiert, ist diese VM-basierte Plattform weiterhin für Ihre Anwendungen verfügbar und erfordert geeignete Schutzläufe und Prozesse, z. B. Patching, um Sicherheit und Geschäftskontinuität sicherzustellen. Die Computeinfrastruktur wird von zusätzlichen Azure-Ressourcen unterstützt, die direkt in Ihrem Abonnement gehostet werden, z. B. Azure-Lastenausgleichsgeräte.

AKS bietet auch Zugriff auf den Kubernetes-API-Server, mit dem Sie die Container-Orchestrierung anpassen und damit Projekte von der Cloud Native Computing Foundation (CNCF) bereitstellen können. Daher gibt es eine signifikante Lernkurve für Workload-Teams, die für Kubernetes neu sind. Wenn Sie mit containerisierten Lösungen noch nicht fertig sind, kann diese Lernkurve abschreckend sein. Die folgenden PaaS-Lösungen bieten eine niedrigere Einstiegsbarriere. Sie können zu Kubernetes wechseln, wenn Ihre Anforderungen die Verschiebung diktieren.

Azure Container Apps

Container Apps, ein PaaS-Angebot, bietet ein Gleichgewicht zwischen Kontrolle und Einfachheit. Es bietet sowohl serverlose als auch dedizierte Computeoptionen, die die Notwendigkeit abstrahieren, das Betriebssystem zu patchen oder Leitplanken um Anwendungen zu erstellen, relativ zum Betriebssystem. Container-Apps abstrahiert auch die Container-Orchestrierungs-API vollständig und stellt eine Teilmenge ihrer Schlüsselfunktionen über Azure-APIs bereit, mit denen Ihr Team möglicherweise bereits vertraut ist. Darüber hinaus sind Layer 7-Eingangs-, Datenverkehrsteilungen, A/B-Tests und Anwendungslebenszyklusverwaltung vollständig einsatzbereit.

Web App für Containers

Web App für Container ist auch ein PaaS-Angebot, bietet aber mehr Einfachheit und weniger Kontrolle als Container-Apps. Es abstrahiert von der Container-Orchestrierung, bietet aber dennoch eine angemessene Skalierung, Verwaltung des Anwendungslebenszyklus, Aufteilung des Datenverkehrs, Netzwerkintegration und Beobachtbarkeit.

Überlegungen zum Hostingmodell

Sie können Azure-Ressourcen wie AKS-Cluster verwenden, um mehrere Workloads zu hosten. Auf diese Weise können Sie Vorgänge optimieren und dadurch die Gesamtkosten reduzieren. Wenn Sie diesen Pfad auswählen, sind hier einige wichtige Überlegungen aufgeführt:

• AKS wird häufig zum Hosten mehrerer Workloads oder unterschiedlicher Workloadkomponenten verwendet. Sie können diese Workloads und Komponenten isolieren, indem Sie systemeigene Kubernetes-Funktionen wie Namespaces, Zugriffssteuerungen und Netzwerksteuerelemente verwenden, um die Sicherheitsanforderungen zu erfüllen.

  Sie können AKS auch in Szenarien mit einzelner Arbeitsauslastung verwenden, wenn Sie die zusätzlichen Funktionen benötigen, die die Kubernetes-API bereitstellt, und Ihr Workloadteam verfügt über genügend Erfahrung, um einen Kubernetes-Cluster zu betreiben. Teams mit weniger Kubernetes-Erfahrung können weiterhin ihre eigenen Cluster erfolgreich betreiben, indem sie von den von Azure verwalteten Add-Ons und Features wie dem automatischen Clusterupgrade profitieren, um den operationellen Mehraufwand zu reduzieren.

• Container-Apps sollten verwendet werden, um eine einzelne Workload mit einer gemeinsamen Sicherheitsgrenze zu hosten. Container-Apps verfügen über eine einzige logische Grenze auf oberster Ebene, die als Container-Apps-Umgebung bezeichnet wird, die auch als erweiterte Sicherheitsgrenze dient. Es gibt keine Mechanismen für eine zusätzliche granulare Zugriffssteuerung. Beispielsweise ist die Kommunikation innerhalb der Umgebung uneingeschränkt, und alle Anwendungen teilen einen einzigen Log Analytics-Arbeitsbereich.

  Wenn die Workload über mehrere Komponenten und mehrere Sicherheitsgrenzen verfügt, stellen Sie mehrere Container-Apps-Umgebungen bereit, oder erwägen Sie stattdessen AKS.

• Web App für Container ist ein Feature von App Service. App Service gruppiert Anwendungen in einer Abrechnungsgrenze, die als App Service-Plan. bezeichnet wird. Da Sie rollenbasierte Zugriffssteuerung (RBAC) auf Anwendungsebene festlegen können, ist es möglicherweise verlockend, mehrere Workloads in einem einzigen Plan zu hosten. Es wird jedoch empfohlen, eine einzelne Workload pro Plan zu hosten, um das Problem "Lauter Nachbar" zu vermeiden. Alle Apps in einem einzelnen App Service-Plan verwenden den gleichen zugewiesenen Compute, Arbeitsspeicher und Speicher.

  Wenn Sie die Hardwareisolation in Betracht ziehen, müssen Sie beachten, dass App Service-Pläne in der Regel auf der Infrastruktur ausgeführt werden, die für andere Azure-Kunden freigegeben ist. Sie können dedizierte Ebenen für dedizierte VMs oder isolierte Ebenen für dedizierte virtuelle Computer in einem dedizierten virtuellen Netzwerk auswählen.

Im Allgemeinen können alle Azure-Containerdienste mehrere Anwendungen hosten, die über mehrere Komponenten verfügen. Container-Apps und Web App für Container eignen sich jedoch besser für eine Komponente mit einer Arbeitsauslastung oder mehrere hoch verwandte Workloadkomponenten, die einen ähnlichen Lebenszyklus gemeinsam nutzen, wobei ein einzelnes Team die Anwendungen besitzt und ausführt.

Wenn Sie nicht zusammenhängende Anwendungskomponenten oder Workloads auf einem Host hosten müssen, sollten Sie AKS in Betracht ziehen.

Der Kompromiss zwischen Kontrolle und Benutzerfreundlichkeit

AKS bietet die beste Konfigurierbarkeit, aber diese Konfigurierbarkeit geht im Vergleich zu den anderen Diensten auf Kosten eines erhöhten operationellen Mehraufwands. Obwohl Container Apps und Web App for Containers beides PaaS-Dienste sind, die ein ähnliches Maß an von Microsoft verwalteten Funktionen aufweisen, legt Web App for Containers den Schwerpunkt auf Einfachheit, um seine Zielgruppe anzusprechen: bestehende Azure PaaS-Kunden, denen die Schnittstelle vertraut ist.

Faustformel

Im Allgemeinen sind Dienste, die mehr Einfachheit bieten, für Kunden geeignet, die sich lieber auf die Featureentwicklung und weniger auf die Infrastruktur konzentrieren möchten. Dienste, die mehr Kontrolle bieten, eignen sich in der Regel für Kunden, die mehr Konfigurierbarkeit benötigen und über die notwendigen Fähigkeiten, Ressourcen und geschäftlichen Rechtfertigungen verfügen, um ihre eigene Infrastruktur zu verwalten.

Gemeinsame Überlegungen für alle Workloads

Obwohl ein Workloadteam möglicherweise ein bestimmtes Dienstleistungsmodell bevorzugt, erfüllt dieses Modell möglicherweise nicht die Anforderungen der Gesamten Organisation. So bevorzugen Entwickler vielleicht einen geringeren operationellen Mehraufwand, während Sicherheitsteams diese Art von Aufwand als notwendig erachten, um die Compliance-Anforderungen zu erfüllen. Teams müssen zusammenarbeiten, um die entsprechenden Kompromisse zu erzielen.

Beachten Sie, dass gemeinsame Überlegungen allgemein sind. Je nach Workloadtyp, aber auch ihrer Rolle innerhalb der Organisation kann nur eine Teilmenge für Sie relevant sein.

Die folgende Tabelle enthält eine allgemeine Übersicht über Überlegungen, einschließlich Dienstfeaturevergleiche. Überprüfen Sie die Überlegungen in jeder Kategorie, und vergleichen Sie sie mit den Anforderungen Ihrer Workload.

Nachdem Sie die vorstehenden Überlegungen überprüft haben, haben Sie möglicherweise noch nicht die perfekte Passform gefunden. Das ist vollkommen normal.

Kompromisse abwägen

Die Auswahl eines Clouddiensts ist keine einfache Übung. Angesichts der Komplexität von Cloud Computing, der Zusammenarbeit zwischen vielen Teams und Ressourceneinschränkungen mit Personen, Budgets und Zeit hat jede Lösung Nachteile.

Beachten Sie, dass für jede bestimmte Workload einige Anforderungen möglicherweise kritischer sind als andere. Ein Anwendungsteam bevorzugt z. B. eine PaaS-Lösung wie Container-Apps, wählt jedoch AKS aus, da sein Sicherheitsteam standardmäßige Netzwerksteuerelemente zwischen komponenten für die verlagerte Workload erfordert, bei dem es sich um ein Nur-AKS-Feature handelt, das Kubernetes-Netzwerkrichtlinien verwendet.

Beachten Sie schließlich, dass die vorherigen gemeinsamen Überlegungen die häufigsten Anforderungen enthalten, aber nicht umfassend sind. Es liegt in der Verantwortung des Workloadteams, jede Anforderung anhand des Featuresatzes des bevorzugten Diensts zu untersuchen, bevor eine Entscheidung bestätigt wird.

Zusammenfassung

In diesem Handbuch werden die häufigsten Überlegungen beschrieben, denen Sie beim Auswählen eines Azure-Containerdiensts begegnen. Es wurde entwickelt, um Workload- Teams bei fundierten Entscheidungen zu leiten. Der Prozess beginnt mit der Auswahl eines Clouddienstmodells, bei dem die gewünschte Steuerungsebene bestimmt wird. Die Kontrolle geht auf Kosten der Einfachheit. Mit anderen Worten, es ist ein Prozess der Suche nach dem richtigen Gleichgewicht zwischen einer selbstverwalteten Infrastruktur und einer, die von Microsoft verwaltet wird.

Viele Workload- Teams können einen Azure-Containerdienst ausschließlich basierend auf dem bevorzugten Dienstmodell auswählen: PaaS im Vergleich zu IaaS. Andere Teams müssen weiter untersuchen, um zu ermitteln, wie dienstspezifische Features Workload oder Organisationsanforderungen erfüllen.

Alle Workload- Teams sollten diesen Leitfaden zusätzlich zur Einbeziehung von Due Diligence verwenden, um schwierig zu rückgängig zu machende Entscheidungen zu vermeiden. Beachten Sie jedoch, dass die Entscheidung erst bestätigt wird, wenn Entwickler den Dienst ausprobieren und basierend auf Erfahrung und Theorie entscheiden.

Beitragende

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

Hauptautoren:

• Andre Dewes | Leitender Kundenberater
• Marcos Martinez | Leitender Servicetechniker
• Julie Ng | Leitende Servicetechnikerin

Andere Mitwirkende:

• Mick Alberts | Technical Writer
• Martin Gjoshevski | Leitender Kundenberater
• Don High | Principal Customer Engineer
• Nelly Kiboi | Servicetechniker
• Xuhong Liu | Leitender Servicetechniker
• Faisal Mustafa | Leitender Kundenberater
• Walter Myers | Principal Customer Engineering Manager
• Sonalika Roy | Leitende Ingenieurin
• Paolo Salvatori | Principal Customer Engineer
• Victor Santana | Principal Customer Engineering

Nächster Schritt

Erfahren Sie mehr über gemeinsame architektonische Überlegungen für die Dienste, die in diesem Artikel Erwähnung.