Lebenszyklus von Apps verwalten

Führen Sie mithilfe von Kubernetes-nativen Tools und Tools von anderen Anbietern rollierende Aktualisierungen und Rollbacks durch, ohne dass Ihren Benutzern hierdurch Ausfallzeiten entstehen.

Updatestrategien

Um Ihre App zu aktualisieren, können Sie aus verschiedenen Strategien auswählen, wie z. B. den folgenden. Sie können mit einer rollierenden Bereitstellung oder sofortigen Umschaltung beginnen, bevor Sie sich mit einer komplexeren Canary-Bereitstellung beschäftigen.

Rollierende Bereitstellung: Sie können Kubernetes-native Funktionen verwenden, um eine v2-Bereitstellung zu erstellen und die vorherige v1-Bereitstellung nach und nach zu ersetzen. Diese Strategie erfordert, dass Apps rückwärtskompatibel sind, damit Benutzer, denen die v2-App-Version bereitgestellt wird, keine unterbrechenden Änderungen erfahren. Weitere Informationen finden Sie unter Laufende Bereitstellungen zum Aktualisieren der Apps verwalten.
Sofortige Umschaltung: Eine sofortige Umschaltung, auch als Blue-Green Deployment bezeichnet, erfordert die doppelten Datenverarbeitungsressourcen, um zwei Versionen einer App gleichzeitig auszuführen. Mit diesem Ansatz können Sie Ihre Benutzer nahezu in Echtzeit auf die neuere Version umschalten. Stellen Sie sicher, dass Sie Service-Label-Selektoren (wie z. B. version: green und version: blue) verwenden, um zu gewährleisten, dass Anfragen an die richtige App-Version gesendet werden. Sie können die neue Bereitstellung mit version: green erstellen, warten, bis sie bereit ist, und anschließend die Bereitstellung mit version: blue löschen. Sie können auch eine rollierende Aktualisierung ausführen, aber legen Sie den Parameter maxUnavailable auf 0% und den Parameter maxSurge auf 100% fest.
Canary- oder A/B-Bereitstellung: Eine Canary-Bereitstellung ist eine komplexere Aktualisierungsstrategie und besteht darin, dass Sie einen Prozentsatz von Benutzern wie z. B. 5% wählen und diese an die neue App-Version senden. Sie erfassen Metriken in Ihren Protokollierungs- und Überwachungstools zur Leistung der neuen App-Version, führen A/B-Tests durch und implementieren dann die Aktualisierung für weitere Benutzer. Wie bei allen Bereitstellungen ist die Bezeichnung der App (z. B. mit version: stable und version: canary) von entscheidender Bedeutung. Um Canary-Bereitstellungen zu verwalten, können Sie den Add-on-Service-Mesh „ Istio “ installieren, „ Monitoring “ für Ihren Cluster einrichten und anschließend den Service-Mesh „ Istio “ für A/B-Tests verwenden, wie in diesem Blogbeitrag beschrieben.

Apps skalieren

Mit „ Kubernetes “ können Sie die horizontale Pod-Autoskalierung aktivieren, um die Anzahl der Instanzen Ihrer Anwendungen je nach CPU-Auslastung automatisch zu erhöhen oder zu verringern.

Möchten Sie Ihre Workerknoten anstelle Ihrer Pods skalieren? Probieren Sie den Cluster-Autoscaler aus.

Vorbereitende Schritte:

Melden Sie sich an Ihrem Konto an. If applicable, target the appropriate resource group. Legen Sie den Kontext für den Cluster fest.
Stellen Sie sicher, dass Ihnen eine Servicezugriffsrolle zugeordnet ist, die Ihnen die entsprechende RBAC-Rolle für Kubernetes erteilt, um mit Kubernetes-Ressourcen in dem Namensbereich arbeiten zu können.

Zur Skalierung Ihrer Anwendungen:

Stellen Sie Ihre App für einen Cluster über die Befehlszeilenschnittstelle (CLI) bereit. Für Bereitstellungen mit einem höheren Grad an Komplexität ist gegebenenfalls die Erstellung einer Konfigurationsdatei erforderlich.
```
kubectl create deployment <app_name> --image=<image>
```
Legen Sie für die Container, die in Ihrer Bereitstellung ausgeführt werden, Grenzwerte für CPU-Ressourcen in Millicores (m) fest, beispielsweise 100m. Sie können auch Speicherbegrenzungen festlegen, wobei jedoch die Funktion zur horizontalen automatischen Pod-Skalierung (Horizontal Pod Autoscaler, HPA) nur CPU-Ressourcengrenzen für die Skalierung berücksichtigt. Weitere Informationen finden Sie in der Dokumentation zu „ kubectl set resources “.
```
kubectl set resources deployment <app_name> --limits=cpu=100m
```

Erstellen Sie eine Funktion zur horizontalen automatischen Pod-Skalierung und definieren Sie Ihre Richtlinie. Weitere Information finden Sie in der Dokumentation für kubectl autoscale.

kubectl autoscale deployment <deployment_name> --cpu-percent=<percentage> --min=<min_value> --max=<max_value>

Verstehen Sie Ihre Befehlsoptionen
Optionen	Beschreibung
`--cpu-percent`	Die durchschnittliche CPU-Auslastung, die durch die Funktion zur automatischen horizontalen Skalierung von Pods (Horizontal Pod Autoscaler) aufrechterhalten wird. Die Angabe erfolgt als Prozentsatz.
`--min`	Die Mindestanzahl von bereitgestellten Pods, die zur Aufrechterhaltung der angegebenen CPU-Auslastung verwendet werden.
`--max`	Die maximale Anzahl von bereitgestellten Pods, die zur Aufrechterhaltung der angegebenen CPU-Auslastung verwendet werden.

Laufende Bereitstellungen zum Aktualisieren der Apps verwalten

Sie können den Rollout von App-Änderungen auf eine automatisierte und gesteuerte Art für Workloads mit einer Pod-Vorlage verwalten, z. B. Bereitstellungen. Wenn der Rollout nicht nach Plan verläuft, können Sie die Bereitstellung auf die vorherige Revision rückgängig machen.

Möchten Sie Ausfallzeiten während einer rollierenden Aktualisierung vermeiden? Stellen Sie sicher, dass eine Bereitschaftsprüfung in der Bereitstellung angegeben ist, damit mit dem Rollout der nächsten App fortgefahren wird, wenn die Aktualisierung der letzten App abgeschlossen ist.

Vorbereitende Schritte:

Melden Sie sich an Ihrem Konto an. If applicable, target the appropriate resource group. Legen Sie den Kontext für den Cluster fest.
Erstellen Sie eine Bereitstellung.
Stellen Sie sicher, dass Sie über eine Servicezugriffsrolle verfügen, die Ihnen die entsprechende RBAC-Rolle für Kubernetes erteilt, um mit Kubernetes-Ressourcen in dem Namensbereich arbeiten zu können.

Gehen Sie wie folgt vor, um rollierende Aktualisierungen für Ihre Apps zu verwalten:

Um sicherzustellen, dass Ihre Bereitstellungen nur dann als bereit markiert werden, wenn der Container aktiv und bereit zum Verarbeiten von Anforderungen ist, fügen Sie Aktivitäts- und Bereitschaftsprüfungen für Ihre Bereitstellung hinzu.
Aktualisieren Sie Ihre Bereitstellung so, dass sie eine Strategie für rollierende Aktualisierungen enthält, die die maximalen Bedarfsspitzen und nicht verfügbaren Pods oder den Prozentsatz der Pods während der Aktualisierung angibt.
```
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-test
spec:
  replicas: 10
  selector:
    matchLabels:
      service: http-server
  minReadySeconds: 5
  progressDeadlineSeconds: 600
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 50%
      maxSurge: 2
...
```
spec.minReadySeconds

Standardmäßig warten Bereitstellungen, bis der Pod als ready (bereit) markiert ist, bevor sie mit dem Rollout fortfahren. Wenn Sie feststellen, dass die Bereitstellung weiterhin Pods erstellt, obwohl Ihre App im neuesten Pod noch nicht bereit ist, verwenden Sie dieses Feld, um den Bereitstellungs-Rollout zu verlangsamen. Wenn Sie z. B. 5 angeben, wartet die Bereitstellung 5 Sekunden, nachdem der Pod ready ist, bevor er den nächsten Pod erstellt.

spec.progressDeadlineSeconds

Legen Sie ein Zeitlimit in Sekunden fest, bevor eine Bereitstellung als fehlgeschlagen betrachtet wird. Wenn Ihre neue App-Version beispielsweise ohne Zeitlimitüberschreitung einen Programmfehler aufweist und sofort blockiert wird, kann die Implementierung nicht fortgesetzt werden, da der Pod nie den Status ready erreicht. Wenn Sie dieses Zeitlimit auf 600 Sekunden setzen, wird die Bereitstellung, wenn eine Phase des Rollout während 10 Minuten keinen Fortschritt zeigt, als fehlgeschlagen markiert und das Rollout gestoppt.

spec.strategy.type

Geben Sie den Strategietyp RollingUpdate an.

spec.strategy.rollingUpdate.maxUnavailable

Legen Sie die maximale Anzahl von Pods, die während einer Aktualisierung nicht verfügbar sein können, als Zahl (2) oder als Prozentsatz (50%) fest. Verwenden Sie Im Allgemeinen einen Prozentsatz, sodass Sie, wenn Sie die Anzahl der Replikate später ändern, nicht daran denken müssen, die Zahl hier zu aktualisieren - es sei denn, Sie möchten den Rollout darauf begrenzen, dass nur ein einziger Pod zu einem bestimmten Zeitpunkt inaktiv sein kann. Wenn Sie nicht möchten, dass die Auslastung jemals unter 100 % fällt, setzen Sie diesen Wert auf „ 0% “ und geben Sie den Parameter „ spec.strategy.type.rollingUpdate.maxSurge “ an.

spec.strategy.rollingUpdate.maxSurge

Legen Sie fest, wie viele zusätzliche Ressourcen die Bereitstellung während des Rollouts verwenden kann, und zwar als Zahl (2) oder Prozentsatz (50%). Wenn Ihre Bereitstellung beispielsweise 10 Replikate angibt und Sie maxSurge auf 2 setzen, werden während des Rollouts zwei neue Replikate erstellt. Sie haben jetzt 12 Replikate (10 vorhanden, 2 neu). Nachdem die beiden neuen Replikate bereit sind, skaliert die Bereitstellung die alten Replikate auf 8 herunter, um die spezifizierten 10 Replikate zu erfüllen. Dieser Prozess wird so lange fortgesetzt, bis der Rollout abgeschlossen ist und alle 10 Replikate die neue Version ausführen.

Wenn Sie eine sofortige Blue-Green-Switch-Stilaktualisierung durchführen wollen, legen Sie maxSurge auf 100% fest. Die Bereitstellung erstellt alle neuen erforderlichen Replikate und skaliert dann die Replikate der alten Version auf 0 herunter.

Implementieren Sie eine Änderung. Beispiel: Sie möchten das Image ändern, das Sie in Ihrer ursprünglichen Bereitstellung verwendet haben.

Rufen Sie den Namen der Bereitstellung ab.

    kubectl get deployments
    ```
2. Rufen Sie den Namen des Pods ab.

```sh {: pre}
    kubectl get pods
    ```
3. Rufen Sie den Namen des Containers ab, der im Pod ausgeführt wird.

```sh {: pre}
    kubectl describe pod <pod_name>
    ```
4. Legen Sie das neue Image fest, das für die Bereitstellung verwendet werden soll.

```sh {: pre}
    kubectl set image deployment/<deployment_name> <container_name>=<image_name>
    ```
Wenn Sie die Befehle ausführen, wird die Änderung unverzüglich angewendet und im Rolloutprotokoll protokolliert.

Überprüfen Sie den Status der Bereitstellung.
```
kubectl rollout status deployments/<deployment_name>
```
Wenn Sie etwas an dem Status bemerken, das Sie über eine bestimmte Zeit verfolgen möchten, können Sie den Rollout mit den folgenden Befehlen anhalten und fortsetzen.
```
kubectl rollout pause deployment <deployment_name>
```
```
kubectl rollout resume deployment <deployment_name>
```

Machen Sie die Änderung rückgängig.

Zeigen Sie das Rolloutprotokoll für die Bereitstellung an und ermitteln Sie die Revisionsnummer Ihrer letzten Bereitstellung.

    kubectl rollout history deployment/<deployment_name>
    ```
    Schließen Sie zum Anzeigen der Details für eine bestimmte Revision die Revisionsnummer ein.
    {: tip}

    ```sh {: pre}
    kubectl rollout history deployment/<deployment_name> --revision=<number>
    ```
2. Führen Sie ein Rollback auf die frühere Version durch oder geben Sie eine Revision an. Verwenden Sie für das Rollback auf die frühere Version den folgenden Befehl.

```sh {: pre}
    kubectl rollout undo deployment/<deployment_name> --to-revision=<number>
    ```

CI/CD (Continuous Integration and Delivery) einrichten

Mit IBM Cloud und mit anderen Open-Source-Tools können Sie CI/CD, Versionssteuerung, Toolchains und andere Features einrichten, um die Automatisierung der App-Entwicklung und -Bereitstellung zu unterstützen.

Eine Liste der unterstützten Integrationen und der Schritte zum Einrichten einer kontinuierlichen Bereitstellungspipeline finden Sie in der IBM Cloud Konsole und der zugehörigen Cluster-Dokumentation.

Bereitstellungen in einen anderen Cluster kopieren

Wenn Sie in Ihrem Cluster ein Versionskontrollsystem wie Git, Konfigurationsmanagement-Projekte oder Continuous-Delivery-Tools verwenden, können Sie Ihre App-Konfigurationsdateien schnell von einem Cluster auf einen anderen bereitstellen. Es kann vorkommen, dass Sie nur über wenige Bereitstellungen verfügen, die Sie in einem Cluster getestet haben, und es vorziehen, diese Bereitstellungen zu kopieren und in einem anderen Cluster erneut bereitzustellen.

Bevor Sie beginnen, benötigen Sie zwei Cluster und die „ Manager Service-Zugriffsrolle “ für alle Namespaces in beiden Clustern, damit Sie alle Ressourcen aus einem Cluster kopieren und in einem anderen bereitstellen können.

Melden Sie sich an Ihrem Konto an. If applicable, target the appropriate resource group. Legen Sie den Kontext für den Cluster fest.

Rufen Sie eine Liste aller Konfigurationsdateien in Ihrem Cluster ab und überprüfen Sie, ob diese Konfigurationen auch tatsächlich kopiert werden sollen.

kubectl get all

Beispielausgabe

NAME                                   READY   STATUS             RESTARTS   AGE
pod/java-web-6955bdbcdf-l756b          1/1     Running            0          59d
NAME                                   TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
service/java-web                       NodePort    172.21.xxx.xxx   <none>        8080:30889/TCP   59d
NAME                                   READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/java-web               1/1     1            1           59d
NAME                                   DESIRED   CURRENT   READY   AGE
replicaset.apps/java-web-6955bdbcdf    1         1         1       59d

Kopieren Sie die Konfigurationsdateien in Ihrem Cluster in ein lokales Verzeichnis. Entfernen Sie anschließend manuell clusterspezifische Felder wie „ resourceVersion “, „ uid “, „ creationTimestamp “ und „ status “ aus der exportierten YAML-Datei, bevor Sie die Dateien auf einen anderen Cluster anwenden.
```
kubectl get all -o yaml > myconfigs.yaml
```
Melden Sie sich an Ihrem Konto an. If applicable, target the appropriate resource group. Legen Sie den Kontext für den Cluster fest.
Optional: Falls Ihr Cluster mehrere Namespaces verwendet hat, erstellen Sie dieselben Namespaces im Standard-Cluster und kopieren Sie das „Image Pull“-Secret in jeden Namespace.
Stellen Sie die kopierten Konfigurationsdateien in Ihrem Cluster bereit. Wenn eine Konfigurationsdatei bestimmte Informationen enthält, die nicht angewendet werden können, müssen Sie möglicherweise die Konfigurationsdatei aktualisieren und erneut anwenden.
```
kubectl apply -f myconfigs.yaml
```
Beispielausgabe
```
pod/java-web-6955bdbcdf-l756b created
service/java-web created
deployment.apps/java-web created
replicaset.apps/java-web-6955bdbcdf created
```
Überprüfen Sie, ob Ihre Konfigurationsdateien auch angewendet werden.
```
kubectl get all
```