Anwendungen skalieren und lastenausgleichen

Einführung

In diesem Lab werden Sie mithilfe von Minikube einen lokalen Kubernetes-Cluster starten, eine Beispielanwendung (NGINX) bereitstellen und diese dann skalieren, um unterschiedlichen Anforderungen gerecht zu werden. Sie werden die Lastverteilung über mehrere Pods beobachten, Clusterereignisse überwachen und eine kurze Einführung in den Horizontal Pod Autoscaler (HPA) für die zukünftige automatische Skalierung erhalten. Ziel dieses Labs ist es, eine umfassende praktische Erfahrung für das Verständnis von Kubernetes-Skalierung und -Lastverteilung zu vermitteln.

Starten des Kubernetes-Clusters

In diesem Schritt erfahren Sie, wie Sie einen lokalen Kubernetes-Cluster mithilfe von Minikube starten und überprüfen. Dies ist ein wesentlicher erster Schritt für die Bereitstellung und Verwaltung von containerisierten Anwendungen in einer Kubernetes-Umgebung.

Zunächst starten Sie den Minikube-Cluster:

minikube start

Beispielausgabe:

😄  minikube v1.29.0 on Ubuntu 22.04
✨  Automatically selected the docker driver
📌  Using Docker driver with root permissions
🔥  Creating kubernetes in kubernetes cluster
🔄  Restarting existing kubernetes cluster
🐳  Preparing Kubernetes v1.26.1 on Docker 20.10.23...
🚀  Launching Kubernetes...
🌟  Enabling addons: storage-provisioner, default-storageclass
🏄  Done! kubectl is now configured to use "minikube" cluster and "default" namespace

Überprüfen Sie den Clusterstatus mit mehreren Befehlen:

minikube status
kubectl get nodes

Beispielausgabe für minikube status:

minikube
type: Control Plane
host: Running
kubelet: Running
apiserver: Running
kubeconfig: Configured

Beispielausgabe für kubectl get nodes:

NAME       STATUS   ROLES           AGE   VERSION
minikube   Ready    control-plane   1m    v1.26.1

Diese Befehle bestätigen Folgendes:

1. Minikube läuft erfolgreich.
2. Ein lokaler Kubernetes-Cluster wurde erstellt.
3. Der Cluster ist einsatzbereit.
4. Sie haben einen Ein-Knoten-Cluster mit Control-Plane-Funktionalitäten.

Bereitstellung einer Beispielanwendung

In diesem Schritt erfahren Sie, wie Sie eine einfache Webanwendung mithilfe einer Kubernetes-Deployment mit einer einzigen Replik erstellen. Wir werden ein YAML-Manifest für einen NGINX-Webserver erstellen und es auf den Minikube-Cluster anwenden. Das Verständnis, wie man eine Anwendung bereitstellt, ist grundlegend für die Verwendung von Kubernetes.

Zunächst erstellen Sie ein Verzeichnis für Ihre Kubernetes-Manifeste:

mkdir -p ~/project/k8s-manifests
cd ~/project/k8s-manifests

Erstellen Sie eine neue YAML-Datei für die Bereitstellung:

nano nginx-deployment.yaml

Fügen Sie die folgende Bereitstellungskonfiguration hinzu:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:latest
          ports:
            - containerPort: 80

Speichern Sie die Datei (Strg+X, dann Y, dann Eingabe).

Erklärung der YAML-Konfiguration:

• apiVersion: apps/v1: Gibt die API-Version für Deployments an.
• kind: Deployment: Zeigt an, dass es sich um ein Deployment-Objekt handelt, das zur Verwaltung von replizierten Anwendungen verwendet wird.
• metadata: Enthält Metadaten über das Deployment.
  • name: nginx-deployment: Der Name des Deployments.
  • labels: app: nginx: Ein Label, das zur Identifizierung dieses Deployments verwendet wird.
• spec: Enthält die Bereitstellungsspezifikation.
  • replicas: 1: Die gewünschte Anzahl von Pod-Instanzen (Repliken). In dieser ersten Bereitstellung haben wir nur eine Replik.
  • selector: Definiert, wie das Deployment Pods auswählt, die verwaltet werden sollen.
    • matchLabels: app: nginx: Pods mit dem Label app: nginx werden von diesem Deployment verwaltet.
  • template: Die Pod-Vorlage. Sie gibt die Konfiguration für die Pods an, die das Deployment erstellt.
    • metadata.labels: app: nginx: Label, das auf Pods angewendet wird, die von diesem Deployment verwaltet werden.
    • spec.containers: Definiert die Container im Pod.
      • name: nginx: Der Name des Containers.
      • image: nginx:latest: Das Docker-Image für den Container (Verwendung des neuesten NGINX-Images).
      • ports: containerPort: 80: Öffnet Port 80 im Container.

Wenden Sie die Bereitstellung auf den Kubernetes-Cluster an:

kubectl apply -f nginx-deployment.yaml

Beispielausgabe:

deployment.apps/nginx-deployment created

Überprüfen Sie den Status der Bereitstellung:

kubectl get deployments
kubectl get pods

Beispielausgabe für kubectl get deployments:

NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   1/1     1            1           30s

Beispielausgabe für kubectl get pods:

NAME                                READY   STATUS    RESTARTS   AGE
nginx-deployment-xxx-yyy            1/1     Running   0          30s

Wichtige Punkte zu dieser Bereitstellung:

1. Wir haben ein Deployment mit einer einzigen Replik erstellt.
2. Das Deployment verwendet das neueste NGINX-Image.
3. Der Container öffnet Port 80.
4. Das Deployment hat ein Label app: nginx zur Identifizierung.

Untersuchen Sie die Details der Bereitstellung:

kubectl describe deployment nginx-deployment

Die Beispielausgabe zeigt die Bereitstellungskonfiguration, Ereignisse und den aktuellen Zustand.

Skalieren von Deployments zur Bewältigung erhöhter Last

In diesem Schritt erfahren Sie, wie Sie Ihre Anwendung skalieren können, um mehr Traffic zu bewältigen. In der realen Welt reicht möglicherweise eine einzige Replik (Kopie) Ihrer Anwendung nicht aus, wenn sie beliebter wird und die Last steigt. Kubernetes ermöglicht es Ihnen, Ihre Anwendung einfach zu skalieren, indem Sie die Anzahl der Pod-Instanzen (Repliken) erhöhen.

Bevor wir skalieren, besprechen wir kurz, warum mehrere Repliken notwendig sind. Eine einzelne Replik einer Anwendung kann nur eine bestimmte Anzahl von gleichzeitigen Anfragen verarbeiten. Wenn der Traffic die Kapazität überschreitet, kann die Anwendung langsam werden oder nicht mehr reagieren. Mit mehreren Repliken kann die Last auf verschiedene Pod-Instanzen verteilt werden, sodass die Anwendung reaktionsfähig und verfügbar bleibt. Dieses Konzept ist für die Erstellung skalierbarer Anwendungen unerlässlich.

Sie werden nun lernen, wie Sie Ihr Kubernetes-Deployment skalieren können, indem Sie das replicas-Feld im YAML-Manifest ändern und auch den kubectl scale-Befehl verwenden.

Öffnen Sie das zuvor erstellte Deployment-Manifest:

nano ~/project/k8s-manifests/nginx-deployment.yaml

Ändern Sie das replicas-Feld von 1 auf 3:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3 ## Changed from 1 to 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:latest
          ports:
            - containerPort: 80

Speichern Sie die Datei (Strg+X, dann Y, dann Eingabe).

Wenden Sie das aktualisierte Deployment an:

kubectl apply -f ~/project/k8s-manifests/nginx-deployment.yaml

Beispielausgabe:

deployment.apps/nginx-deployment configured

Überprüfen Sie das skalierte Deployment:

kubectl get deployments
kubectl get pods

Beispielausgabe für kubectl get deployments:

NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   3/3     3            3           5m

Beispielausgabe für kubectl get pods:

NAME                                READY   STATUS    RESTARTS   AGE
nginx-deployment-xxx-yyy            1/1     Running   0          5m
nginx-deployment-xxx-zzz            1/1     Running   0          30s
nginx-deployment-xxx-www            1/1     Running   0          30s

Alternative Skalierungsmethode mit kubectl scale:

kubectl scale deployment nginx-deployment --replicas=4

Beispielausgabe:

deployment.apps/nginx-deployment scaled

Überprüfen Sie die neue Anzahl von Repliken:

kubectl get deployments
kubectl get pods

Wichtige Punkte zur Skalierung:

1. Ändern Sie replicas in der YAML-Datei oder verwenden Sie den kubectl scale-Befehl.
2. Verwenden Sie kubectl apply, um das Deployment zu aktualisieren, wenn Sie Änderungen an der YAML-Datei vornehmen.
3. Kubernetes stellt sicher, dass die gewünschte Anzahl von Repliken läuft.
4. Sie können sowohl hochskalieren (Anzahl der Repliken erhöhen) als auch herunterskalieren (Anzahl der Repliken verringern).

Überprüfung der Lastverteilung durch Prüfung der Antworten mehrerer Pods

In diesem Schritt erfahren Sie, wie Sie die Lastverteilung in Kubernetes überprüfen können, indem Sie einen Service erstellen und die Antworten von mehreren Pods prüfen. Die Lastverteilung ist entscheidend, um den Traffic auf mehrere Repliken zu verteilen und sicherzustellen, dass kein einzelner Pod überlastet wird. Kubernetes-Services übernehmen diesen Prozess automatisch.

Erstellen Sie einen Service, um das Deployment bereitzustellen:

nano ~/project/k8s-manifests/nginx-service.yaml

Fügen Sie die folgende Service-Konfiguration hinzu:

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx
  type: ClusterIP
  ports:
    - port: 80
      targetPort: 80

Speichern Sie die Datei (Strg+X, dann Y, dann Eingabe).

Erklärung der YAML-Konfiguration:

• apiVersion: v1: Gibt die API-Version für Services an.
• kind: Service: Zeigt an, dass es sich um ein Service-Objekt handelt.
• metadata: Enthält Metadaten über den Service.
  • name: nginx-service: Der Name des Services.
• spec: Enthält die Service-Spezifikation.
  • selector: Definiert, an welche Pods dieser Service den Traffic leiten wird.
    • app: nginx: Wählt Pods mit dem Label app: nginx aus, die mit den im vorherigen Schritt erstellten Pods übereinstimmen.
  • type: ClusterIP: Erstellt einen internen Service mit einer Cluster-IP-Adresse, der für die interne Kommunikation verwendet wird. Dieser Service-Typ ist nur innerhalb des Kubernetes-Clusters erreichbar.
  • ports: Definiert, wie der Service den Traffic zuordnen wird.
    • port: 80: Der Port, den der Service bereitstellt.
    • targetPort: 80: Der Port, auf dem die Anwendung im Container lauscht.

Wenden Sie den Service an:

kubectl apply -f ~/project/k8s-manifests/nginx-service.yaml

Beispielausgabe:

service/nginx-service created

Überprüfen Sie den Service:

kubectl get services

Beispielausgabe:

NAME            TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
kubernetes      ClusterIP   10.96.0.1       <none>        443/TCP   30m
nginx-service   ClusterIP   10.96.xxx.xxx   <none>        80/TCP    30s

Um nun die Lastverteilung wirklich zu überprüfen, erstellen Sie einen temporären Pod und senden mehrere Anfragen an den Service. Dadurch können Sie sehen, dass die Anfragen auf verschiedene NGINX-Pods verteilt werden.

Erstellen Sie einen temporären Pod, um die Lastverteilung zu testen:

kubectl run curl-test --image=curlimages/curl --rm -it -- sh

Dieser Befehl führt folgende Aktionen aus:

• kubectl run curl-test: Erstellt einen neuen Pod mit dem Namen curl-test.
• --image=curlimages/curl: Verwendet ein Docker-Image, in dem curl installiert ist.
• --rm: Entfernt den Pod automatisch, wenn er fertig ist.
• -it: Alloziert eine Pseudo-TTY und hält stdin geöffnet.
• -- sh: Startet eine Shell-Sitzung im Pod.

Innerhalb des temporären Pods senden Sie mehrere Anfragen:

for i in $(seq 1 10); do curl -s nginx-service | grep -q "Welcome to nginx!" && echo "Welcome to nginx - Request $i"; done

Diese Schleife sendet 10 Anfragen an den nginx-service. Jede Anfrage sollte an einen der verfügbaren NGINX-Pods weitergeleitet werden. Die Ausgabe gibt für jede erfolgreiche Anfrage Welcome to nginx - Request $i aus.

Beispielausgabe:

Welcome to nginx - Request 1
Welcome to nginx - Request 2
Welcome to nginx - Request 3
...

Verlassen Sie den temporären Pod:

exit

Wichtige Punkte zur Lastverteilung:

1. Services verteilen den Traffic auf alle übereinstimmenden Pods.
2. Jede Anfrage kann möglicherweise einen anderen Pod treffen.
3. Kubernetes verwendet standardmäßig einen Round-Robin-Ansatz.
4. Der Service-Typ ClusterIP bietet interne Lastverteilung.
5. Der curl-Test zeigt, dass die Last auf mehrere NGINX-Instanzen verteilt wird.

Dynamische Anpassung der Deployment-Skalierung an den Bedarf

In diesem Schritt üben Sie die dynamische Anpassung der Skalierung Ihres Kubernetes-Deployments an die sich ändernden Anforderungen der Anwendung mithilfe des kubectl scale-Befehls. Dieser Schritt betont den praktischen Aspekt der Anpassung der Anzahl der laufenden Repliken ohne direkte Änderung der YAML-Datei, was für schnelle Anpassungen bei Verkehrsspitzen nützlich sein kann.

Zunächst überprüfen Sie den aktuellen Status des Deployments:

kubectl get deployments

Beispielausgabe:

NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   4/4     4            4           45m

Skalieren Sie das Deployment mit dem kubectl-Befehl:

kubectl scale deployment nginx-deployment --replicas=5

Beispielausgabe:

deployment.apps/nginx-deployment scaled

Überprüfen Sie die neue Anzahl von Repliken:

kubectl get deployments
kubectl get pods

Beispielausgabe für Deployments:

NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   5/5     5            5           46m

Beispielausgabe für Pods:

NAME                                READY   STATUS    RESTARTS   AGE
nginx-deployment-xxx-yyy            1/1     Running   0          1m
nginx-deployment-xxx-zzz            1/1     Running   0          1m
nginx-deployment-xxx-www            1/1     Running   0          1m
nginx-deployment-xxx-aaa            1/1     Running   0          1m
nginx-deployment-xxx-bbb            1/1     Running   0          1m

Jetzt aktualisieren Sie die Deployment-YAML-Datei für eine dauerhafte Skalierung:

nano ~/project/k8s-manifests/nginx-deployment.yaml

Ändern Sie das replicas-Feld:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 5 ## Updated from previous value
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:latest
          ports:
            - containerPort: 80

Wenden Sie die aktualisierte Konfiguration an:

kubectl apply -f ~/project/k8s-manifests/nginx-deployment.yaml

Beispielausgabe:

deployment.apps/nginx-deployment configured

Simulieren Sie eine Herunterskalierung bei verringertem Bedarf:

kubectl scale deployment nginx-deployment --replicas=2

Beispielausgabe:

deployment.apps/nginx-deployment scaled

Überprüfen Sie die reduzierte Anzahl von Repliken:

kubectl get deployments
kubectl get pods

Wichtige Punkte zur Skalierung:

1. Verwenden Sie kubectl scale für schnelle, temporäre Skalierungen.
2. Aktualisieren Sie die YAML-Datei für eine dauerhafte Konfiguration.
3. Kubernetes stellt eine reibungslose Skalierung mit minimaler Störung sicher.
4. Sie können sowohl hoch- als auch herunterskalieren, je nach Anwendungsbedarf, sowohl mit Befehlen als auch über die Konfiguration.

Überwachen von Deployment- und Pod-Ereignissen auf Änderungen

In diesem Schritt lernen Sie, wie Sie Kubernetes-Deployments und Pods mithilfe verschiedener kubectl-Befehle überwachen können, um Änderungen zu verfolgen, Probleme zu beheben und den Lebenszyklus Ihrer Anwendungen zu verstehen. Die Beobachtbarkeit (Observability) ist entscheidend für die Gewährleistung der Gesundheit und Leistung Ihrer Anwendungen.

Beschreiben Sie das aktuelle Deployment, um detaillierte Informationen zu erhalten:

kubectl describe deployment nginx-deployment

Beispielausgabe:

Name:                   nginx-deployment
Namespace:              default
CreationTimestamp:      [timestamp]
Labels:                 app=nginx
Replicas:               2 desired | 2 updated | 2 total | 2 available | 0 unavailable
StrategyType:           RollingUpdate
MinReadySeconds:        0
RollingUpdateStrategy:  25% max unavailable, 25% max surge
Pod Template:
  Labels:  app=nginx
  Containers:
   nginx:
    Image:        nginx:latest
    Port:         80/TCP
    Host Port:    0/TCP
    Environment:  <none>
    Mounts:       <none>
Conditions:
  Type           Status  Reason
  ----           ------  ------
  Available      True    MinimumReplicasAvailable
  Progressing    True    NewReplicaSetAvailable
OldReplicaSets:  <none>
NewReplicaSet:   nginx-deployment-xxx (2/2 replicas created)
Events:          <some deployment events>

Rufen Sie detaillierte Informationen zu einzelnen Pods ab:

kubectl describe pods -l app=nginx

Die Beispielausgabe zeigt Details für jeden Pod, einschließlich:

• Aktueller Status
• Container-Informationen
• Ereignisse
• IP-Adressen
• Knoteninformationen

Zeigen Sie clusterweite Ereignisse an:

kubectl get events

Beispielausgabe:

LAST SEEN   TYPE      REASON              OBJECT                           MESSAGE
5m          Normal    Scheduled           pod/nginx-deployment-xxx-yyy    Successfully assigned default/nginx-deployment-xxx-yyy to minikube
5m          Normal    Pulled              pod/nginx-deployment-xxx-yyy    Container image "nginx:latest" already present on machine
5m          Normal    Created             pod/nginx-deployment-xxx-yyy    Created container nginx
5m          Normal    Started             pod/nginx-deployment-xxx-yyy    Started container nginx

Filtern Sie Ereignisse für bestimmte Ressourcen:

kubectl get events --field-selector involvedObject.kind=Deployment

Die Beispielausgabe zeigt nur deploymentbezogene Ereignisse.

Simulieren Sie ein Ereignis, indem Sie einen Pod löschen:

## Get a pod name
POD_NAME=$(kubectl get pods -l app=nginx -o jsonpath='{.items[0].metadata.name}')

## Delete the pod
kubectl delete pod $POD_NAME

Beobachten Sie die Ereignisse und die Pod-Wiederherstellung:

kubectl get events
kubectl get pods

Wichtige Punkte zur Überwachung:

1. kubectl describe liefert detaillierte Ressourceninformationen.
2. kubectl get events zeigt clusterweite Ereignisse an.
3. Kubernetes ersetzt automatisch gelöschte Pods.
4. Ereignisse helfen bei der Behebung von Deployment-Problemen.
5. Verwenden Sie describe für detaillierte Objektinformationen und events zum Verfolgen von Aktionen.

Kurze Einführung in den Horizontal Pod Autoscaler (HPA) für zukünftiges Lernen

In diesem Schritt erhalten Sie eine Einführung in den Horizontal Pod Autoscaler (HPA), eine leistungsstarke Kubernetes-Funktion, die Anwendungen automatisch basierend auf der Ressourcenauslastung skaliert. Der HPA ermöglicht es Ihnen, Skalierungsregeln basierend auf Metriken wie CPU-Auslastung, Speichernutzung oder sogar benutzerdefinierten Metriken zu definieren.

Grundlagen des HPA:

Der HPA passt automatisch die Anzahl der laufenden Pod-Replikate in einer Deployment, ReplicaSet oder StatefulSet an, basierend auf der beobachteten CPU- oder Speichernutzung oder auf benutzerdefinierten Metriken, die von Ihren Anwendungen bereitgestellt werden. Dies stellt sicher, dass Ihre Anwendung automatisch skaliert werden kann, um wechselnde Verkehrslasten zu bewältigen, was die Leistung und Verfügbarkeit verbessert.

Aktivieren Sie das Metrics Server-Addon in Minikube:

minikube addons enable metrics-server

Beispielausgabe:

* The 'metrics-server' addon is enabled

Der Metrics Server liefert Kubernetes mit Nutzungsdaten zu Ihren Ressourcen und ist für die Funktionsfähigkeit des HPA unerlässlich.

Erstellen Sie eine Deployment mit Ressourcenanforderungen:

nano ~/project/k8s-manifests/hpa-example.yaml

Fügen Sie den folgenden Inhalt hinzu:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: php-apache
spec:
  selector:
    matchLabels:
      run: php-apache
  replicas: 1
  template:
    metadata:
      labels:
        run: php-apache
    spec:
      containers:
        - name: php-apache
          image: k8s.gcr.io/hpa-example
          ports:
            - containerPort: 80
          resources:
            limits:
              cpu: 500m
            requests:
              cpu: 200m
---
apiVersion: v1
kind: Service
metadata:
  name: php-apache
  labels:
    run: php-apache
spec:
  ports:
    - port: 80
  selector:
    run: php-apache

Wenden Sie die Deployment an:

kubectl apply -f ~/project/k8s-manifests/hpa-example.yaml

Erklärung der YAML-Konfiguration:

• Diese YAML-Datei definiert eine Deployment für eine PHP-Anwendung und den entsprechenden Service.
• Die Deployment-Konfiguration ähnelt stark der von NGINX, mit Ausnahme von:
  • name: php-apache: Der Name der Deployment und des Pod-Containers.
  • image: k8s.gcr.io/hpa-example: Das Docker-Image für den Container.
  • resources: Dieser Abschnitt gibt die Ressourcenanforderungen für den Container an.
    • limits.cpu: 500m: Die maximale CPU, die der Container verwenden darf.
    • requests.cpu: 200m: Die garantierte CPU-Menge, die dem Container zugewiesen wird.
• Der Service ist eine Standard-Service-Konfiguration, die die Deployment intern verfügbar macht.

Erstellen Sie eine HPA-Konfiguration:

nano ~/project/k8s-manifests/php-apache-hpa.yaml

Fügen Sie das folgende HPA-Manifest hinzu:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: php-apache
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: php-apache
  minReplicas: 1
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 50

Wenden Sie die HPA-Konfiguration an:

kubectl apply -f ~/project/k8s-manifests/php-apache-hpa.yaml

Erklärung der YAML-Konfiguration:

• apiVersion: autoscaling/v2: Gibt die API-Version für HorizontalPodAutoscaler an.
• kind: HorizontalPodAutoscaler: Zeigt an, dass es sich um ein HPA-Objekt handelt.
• metadata: Enthält Metadaten über den HPA.
  • name: php-apache: Der Name des HPA.
• spec: Enthält die HPA-Spezifikation.
  • scaleTargetRef: Definiert die Ziel-Deployment, die skaliert werden soll.
    • apiVersion: apps/v1: Die API-Version der Zielressource.
    • kind: Deployment: Der Typ der Zielressource, bei dem es sich um eine Deployment handelt.
    • name: php-apache: Der Name der Ziel-Deployment, die skaliert werden soll.
  • minReplicas: 1: Die minimale Anzahl von Replikaten, die laufen bleiben sollen.
  • maxReplicas: 10: Die maximale Anzahl von Replikaten, auf die skaliert werden kann.
  • metrics: Definiert, wie die Skalierungsmetriken ermittelt werden.
    • type: Resource: Skaliert basierend auf einer Ressourcenmetrik.
    • resource.name: cpu: Skaliert basierend auf der CPU-Nutzung.
    • resource.target.type: Utilization: Skaliert basierend auf einem Prozentsatz der vom Pod angeforderten CPU.
    • resource.target.averageUtilization: 50: Skaliert, wenn die durchschnittliche CPU-Nutzung über alle Pods 50 % der Anforderungen überschreitet.

Überprüfen Sie die HPA-Konfiguration:

kubectl get hpa

Beispielausgabe:

NAME         REFERENCE              TARGETS         MINPODS   MAXPODS   REPLICAS   AGE
php-apache   Deployment/php-apache  0%/50%          1         10        1          30s

Simulieren Sie eine Last und beobachten Sie die automatische Skalierung in Echtzeit

Um eine hohe Last zu simulieren und den Autoscaler auszulösen, führen Sie in einem Terminal einen Lastgenerator aus und überwachen Sie die Skalierungsaktivität in einem separaten Terminal.

Öffnen Sie zunächst ein Terminal für den Lastgenerator:

kubectl run -i --tty load-generator --rm --image=busybox --restart=Never -- /bin/sh -c "while sleep 0.01; do wget -q -O- http://php-apache; done"

SCHLIESSEN SIE DAS TERMINAL MIT DEM LASTGENERATOR NICHT. ÖFFNEN SIE EIN ANDERES TERMINAL, um die Skalierungsaktivität zu überwachen.

Im zweiten Terminal können Sie mehrere Befehle verwenden, um die automatische Skalierung in Echtzeit zu beobachten:

1. Überwachen Sie den HPA-Status (aktualisiert sich alle paar Sekunden):

kubectl get hpa -w

2. Beobachten Sie, wie Pods erstellt werden, wenn der HPA hochskaliert:

kubectl get pods -w

3. Verfolgen Sie Ereignisse, die sich auf die Skalierungsaktivität beziehen:

kubectl get events --sort-by='.lastTimestamp' -w

Sie können jeden dieser Befehle ausführen, um verschiedene Aspekte des Skalierungsprozesses zu beobachten. Beispielsweise zeigt das Beobachten von Pods mit der -w-Option, wie Pods in Echtzeit erstellt werden, wenn das System skaliert:

Beispielausgabe für kubectl get pods -w:

NAME                         READY   STATUS    RESTARTS   AGE
php-apache-xxxxxxxxx-xxxxx   1/1     Running   0          2m
load-generator               1/1     Running   0          30s
php-apache-xxxxxxxxx-yyyyy   0/1     Pending   0          0s
php-apache-xxxxxxxxx-yyyyy   0/1     ContainerCreating   0          0s
php-apache-xxxxxxxxx-yyyyy   1/1     Running   0          3s
php-apache-xxxxxxxxx-zzzzz   0/1     Pending   0          0s
php-apache-xxxxxxxxx-zzzzz   0/1     ContainerCreating   0          0s
php-apache-xxxxxxxxx-zzzzz   1/1     Running   0          2s

Sie werden sehen, dass der HPA auf die erhöhte Last reagiert, indem er die Anzahl der Pods erhöht. Die Aktualisierung der Metriken kann eine Minute oder länger dauern, um die Änderungen widerzuspiegeln:

Beispielausgabe für kubectl get hpa -w:

NAME         REFERENCE               TARGETS   MINPODS   MAXPODS   REPLICAS   AGE
php-apache   Deployment/php-apache   0%/50%    1         10        1          30s
php-apache   Deployment/php-apache   68%/50%   1         10        1          90s
php-apache   Deployment/php-apache   68%/50%   1         10        2          90s
php-apache   Deployment/php-apache   79%/50%   1         10        2          2m
php-apache   Deployment/php-apache   79%/50%   1         10        4          2m15s

Wenn Sie mit der Beobachtung fertig sind, drücken Sie Ctrl+C, um den Überwachungsbefehl zu beenden, und kehren Sie dann zum ersten Terminal zurück und drücken Sie Ctrl+C, um den Lastgenerator zu stoppen.

Wichtige Punkte zum HPA:

1. Skaliert Pods automatisch basierend auf der Ressourcenauslastung, was die Resilienz der Anwendung verbessert.
2. Kann basierend auf CPU, Speicher oder benutzerdefinierten Metriken skaliert werden.
3. Definiert die minimale und maximale Anzahl von Replikaten, um eine ausgewogene und effiziente Skalierung sicherzustellen.
4. Der HPA ist eine entscheidende Komponente für die Aufrechterhaltung der Anwendungsleistung und -verfügbarkeit bei wechselnden Lasten.
5. Die Verwendung der -w-Option (watch) mit kubectl-Befehlen ermöglicht die Echtzeitüberwachung von Clusteränderungen.

Zusammenfassung

In diesem Lab haben Sie praktische Erfahrungen mit Skalierung und Lastverteilung in Kubernetes gesammelt. Sie haben begonnen, indem Sie einen lokalen Kubernetes-Cluster mit Minikube erstellt und eine einfache NGINX-Webanwendung bereitgestellt haben. Anschließend haben Sie verschiedene Skalierungsmethoden untersucht, darunter die Modifikation von Deployment-YAML-Dateien und die Verwendung von kubectl scale, um die Anzahl der Pod-Replikate anzupassen. Sie haben gelernt, wie Sie die Lastverteilung mithilfe von Kubernetes-Services und einem temporären Test-Pod überprüfen können.

Darüber hinaus haben Sie gelernt, wie Sie Deployments und Pods mithilfe der Befehle kubectl describe und kubectl get events überwachen können. Schließlich haben Sie ein grundlegendes Verständnis des Horizontal Pod Autoscalers (HPA) erlangt, einschließlich dessen Funktionsweise, wie er Ihre Anwendung basierend auf der Ressourcenauslastung automatisch skalieren kann, anhand eines Beispiels mit einem php-apache-Image. Dieses Lab bietet eine umfassende Einführung in Kubernetes-Skalierung, Lastverteilung, Überwachung und Autoskalierungstechniken und legt die Grundlage für die Verwaltung komplexerer Anwendungen in Kubernetes.