Auf die Abschaltung des Container-Start-Agents vorbereiten

Der Container-Start-Agent (konlet), der Container auf Compute Engine-Instanzen während der VM-Erstellung bereitstellt, wird eingestellt.

In diesem Dokument wird beschrieben, wie Sie die Migration von Containern planen, die Sie während der VM-Erstellung erstellt haben zu anderen Cloud de Confiance by S3NS Diensten.

Allgemeine Informationen

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

Mit dem Container-Start-Agent können Sie Container auf Compute Engine-Instanzen oder auf Instanzen in einer verwalteten Instanzgruppe (Managed Instance Group, MIG) während der VM-Erstellung bereitstellen und konfigurieren und einen Docker-Container starten.

Warum wird der Container-Start-Agent eingestellt?

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

Weitere Informationen zu den Optionen, die eingestellt werden, 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 stellt Google den Support für den Container-Start-Agent ein und es werden keine weiteren Updates für VMs bereitgestellt, die die gce-container-declaration Metadaten verwenden. Sie führen die Arbeitslasten auf eigenes Risiko aus und dies kann sich auf Ihren Workflow auswirken.

Wir empfehlen Ihnen, Container weit vor diesen Terminen zu alternativen Lösungen zu migrieren, um einen reibungslosen Übergang zu gewährleisten.

Ab wann kann ich keine neuen VMs oder MIGs mehr mit Containern erstellen, die direkt mit den Metadaten gce-container-declaration bereitgestellt werden?

12 Monate nach der ersten Benachrichtigung über die Einstellung, also ab dem 31. Juli 2026.

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

Wir stellen den Support für alle Arbeitslasten ein, die mit dem Container-Start-Agent bereitgestellt wurden, 24 Monate nach der ersten Benachrichtigung über die Einstellung, also ab dem 31. Juli 2027.

Wie wirkt sich diese Einstellung auf meine Terraform-Konfiguration aus?

Wenn Sie Terraform oder eine ähnliche Automatisierung verwenden, um VMs oder MIGs 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. Aktualisieren Sie Ihre Terraform-Konfiguration, um ein Startscript für die Containerbereitstellung zu verwenden, und entfernen Sie die Abhängigkeit vom Metadatenschlüssel gce-container-declaration, um Störungen zu vermeiden. Eine detaillierte Anleitung finden Sie in der Migrationsanleitung.

Bedeutet diese Einstellung, dass auch Container-Optimized OS-Images eingestellt werden?

Nein, Container-Optimized OS-Images werden nicht eingestellt. Die Änderung betrifft die Bereitstellung von Containern auf VMs, die Container-Optimized OS verwenden. Neuere Versionen von Container-Optimized OS unterstützen konlet nicht mehr, den Container-Start-Agent, der den gce-container-declaration Metadatenschlüssel verwendet, um Container bereitzustellen. Container-Optimized OS-Images sind weiterhin verfügbar und werden unterstützt. Sie müssen jedoch Ihre VM-Konfiguration aktualisieren, um ein Startskript oder cloud-init zu verwenden, um Container bereitzustellen, anstatt sich auf den Metadatenschlüssel gce-container-declaration zu verlassen.

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 wurden. 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 während der VM-Erstellung einen Container auf einer VM bereitstellen, indem Sie den Container-Start-Agent verwenden oder gce-container-declaration angeben, sind Sie von dieser Einstellung betroffen. Führen Sie den folgenden gcloud CLI-Befehl aus, um zu prüfen, ob Instanzen in Ihrem Projekt betroffen sind:

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

Dieser Befehl enthält eine Liste aller VM-Instanzen in Ihrem Projekt, 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 in allen aktiven Projekten aus.

Weitere Informationen zum Aufrufen 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 enthält 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.

Gibt es eine Möglichkeit, die Erstellung von VMs zu verhindern, die den Container-Start-Agent verwenden?

Ja. Administratoren von Organisationen können die Einschränkung der Organisationsrichtlinie compute.managed.disableVmsWithContainerStartupAgent erzwingen, um die Erstellung von Ressourcen zu deaktivieren, die den Container-Start-Agent und den Metadatenschlüssel gce-container-declaration verwenden. Sie können diese Richtlinie auch im Probelaufmodus erzwingen, um die Nutzung zu beobachten, bevor Sie die Ressourcenerstellung blockieren. Weitere Informationen finden Sie unter Erstellung von VMs verhindern, die die eingestellten Container-Metadaten verwenden.

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

Nein. Sicherheit und Datenschutz sind die Grundlage für alles, was wir bei Google tun. Wenn Sie unsere Skripts oder verwalteten Lösungen verwenden, können Sie bestimmte Sicherheits- und Datenschutzeinstellungen konfigurieren, um Ihre Anforderungen zu erfüllen. Weitere Informationen finden Sie in der Migrationsanleitung.

Alternative Lösungen

Welche alternativen Lösungen werden für Container in Compute Engine 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 oder 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 Batch-Job mit einem bestimmten Endzustand ist und zusätzliche Rechenressourcen benötigt, sollten Sie Batch in Betracht ziehen. Sie können auch Startskripts verwenden.
• Wenn Sie erweiterte Steuerungsmöglichkeiten 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 Startskript zu verwenden?

Wir empfehlen Ihnen, 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.

Die wichtigsten Vorteile sind:

• Weniger Verwaltungsaufwand: Als vollständig verwaltete DiensteCloud de Confiance übernimmt die zugrunde liegende Infrastruktur (VMs, Patching, Skalierung). Dieser Ansatz spart wertvolle Arbeitszeit und reduziert den Betriebsaufwand.
• Automatische Skalierung und Elastizität: Diese Dienste passen die Ressourcen automatisch an die Nachfrage 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.
• Verfügbarkeit des kostenlosen Kontingents nutzen: GKE, Cloud Run und Batch bieten ein kostenloses Kontingent, mit dem Sie kleinere Arbeitslasten ausführen oder Tests durchführen können, ohne dass Kosten anfallen.

Eine detaillierte Anleitung zur Migration finden Sie in der Migrationsanleitung.

Welche Kosten sind mit den einzelnen alternativen Lösungen verbunden und wie schneiden sie im Vergleich zur aktuellen Einrichtung ab?

Startskripts oder cloud-init für die Containerbereitstellung: Wenn Sie Startskripts oder cloud-init als direkten Ersatz verwenden, ändern sich Ihre 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, bei denen auch im Leerlauf Kosten anfallen, können diese verwalteten Dienste effizienter sein. Darüber hinaus können kostenlose Kontingente die Kosten für kleinere, temporäre Arbeitslasten weiter senken.

Weitere Informationen finden Sie unter Optionen für die Containerbereitstellung vergleichen. Die Preise variieren je nach ausgewähltem Dienst und Ihrer spezifischen Konfiguration. Verwenden Sie den Preis rechner, um eine genaue Schätzung zu erhalten.

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

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

Migrationsprozess

Welcher Ansatz wird für die Migration von Containern zu den alternativen Lösungen empfohlen?

Wir empfehlen Ihnen, bei der Migration so vorzugehen:

• Optionen kennenlernen: In der Migration Anleitung finden Sie alternative Möglichkeiten, Ihre Container auszuführen.
• Migration frühzeitig planen: Um einen reibungslosen Übergang zu gewährleisten, beginnen Sie weit vor dem 31. Juli 2026 mit der Planung der Migration Ihrer aktuellen Containerbereitstellungen.
• Auf neue Arbeitslasten vorbereiten: Achten Sie darauf, dass Ihre neuen Containerarbeitslasten bereit sind, bis zum 31. Juli 2026 auf alternativen Lösungen ausgeführt zu werden, da die direkte Bereitstellung von Containern auf VMs oder MIGs nicht mehr möglich ist.
• Letzte Migrationsfrist: Migrieren Sie alle Ihre vorhandenen Containerarbeitslasten bis zum 31. Juli 2027 zu alternativen Lösungen. An diesem Datum wird die direkte Bereitstellung vollständig eingestellt.

Muss ich zu einer der empfohlenen Lösungen migrieren oder gibt es Alternativen, die ich verwenden kann?

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

Ist im Rahmen des Migrationsprozesses eine Datensicherung oder ein Datenexport erforderlich?

Eine Datensicherung oder ein Datenexport ist zwar immer eine wichtige Best Practice für die Datensicherheit und die 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 erste Einrichtung und das Testen mit Startskripts sollten etwa 1 bis 2 Stunden dauern. Nachfolgende Bereitstellungen sollten jeweils nur wenige Minuten dauern.

Verwaltete Dienste: Die Entscheidung für Cloud de Confiance by S3NS Lösungen wie Cloud Run, Batch oder GKE, die serverlose und vollständig verwaltete PaaS-Angebote sind, erfordert möglicherweise eine höhere anfängliche Investition an Zeit und Aufwand. 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. um sicherzustellen, dass sie zustandslos ist. Die langfristigen Vorteile können jedoch erhebliche Verbesserungen der betrieblichen Effizienz, Skalierbarkeit und Kosteneffizienz umfassen.

Eine Anleitung für diese Umstellung finden Sie in der Migrationsanleitung.

Wenn ich zu einer Alternative migriere, sind dann Unterbrechungen oder Ausfallzeiten für Cloud de Confiance by S3NS Projekte, VMs, Dienste und Apps zu erwarten?

Im Allgemeinen ist die Umstellung auf die empfohlene alternative Lösung so konzipiert, dass keine Ausfallzeiten entstehen.

Bei der Migration von Containern mit langer Laufzeit auf Compute Engine-VMs empfehlen wir, neue VMs mit der alternativen Konfiguration einzurichten und den Traffic umzuleiten, sobald sie getestet wurden, um Unterbrechungen zu vermeiden.

Wie wirkt sich diese 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. Aktualisieren Sie Ihre Konfiguration, um ein Startskript für die Containerbereitstellung zu verwenden, und entfernen Sie die Abhängigkeit vom Metadatenschlüssel gce-container-declaration, um Unterbrechungen zu vermeiden. Eine detaillierte Anleitung zur Implementierung dieser Änderung finden Sie unter Container migrieren, die während 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 mir zur Unterstützung bei der Migration und für technische Informationen zur Verfügung?

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