Konzept: Bereitstellen einer Anwendung

Abgeschlossen

Bevor Sie Ihre Anwendung in Kubernetes bereitstellen, lesen wir Kubernetes-Bereitstellungen und besprechen deren Einschränkungen in unserem Szenario.

Was sind Kubernetes-Bereitstellungen?

Eine Kubernetes-Bereitstellung ist eine Weiterentwicklung von Pods. Bereitstellungen verpacken Pods in ein intelligentes Objekt, mit dem sie aufskaliert werden können. Sie können Ihre Anwendung problemlos duplizieren und skalieren, um eine höhere Auslastung zu unterstützen, ohne dass Sie komplexe Netzwerkregeln konfigurieren müssen.

Bereitstellungen ermöglichen es Ihnen, Ihre Anwendungen ohne Ausfallzeiten zu aktualisieren, indem Sie das Image-Tag ändern. Durch das Aktualisieren einer Bereitstellung werden die Online-Apps einzeln deaktiviert und durch die neueste Version ersetzt, anstatt alle Apps zu löschen und neue zu erstellen. Dies bedeutet, dass die Bereitstellung die darin enthaltenen Pods ohne sichtbare Auswirkungen auf die Verfügbarkeit aktualisieren kann.

Obwohl es viele Nutzen für die Verwendung von Bereitstellungen über Pods gibt, sind sie nicht in der Lage, unser Szenario angemessen zu behandeln.

Dieses Szenario umfasst eine ereignisgesteuerte Anwendung, die eine große Anzahl von Ereignissen zu verschiedenen Zeiten empfängt. Ohne ein KEDA Scaler-Objekt oder HPA müssen Sie die Anzahl der Replikate manuell anpassen, um die Anzahl der Ereignisse zu verarbeiten und die Bereitstellung nach unten zu skalieren, wenn die Last wieder normal ist.

Stichproben-Bereitstellungsmanifest

Hier sehen Sie einen Stichprobenausschnitt unseres Bereitstellungsmanifests:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: contoso-microservice
spec:
  replicas: 10                      # Tells K8S the number of pods needed to process the Redis list items
  selector:                         # Define the wrapping strategy
    matchLabels:                    # Match all pods with the defined labels
      app: contoso-microservice     # Labels follow the `name: value` template
  template:                         # Template of the pod inside the deployment
    metadata:
      labels:
        app: contoso-microservice
    spec:
      containers:
        - image: mcr.microsoft.com/mslearn/samples/redis-client:latest
          name: contoso-microservice

Im Beispielmanifest ist replicas auf 10 festgelegt. Dies ist die höchste Zahl, die wir für erforderliche Replikate festlegen können, welche für die Verarbeitung der Spitzenanzahl von Ereignissen verfügbar sind. Dies führt jedoch dazu, dass die Anwendung in Zeiten, in denen es keine Spitzenlast gibt, zu viele Ressourcen verbraucht, wodurch andere Bereitstellungen innerhalb des Clusters untergehen könnten.

Eine Lösung besteht darin, eine eigenständige HPA zu verwenden, um die CPU-Auslastung der Pods zu überwachen. Dies ist eine bessere Option als die manuelle Skalierung in beide Richtungen. Die HPA konzentriert sich jedoch nicht auf die Anzahl der empfangenen Ereignisse in der Redis-Liste.

Die beste Lösung ist die Verwendung von KEDA und einem Redis-Skalierer, um die Liste abzufragen und festzustellen, ob mehr oder weniger Pods zur Verarbeitung der Ereignisse benötigt werden.