In diesem Artikel wird der Azure Kubernetes Service (AKS) vorgestellt. Es werden die wichtigsten Begriffe geklärt und ein Überblick gegeben, wie AKS bei einer containerbasierten Applikation unterstützen kann und welche Vorteile er gegenüber reinem Kubernetes bietet.

Das Open-Source-Projekt Kubernetes (K8s) ist längst in aller Munde und hat sich als „das“ Containerorchestrierungstool etabliert. Es bringt, hauptsächlich im Kontext einer Microservices-basierten Multicontainer-anwendung, bereits viele praktische Features mit. Da wären beispielsweise die Möglichkeiten von Updates ohne Downtime, Skalierbarkeit, Service Discovery und Selbstheilungstechniken.

Was ist AKS?

Ein Kubernetes-Cluster selbst zu installieren und zu betreiben, bedeutet allerdings einiges an Aufwand. An dieser Stelle setzt Azure Kubernetes Service an. Hierbei handelt es sich um einen Managed Kubernetes Service in der Azure Cloud. Auch AKS verwendet Kubernetes und zielt auf Containeranwendungen, unterstützt zusätzlich aber in vielen Bereichen wie Node-Management, Security, Skalierung und Monitoring. Das vereinfacht die Installation und den Betrieb eines Kubernetes-Clusters erheblich.

ZUM NEWSLETTER

Regelmäßig News zur Konferenz und der .NET-Community

AKS – Fakten und Begriffe

Cluster Management: Die virtuellen Maschinen zur Steuerung des Clusters – die Master Nodes – werden komplett von Microsoft verwaltet und sind kostenfrei. Bezahlen muss man lediglich für die Rechenleistung der Worker Nodes, ihren Speicherbedarf und ihre Netzwerkressourcen. Für die Worker Nodes, auf denen die Applikationen laufen, stehen Linux- und Windows-Maschinen zur Verfügung.

Abbildung 1 verdeutlich die Arbeitsteilung. Die Komponenten sind bereits von Kubernetes bekannt. Die Master Nodes bestehen aus dem API-Server, der etcd-Datenbank, dem Scheduler und dem Controller Manager. Der API-Server nimmt Befehle entgegen und prüft diese. In der etcd-Datenbank wird der State des Clusters gespeichert. Über den Scheduler wird geregelt, auf welchen Nodes welche Pods (mit den Containern) platziert werden. Der Controller Manager verwaltet Replica Set Controller und Deployment Controller. Der linke Teil wird komplett von Azure verwaltet, inklusive beispielsweise der Skalierung und dem Patching der virtuellen Maschinen.

Abb. 1: AKS-Komponenten (Quelle: Microsoft)

Auf den virtuellen Maschinen der Worker Nodes finden sich der kubelet-Agent zur Kommunikation mit dem API-Server und Pod-Erstellung, kube-proxy für Netzwerkaufgaben und eine Container-Runtime. Auch bei diesen Bestandteilen unterstützt AKS: Sie müssen nicht manuell auf den Nodes installiert werden.

Auch bei AKS sind natürlich Pods, Replica Sets, Deployments, Nodes und Node Pools relevant [1].

Worker Nodes: Ein Node Pool beschreibt ein Set gleicher virtueller Maschinen, auch Worker Nodes genannt, auf denen die Applikationen betrieben werden. Bezogen auf Azure-Ressourcen können das einzelne VMs oder Virtual Machine Scale Sets sein. Des Weiteren besteht die Möglichkeit, virtuelle Nodes zu verwenden, mehr dazu beim Thema Skalierung. Für die Pools können verschiedene Typen virtueller Maschinen gewählt werden, beispielsweise CPU-optimierte Serien oder solche mit GPUs. Für erhöhte Security- und Complianceanforderungen kann auch das Modell Compute Isolation gewählt werden, bei dem physikalische Server im Azure Data Center nicht mit anderen Kunden geteilt werden.

High Availability: Die Node-Auto-Repair-Funktion hilft, ungesunde Nodes zu identifizieren und ggf. neu zu starten [2]. Um eine höhere Verfügbarkeit bei den Worker Nodes zu gewährleisten, können diese per Pool auf Availability Zones verteilt werden, das heißt auf mehrere Data Center in einer Region. Für sehr kritische Workloads kann außerdem eine kostenpflichtige SLA-Option gebucht werden, die durch zusätzliche Ressourcen bei den Master Nodes die Verfügbarkeit auf 99,95 Prozent bei Verwendung von Availability Zones erhöht. Die SLA ist dann auch finanziell gesichert, falls das Versprechen seitens Azure nicht eingehalten wird [3].

Für Anforderungen im Bereich Disaster Recovery können z. B. Multi-Region-Cluster (Abb. 2) aufgebaut werden. Die AKS-Cluster werden dafür in verschiedenen Regionen für Ausfallsicherheit aufgebaut und die globale Request-Verteilung etwa mit Hilfe eines Azure Traffic Manager erreicht.

Abb. 2: Multi-Region-Cluster (Quelle: Microsoft)

Auch Container-Images können global repliziert werden, wenn die entsprechende SKU in der Azure Container Registry verwendet wird. Das verringert die Latenz beim Image Pull, erhöht die Verfügbarkeit und spart Kosten beim Netzwerktransfer [4].

Netzwerk: Beim AKS gibt es zwei verschiedene Netzwerktypen, die für die Cluster zur Verfügung stehen: kubenet und Container Networking Interface (CNI).

Die kubenet-Variante ist der einfachere Ansatz. Die IP-Adressen der Pods sind hier abstrahiert und müssen nicht im Adresspool des virtuellen Netzwerks berücksichtigt werden. Angesprochen werden sie durch Network Address Translation (NAT) auf den Nodes. Bei diesem Ansatz sind allerdings keine Windows Node Pools möglich. Beim CNI-Ansatz bekommt jeder Pod eine IP-Adresse aus dem IP-Pool des VNets zugewiesen, was daher eine aufwendigere Planung beim Clusteraufbau erfordert. Dieser Ansatz muss gewählt werden, wenn die AKS Network Policies angewendet werden sollen oder ein Azure Application Gateway als Ingress-Ressource gewünscht ist. Tabelle 1 listet weitere Unterschiede auf.

SIE LIEBEN AZURE?

Entdecken Sie die BASTA! Tracks

Mehr erfahren

kubenet	CNI
POD IPs werden abstrahiert, NAT auf den Nodes	Jeder Pod bekommt eine eigene IP-Adresse
Limit von 400 Nodes pro Cluster	Notwendig für: – Network Policies – Application Gateway als Ingress-Ressource
Neine Windows Nodes	Benötigt einen größeren IP-Adressraum und mehr Planung

Tabelle 1: Vergleich der AKS-Netzwerkoptionen

Es ist zu beachten, dass der Netzwerktyp nach der Clustererstellung nicht mehr geändert werden kann [5].

Magie mit kubectl: Bei der Interaktion mit dem AKS-Cluster wird das Tool kubectl verwendet. Dass hierbei eine gewisse Magie stattfindet, indem durch K8s-Befehle gleichzeitig auch Azure-Ressourcen erstellt und konfiguriert werden, liegt an zusätzlichen Pods auf den Master Nodes. Beispielsweise sind das CSI Driver für das universelle Speichermanagement oder Pods vom cloud-provider-azure-Projekt. Letztere helfen dabei, die zusätzliche Azure-Load-Balancer- und Network-Security-Group-Konfigurationen durchzuführen, wenn ein externer Service als Kubernetes-Ressource erstellt wird [6].

Storage: Auch bei der Speicherverwaltung kann AKS unterstützen. Sofern der lokale Speicher auf den Nodes selbst nicht ausreicht, beispielsweise weil Persistenz über den Pod-Lifecycle hinaus gebraucht wird, können Azure Discs oder Fileshares angebunden werden (Abb. 3). Dabei muss die Kubernetes-Ressource Persistent Volume Claim (PVC) erstellt und die Volume-Einbindung beim Deployment angegeben werden. Je nach der im PVC verwendeter Storage Class wird dann automatisch eine Azure Disc oder ein Azure Fileshare erstellt. Storage Classes gibt es built-in, sie können aber auch individuell erstellt werden. Im Hintergrund wird dann – im empfohlenen, moderneren Ansatz – der Azure Disc Container Storage Interface (CSI) Driver verwendet. Dieser arbeitet gemäß CSI-Spezifikation [7] und läuft als Plug-in im Cluster. Damit ist es nun auch möglich, Storage-Typen neu zu erstellen oder anzupassen, ohne den Kubernetes Core zu verändern. Über die Storage Classes wird auch das Löschverhalten für die Azure-Ressourcen geregelt, wenn das Volume nicht mehr in Pods eingebunden ist [8], [9].

Abb. 3: Storage-Optionen im AKS-Cluster (Quelle: Microsoft)

Tools: Für die Arbeit mit einem AKS-Cluster stehen mehrere Tools zur Verfügung. Zu erwähnen ist hier sicher das Azure Portal, in dem zum einen das GUI vorhanden ist und außerdem die Cloud Shell für Konsolenbefehle verwendet werden kann. Über das GUI kann der Cluster selbst verwaltet werden, außerdem bietet es Möglichkeiten für das Clustermonitoring. In der Cloud Shell ist kubectl bereits installiert. Komfortabel ist auch die Arbeit mit Visual Studio Code, das mit entsprechenden Extensions unterstützt. kubectl muss hier aber extra installiert werden.

Als weitere interessante Option zur Clusterverwaltung ist Octant zu erwähnen, ein Open-Source-Projekt mit webbasiertem Interface [10].

Unterstützung der Security

Netzwerk: Beim Thema Security bietet AKS zahlreiche Möglichkeiten, um den Cluster abzusichern, Zugriffe und Datenverkehr zu steuern. Bei AKS handelt es sich um PaaS, daher hat es automatisch einen Public Endpoint. Soll der Zugriff darauf eingeschränkt werden, kann das z. B. mit definierten IP Ranges erreicht werden, außerhalb derer kein Access möglich ist. Der Cluster kann aber auch privat sein und komplett aus dem Internet genommen werden. In diesem Fall ist eine Kommunikation mit dem API-Server nur über das konfigurierte VNet mit Hilfe von Azure Private Links möglich. Der Datenverkehr bleibt dann im Azure-Backbone-Netzwerk [11].

Die Einschränkung per Private Link funktioniert ebenfalls bei anderen Azure Services, die häufig im Cluster eingebunden sind, beispielsweise Storage oder eine Azure Container Registry. Bei der Filterung vom Datenverkehr zwischen den Nodes kommen auch Network Security Groups (NSG) zum Einsatz, bei denen AKS die Verwaltung der Regeln übernimmt. Das funktioniert bei beiden Netzwerktypen. Wird beispielsweise einer externer K8s Service erstellt, wird neben der Load-Balancer-Konfiguration auch die der NSG von AKS angepasst [12].

Microsoft Defender for Cloud und Key Vault: Vor kurzem noch unter den Namen Azure Security Center und Azure Defender bekannt, kann für den Cluster selbst oder andere im Kontext verwendete Services zusätzlicher Schutz aktiviert werden, beispielsweise für die Azure Container Registry. Hierbei unterstützt der Defender u. a. durch das kontinuierliche Scannen der Images mit der Engine des IT-Security-Anbieter Qualys, was z. B. fehlende Securitypatches des OS Layers aufdecken kann [13].

Bei AKS kann durch die Aktivierung des kostenpflichtigen Defenders ein eingeschleuster Krypto-Mining-Container entdeckt werden oder auch Zugriffe von ungewöhnlichen oder verschleierten IP-Adressen. Die Resultate können dann im Defender-Portal (Security Center) eingesehen werden [14].

Für das sichere Ablegen von Passwörtern, Connection-Strings oder Zertifikaten eignet sich der Azure Key Vault. Er kann über eine Erweiterung direkt in den Cluster eingebunden werden. Es laufen dann einfach zusätzliche Pods auf den Nodes und über den CSI Driver können die Key-Vault-Ressourcen als Volumes den Pods zur Verfügung gestellt werden.

Azure Policies und Network Policies: Zur Überwachung von Compliance und eingehaltenen Sicherheitsrichtlinien sind die Azure Policies ein mächtiges Instrument. Sie können durch das Aktivieren eines Cluster-Add-ons auch in diesem verwendet werden. Viele AKS spezifische Policy-Definitionen sind bereits standardmäßig vorhanden und es gibt auch Initiativen, in denen Policys für einen Security-Baseline-Standard gebündelt werden. Es können aber auch individuelle Policys erstellt werden. Je nach Konfiguration kann eine Policy eine Fehlkonfiguration melden (Audit) oder neben anderen Effekten z. B. eine Ressourcenerstellung verhindern [15].

Beispiele für Complianceprüfungen ist das Festlegen erlaubter Regionen oder der SKUs virtueller Maschinen. Im Bereich Security gibt es Optionen zur Einschränkung von Pod-Privilegien, erlaubten Ports oder Ressourcenzuweisungen für Pods.

Um den Datenverkehr zwischen den Pods granularer steuern zu können, stehen die Kubernetes Network Policies zur Verfügung, bei deren Erstellung und Verwaltung AKS mit dem gleichnamigen Feature unterstützen kann. Basierend auf den Namespace- und Pod-Labels kann eine Restriktion zwischen Pods erstellt werden, per Default gibt es dort keine.

Es kann zwischen den Microsoft Azure Network Policies und denen des Anbieters Calico gewählt werden. Bei den Microsoft Policies ist anzumerken, dass diese nur auf Linux Nodes empfohlen werden und ein CNI-Netzwerk brauchen. Calico Policies arbeiten auch mit dem kubenet-Netzwerk und haben in der Preview Windows-Unterstützung, können aber natürlich nicht mit Azure-Support aufwarten [16].

AAD-Integration: Für die Zugriffssteuerung auf den Cluster kann Azure Active Directory (AAD) integriert werden. Auch in diesem Fall muss dafür lediglich ein Feature aktiviert werden. Die Integration vom AAD verbindet dann das Azure-RBAC-System mit dem Kubernetes RBAC. Dadurch kann der Cluster-Access über die AAD-Gruppen- und Rollenzuweisungen gesteuert werden, mit vorhandenen AKS-spezifischen Rollen oder selbst erstellten. Außerdem kann damit auch mit Services wie Conditional Access oder Privileged Identity Management (PIM) gearbeitet werden. Zu beachten ist, dass dieses Feature zwar nachträglich aktiviert, aber nicht wieder deaktiviert werden kann. Außerdem ist die Aktivierung von K8s RBAC im Cluster erforderlich [17].

Node Patching/Upgrades: Ein wichtiges Thema im Securitykontext ist natürlich das Patching der Betriebssysteme. Bei AKS muss das bei den Master Nodes gar nicht beachten werden, da diese von Azure verwaltet und gepatcht werden. Bei den Linux Worker Nodes werden Updates in der Nacht automatisch bezogen und für die Unterstützung bei nötigen Neustarts der Nodes gibt es das Kured-Projekt. Zusätzliche Pods auf den Nodes in Form von Daemon-Sets prüfen die Existenz der /var/run/reboot-required-Datei und können im entsprechenden Fall das Neustarten des Nodes inklusive Rescheduling der Pods übernehmen [18].

Bei den Windows Worker Nodes gibt es keine täglichen Updates, es kann aber der AKS-Upgrade-Prozess verwendet werden, um die neuesten gepatchten Basis-Images für die Nodes zu erhalten.

Dieser Prozess, mit dem auch die K8s-Version im Cluster erneuert werden kann, verwendet den Cordon-and-Drain-Ansatz: Ein Node wird zunächst markiert, damit der K8s Scheduler keine neuen Pods mehr auf diesem plant. Laufende Pods werden auf andere Nodes verteilt und ein neuer Node wird erstellt und kann Pods aufnehmen. Sobald der markierte Node keine Pods mehr aufweist, wird er gelöscht und es wird mit dem nächsten Node fortgefahren. Auf diese Art kann eine Downtime der Anwendung verhindert werden. Das Upgrade kann z. B. mit dem Azure CLI erledigt und optional getrennt nach Master und Worker Nodes vorgenommen werden [19]. Snippet für einen Upgradebefehl per CLI:

az aks upgrade --resource-group $rgName --name $aksClusterName --kubernetes-version 1.21.1 --control-plane-only

Des Weiteren gibt es für die Kubernetes-Version einen Auto-Upgrade-Channel in der Preview, der automatisch und in verschiedenen Stufen die Version updaten kann [20]. Snippet für CLI:

az aks update --resource-group $rgName --name $aksClusterName --auto-upgrade-channel stable

Skalierung und Monitoring

HPA und Cluster-Autoscaler: Bei einer containerbasierten Microservices-Architektur ist die Skalierung der Pods bzw. des gesamten Clusters auch ein bedeutendes Thema, bei dem AKS mit zusätzlichen Techniken helfen kann. Der Horizontal Pod Autoscaler (HPA), der anhand von Pod-Metriken wie CPU-Nutzung skaliert und so Pods auf einem Node erstellt und entfernt, ist bereits von K8s selbst bekannt.

AKS hat aber auch einen Cluster-Autoscaler. Dieser kann dem Cluster automatisch neue Nodes hinzufügen bzw. sie entfernen, wenn die Ressourcennutzung auf den virtuellen Maschinen das erfordert. Der Autoscaler kann über das Portal oder einfach per CLI aktiviert werden, wie im folgenden Code-Snippet für einen Cluster mit Single Node Pool ersichtlich ist:

az aks update --name $aksClusterName --resource-group $rgName --enable-cluster-autoscaler --min-count 1 --max-count 3

Es kann damit zwischen einem und drei Nodes automatisch skaliert werden, mit verschiedenen Profilen wird eine granulare Skalierung möglich. Die zusätzlichen Nodes benötigen keine weitere Konfiguration [21].

Außerdem gibt es für die Skalierung noch das Framework Kubernetes-based Event-driven Autoscaling (KEDA), das weitere umfangreiche Metriken und Events als Trigger erlaubt. KEDA kreiert zusätzliche Pods zum Operieren und Event Listening im Cluster und arbeitet mit dem HPA zusammen. Dadurch kann für das Pod Scaling mit vielen weiteren Signalen gearbeitet werden, z. B. Azure-Monitor-Metriken, Storage oder Event Hubs. Andere Event Sources weiterer Cloud-Provider werden auch unterstützt [22].

Rapid Burst Scaling: Die Skalierung über Nodes kann unter Umständen einfach zu langsam sein. Für diesen Anwendungsfall kann mit Virtual Kubelets gearbeitet werden (Abb.4) [23]. Hierbei handelt es sich um eine Open-Source-Kubernetes-Implementierung, mit der Nodes im Cluster simuliert werden können; ein Kubelet registriert sich dann selbst als Node. Die nötige Rechenpower hinter den Virtual Kubelets kommt nicht direkt von virtuellen Maschinen, sondern beispielsweise vom Azure Batch Service mit GPUs oder von Azure Container Instances, auf denen die Container laufen. Das ist zwar teurer, skaliert aber deutlich schneller als über den Node Scaler. Daher kommt auch der Name Rapid Burst Scaling, weil es eher für den Ausgleich von Spitzenlasten und nicht für den Dauerzustand konzipiert ist [24].

Abb. 4: AKS-Virtual-Kubelet-Optionen (Quelle: Microsoft)

Azure Monitor mit AKS: AKS bietet durch die Integration in den Azure Monitor komfortable Möglichkeiten, den Cluster zu überwachen (Abb. 5). Für die umfangreichste Datenlage wird der Cluster mit einem Azure Log Analytics Workspace verknüpft, der die zentrale Datensenke darstellt. Wenn noch die entsprechenden Diagnostic-Settings vom Cluster aktiviert werden, können neben metrischen Daten wie CPU-Nutzung, Disk-Belegung oder Netzwerkverkehr auch Logdaten vom API-Server, dem Controller Manager oder dem Scheduler gesammelt werden.

Wie aus der Monitoringwelt bekannt, stehen für die Analyse dieser Daten zahlreiche Werkzeuge zur Verfügung. Die Daten können z. B. in Monitor Workbooks oder über Power BI visualisiert werden. Der Cluster kann aber auch auf Basis der Daten skalieren und es gibt Optionen, über das Alerting Benachrichtigungen zu versenden. Bei Bedarf können sogar weitere Arbeitsschritte, beispielsweise über Azure Functions, Logic Apps oder verbundene Ticketsysteme, erledigt werden.

Abb. 5: AKS und Azure Monitor (Quelle: Microsoft)

Microsoft liefert über die Container Insights Solution, basierend auf vorhandenen Workbooks, u. a. Einsichten über den Zustand von Nodes, Containern und deren Live-Logs. Das Monitoring-Add-on kann auch nach der Erstellung des Clusters aktiviert werden.

Abb. 6: KQL-Query und Chart

Die Kusto Query Language (KQL), eine SQL-ähnliche Abfragesprache aus der Azure-Monitor-Welt, bietet zudem viele Optionen einer individuellen Analyse. Im Log-Analytics-Bereich des Azure Portal können dann direkt Abfragen für Informationen aus dem Cluster ausgeführt werden [25]. Folgende Query liefert Basisdaten über im Cluster laufende Container der letzten 30 Minuten und rendert direkt einen Chart (Abb. 6):

ContainerInventory | where TimeGenerated >= ago(30m) | summarize AggregatedValue = dcount(ContainerID) by ContainerState, Image | render columnchart

ZUM NEWSLETTER

Regelmäßig News zur Konferenz und der .NET-Community

Erweiterte Integration mit anderen (Azure) Services

Neben der automatischen Erstellung von Storage-Ressourcen oder der NSG-Konfiguration gibt es noch zahlreiche weitere Integrationen zu Azure Services und Ressourcen, wovon einige an dieser Stelle noch einmal kurz beleuchtet werden sollen.

Verwendung von Azure Application Gateway als Ingress: In einem Kubernetes-Cluster werden häufig Ingress-Controller verwendet, um den Datenverkehr granularer zu steuern und bestimme Regeln umzusetzen. Eine verbreitete Implementierung ist NGINX [26]. Damit bleibt die Ressourcenlast für den Ingress-Controller allerdings im Cluster selbst. Eine Alternative ist, das Azure Application Gateway als Ingress-Controller zu verwenden.

Beim Azure Application Gateway handelt es sich um einen Layer 7 Load Balancer mit der Option einer integrierten Firewall. Das Application Gateway kann ebenfalls mit Features wie TLS-Terminierung oder URL-Path-Routing aufwarten. Mit dem aktivierten Application-Gateway-Ingress-Controller-(AGIC-)Add-on kann es als Ingress-Ressource im Cluster verwendet werden, reduziert die Last im Cluster selbst und kann unabhängig skalieren. Da das Application Gateway direkt mit den Pods über private IPs kommuniziert, benötigt es keine Node Ports oder KubeProxy Services und nimmt damit zusätzlich Last aus dem Cluster. Ein CNI-Netzwerk ist aber Voraussetzung. Die Aktivierung des Add-ons erstellt dann nötige Kubernetes-Ingress-Ressourcen, Services und Pods [27].

Mit folgendem CLI-Befehl kann das Add-on in einem bestehenden Cluster aktiviert werden, der dann mit einem vorhandenen Application Gateway verknüpft wird:

az aks enable-addons -n $aksClusterName -g $rgName -a ingress-appgw --appgw-id $appgwId

Azure Functions mit KEDA: Im Abschnitt „Monitoring“ wurde bereits einmal auf das KEDA-Framework eingegangen. KEDA ermöglicht es, Azure Functions direkt im AKS-Cluster in einem Container auszuführen. Die Azure Function App muss hierfür im Containermodus erstellt werden, damit die Runtime entsprechend zur Verfügung steht. Nachdem KEDA im Cluster installiert wurde [28], kann die Function-App z. B. über die Function-Core-Tools in den Cluster geladen werden. Dieser Vorgang erstellt ein Manifest mit Deployment, Scaled Object und Secrets für die Umgebungsvariablen aus der local.settings.json-Datei.

Auch hier arbeitet KEDA mit dem HPA zusammen und ermöglicht, basierend auf Events wie neuen Nachrichten in einer Azure Storage oder Service Bus Queue, anhand von Cronjobs oder anderen Triggern, den Function-Container zu skalieren, solange Arbeit zu verrichten ist [29].

Azure Active Directory (AAD) Pod Identity: Sofern die AAD-Integration für den Cluster vorhanden ist und ein CNI-Netzwerk gewählt wurde, kann für den Azure-Ressourcenzugriff die AAD Pod Identity verwendet werden. Für Kubenet wird das aus Sicherheitsaspekten nicht empfohlen. Wird das Add-on aktiviert, laufen für die Funktionalität wieder zusätzliche Pods als Daemon-Set auf den Nodes. Über diesen Ansatz kann die Identität eines Pods mit einer Identität aus Azure verknüpft werden und der Pod bekommt den nötigen Zugriff auf eine Cloud-Ressource. Dieses Feature ist aktuell nur auf Linux Nodes verfügbar und befindet sich noch im Preview-Status [30].

Continuous Integration und Deployment: Zur Abrundung des Bilds sei hier nochmals die mögliche Verknüpfung zu CI/CD Pipelines beispielsweise von Azure DevOps oder GitHub Actions erwähnt. Ein Code-Commit triggert z. B. die automatische Erstellung neuer Images, die in die Containerrepositorys geladen und etwa durch einen Helm-Upgrade-Schritt eine aktualisierte Version der Anwendung im AKS-Cluster verfügbar machen. Helm ist ein Package-Manager für Kubernetes-Ressourcen und in AKS integriert [31].

Architekturen

Abbildung 7 veranschaulicht den Aufbau einer Beispiel-Microservices-Architektur mit Verwendung eines AKS-Clusters. Die verschiedenen Services sind durch Container in Pods realisiert, Datenbanken befinden sich aber häufig außerhalb des Clusters, um eine Stateless-Architektur zu vereinfachen. Es wird grundsätzlich empfohlen, Daten eher in PaaS-Diensten zu speichern, die Multi-Region-Replikation unterstützen. Als Ingress-Controller wird NGINX verwendet, ein Load Balancer routet den Internetverkehr zum Ingress. Das AAD ist als Identity Provider angebunden und Secrets liegen im Azure Key Vault. Updates der Anwendungen erfolgen durch CI/CD Pipelines, es erfolgt ein Pushen der Images in die Container Registry und ein Pullen dieser vom Cluster nach einem Helm-Upgrade-Befehl [32].

Abb. 7: AKS-Cluster-Architektur (Quelle: Microsoft)

Tipps, Tricks und Hands-on

Ist ein Cluster nicht produktiv und wird nicht dauerhaft gebraucht, soll es aber auch nicht bei jedem Gebrauch neu provisioniert werden, kann es gestoppt werden [33]. Damit werden sämtliche Worker Nodes dealloziert und verursachen keine (CPU-)Kosten mehr (Abb. 8). Es bleiben lediglich die Kosten für Netzwerk-ressourcen und Storage. Das Anhalten des Clusters kann im Azure-Portal und durch den folgenden CLI-Befehl erreicht werden:

az aks stop --name $aksClusterName --resource-group $rgName

Um den Cluster wieder zu starten, genügt folgendes Command:

az aks start --name $aksClusterName --resource-group $rgName

Bei der Erstellung der Node Pools können keine virtuellen Maschinen mit Standard-HDDs verwendet werden.

Abb. 8: Gestoppter AKS-Cluster

Beim CNI-Netzwerktyp sollte die IP-Adressplanung definitiv nicht unterschätzt werden. Jeder Pod braucht eine Adresse und nachträgliche Änderungen an Adressbereichen können schwierig bzw. praktisch unmöglich werden. Daher sollte die Menge der Workloads im Cluster so gut wie möglich eingeschätzt und bei der Definition der Adressbereiche berücksichtigt werden [34].

Außerdem bietet es sich an, bestimmte Prozesse und Rollen zu definieren und zu besetzen, beispielsweise einen Cluster-Admin oder ein AKS-Team. AKS kann zwar in vielen Bereich unterstützen, ersetzt aber dennoch nicht eine gute Operations-Basis.

Abb. 9: Generierte Ressourcengruppe von AKS

Die Ressourcen, die von AKS erstellt werden, finden sich in einer anderen, automatisch generierten Ressourcengruppe nach dem Schema (Abb. 9):

MC_<Ressourcengruppe AKS>_<Cluster Name> _<Region>

SIE LIEBEN .NET?

Entdecken Sie die BASTA! Tracks

Mehr erfahren

Walkthrough

Wer den Einsatz des Azure Kubernetes Service Hands-on ausprobieren möchte, findet bei Microsoft ein gutes Tutorial [35]. Im Beispiel wird ein AKS-Cluster Schritt für Schritt aufgebaut und deckt Themen wie Skalierung, Ingress, Zertifikatsmanagement und Monitoring mit ab (Abb.10).

Abb. 10: Tutorial zum Aufbau eines AKS-Clusters (Quelle: Microsoft)

Fazit

Wer eine Multi-Container-Applikation mit Kubernetes hosten möchte, findet in AKS einen Dienst, der gegenüber einer eigens betriebenen Kubernetes-Landschaft viel Unterstützung bietet und den Aufwand beim Aufbau und beim Betrieb reduziert. Wer simplere Containerarchitekturen in der Azure-Cloud betreiben will, ist eventuell mit Azure Container Instances [36] oder Azure App Service [37] besser beraten. Auch ein Blick in den neuen (Preview) Service Azure Container Apps lohnt sich [38].