Kubernetes ist in Sachen Anwendungsentwicklung nicht mehr wegzudenken und Unternehmen stehen vor der Notwendigkeit, diese Technologie zu adaptieren. Allerdings haben viele Firmen nicht die Ressourcen und das Know-how, um Kubernetes selbst zu betreiben. Gemanagte Kubernetes-Umgebungen wie Google Kubernetes Engine (GKE), Azure Kubernetes Service (AKS) oder Elastic Kubernetes Service (EKS) erleichtern den Betrieb. Diese Dienste übernehmen viele Betriebsaufgaben wie zum Beispiel die Installation der Kubernetes-Umgebung und automatisieren das Patching, die Wiederherstellung bei Knotenausfällen und das Skalieren der Kubernetes-Cluster.

IT-Verantwortliche sehen sich aber dennoch vielen Herausforderungen gegenüber. Denn für den produktiven Einsatz sind häufig noch diverse weitere Tools wie etwa Service Mesh, Monitoring- und Logging-Werkzeuge, Security-Anwendungen, Devops-Werkzeuge et cetera erforderlich. Rund um Kubernetes hat sich ein komplexes Ökosystem an Tools angesiedelt, das sich in der Landkarte der Cloud Native Computing Foundation (CNCF) widerspiegelt [1]. Die CNCF ist eine von allen großen Herstellern unterstützte Initiative zur Förderung von cloudnativen Technologien, die eine Vielzahl von Open-Source-Produkten beinhalten. Aufgrund der hohen Dynamik innerhalb des Ökosystems rund um Kubernetes ist es für IT-Verantwortliche schwierig, den Überblick zu behalten.

Mit Azure Container Apps (ACA) adressiert Microsoft diese Problemstellung, indem es IT-Verantwortlichen einen abstrahierten, auf Azure Kubernetes Service (AKS) aufbauenden PaaS-Dienst bereitstellt. Im Gegensatz zu AKS ist Azure Container App serverless, das heißt, der Kunde bekommt die darunterliegenden virtuellen Maschinen beziehungsweise die AKS-Infrastruktur, auf denen die Container laufen, nicht zu Gesicht und muss sich auch nicht um diese kümmern. Laut Microsoft existieren mehrere Szenarien, für die Azure Container Apps besonders geeignet sind: der Betrieb von Microservices, die ereignisgesteuerte Verarbeitung (event-driven processing), containerbasierte Webapplikationen und Backend-Applikationen sowie für das Hosting von Public-API-Endpoints.

Herauszustellen ist die Einfachheit, mit der sich die Anwendungen in ACA ausrollen lassen. Eine Einschränkung bei Container-Apps sind allerdings die Ressourcen, die Sie Containern zuweisen können. So sind aktuell Container nur mit bis zu zwei Cores und 4 GByte RAM möglich. Dies bedeutet, dass Sie größere Anwendungen, sofern möglich, auf mehrere Container-Instanzen verteilen müssen. Diese können Sie aber durch Autoscaling bequem hoch- und runterskalieren. Außerdem können Sie aktuell nicht zwischen verschiedenen Hardwarekonfigurationen wählen, so gibt es beispielswiese keine GPU-Unterstützung. Zudem sollten Sie den hohen IP-Adressbedarf beim Betrieb von ACA im eigenen VNET (es wird ein /23-Subnetz pro Container-App-Environment benötigt) im Blick behalten, insbesondere dann, wenn Sie aus Isolationsgründen mehrere Environments betreiben.

Die ACA-Infrastruktur bringt Tools aus dem CNCF-Ökosystem mit, dazu gehören Envoy, Kubernetes Event Driven Autoscaling (KEDA) und Distributed Application Runtime (Dapr). Diese Tools helfen bei typischen Herausforderungen im Betrieb von containerisierten Anwendungen. So ist Envoy beispielsweise ein HTTP-Proxy, den Azure Container Apps als Ingress, aber auch für die SSL-Terminierung sowie für Traffic-Splitting einsetzt.

KEDA geht über den in Kubernetes bereits mitgelieferten Autoskalierungsansatz "Horizontal Pod Autoscaler" hinaus, indem sich neben dem Skalieren auf Basis der CPU- und Memory-Auslastung noch beliebige externe Metriken einbinden lassen. Ein häufiger Anwendungsfall ist das Anpassen von Jobservern auf Basis der Anzahl aktueller Job-Requests beziehungsweise Nachrichten, die in einer externen Queue zwischengespeichert sind. KEDA erlaubt zudem, die containerisierte Anwendung auf null Container-Instanzen herunterzufahren. Das reduziert die Kosten, wenn aktuell keine Last anliegt. Greift der Benutzer in diesem Moment, wenn gerade keine Containerinstanzen laufen, auf die Anwendung zu, muss er jedoch beim Aufbau der Seite mit leicht erhöhten Wartezeiten rechnen, bis wieder eine Instanz anläuft.

Dapr unterstützt Entwickler beim Betrieb von verteilten, auf Microservices basierten Anwendungen. Die Runtime nimmt dem Entwickler typische Aufgaben ab, um die er sich nicht unbedingt selbst kümmern möchte. Dazu zählen etwa die sichere Kommunikation der einzelnen Microservices über mTLS oder auch der Austausch von Nachrichten zwischen Microservices über die Pub/Sub-API von Dapr. Des Weiteren erleichtert das Tool auch das Anwendungsmonitoring durch Distributed Tracing, ohne dass der Programmierer die Anwendung entsprechend instrumentieren muss. Es ist allerdings nicht notwendig, Dapr für alle Container-Apps zu aktivieren, es funktioniert auch für einzelne Microservices.

Azure Container Apps ist zwar wesentlich einfacher zu verwalten als sein großer Bruder Azure Kubernetes Service (AKS), unter der Haube basiert der Dienst dennoch auf AKS. Für IT-Verantwortliche ist das nicht direkt sichtbar. Stattdessen bringt ACA eine Reihe von Komponenten mit, die eine Abstraktionsschicht darstellen, um Container sicher zu betreiben.

Die grundlegende Ausführungsumgebung für Container-Apps sind Environments – vergleichbar am ehesten mit eigenständigen Kubernetes-Clustern. Ein Environment spannt außerdem ein virtuelles Netzwerk (VNET) auf, innerhalb dessen sich verschiedene Container-Apps betreiben lassen. Sollten Sie höhere Anforderungen hinsichtlich der Isolation zwischen verschiedenen Container-Apps haben, empfiehlt es sich, mit verschiedenen ontainer-App-Environments zu arbeiten.

Des Weiteren können Sie wählen, ob Sie ein Container-App-Environment in einem von Microsoft gemanagten oder in einem vom Ihnen betriebenen VNET aufsetzen. Letzteres ist beispielsweise dann zu empfehlen, wenn die Konnektivität zu anderen, nicht in Container-Apps gehosteten Diensten wie Datenbanken notwendig ist. Außerdem gilt es zu berücksichtigen, dass Azure als Minimalanforderung beim Betrieb im eigenen VNET ein Subnetz der Größe "/23" verlangt, das heißt, es sind 512 IP-Adressen pro Environment notwendig.

Eine Container-App repräsentiert eine Anwendung beziehungsweise einen Microservice, bestehend aus einem oder mehreren Containern, die sich die gleichen Storage- sowie Netzwerkressourcen teilen und demselben Lebenszyklus unterliegen (ähnlich einem Pod in Kubernetes). Die Nutzung von mehreren Containern innerhalb einer Container-App erlaubt, dass neben dem Haupt-Container noch ein Sidecar-Container deployed wird.

Während der Haupt-Container die Business-Logik ausführt, kommt der Sidecar-Container für unterstützende Funktionen zum Einsatz. Dies können das zusätzliche Deployment eines Logging-Agenten oder auch Netzwerkfunktionen sein. Dieser Ansatz dient zum Beispiel bei der in Container Apps integrierten DAPR Runtime dazu, bestimmte Kommunikations- sowie Monitoringaufgaben für Microservices in einen separaten Container auszulagern.

Eine bestimmte Version einer ACA-Applikation wird als Revision abgebildet, ähnlich einem "Deployment" im Kubernetes-Umfeld. So unterstützen Revisionen auch Replicas, falls nicht nur eine einzelne Instanz einer Container-Anwendung laufen soll. Die Anzahl der Replicas innerhalb von Azure Container Apps ist über Autoscaling anpassbar, was typischerweise auf Basis einer Metrik erfolgt. Aktuell unterstützt ACA die Anzahl der simultanen HTTP- oder TCP-Requests, die CPU- oder Arbeitsspeicherauslastung der Container sowie weitere eventbasierte Schwellenwerte wie die Anzahl der Messages in einer Queue oder in einem Messaging-Dienst wie Azure Service Bus, Azure Event Hubs, Apache Kafka oder Redis. Durch die Integration von KEDA lassen sich aber auch eine Vielzahl von externen Diensten als Skalierungsquelle einsetzen.

Im Folgenden wollen wir die wesentlichen Schritte beim Aufbau einer Container-App aufzeigen. Zuallererst benötigen Sie ein Container-Apps-Environment, in dem später die eigentliche Anwendung läuft. Dieses legen Sie in der CLI über den folgenden Befehl an:

Dabei müssen Sie mehrere Parameter angeben: den Namen des Container App Environments (im Beispiel "it-administrator-env"), eine Ressourcengruppe ("it- administrator-rg"), in die das Environment angelegt wird, sowie die Azure-Region ("westeurope"). In dem neu erstellten ACA-Environment rollen Sie nun die eigentliche Anwendung aus:

In diesem Fall erstellen wir eine Container-App mit dem Namen "it-admin-web" in der gleichen Resosurcengruppe, in der wir auch das Environment erstellt haben. Als Container-Image dient ein Nginx-basiertes Webserver-Abbild ("it-admin-acr.azurecr.io/it-admin-nginx:v1.0"), das in einer eigenen Azure-Container-Registry ("it-admin-acr.azurecr.io") liegt. Dies setzt allerdings voraus, dass eine solche Registry bereits vorhanden ist.

Über eine Container-Registry lassen sich Images zentral verwalten und verteilen. Das wohl bekannteste Beispiel dafür ist Docker Hub, eine öffentlich zugängliche Registry, die über 100.000 Images enthält. Unternehmen setzen in der Regel aber auf private Registries, in denen sie ihre Container-Images sicher ablegen und mit entsprechenden Zugriffskontrollen versehen. Mit Azure Container Registry bietet Microsoft einen Dienst, mit dem Sie eigene Registrierungen erstellen können.

Im obigen Codebeispiel benutzen wir eine private Registry namens "it-admin-acr.azurecr.io", in der das Image "it-admin-nginx" mit dem Tag "v1.0" lagert. Um dies nachzustellen, müssen Sie sich eine eigene Registry vorab ablegen und dort ein entsprechendes Container-Image hochladen. Da die Container-App einen Webserver auf Basis Nginx hosten soll, der von außen erreichbar ist, legen Sie gleich ein Ingress vom Typ "External" mit an. Als Target-Port verwenden Sie Port 80/HTTP. Hier ist zu beachten, dass dies der Port ist, auf dem der Container intern horcht – von außen ist die Container-App trotzdem über Port 443 erreichbar. Sie müssen dazu keinen Ingress beziehungsweise keinen Ingress-Controller bereitstellen, wie dies bei Kubernetes der Fall ist, sondern diese Funktionalität deckt bereits der Envoy-Proxy ab. Eine Einschränkung besteht darin, dass Sie aktuell nur einen Port nach außen freigeben können. Möchten Sie eine eigene Custom-Domain verwenden, gilt es noch, ein valides SSL-Zertifikat bereizutstellen. Mit dem Parameter "--query" fragen Sie den FQDN der neu erstellen App ab.

Für eine neue Container-App-Instanz wird automatisch eine Revision erstellt, also eine unveränderbare (immutable) Version. Treten bestimmte revisionsbezogene Änderungen an der Container-App wie zum Beispiel eine Änderung des Images auf, erstellt das System automatisch eine neue Revision. Diese lassen sich aber nicht nur als Versionierungsansatz nutzen, sondern auch als Deployment-Mechanismus. Dies ermöglicht A-B-Testing, bei dem der Traffic auf verschiedene Revisions aufgeteilt wird. Einen ähnlichen Ansatz stellt das Blue-Green-Testing dar, bei dem sich der Traffic auf die alte Revision graduell verringert beziehungsweise auf der neuen graduell erhöht (Bild 1). Damit ist das Ausrollen neuer Versionen einer Applikation ohne Downtime machbar.

Das Erstellen einer neuen Revision gestaltet sich sehr leicht. Sie müssen den Namen des Container-Images sowie dessen Tags sowie die vorgesehenen Ressourcen für eine Instanz des Containers angeben. Den Containern einer einzelnen Container-App können Sie maximal zwei Cores und 4 GByte Memory zuweisen. Laufen mehrere Container innerhalb der gleichen Container App, müssen sich diese die Ressourcen teilen. Sollten dies nicht reichen, erreichen Sie eine Deckung höheren Ressourcenbedarfs nur durch eine horizontale Skalierung, also durch mehrere Instanzen des Containers. Bild 2 zeigt die Container-Einstellungen für eine neue Revision in der Azure-UI.

Für den produktiven Betrieb von Anwendungen sind auch Monitoringwerkzeuge notwendig, um eine ganzheitliche Sicht auf den Zustand einer Applikation zu bekommen. Azure bietet dafür eine Reihe von Tools, mit denen sich Azure Container Apps überwachen lassen. Zum einen gehören dazu klassische Metriken, um beispielsweise die CPU-Auslastung oder auch den Netzwerkverkehr einer Container-App zu messen.

Des Weiteren bietet ACA Unterstützung für das Logging, indem es sowohl System- als auch Applikationslogs automatisch an einen sogenannten Log Analytics Workspace schickt. Ein solcher dient in Azure dem Sammeln und Auswerten von Logdateien. Applikationslogs sind alle Daten, die die Applikation an die "stdout"- beziehungswiese "stderrr"-Schnittstelle schickt. Die Auswertung erfolgt dann via Kusto, einer Azure-Abfragesprache zum Filtern von Logs. Neben der Analyse von historischen Logs bringt ACA aber auch noch Log-Streams zur Echtzeitauswertung mit. Für ein vertieftes Troubleshooting haben Sie auch Zugriff auf die Container-Console, die es ermöglicht, sich direkt auf einen der Container einer Container-App zu verbinden.

Die Abrechnung von Azure Container Apps erfolgt verbrauchsabhängig. Es gibt zwei Preiskomponenten, die sich in der Rechnung finden: der Verbrauch von CPU und RAM sowie die Anzahl der Requests. Der Preis pro GBit/s unterscheidet sich, je nachdem, ob ein Container aktiv oder inaktiv (idle) ist. Ist er aktiv, zahlen Sie in der Region "Germany West Central" für eine vCPU 0,0864 US-Dollar pro Stunde sowie für eine GiB-Sekunde 0,000003 US-Doller. Ist der Container inaktiv, verbraucht also so gut wie keine CPU- und Netzwerkressourcen, kostet die vCPU 0,0108 US-Dollar pro Stunde. Zusätzlich schlagen die Requests mit 0,40 US-Dollar pro eine Million zu Buche.

Da diese Zahlen sehr klein sind, wollen wir anhand eines praxisnahen Beispiels etwas mehr Licht in die Kostenstruktur bringen: Betreiben Sie einen Container mit einem Core und 2 GByte RAM, sind pro Monat 70,39 US-Dollar fällig. Ist der Container permanent inaktiv, kostet er nur 15,95 US-Dollar. Das Preismodell zeigt, dass gerade Workloads, die nur sporadische Last aufweisen, sich gut für Container-Apps eignen. Zusätzlich bietet ACA einen "Free Tier", also ein kostenloses Kontingent. So lässt sich pro Monat ein Container mit einer CPU und 2 GByte RAM für etwas mehr als zwei Tage gratis betreiben.

Azure Container Apps erlaubt den Betrieb von containerbasierten Anwendungen, ohne dass Sie sich um die Komplexität einer Container-Orchestrierung wie Kubernetes kümmern müssen. Gerade in den letzten Jahren ist das Ökosystem rund um Kubernetes so angewachsen, dass es selbst Experten schwerfällt, mit der Vielzahl an Neuerungen und Produkten Schritt zu halten. Um es IT-Verantwortlichen einfacher zu machen, bringt ACA bereits einige Werkzeuge von Haus aus mit, die insbesondere Standardanforderungen hinsichtlich Konnektivität, Autoskalierung abdecken, aber auch das Deployment-Management vereinfachen.

Diesem Vorteil steht aber der Nachteil entgegen, dass die ACA-Nutzer von Microsoft abhängig sind, da Produkte aus dem Kubernetes-Umfeld sich in der Regel nicht integrieren lassen. Sie müssen sich also mit dem zufriedengeben, was Microsoft an Features mitbringt. Insgesamt lässt sich sagen, dass Microsoft mit Azure Container Apps eine Marktlücke für IT-Verantwortliche adressiert, die den Aufwand scheuen, den der Betrieb von Kubernetes mit sich bringt, aber trotzdem bestimmte Enterprise-Features aus dem Kubernetes-Ökosystem nutzen wollen.