Microsoft Azure Kubernetes Service, Teil 2 Kubernetes App auf AKS bereitstellen

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

Confluent Germany GmbH

Windhoff Group

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.

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.

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.

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):

Zum Überprüfen der Verbindung zum AKS-Cluster kann man das Kommando …

… 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.

Nun können wir unsere Voting-App wie folgt auf dem Cluster bereitstellen:

Wenn die Anwendung ausgeführt wird, stellt ein Kubernetes-Dienst das Front-End der Anwendung dem Internet zur Verfügung. Der Vorgang kann einige Minuten dauern. Man kann aber den Fortschritt in der Cloud Shell mit dem kubelet-Kommando „get service“ überwachen:

Jetzt muss man nur noch warten, bis sich die EXTERNAL-IP-Adresse von „anstehend“ zu einer tatsächlichen öffentlichen IP-Adresse ändert. Dann kann man den Befehl mit Strg + C ausbrechen und mit der externen IP in einem Browser-Fenster prüfen, ob die Frontend-App verfügbar ist, wie im vorangestellten Bild zu sehen.

(ID:46968121)