Containerarbeitslasten für verbesserte Laufzeit upgraden

Wenn bereits Containerarbeitslasten mit den Migrate to Containers-Versionen 1.7.x und 1.8.x erstellt wurden, können Sie diese in den vereinfachten Linux-Dienstmanager konvertieren. Mit dieser Konvertierung können Sie diese Container dann in GKE Autopilot-Clustern ausführen.

Hinweis: Die Konvertierung einer Containerarbeitslast, die mit Migrate to Containers-Versionen vor 1.7.0 erstellt wurde, wird nicht unterstützt.

Zum Ausführen der Konvertierung bearbeiten Sie das Dockerfile und die Datei deployment_spec.yaml, die bei der ursprünglichen Migration erstellt wurden. Anschließend können Sie die Containerarbeitslast in Autopilot-Clustern bereitstellen.

Informationen zu Konvertierungen von Containerarbeitslasten

Das Verfahren zur Konvertierung vorhandener Arbeitslasten hängt auch davon ab, ob Sie eine zustandslose Arbeitslast oder eine zustandsorientierte Arbeitslast konvertieren.

Eine zustandsorientierte Arbeitslast verwaltet oder speichert Statusinformationen. Bei zustandsorientierten Arbeitslasten stellen Sie häufig zusätzliche Volumes mithilfe von StatefulSet in spec.containers.volumeMounts bereit. Behalten Sie die volumeMounts-Definitionen bei und entfernen Sie sie auch für /sys/fs/cgroup. Weitere Informationen finden Sie unter Externe Volumes bereitstellen.

Für die allgemeine Konvertierung einer vorhandenen Arbeitslast ist Folgendes erforderlich:

• Dockerfile

  • Migrate to Containers-Version auf 1.15.0 festlegen
  • Fügen Sie zwei ADD-Befehle ein, um die Datei logs.yaml in das Container-Image zu kopieren.
  • Fügen Sie einen RUN-Befehl für das Dienstprogramm servicemanager_generate_config ein.

• deployment_spec.yaml-Datei für:

  • Löschen Sie die Definitionen hostPath und volumeMounts für /sys/fs/cgroup.
  • Löschen Sie die Definition securityContext.
  • Löschen Sie die Definition readinessProbe.
  • Sie können die Definitionen mountPath und configMap für logs-config beibehalten. Logging funktioniert jedoch derzeit nicht mit dem vereinfachten Linux-Dienstmanager.

Informationen zum jeweiligen Konvertierungsprozess finden Sie in den folgenden Abschnitten:

• Zustandslose Arbeitslast konvertieren
• Zustandsorientierte Arbeitslast konvertieren

Zustandslose Arbeitslast konvertieren

Das folgende Beispiel zeigt, wie eine zustandslose Containerarbeitslast konvertiert wird:

1. Suchen Sie das Verzeichnis mit den vorhandenen Migrationsartefakten, einschließlich der Datei deployment_spec.yaml.

2. Bearbeiten Sie das Dockerfile, um die Produktversion festzulegen, die logs.yaml-Datei zu kopieren und das Dienstprogramm servicemanager_generate_config auszuführen:

   ...
   # Set the product version to 1.15.0:
   FROM anthos-migrate.gcr.io/v2k-run-embedded:v1.15.0 as migrate-for-anthos-runtime
   
   ...
   
   ADD blocklist.yaml /.m4a/blocklist.yaml
   # Insert the ADD commands to copy the `logs.yaml` file to the container image:
   ADD logs.yaml /code/config/logs/logsArtifact.yaml
   ADD logs.yaml /code/config/logs/logs.yaml
   
   # Insert the RUN command for servicemanager_generate_config:
   RUN /servicemanager_generate_config build-all -o /.m4a/
   
   # Migrate to Containers image includes entrypoint
   ENTRYPOINT [ "/.v2k.go" ]

3. Öffnen Sie die Datei deployment_spec.yaml in einem Editor. Beispiel:

   vi  deployment_spec.yaml

4. Suchen Sie den folgenden Abschnitt in der Datei und löschen Sie die angegebenen Zeilen:

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     creationTimestamp: null
     name: IMAGE_NAME
        …
       spec:
         containers:
         - image: gcr.io/PROJECT_NAME/IMAGE_NAME:LABEL
           name: IMAGE_NAME
   # Delete the following lines:
           readinessProbe:
             exec:
               command:
               - /code/ready.sh
           resources: {}
           securityContext:
             privileged: true
           volumeMounts:
           - mountPath: /sys/fs/cgroup
             name: cgroups
           - mountPath: /code/config/logs
             name: logs-config
         volumes:
         - hostPath:
             path: /sys/fs/cgroup
             type: Directory
           name: cgroups
         - configMap:
             name: suitecrm-crddefault-logs
           name: logs-config
   # Stop the delete here.

5. Fügen Sie die Zeilen unten hinzu, um die HC_V2K_SERVICE_MANAGER-Umgebungsvariable festzulegen.

   Achtung: Wenn Sie Migrate to Containers 1.10 oder höher verwenden, überspringen Sie diesen Schritt.

   spec:
     containers:
     - image: gcr.io/PROJECT_NAME/IMAGE_NAME:LABEL
       name: IMAGE_NAME
   # Add the following lines:
       env:
         - name: HC_V2K_SERVICE_MANAGER
           value: "true"

6. Speichern Sie die Datei.

7. Achten Sie darauf, dass der Zielcluster Lesezugriff auf die Docker-Image-Registry hat, wie unter Der Zielcluster muss Lesezugriff auf die Docker-Registry haben beschrieben.

8. Erstellen Sie das aktualisierte Image und übertragen Sie es mit einem aktualisierten Versions-Tag an Container Registry, damit genügend Zeit bleibt, um den Build fertigzustellen. Im folgenden Beispiel befindet sich das Image im aktuellen Verzeichnis:

   gcloud builds submit --timeout 4h --tag gcr.io/PROJECT_NAME/IMAGE_NAME:LABEL .

9. Stellen Sie den Container bereit:

   kubectl apply -f deployment_spec.yaml

   Wenn Sie die Bereitstellungsspezifikation auf einen Autopilot-Cluster anwenden, ohne die erforderlichen Änderungen in deployment_spec.yaml vorzunehmen, wird eine Fehlermeldung im folgenden Format angezeigt:

   "Trying to run without root privileges is not possible. Did you try to use the new runtime? In that case please pass the environment variable HC_V2K_SERVICE_MANAGER=true to the pod"

10. Sehen Sie sich die Pods an, die im Cluster bereitgestellt werden.

    Hinweis: Das Laden der Knoten und das Abrufen des Images können einige Minuten dauern.

    kubectl get pods

Zustandsorientierte Arbeitslast konvertieren

Das folgende Beispiel zeigt, wie Sie eine zustandsorientierte Containerarbeitslast konvertieren:

1. Suchen Sie das Verzeichnis mit den vorhandenen Migrationsartefakten, einschließlich der Datei deployment_spec.yaml.

2. Bearbeiten Sie das Dockerfile, um die Produktversion festzulegen, und führen Sie das Dienstprogramm servicemanager_generate_config aus:

   ...
   # Set the product version to 1.15.0:
   FROM anthos-migrate.gcr.io/v2k-run-embedded:v1.15.0 as migrate-for-anthos-runtime
   
   ...
   
   ADD blocklist.yaml /.m4a/blocklist.yaml
   # Insert the ADD commands to copy the `logs.yaml` file to the container image:
   ADD logs.yaml /code/config/logs/logsArtifact.yaml
   ADD logs.yaml /code/config/logs/logs.yaml
   
   # Insert the RUN command for servicemanager_generate_config:
   RUN /servicemanager_generate_config build-all -o /.m4a/
   
   # Migrate to Containers image includes entrypoint
   ENTRYPOINT [ "/.v2k.go" ]

3. Öffnen Sie die Datei deployment_spec.yaml in einem Editor. Beispiel:

   vi  deployment_spec.yaml

4. Suchen Sie die folgenden drei Abschnitte in der Datei und löschen Sie die angegebenen Zeilen:

   apiVersion: apps/v1
   kind: StatefulSet
   ...
   spec:
     containers:
     - image: gcr.io/PROJECT_NAME/IMAGE_NAME:LABEL
       name: IMAGE_NAME
   # Delete the following lines:
       readinessProbe:
         exec:
           command:
           - /code/ready.sh
       resources: {}
       securityContext:
         privileged: true
   # Stop the delete here.
       volumeMounts:
   # Delete the following lines:
       - mountPath: /sys/fs/cgroup
         name: cgroups
   # Stop the delete here.
       - mountPath: /opt/suitecrm-7.10.5-0/mysql/data
         name: data-pvc-0-1b12-d0af-48b3-9f5e-6c25fa5
         subPath: opt/suitecrm-7.10.5-0/mysql/data
     volumes:
   # Delete the following lines:
     - hostPath:
         path: /sys/fs/cgroup
         type: Directory
       name: cgroups
   # Stop the delete here.
     - name: data-pvc-2-d0af-48b3-9f5e09c25fa5
       persistentVolumeClaim:
         claimName: data-pvc-0-1a2-d0af-48b3-9f5e-605fa5

   Beachten Sie, dass Sie nur die Definitionen volumeMounts und volumes für cgroups entfernen und die verbleibenden Definitionen beibehalten.

5. Fügen Sie die folgenden Zeilen hinzu, um die Umgebungsvariable HC_V2K_SERVICE_MANAGER festzulegen:

   Achtung: Wenn Sie Migrate to Containers 1.10 oder höher verwenden, überspringen Sie diesen Schritt.

   spec:
     containers:
     - image: gcr.io/PROJECT_NAME/IMAGE_NAME:LABEL
       name: IMAGE_NAME
   # Add the following lines:
       env:
       - name: HC_V2K_SERVICE_MANAGER
         value: "true"
   # Stop the add here.
       volumeMounts:
       - mountPath: /opt/suitecrm-7.10.5-0/mysql/data
         name: data-pvc-0-1b12-d0af-48b3-9f5e-6c25fa5
         subPath: opt/suitecrm-7.10.5-0/mysql/data
     volumes:
     - name: data-pvc-2-d0af-48b3-9f5e09c25fa5
       persistentVolumeClaim:
         claimName: data-pvc-0-1a2-d0af-48b3-9f5e-605fa5

6. Speichern Sie die Datei.

7. Achten Sie darauf, dass der Zielcluster Lesezugriff auf die Docker-Image-Registry hat, wie unter Der Zielcluster muss Lesezugriff auf die Docker-Registry haben beschrieben.

8. Erstellen Sie das aktualisierte Image und übertragen Sie es mit einem aktualisierten Versions-Tag an Container Registry, damit genügend Zeit bleibt, um den Build fertigzustellen. Im folgenden Beispiel befindet sich das Image im aktuellen Verzeichnis:

   gcloud builds submit --timeout 4h --tag gcr.io/PROJECT_NAME/IMAGE_NAME:LABEL .

9. Stellen Sie den Container bereit:

   kubectl apply -f deployment_spec.yaml

   Wenn Sie die Bereitstellungsspezifikation ohne die erforderlichen Änderungen in deployment_spec.yaml auf einen Autopilot-Cluster anwenden, wird eine Fehlermeldung im folgenden Format angezeigt:

   "Trying to run without root privileges is not possible. Did you try to use the new runtime? In that case please pass the environment variable HC_V2K_SERVICE_MANAGER=true to the pod"

10. Sehen Sie sich die Pods an, die im Cluster bereitgestellt werden.

    Hinweis: Das Laden der Knoten und das Abrufen des Images können einige Minuten dauern.

    kubectl get pods

Aufgaben nach der Konvertierung

Nach der Konvertierung einer vorhandenen Migration zur Verwendung des vereinfachten Linux-Dienstmanagers können Sie sie folgendermaßen ändern:

• Aktualisieren Sie die von der migrierten Arbeitslast verwendeten Dienste.
• Fügen Sie neue Dienste hinzu.

In beiden Szenarien müssen Sie das Dockerfile bearbeiten und dann das Container-Image neu erstellen.

Dienste aktualisieren

In diesem Abschnitt bearbeiten Sie das Dockerfile, um die Datei services-config.yaml im Container auf der Grundlage von Änderungen in /etc/systemd für die migrierte Arbeitslast zu aktualisieren.

So aktualisieren Sie das Container-Image für eine Änderung an einem vorhandenen Dienst:

1. Fügen Sie den Dockerfile-Befehl servicemanager_generate_config hinzu:

   Hinweis: Fügen Sie den Befehl servicemanager_generate_config direkt zum Dockerfile hinzu. Versuchen Sie nicht, ihn innerhalb der Containerarbeitslast auszuführen.

   ...
   FROM anthos-migrate.gcr.io/v2k-run-embedded:v1.15.0 as migrate-for-anthos-runtime
   
   ...
   
   ADD blocklist.yaml /.m4a/blocklist.yaml
   
   # Use the update command for servicemanager_generate_config to update the configuration:
   RUN /servicemanager_generate_config update -u /.m4a/
   
   # Migrate to Containers image includes entrypoint
   ENTRYPOINT [ "/.v2k.go" ]

2. Erstellen Sie das aktualisierte Image und übertragen Sie es mit einem aktualisierten Versions-Tag an Container Registry, damit genügend Zeit bleibt, um den Build fertigzustellen. Im folgenden Beispiel befindet sich das Image im aktuellen Verzeichnis:

   gcloud builds submit --timeout 4h --tag gcr.io/PROJECT_NAME/IMAGE_NAME:LABEL .

3. Stellen Sie das neu erstellte Image bereit:

   kubectl set image deployment/myWorkload my-app=gcr.io/PROJECT_NAME/IMAGE_NAME:LABEL --record

Dienste hinzufügen

So fügen Sie dem Container-Image einen Dienst hinzu:

1. Fügen Sie den Dockerfile-Befehl servicemanager_generate_config hinzu:

   Hinweis: Fügen Sie den Befehl servicemanager_generate_config direkt zum Dockerfile hinzu. Versuchen Sie nicht, ihn innerhalb der Containerarbeitslast auszuführen.

   ...
   FROM anthos-migrate.gcr.io/v2k-run-embedded:v1.15.0 as migrate-for-anthos-runtime
   
   ...
   
   ADD blocklist.yaml /.m4a/blocklist.yaml
   
   # This example adds the redis-server service.
   # Add the following lines to install redis-server.
   RUN apt-get update && apt-get -y install redis-server
   
   # Use the servicemanager_generate_config add command to add
   # redis-server to the configuration:
   RUN /servicemanager_generate_config add redis-server -u /.m4a/
   
   # Migrate to Containers image includes entrypoint
   ENTRYPOINT [ "/.v2k.go" ]

2. Erstellen Sie das aktualisierte Image und übertragen Sie es mit einem aktualisierten Versions-Tag an Container Registry, damit genügend Zeit bleibt, um den Build fertigzustellen. Im folgenden Beispiel befindet sich das Image im aktuellen Verzeichnis:

   gcloud builds submit --timeout 4h --tag gcr.io/PROJECT_NAME/IMAGE_NAME:LABEL .

3. Stellen Sie das neu erstellte Image bereit:

   kubectl set image deployment/myWorkload my-app=gcr.io/PROJECT_NAME/IMAGE_NAME:LABEL --record

Syntax von servicemanager_generate_config

Das Dienstprogramm servicemanager_generate_config bietet die folgenden Optionen:

• build-all -o /.m4a/: erstellt die Migration neu und schreibt die Konfiguration in das Verzeichnis m4a. Ändern Sie nicht den Namen des Verzeichnisses.

  Verwenden Sie diese Form des Befehls, wenn Sie die Migration zum ersten Mal ausführen, um den vereinfachten Linux-Dienstmanager zu verwenden.

• update -u /.m4a/: Aktualisieren Sie die Liste der vorhandenen Dienste im m4a-Verzeichnis. Ändern Sie nicht den Namen des Verzeichnisses.

• add SERVICE_NAME -u /.m4a/: Fügen Sie der Migration einen Dienstnamen hinzu und schreiben Sie die Konfiguration in das m4a-Verzeichnis. Ändern Sie nicht den Namen des Verzeichnisses.

  Wenn Sie mehrere Dienste hinzufügen möchten, fügen Sie mehrere RUN /servicemanager_generate_config-Befehle hinzu, einen pro Dienst.

Nächste Schritte

• Weitere Informationen zur neuen erweiterten Laufzeit