Im zweiten Teil dieser Serie wollen wir auf einem AKS-Cluster eine Anwendung bereitstellen, die aus mehreren Containern besteht. Dank integrierter kubectl-Kommandozeile und anderer Funktionen gelingt das mit dem Azure Kubernetes Service ohne große Umstände.
Im ersten Teil dieses Workshops haben wir die Kubernetes-Steuerebene – also die Kubernetes-Master-Komponenten – als komplett von Azure verwalteten Cluster bereitgestellt. Nun wollen wir eine Anwendung auf unserem Cluster deployen. Es handelt sich um eine Voting-App aus den Azure-Samples bei GitHub, deren Beispiel-Code Microsoft zum Testen zur Verfügung stellt.
Bekanntlich definiert eine Manifest-Datei für Kubernetes deklarativ einen „gewünschten Zustand“ für den Cluster. In der Datei ist unter anderem vermerkt, welche Container-Images (z. B. vom Docker Hub) auf dem Cluster ausgeführt werden sollen. Die Manifest-Datei aus dem GitHub-Beispiel erstellt sämtliche Objekte, die zum Bereitstellen der Voting-App gebraucht werden. Das Manifest definiert eigentlich zwei Kubernetes-Deployments, einmal die Python-Sample-App für das Voting und eine weitere für eine Redis-Instanz. Ferner erstellt das Manifest zwei Kubernetes-Services, nämlich einen internen Dienst (Cluster-IP) für die Redis-Instanz und einen externen Dienst für einen Load Balancer, über den Endanwender aus dem Internet auf die Voting-App zugreifen.
Zur Erinnerung: Der Dienst „Cluster IP“ erzeugt eine interne IP-Adresse, die nur innerhalb des AKS-Clusters verwendet wird, also z. B. für interne Anwendungen, die andere Workloads im Cluster unterstützen.
![Cluster-IP ist ein Kubernetes-Virtual-Network-Dienst, der Konnektivität für interne Anwendung zur Verfügung stellt. (Bild: Microsoft)](https://cdn1.vogel.de/unsafe/540x0/smart/images.vogel.de/vogelonline/bdb/1764000/1764004/original.jpg)
Der Service „Load Balancer“ erstellt eine „Azure Load Balancer“-Ressource, konfiguriert deren Frontend-Konfiguration mit einer externen IP-Adresse und verbindet die jeweils angeforderten Pods mit dem Backend-Pool. Dabei werden an den gewünschten Ports Lastenausgleichsregeln derart erstellt, dass der Datenverkehr des Nutzers die Anwendung erreicht.
![LoadBalancer ist ein Kubernetes-Virtual-Network-Dienst, der Konnektivität für externe Anwendung zur Verfügung stellt. Bei AKS wird dieser Kubernetes-Dienst auf einen Azure Load Balancer abgebildet. (Bild: Microsoft)](https://cdn1.vogel.de/unsafe/540x0/smart/images.vogel.de/vogelonline/bdb/1764000/1764005/original.jpg)
Uns geht es in diesem Workshop allerdings nicht um die Anwendung an sich bzw. die Manifest-Datei im Einzelnen, uns interessieren vielmehr die für die Bereitstellung zu verwendenden Tools-Sets. Die Manifest-Datei für die komplette Anwendung steht wie oben erwähnt auf GitHub in verschiedenen Ausprägungen zur Verfügung: „Azure Vote All-in-One“, „Services“ (für die o. erwähnte Cluster-IP und den Load Balancer), „Storage-Ressources“, „Pod-Secrets“ und „azure-vote-Deployment“. Wir beschränken uns in diesem Workshop vorerst auf letzteres, also das reine Deployment des Voting-App-Frontends.
Kubectl
Im Gegensatz zu EKS bei AWS (Elastic Kubernetes Service) muss man sich in Azure um das Bereitstellen des kubectl-Kommandozeilen-Tools sowie das Einrichten der Cluster-Authentifizierung nicht in dem Maße kümmern, wie wir es in unseren EKS-Workshops beschrieben haben. Zumindest dann nicht, wenn man als Client die Azure-Cloud-Shell verwendet: hier ist kubectl bereits installiert.
![Die Azure-Vote-Manifest-Datei mit dem zugehörigen Deployment in der CloudShell. (Bild: Drilling / Microsoft).](https://cdn1.vogel.de/unsafe/540x0/smart/images.vogel.de/vogelonline/bdb/1764000/1764006/original.jpg)
Man startet also einfach aus dem Azure-Portal eine Cloud-Shell und verwendet einen beliebigen Editor, wie z. B. nano in der der Cloud-Shell-Bash, in den wir den von der oben genannten GitHub-Seite kopierten Inhalt der Manifest-Datei aus der Zwischenablage einfügen. Anschließend verlässt man nano mit [Strg X] und speichert den Inhalt der neuen Dateien und einem passenden Namen wie z. B. „azure-vote.yaml“. Wichtig ist die Endung, da es sich um eine Yaml-Datei handelt.
Nun stellen wir eine Verbindung zum Cluster her, laden die Anmeldeinformationen herunter und konfigurieren die Kubernetes-CLI für deren Verwendung. Das geschieht an der Azure-CLI (diese lässt sich in der Azure-Cloud-Shell sowohl an der Bash als auch der Powershell verwenden):
az aks get-credentials –resource-group <RessourceGroup-Name> –name <Cluster Name>
![Zum Überprüfen der Verbindung zum AKS-Cluster kann man das Kommando … kubectl get nodes.](https://cdn1.vogel.de/unsafe/540x0/smart/images.vogel.de/vogelonline/bdb/1764000/1764007/original.jpg)
Zum Überprüfen der Verbindung zum AKS-Cluster kann man das Kommando …
kubectl get nodes
… verwenden. Das Kommando gibt alle Knotenpools mit den darin befindlichen Knoten zurück. Im Beispiel ist dies nur der so genannte primäre Knotenpool namens „aks-agentpool“, der derzeit aus genau einem Knoten besteht.
![Das Bereitstellen der App auf dem AKS-Cluster. (Bild: Drilling).](https://cdn1.vogel.de/unsafe/540x0/smart/images.vogel.de/vogelonline/bdb/1764000/1764008/original.jpg)
Nun können wir unsere Voting-App wie folgt auf dem Cluster bereitstellen:
![Erfolgreiche Bereitstellung der Voting-App auf einem AKS-Cluster. (Bild: Drilling / Microsoft).](https://cdn1.vogel.de/unsafe/540x0/smart/images.vogel.de/vogelonline/bdb/1764000/1764010/original.jpg)