Über den Azure Kubernetes Service, kurz AKS, haben wir in diesem Workshop bereits eine Anwendung per Container Cluster bereitgestellt. Die Skalierung von Kubernetes-Clustern im Allgemeinen und AKS-Clustern im Speziellen schauen wir uns in diesem Teil an.
Beginnen wir analog zum zweiten Teil dieser Serie erneut damit, dass wir uns zwecks Kontrolle der Konnektivität der seinerzeit erstellten AKS-Cluster die Anzahl und Verteilung der Knoten-Pools und Knoten im Cluster anzeigen lassen. Hierzu setzen wir das kubectl-Kommando „get nodes“ ab:
kubectl get nodes
Nun ermitteln wir mit dem Kommando …
kubectl get pods
…, aus wie vielen Pods unsere Anwendung besteht sowie die IDs der jeweiligen Pods nebst jeweiligem Pod-Status. Ferner könnten wir jederzeit den Status unseres Deployments ermitteln, dies gelingt mit dem Kommando:
kubectl get deployment
Unser Deployment besteht aus einem Frontend und einem Backend. (Bild: Drilling / Microsoft).Nun wollen wir uns mit den Skalierungsoptionen in AKS befassen und exemplarisch einige Arten der manuellen Skalierung ausprobieren. Dazu sollten wir aber noch etwas Hintergrundwissen anhäufen.
Skalierung in Kubernetes und AKS
Da Anwendungen über die Kapazität eines einzelnen Pods hinauswachsen können, verfügt Kubernetes über eine automatische Cluster-Skalierung. Diese basiert auf dem Hinzufügen von Compute-Ressourcen.
Standardmäßig prüft die automatische Cluster-Skalierung den Metrik-API-Server alle zehn Sekunden auf eine potenziell erforderliche Anpassung der Anzahl von Knoten. Sollte eine Skalierung erforderlich sein, wird die Anzahl der Knoten im AKS-Cluster automatisch herauf- oder herabgesetzt. Darüber hinaus gibt es in Kubernetes einen horizontalen Pod-Autoscaler (HPA), der auf Basis von Metriken skaliert und mit dem Cluster-Autoscaler Hand in Hand arbeitet.
Kubernetes nutzt die horizontale automatische Podskalierung zum Überwachen des Ressourcenbedarfs und zum automatischen Skalieren der Anzahl der Replikate. Standardmäßig überprüft die horizontale automatische Podskalierung die Metriken-API alle 30 Sekunden auf erforderliche Änderungen der Replikat-Anzahl.
Allgemein erhöht oder reduziert die horizontale automatische Pod-Skalierung die Anzahl von Pods nach Bedarf der Anwendung. Die automatische Cluster-Skalierung wiederum ändert die Anzahl der Knoten, um den Kapazitätsbedarf für zusätzliche Pods zu decken. Ändert sich also die Anzahl der benötigten Anwendungsinstanzen, muss die Anzahl der zugrunde liegenden Kubernetes-Knoten möglicherweise ebenfalls geändert werden.
AKS-Admins können aber die Anzahl der Replikate (Pods) und Knoten auch jederzeit manuell skalieren, um zu testen, wie die Anwendung auf eine Änderung in verfügbaren Ressourcen und Status reagiert. Beim manuellen Skalieren kann man jederzeit eine feste Anzahl der zu verwendenden Ressourcen wie z. B. die Anzahl der Knoten definieren und somit erzwingen. Für das manuelle Skalieren definiert man die Replika- und/oder Knotenanzahl.
Die Kubernetes-API plant dann das Erstellen zusätzlicher Pods oder Entfernen von Knoten auf Basis dieser Replikat- oder Knotenanzahl. Konkret ruft beim horizontalen Skalieren von Knoten die Kubernetes-API die relevante Azure-Compute-API auf, die an den vom Cluster verwendeten Compute-Typ gebunden ist. So könnte der AKS-Cluster beispielsweise auf VM Scale Sets basieren, welche die Logik für die Auswahl der zu entfernenden Knoten durch die „VM Scale Sets“-API ermittelt.
Abkühlung der Skalierung von Ereignissen
Da die horizontale automatische Pod-Skalierung die Metriken-API alle 30 Sekunden überprüft, werden Skalierungsereignisse möglicherweise nicht erfolgreich abgeschlossen, bevor eine andere Überprüfung erfolgt. Somit könnte die horizontale automatische Pod-Skalierung die Anzahl der Replikate ändern, bevor ein vorangegangenes Skalierungsereignis eine Ressourcenanforderung empfangen und entsprechend anpassen konnte.
Um solche Ereignisse zu minimieren, kann der Admin einen Verzögerungswert festlegen. Dieser Wert definiert, wie lange die horizontale automatische Pod-Skalierung nach einem Skalierungsereignis warten muss, bevor ein anderes Skalierungsereignis ausgelöst werden kann. Dieses Verhalten ermöglicht es, dass die neue Replikat-Anzahl wirksam wird und die Metriken-API die verteilte Workload widerspiegeln kann.
kubectl scale –replicas=2 deployment/<Deployment Name>
Das Resultat überprüfen wir dann mit
kubectl get pods
Nun wollen wir die Anzahl der Knoten im Cluster erhöhen. Hierzu verwenden wir allerdings die AKS-Kommando-Ebene in Form des Befehls „az aks scale“.
az aks scale –resource-group <Name Ressource-Group> –name <Cluster Name> –node-count 2
Das Ergebnis prüfen wir wieder mit dem get-Befehl:
Schließlich erhöhen wir noch einmal die Anzahl der Replikate auf 5 und prüfen das Ergebnis.
kubectl scale –replicas=5 deployment/<Deployment Name>
Wir können uns wie folgt auch der Verteilung der Pods über den Cluster ansehen:
kubectl get pod -o=custom-columns=NODE:.spec.nodeName,POD:.metadata.name
