Neue erweiterte Laufzeit

Der ursprüngliche Linux-Dienstmanager für Migrate to Containers auf sysv init und systemd angewiesen. Der vereinfachte Linux-Dienstmanager ersetzt ihn durch eine vereinfachte, containerfreundliche Alternative.

Dieser vereinfachte Linux-Dienstmanager bietet Funktionen, mit denen Sie Ihre migrierten Containerarbeitslasten folgendermaßen bereitstellen können:

• GKE Autopilot-Cluster

• Cloud Run

Der vereinfachte Linux-Dienstmanager löst auch Kompatibilitätsprobleme mit Kubernetes-Plug-ins. Mit dem vereinfachten Linux-Dienstmanager ist es beispielsweise nicht mehr erforderlich, einen hostpath für /sys/fs/cgroup in der Datei deployment_spec.yaml zu definieren und privilegierte Container zu erstellen.

Hinweis

• Migrate to Containers stellt ein Tool bereit, das Sie auf einer VM-Arbeitslast ausführen, um die Eignung der Arbeitslast für die Migration zu einem Container zu ermitteln. Weitere Informationen finden Sie unter Eignungsbewertungstool verwenden.

Informationen zu GKE-Autopilot-Clustern

Autopilot ist ein Betriebsmodus in Google Kubernetes Engine (GKE). Autopilot ist darauf ausgelegt, die Betriebskosten für die Verwaltung von Clustern zu reduzieren, Ihre Cluster für die Produktion zu optimieren und eine höhere Arbeitslastverfügbarkeit zu ermöglichen. Im Autopilot-Modus stellt GKE die zugrunde liegende Infrastruktur des Clusters bereit und verwaltet diese, einschließlich Knoten und Knotenpools. So erhalten Sie einen optimierten Cluster mit automatisierter Umgebung.

Hinweis: Autopilot wird für GKE-Cluster unterstützt, aber nicht für GKE Enterprise-Cluster.

Weitere Informationen finden Sie unter Autopilot-Übersicht.

Informationen zu Cloud Run

Cloud Run ist eine verwaltete Computing-Plattform, mit der Sie zustandslose Container ausführen können, die sich über Webanfragen oder Pub/Sub-Ereignisse aufrufen lassen. Mit dem vereinfachten Linux-Dienstmanager können Sie Ihre migrierten Containerarbeitslasten in Cloud Run bereitstellen.

Hinweis: Die Containerarbeitslast muss zustandslos sein, um in Cloud Run bereitgestellt zu werden. Weitere Informationen, einschließlich der vollständigen Liste der Anforderungen für die Bereitstellung von Containern in Cloud Run, finden Sie unter Dienst entwickeln.

Workload Identity mit Migrate to Containers und GKE verwenden

Mit Migrate to Containers und GKE können Sie Ihre migrierten Arbeitslasten in Google Distributed Cloud bereitstellen. Manchmal verwenden Sie denselben Cluster wie der Verarbeitungscluster und den Bereitstellungscluster. Wenn Sie in Ihrem Deployment-Cluster Workload Identity aktiviert haben, konfigurieren Sie Ihre Deployment-Umgebung so, dass sie Migrate to Containers und GKE unterstützt.

Achten Sie außerdem darauf, dass alle im Rahmen des Initialisierungsprozesses gestarteten Dienste ordnungsgemäß für Workload Identity konfiguriert sind. Die auszuführenden Schritte hängen vom Dienstmanager für Ihren Cluster ab. Konfigurationsschritte finden Sie unter Linux-Arbeitslast in einem Zielcluster bereitstellen.

Änderungen gegenüber der vorhandenen Laufzeit

Für die Verwendung des vereinfachten Linux-Dienst-Managers sollten Sie sich über die folgenden Änderungen und Einschränkungen der vorhandenen Laufzeit informieren.

Neue Artefaktdatei services-config.yaml hinzugefügt

Wenn Sie den vereinfachten Linux-Dienstmanager aktivieren, erstellt Migrate to Containers beim Erstellen der Migrationsartefakte die neue Artefaktdatei services-config.yaml. Mit dieser Datei können Sie die Anwendungsinitialisierung für einen bereitgestellten Container steuern. Weitere Informationen finden Sie unter services-config.yaml verwenden.

Hinweis: services-config.yaml wird nur erstellt, wenn Sie mit Migrate to Containers Version 1.15.0 eine neue Migration ausführen. Sie wird nicht erstellt, wenn Sie eine vorhandene Migration von einer vorherigen Version zu Version 1.15.0 konvertieren.

Bereitschaftsprüfungen

Bei Verwendung der aktuellen Laufzeit fügt Migrate to Containers eine Bereitschaftsprüfung in die Datei deployment_spec.yaml ein. Wenn Sie den vereinfachten Linux-Dienstmanager aktivieren, wird keine Bereitschaftsprüfung hinzugefügt.

Wenn Sie eine Bereitschaftsprüfung hinzufügen möchten, empfehlen wir die Verwendung einer HTTP-Bereitschaftsprüfung. Weitere Informationen finden Sie unter Bereitschaftsprüfungen definieren.

Hinweis: Sie können die vereinfachte Bereitschaftsprüfung für Linux-Dienstmanager zu Ihrer Dienstdefinition hinzufügen:

        readinessProbe:
          exec:
            command:
            - /.m4a/gamma status

Diese Prüfung kann jedoch ein falsch-negatives Ergebnis zurückgeben.

syslog-Unterstützung

Der vereinfachte Linux-Dienstmanager erstellt einen Unix-Socket unter /dev/log, um den Syslog zu unterstützen. Der vereinfachte Linux-Dienstmanager leitet diese Lognachrichten an stdout weiter, sodass sie von Kubernetes als Containerlogs aufgezeichnet werden.

Beschränkungen

Beachten Sie bei der Verwendung des vereinfachten Linux-Dienst-Managers die folgenden Beschränkungen.

Arbeitslasteinschränkungen

Der vereinfachte Linux-Dienstmanager funktioniert am besten mit den folgenden Arbeitslasttypen:

Image	Betriebssystem	Dienste
Compute Engine Ubuntu 12.04	Ubuntu 12.04	apache2
Compute Engine Ubuntu 14.04	Ubuntu 14.04	redis, mysql, apache2
Compute Engine Ubuntu 18.04	Ubuntu 18.04	apache2, mysql, redis-server, tomcat
RHEL SAP 7.4	Red Hat	httpd
Bitnami	Ubuntu	bitnami
Compute Engine Memcached-Image	Debian 10.9	bitnami
Compute Engine Marketplace-Wordpress	Debian 9.13	apache2, mysql, php
Compute Engine Marketplace-Tomcat	Debian 9.13	tomcat8
Compute Engine Marketplace-Jenkins	Debian 10.9	apache2, jenkins
Compute Engine Marketplace-Moodle	Debian 9.13	apache2, mysql, php7.4-fpm, phpsessionclean
Compute Engine Marketplace-Odoo	Debian 9.13	odoo, nginx
Compute Engine Marketplace Opencart	Debian 9.13	apache2, mysql, php7.0-fpm, supervisor, mariadb
Compute Engine Marketplace-Erpnext	Debian 10.9	nginx, redis-server, supervisor, mariadb
Compute Engine Marketplace-Wildfly	Debian 10.10	wildfly, cron

systemd-Einschränkungen

Wenn Sie systemd als Init-System verwenden, beachten Sie die folgenden Einschränkungen:

• Die systemd-Diensttypen simple, exec und notify werden als exec-Dienst behandelt. Das bedeutet, dass der Dienst als gestartet gilt, wenn exec erfolgreich ist.

• Benachrichtigungs-Sockets werden für sd_notify() nur für READY=1-Nachrichten unterstützt.

  Bei Bedarf können Sie weitere Bereitschaftsprüfungen bereitstellen. Zum Beispiel HTTP-Prüfung oder andere Arten von Diagnosen.

• Socket-Einheitendateien werden nicht unterstützt. Es werden keine Sockets erstellt und keine Umgebungsvariablen angelegt.

Updates für Version 1.9.0

Der vereinfachte Linux-Dienstmanager für Version 1.9.0 enthält die folgenden Aktualisierungen:

• Der Linux-Dienstmanager ist jetzt allgemein verfügbar und befindet sich nicht mehr in der öffentlichen Vorschau.

• Das Verfahren zur Konvertierung vorhandener Containerarbeitslasten zur Unterstützung von Autopilot wurde geändert. Sie müssen jetzt sowohl das Dockerfile als auch die Datei deployment_spec.yaml für eine vorhandene Migration bearbeiten, um sie zu konvertieren.

• Die Datei config.yaml wurde in services-config.yaml umbenannt.

Aktualisierungen für Version 1.8.1

Der vereinfachte Linux-Dienstmanager wurde ursprünglich im Rahmen der Migrate to Containers Version 1.8 in der öffentlichen Vorschau veröffentlicht. Der vereinfachte Linux-Dienstmanager für Version 1.8.1 enthält die folgenden Aktualisierungen:

• Sie müssen im Migrationsplan keine Annotation mehr festlegen, um den vereinfachten Linux-Dienstmanager zu aktivieren. Stattdessen legen Sie jetzt v2kServiceManager fest. Weitere Informationen finden Sie unter Container in Autopilot-Clustern bereitstellen.

• Die Umgebungsvariable HC_GAMMA_RUNTIME wurde in HC_V2K_SERVICE_MANAGER umbenannt.

• Die Einträge prestart und poststart in der Datei services-config.yaml werden nun automatisch ausgefüllt. Weitere Informationen finden Sie unter services-config.yaml verwenden.

• Die Datei services-config.yaml wurde unterstützt, sodass Sie Umgebungsvariablen auf globaler Ebene oder auf Anwendungsebene angeben können. Weitere Informationen finden Sie unter services-config.yaml verwenden.

• Logging-Unterstützung wurde hinzugefügt, mit der Sie in Cloud Logging geschriebene Logdaten anpassen können. Weitere Informationen finden Sie unter In Cloud Logging geschriebene Logdaten anpassen.

Nächste Schritte

• Anwendungen in GKE Autopilot-Cluster migrieren und dort bereitstellen