So konfigurieren Sie Kubernetes für Rolling Update

Einführung

Laufende Updates sind ein wichtiger Bestandteil des Lebenszyklus einer modernen App, wobei Benutzer ständig neue Funktionen und keine Ausfallzeiten erwarten. Während Kubernetes in der Vergangenheit Replication Controller verwendet hat, um diese Funktionalität zu ermöglichen, empfehlen neuere Versionen die Verwendung von Deployments.

Dieses Tutorial zeigt Ihnen, wie Sie fortlaufende Updates mit Kubernetes-Bereitstellungen durchführen. Mit dieser Methode können Sie Ihre Apps schnell aktualisieren und keine Ausfallzeiten erreichen, während Rollback-Unterstützung gewährleistet ist.

Voraussetzungen

• Ein Kubernetes-Cluster
• Zugriff auf ein Terminalfenster
• Das kubectl-Befehlszeilentool

Laufende Updates aktivieren

Kubernetes-Bereitstellungen fungieren als Wrapper um ReplicaSets, bei denen es sich um Kubernetes-Controller handelt, die für die Pod-Verwaltung zuständig sind. Bereitstellungen stellen ReplicaSets zusätzliche Funktionen bereit – sie führen Zustandsprüfungen, fortlaufende Updates und Rollbacks durch.

1. Erstellen Sie zuerst eine yaml Datei mit Bereitstellungsspezifikationen mit einem Texteditor wie Nano:

nano nginx-test.yaml

Die folgende Beispieldatei enthält die grundlegenden Deklarationen, die für eine Kubernetes-Bereitstellung erforderlich sind:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 4
  selector:

    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2

        ports:
        - containerPort: 80

2. Speichern und beenden Sie die Datei.

3. Erstellen Sie dann die Bereitstellung mit kubectl create Befehl und die yaml Datei, die Sie gerade erstellt haben:

kubectl create -f nginx-test.yaml

4. Überprüfen Sie die Bereitstellung:

kubectl get deployment

Die Ausgabe sollte bestätigen, dass die Bereitstellung bereit ist:

4. Überprüfen Sie als Nächstes die ReplicaSets, indem Sie den folgenden Befehl ausführen:

kubectl get rs

In der Beispieldatei sind vier Repliken angegeben, die alle als bereit angezeigt werden:

5. Überprüfen Sie abschließend, ob die Pods oben sind:

kubectl get pod

Die Ausgabe zeigt Pods als bereit und ausgeführt:

Stellen Sie null Ausfallzeiten sicher

Um rollierende Updates ohne Ausfallzeit zu konfigurieren, müssen Sie die Update-Strategie angeben.

1. Fügen Sie der Bereitstellung yaml die folgende Deklaration hinzu Datei unter spec Kategorie:

minReadySeconds: 5
strategy:
  type: RollingUpdate
  rollingUpdate:
    maxSurge: 1
    maxUnavailable: 1

• minReadySeconds teilt Kubernetes mit, wie lange es warten soll, bis es den nächsten Pod erstellt. Diese Eigenschaft stellt sicher, dass sich alle Anwendungs-Pods während des Updates im Bereitschaftszustand befinden.
• maxSurge gibt die maximale Anzahl (oder den Prozentsatz) von Pods über der angegebenen Anzahl von Replikaten an. Im obigen Beispiel beträgt die maximale Anzahl von Pods 5 seit 4 Replikate werden in yaml angegeben Datei.
• maxUnavailable gibt die maximale Anzahl (oder den Prozentsatz) nicht verfügbarer Pods während des Updates an. Wenn maxSurge auf 0 gesetzt ist , darf dieses Feld nicht 0 sein .

Hinzufügen der obigen Spezifikation zur yaml-Bereitstellung Datei ausreicht, um mit der Durchführung fortlaufender Kubernetes-Updates zu beginnen. Es garantiert jedoch keine Null-Ausfallzeit. Kubernetes kann nicht erkennen, wann ein neuer Pod fertig ist – es eliminiert den alten Pod, sobald der neue erstellt wird. Dieses Problem führt zu Ausfallzeiten, bis der neue Pod Anforderungen annehmen kann.

Um dieses Problem zu beheben, bietet Kubernetes das Konzept der Readiness Probes . Die Probes überprüfen den Status von Pods und ermöglichen fortlaufende Aktualisierungen nur dann, wenn alle Container in einem Pod bereit sind. Pods gelten als bereit, wenn die Bereitschaftsprüfung erfolgreich ist und nach der in minReadySeconds angegebenen Zeit ist bestanden.

2. Um Readiness Probes einzurichten, fügen Sie die folgenden Zeilen zu spec.template.spec hinzu Kategorie in der Bereitstellungsdatei:

readinessProbe:
  httpGet:
    path: /
    port: 8080
    initialDelaySeconds: 5
    periodSeconds: 5
    successThreshold: 1

• initialDelaySeconds gibt an, wie lange die Sonde warten muss, um zu starten, nachdem der Container gestartet wurde.
• periodSeconds ist die Zeit zwischen zwei Sonden. Der Standardwert ist 10 Sekunden, während der Minimalwert 1 ist zweitens.
• successThreshold ist die Mindestanzahl aufeinanderfolgender erfolgreicher Tests nach einem fehlgeschlagenen, damit der gesamte Prozess als erfolgreich betrachtet wird. Der Standard- und Minimalwert sind beide 1 .

Die gesamte Bereitstellungsdatei, die ordnungsgemäß für Rolling Updates konfiguriert ist, sollte folgendermaßen aussehen:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 4
  selector:

    matchLabels:
      app: nginx
  minReadySeconds: 5
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.0

        ports:
        - containerPort: 80
        readinessProbe:
          httpGet:
            path: /
            port: 8080
            initialDelaySeconds: 5
            periodSeconds: 5
            successThreshold: 1
        

3. Speichern Sie die Datei und beenden Sie sie.

4. Verwenden Sie dann kubectl apply um die Änderungen zu übernehmen:

kubectl apply -f nginx-text.yaml --record

Der --record Flag wird im Rollback-Prozess einen Zweck erfüllen.

Die Ausgabe zeigt, dass die Bereitstellung erfolgreich konfiguriert wurde.

Rollendes Update durchführen

Es gibt drei Möglichkeiten, Rolling Updates durchzuführen.

So ändern Sie beispielsweise das App-Image:

Option 1:Sie können kubectl set verwenden um die Aktion auf der Kommandozeile auszuführen:

kubectl set image deployment nginx-deployment nginx=nginx:1.14.2 --record

Option 2:Ändern Sie alternativ die Image-Version in spec.templates.spec.containers Abschnitt der yaml Datei. Verwenden Sie dann kubectl replace um das Update durchzuführen:

kubectl replace -f nginx-test.yaml

Option 3:Sie können auch kubectl edit verwenden um die Bereitstellung direkt zu bearbeiten:

kubectl edit deployment nginx-deployment --record

Nehmen Sie die erforderlichen Änderungen im sich öffnenden Editor vor:

Die Änderungen werden übernommen, wenn Sie den Editor schließen.

Rollout-Status prüfen

Überprüfen Sie den Rollout-Status der Bereitstellung mit der folgenden Syntax:

kubectl rollout status deployment nginx-deployment

Die Ausgabe bestätigt den erfolgreichen Rollout:

Rollendes Update anhalten und fortsetzen

Laufende Updates mit dem entsprechenden kubectl rollout anhalten und fortsetzen Befehle.

Um die Aktualisierung anzuhalten, führen Sie Folgendes aus:

kubectl rollout pause deployment nginx-deployment

Um die Aktualisierung fortzusetzen, führen Sie Folgendes aus:

kubectl rollout resume deployment nginx-deployment

Pods für die Bereitstellung planen

Verwenden Sie Affinitäts- und Anti-Affinitätseigenschaften, um zu steuern, auf welchen Knoten Kubernetes bestimmte Pods in Ihrer Bereitstellung plant.

Pod-Affinität

Es gibt zwei Arten von Affinität derzeit in Kubernetes verfügbar:

• requiredDuringSchedulingIgnoredDuringExecution weist Kubernetes an, Pods nur auf Knoten auszuführen, die bestimmte Kriterien erfüllen, z. B. einen bestimmten Prozessortyp.
• preferredDuringSchedulingIgnoredDuringExecution ermöglicht es, Pods an anderer Stelle auszuführen, wenn und nur wenn keine Knoten bestimmte Kriterien erfüllen.

Diese Eigenschaften sind in der PodSpec aufgeführt Datei. Ein Pod kann beispielsweise wie folgt angegeben werden:

apiVersion: v1
kind: Pod
metadata:
  name: affinity-test
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: kubernetes.io/test-name
            operator: In
            values:
            - test1
            - test2
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1
        preference:
          matchExpressions:
          - key: example-node-label-key
            operator: In
            values:
            - example-node-label-value
  containers:
  - name: affinity-test
    image: k8s.gcr.io/pause:2.0

Die obige Datei weist Kubernetes an, den Pod nur auf einem Knoten mit einem Label auszuführen, dessen Schlüssel kubernetes.io/test-name ist und dessen Wert entweder test1 ist oder test2 . Darüber hinaus bevorzugt Kubernetes Knoten, deren Schlüssel example-node-label-key ist , mit dem example-node-label-value Wert.

Pod-Anti-Affinität

Pod-Anti-Affinität ist nützlich, wenn Sie nicht möchten, dass alle Pods auf demselben Knoten ausgeführt werden. Sie funktioniert ähnlich wie die Affinität, wobei dieselben zwei Typen verfügbar sind:requiredDuringSchedulingIgnoredDuringExecution und preferredDuringSchedulingIgnoredDuringExecution .

Das folgende Beispiel gibt eine Anti-Affinitätsregel an, die Kubernetes anweist, die „Test“-App-Pods vorzugsweise nicht für Knoten zu planen, die bereits die „Test“-Pods haben:

podAntiAffinity:
  preferredDuringSchedulingIgnoredDuringExecution:
  - weight: 100
    podAffinityTerm:
      labelSelector:
        matchExpressions:
        - key: app
          operator: In
          values: 
          - test
      topologyKey: Kubernetes.io/hostname

Rollback-Änderungen

Wenn beim Aktualisierungsprozess etwas schief geht, können Sie Änderungen rückgängig machen und zu einer früheren Version der App zurückkehren. Verwenden Sie dazu das folgende kubectl rollout Befehl:

kubectl rollout history deployment nginx-deployment

Die Ausgabe listet die verfügbaren Revisionen auf, die durch Hinzufügen von --record erstellt wurden Flag beim Ausführen eines Updates:

Wählen Sie die gewünschte Revision aus und geben Sie den folgenden Befehl ein, um die Änderungen rückgängig zu machen:

kubectl rollout undo deployment nginx-deployment --to-revision=1

Der obige Befehl kehrt zu Revision 1 zurück und erzeugt die folgende Ausgabe: