Auf die Einstellung des Startup-Agents vorbereiten

Der Container-Start-Agent, der Container auf Compute Engine-Instanzen während der VM-Erstellung bereitstellt, ist eingestellt.

In diesem Dokument wird beschrieben, wie Sie die Migration von Containern planen, die Sie beim Erstellen von VMs zu anderen Trusted Cloud by S3NS Diensten erstellt haben.

Allgemeine Informationen

Was ist ein Container-Start-Agent in Compute Engine?

Mit dem Container-Start-Agent können Sie Container in Compute Engine bereitstellen und konfigurieren oder Instanzen in einer verwalteten Instanzgruppe (MIG) während der VM-Erstellung und des Starts eines Docker-Containers.

Warum wird der Container-Startup-Agent nicht mehr unterstützt?

Basierend auf Kundenfeedback Trusted Cloud by S3NS werden die Optionen für die Containerbereitstellung verbessert. Wir haben den Container-Start-Agent eingestellt, um Ihnen flexiblere Optionen für die Bereitstellung Ihrer Container zu bieten.

Weitere Informationen zu den eingestellten Optionen finden Sie unter Eingestellte Optionen zum Konfigurieren von Containern auf VMs.

Was sind die wichtigsten Meilensteine für diese Einstellung und was passiert, wenn ich die Frist nicht einhalte?

Ab dem 31. Juli 2026 funktionieren alle Workflows, die auf dem Container-Start-Agent oder den gce-container-declaration-Instanzmetadaten basieren, nicht mehr.

Ab dem 31. Juli 2027 wird der Container-Start-Agent nicht mehr von Google unterstützt. Für alle laufenden VMs, die die gce-container-declaration-Metadaten verwenden, werden keine weiteren Updates bereitgestellt. Sie führen die Arbeitslasten auf eigenes Risiko aus und dies kann sich auf Ihren Workflow auswirken.

Wir empfehlen Ihnen, Container rechtzeitig auf alternative Lösungen zu migrieren, um einen reibungslosen Übergang zu gewährleisten.

Wann kann ich keine neuen VMs oder MIGs mehr erstellen, auf denen Container direkt mit den gce-container-declaration-Metadaten bereitgestellt werden?

12 Monate nach der ersten Einstellungsbenachrichtigung, also am 31. Juli 2026.

Wann kann ich keine Containerbereitstellungen mehr auf VMs oder MIGs ausführen, die die gce-container-declaration-Metadaten verwenden?

Die Unterstützung für alle Arbeitslasten, die mit dem Container-Start-Agent bereitgestellt werden, wird 24 Monate nach der ersten Benachrichtigung über die Einstellung eingestellt, also am 31. Juli 2027.

Ich verwende cloud-init, um Container auf VMs auszuführen. Bin ich von dieser Änderung betroffen?

Nein. Diese Einstellung hat keine Auswirkungen auf VMs, die mit cloud-init konfiguriert werden. Sie können cloud-init weiterhin zum Konfigurieren von Instanzen verwenden. Weitere Informationen finden Sie unter cloud-init mit Cloud-Konfiguration verwenden.

Woher weiß ich, ob ich von dieser Änderung betroffen bin?

Wenn Sie einen Container auf einer VM während der VM-Erstellung mit dem Container-Start-Agent oder durch Angabe von gce-container-declaration bereitstellen, sind Sie von dieser Einstellung betroffen. Führen Sie den folgenden gcloud CLI-Befehl aus, um zu prüfen, ob in Ihrem Projekt Instanzen betroffen sind:

gcloud compute instances list --filter="metadata.items.key:gce-container-declaration"

Mit diesem Befehl wird eine Liste aller VM-Instanzen in Ihrem Projekt zurückgegeben, die den Metadatenschlüssel gce-container-declaration enthalten. Der Metadatenschlüssel identifiziert eindeutig VMs, die von der Einstellung betroffen sind. Wenn Sie mehrere Projekte verwenden, führen Sie den Befehl für alle aktiven Projekte aus.

Weitere Informationen zum Ansehen von Projektmetadaten finden Sie in der Metadatendokumentation.

Wenn Sie eine bestimmte Instanz prüfen möchten, führen Sie den folgenden gcloud CLI-Befehl aus:

gcloud compute instances describe VM_NAME

Ersetzen Sie VM_NAME durch den Namen der VM-Instanz. Dieser Befehl liefert alle Informationen für eine bestimmte Instanz, einschließlich der Metadaten. Wenn Sie den Metadatenschlüssel gce-container-declaration in der Befehlsausgabe sehen, ist Ihre VM von dieser Änderung betroffen.

Besteht während der Migration ein Risiko für die Projektsicherheit oder den Datenschutz?

Nein. Sicherheit und Datenschutz sind die Grundlage aller unserer Aktivitäten bei Google. Wenn Sie unsere Skripts oder verwalteten Lösungen verwenden, können Sie bestimmte Sicherheits- und Datenschutzeinstellungen flexibel konfigurieren, um Ihre Anforderungen zu erfüllen. Weitere Informationen finden Sie in der Migrationsanleitung.

Alternative Lösungen

Welche alternativen Lösungen zu Containern in Compute Engine werden empfohlen und wie wähle ich die richtige für meine Anforderungen aus?

Sie haben folgende Möglichkeiten, Ihren Container zu migrieren:

• Wenn Sie weiterhin Container auf VMs oder MIGs bereitstellen, Container für Tests und Entwicklung ausführen oder eine Arbeitslast ausführen möchten, die aus einer einzelnen VM besteht, verwenden Sie Startskripts oder cloud-init.
• Wenn Sie zustandslose Containeranwendungen und kleine bis mittelgroße Jobs haben, sollten Sie Cloud Run in Betracht ziehen. Sie können auch Startskripts verwenden.
• Wenn Ihr Container ein Batchjob mit einem bestimmten Endstatus ist und zusätzliche Rechenressourcen benötigt, sollten Sie Batch in Betracht ziehen. Sie können auch Startskripts verwenden.
• Wenn Sie erweiterte Steuerung und Skalierbarkeit benötigen oder Ihre Anforderungen mit den anderen Optionen nicht erfüllen können, sollten Sie GKE in Betracht ziehen.

Eine detaillierte Anleitung und Empfehlungen zu Migrationsoptionen finden Sie in der Migrationsanleitung.

Warum sollte ich eine Migration zu einem verwalteten Dienst wie Cloud Run, GKE oder Batch in Betracht ziehen, anstatt ein Startupskript zu verwenden?

Wir empfehlen, eine Migration zu Containerlösungen wie Google Kubernetes Engine, Cloud Run und Batch in Betracht zu ziehen. Diese verwalteten Dienste bieten erhebliche Vorteile gegenüber herkömmlichen VM-basierten Bereitstellungen, darunter verbesserte Skalierbarkeit, Flexibilität und erweiterte Verwaltungsfunktionen.

Zu den wichtigsten Vorteilen gehören:

• Verwaltungsaufwand reduzieren: Als vollständig verwaltete Dienste übernimmtTrusted Clouddie zugrunde liegende Infrastruktur (VMs, Patching, Skalierung). So können Sie wertvolle Mitarbeiterzeit einsparen und den Betriebsaufwand reduzieren.
• Automatisch skalieren und für Elastizität sorgen: Diese Dienste passen Ressourcen automatisch an den Bedarf an. Dies führt zu einer besseren Ressourcennutzung und potenziellen Kosteneinsparungen im Vergleich zur Überbereitstellung von VMs.
• Kosteneffizienz für inaktive Lasten: Im Gegensatz zu VMs, bei denen auch im Leerlauf Kosten anfallen, können verwaltete Dienste für Anwendungen mit schwankendem oder geringem Traffic kostengünstiger sein.
• Kostenloses Kontingent nutzen: Für GKE, Cloud Run und Batch ist ein kostenloses Kontingent verfügbar, mit dem Sie kleinere Arbeitslasten ausführen oder Tests durchführen können, ohne dass Kosten anfallen.

Eine ausführliche Anleitung zur Migration finden Sie in der Migrationsanleitung.

Welche Kosten sind für die einzelnen alternativen Lösungen zu berücksichtigen und wie schneiden sie im Vergleich zur aktuellen Einrichtung ab?

Startscripts für die Containerbereitstellung oder cloud-init: Die Verwendung von Startscripts oder cloud-init als direkter Ersatz ändert die Compute Engine-Kosten nicht. Sie zahlen weiterhin für die zugrunde liegenden VM-Ressourcen.

Verwaltete Dienste: Die Umstellung auf Dienste wie Cloud Run oder Batch kann zu Kosteneinsparungen führen, insbesondere bei Anwendungen mit variabler Nutzung. Im Gegensatz zu VMs, für die auch im Leerlauf Gebühren anfallen, können diese verwalteten Dienste effizienter sein. Außerdem können Sie mit kostenlosen Stufen die Kosten für kleinere, temporäre Arbeitslasten weiter senken.

Weitere Informationen finden Sie unter Containerbereitstellungsoptionen vergleichen. Die Preise variieren je nach ausgewähltem Dienst und Ihrer spezifischen Konfiguration. Mit dem Preisrechner können Sie die Kosten kalkulieren.

Bedeutet diese Einstellung, dass Container-Optimized OS-Images eingestellt werden und wir daher unsere eigene VM-Vorlage konfigurieren müssen, wenn wir Docker auf Compute Engine-VMs ausführen möchten?

Nein,Container-Optimized OS-Images selbst werden nicht eingestellt. Die Änderung betrifft den Start von Containern auf VMs mit Container-Optimized OS. Neuere Container-Optimized OS-Versionen unterstützen konlet nicht mehr. Das ist der Start-Agent, der Container mit dem Metadatenschlüssel gce-container-declaration startet. Das bedeutet, dass Container-Optimized OS-Images weiterhin verfügbar und unterstützt werden. Sie müssen Ihre VM jedoch aktualisieren, damit sie ein Startskript oder eine cloud-init-Konfiguration verwendet, um Container bereitzustellen, anstatt den Metadatenschlüssel gce-container-declaration zu verwenden.

Migrationsprozess

Was ist die empfohlene Vorgehensweise für die Migration von Containern zu den alternativen Lösungen?

Wir empfehlen Ihnen, bei der Migration so vorzugehen:

• Optionen kennenlernen: Im Migrationsleitfaden finden Sie alternative Möglichkeiten zum Ausführen Ihrer Container.
• Migration frühzeitig planen: Damit die Umstellung reibungslos verläuft, sollten Sie die Migration Ihrer aktuellen Containerbereitstellungen rechtzeitig vor dem 31. Juli 2026 planen.
• Neue Arbeitslasten vorbereiten: Sorgen Sie dafür, dass Ihre neuen Containerarbeitslasten bis zum 31. Juli 2026 auf alternativen Lösungen ausgeführt werden können, da die direkte Bereitstellung von Containern auf VMs oder MIGs nicht mehr möglich ist.
• Endgültige Migrationsfrist: Sorgen Sie dafür, dass alle Ihre vorhandenen Containerarbeitslasten bis zum 31. Juli 2027 auf alternative Lösungen migriert werden. An diesem Datum wird die Methode für die direkte Bereitstellung vollständig eingestellt.

Muss ich zu einer der empfohlenen Lösungen migrieren oder gibt es Alternativen?

Wir unterstützen Sie dabei, die Lösung zu finden, die Ihren geschäftlichen Anforderungen entspricht und aktiv unterstützt wird. Ressourcen wie die Migrationsanleitung können Ihnen dabei helfen, die am besten geeignete Option auszuwählen.

Ist im Rahmen der Migration eine Datensicherung oder ein Datenexport erforderlich?

Das Sichern oder Exportieren von Daten ist zwar immer eine wichtige Best Practice für die Datensicherheit und Geschäftskontinuität, aber für diesen Migrationsprozess nicht erforderlich.

Wie viel Zeit benötige ich für die Migration zu einer der Alternativen und gibt es Faktoren, die meinen Zeitaufwand beeinflussen könnten?

Startskript für die Containerbereitstellung: Die Ersteinrichtung und das Testen mit Startskripts sollten etwa 1 bis 2 Stunden dauern. Nachfolgende Bereitstellungen sollten jeweils nur wenige Minuten dauern.

Verwaltete Dienste: Wenn Sie sich fürTrusted Cloud by S3NS -Lösungen wie Cloud Run, Batch oder GKE entscheiden, die serverlose und vollständig verwaltete PaaS-Angebote sind, kann dies eine größere Vorabinvestition an Zeit und Aufwand erfordern. Das liegt an der grundlegenden Änderung von einem VM-zentrierten (IaaS-)Ansatz, bei dem Sie die Infrastruktur verwalten, zu einem PaaS-Modell, bei dem die Plattform einen Großteil dieser Aufgaben übernimmt. Diese Anpassung kann Änderungen an Ihrer Anwendung erforderlich machen, z. B. dafür zu sorgen, dass sie zustandslos ist. Die langfristigen Vorteile können jedoch erhebliche Verbesserungen bei betrieblicher Effizienz, Skalierbarkeit und Kosteneffizienz umfassen.

Eine Anleitung für diese Umstellung finden Sie im Migrationsleitfaden.

Wenn ich mich für die Migration zu einer Alternative entscheide, sind dann Unterbrechungen oder Ausfallzeiten für Trusted Cloud by S3NS -Projekte, VMs, Dienste und Apps zu erwarten?

Im Allgemeinen ist der Übergang zur empfohlenen alternativen Lösung so konzipiert, dass er ohne Ausfallzeiten erfolgt.

Bei der Migration von Containern mit langer Ausführungszeit auf Compute Engine-VMs empfehlen wir, zur Vermeidung von Unterbrechungen neue VMs mit der alternativen Konfiguration einzurichten und den Traffic umzuleiten, sobald sie getestet wurden.

Wie wirkt sich die Migration auf meine Terraform-Konfiguration aus?

Wenn Sie Terraform oder eine ähnliche Automatisierung verwenden, um VMs oder MIGs mit Containern zu erstellen oder zu aktualisieren, indem Sie den Metadatenschlüssel gce-container-declaration explizit festlegen, funktioniert Ihr Workflow ab dem 31. Juli 2026 nicht mehr. Um Unterbrechungen zu vermeiden, müssen Sie Ihre Konfiguration so aktualisieren, dass sie ein Startskript für die Containerbereitstellung enthält, und die Abhängigkeit vom Metadatenschlüssel gce-container-declaration entfernen. Eine detaillierte Anleitung zum Implementieren dieser Änderung finden Sie unter Container migrieren, die bei der VM-Erstellung auf VMs bereitgestellt wurden.

Support

An wen kann ich mich in Compute Engine wenden, wenn ich Fragen zum Migrationsprozess habe?

Wenn Sie Fragen haben oder Unterstützung benötigen, wenden Sie sich an den Google Cloud-Support.

Welche Ressourcen stehen zur Verfügung, um mich bei der Migration zu unterstützen und technische Anleitungen zu geben?

Diese FAQs, eine Migrationsanleitung und der Google Cloud-Support stehen Ihnen zur Unterstützung bei der Migration zur Verfügung.