Projekte auf die Verwendung von zonalem DNS umstellen

In diesem Dokument wird beschrieben, wie Sie ein vorhandenes Projekt vom globalen DNS zum zonalen DNS migrieren. Zonales DNS erhöht die Zuverlässigkeit, indem es Ausfälle in Zonen isoliert und so Unterbrechungen wichtiger Dienste wie das Erstellen von Instanzen und die automatische Reparatur verhindert.

Hinweise

• Richten Sie die Authentifizierung ein, falls Sie dies noch nicht getan haben. Bei der Authentifizierung wird Ihre Identität für den Zugriff auf Google Cloud -Dienste und APIs überprüft. Zur Ausführung von Code oder Beispielen aus einer lokalen Entwicklungsumgebung können Sie sich so bei Compute Engine authentifizieren.
  <x0A>

  Select the tab for how you plan to use the samples on this page:

  Console

  When you use the Google Cloud console to access Google Cloud services and APIs, you don't need to set up authentication.

  gcloud

  1. After installing the Google Cloud CLI, initialize it by running the following command:

     gcloud init

     If you're using an external identity provider (IdP), you must first sign in to the gcloud CLI with your federated identity.

  2. Set a default region and zone.

  REST

  Verwenden Sie die von der gcloud CLI bereitgestellten Anmeldedaten, um die REST API-Beispiele auf dieser Seite in einer lokalen Entwicklungsumgebung zu verwenden.

  After installing the Google Cloud CLI, initialize it by running the following command:

  gcloud init

  If you're using an external identity provider (IdP), you must first sign in to the gcloud CLI with your federated identity.

  Weitere Informationen finden Sie in der Dokumentation zur Google Cloud -Authentifizierung unter Für die Verwendung von REST authentifizieren.

Erforderliche Rollen

Bitten Sie Ihren Administrator, Ihnen die folgenden IAM-Rollen zuzuweisen, um die Berechtigungen zu erhalten, die Sie zum Migrieren von Projekten zur Verwendung von zonalem DNS benötigen:

• Projekt für die Verwendung des zonalen DNS migrieren: Project Editor (roles/resourcemanager.projectEditor) für das Projekt
• VMs zum zonalen DNS innerhalb eines Projekts migrieren: Compute Instance Admin (v1) (roles/compute.instanceAdmin.v1) für das Projekt
• Wenn Ihre VM ein Dienstkonto verwendet: Service Account User (roles/iam.serviceAccountUser) für das Dienstkonto oder Projekt

Weitere Informationen zum Zuweisen von Rollen finden Sie unter Zugriff auf Projekte, Ordner und Organisationen verwalten.

Diese vordefinierten Rollen enthalten die Berechtigungen, die zum Migrieren von Projekten zur Verwendung von zonenbasiertem DNS erforderlich sind. Erweitern Sie den Abschnitt Erforderliche Berechtigungen, um die erforderlichen Berechtigungen anzuzeigen:

Sie können diese Berechtigungen auch mit benutzerdefinierten Rollen oder anderen vordefinierten Rollen erhalten.

Projekt zu zonalem DNS migrieren

So migrieren Sie ein Projekt zur Verwendung von zonalem DNS:

1. Prüfen, ob Ihr Projekt standardmäßig globales DNS verwendet
2. Migrationsbereitschaft Ihrer Projekte mithilfe der Analyse von Anfragen ermitteln
3. Mit zonalem DNS kompatible Projekte migrieren
4. Inkompatible Abfragen korrigieren
5. Globale DNS-Logs überwachen, um die Migrationsbereitschaft zu bestätigen.
6. Verbleibende Projekte zu zonalem DNS migrieren
7. Prüfen, ob sich eine Änderung am zonalen DNS auf Ihr Projekt auswirkt

Prüfen, ob Ihr Projekt standardmäßig globales DNS verwendet.

Prüfen Sie, ob Ihre Projekte von der Verwendung des globalen DNS zum zonalen DNS migriert werden müssen. Sie müssen nur Projekte migrieren, die so konfiguriert sind, dass sie globales DNS als Standard für alle internen DNS-Namen verwenden, die innerhalb des Projekts erstellt werden.

gcloud compute project-info describe --project=PROJECT_ID --flatten="vmDnsSetting"

GET https://compute.googleapis.com/compute/v1/projects/PROJECT_ID?fields=id,name,vmDnsSetting

Migrationsbereitschaft eines Projekts mit der Analyse von Abfragen ermitteln

Um zu prüfen, ob ein Projekt zu zonalem DNS migriert werden kann, ohne dass Codeänderungen erforderlich sind oder die Verwendung von globalem DNS geändert werden muss, Google Cloud wird der DNS-Abfrageverlauf analysiert. Diese Analyse liefert die folgenden Messwerte, die die Kompatibilität des Projekts mit zonalem DNS angeben:

• zonal_dns_ready (Kompatible Abfragen): Dieser Messwert gibt die Gesamtzahl der Abfragen innerhalb eines 100-Tage-Zeitraums an, die mit zonalem DNS erfolgreich aufgelöst werden können.

• zonal_dns_risky (Nicht kompatible Anfragen): Dieser Messwert gibt die Gesamtzahl der Anfragen an, die nicht mit zonalem DNS aufgelöst werden können. Diese Anfragen umfassen in der Regel die regionsübergreifende Kommunikation oder andere Szenarien, in denen die zonale Auflösung fehlschlägt. Wichtig: Wenn dieser Messwert einen Wert ungleich null hat, ist Ihr Projekt noch nicht für die Migration bereit. Sie müssen diese inkompatiblen Anfragen beheben, bevor Sie zu zonalem DNS wechseln können.

Verwenden Sie den Metrics Explorer in der Google Cloud -Konsole, um diese Messwerte aufzurufen.

1. Rufen Sie in der Google Cloud Console die Seite leaderboard Metrics Explorer auf:

   Zum Metrics Explorer

   Wenn Sie diese Seite über die Suchleiste suchen, wählen Sie das Ergebnis aus, dessen Zwischenüberschrift Monitoring ist.

2. Klicken Sie auf der rechten Seite der Symbolleiste, die das Feld Messwert auswählen enthält, auf Code-Editor, MQL oder PromQL.

3. Wenn das Abfrage-Eingabefeld nicht mit MQL-Abfrage betitelt ist, dann wählen Sie in der unteren rechten Ecke des Abfrage-Eingabefelds für Sprache die Option MQL.

4. Geben Sie im Abfrageeingabefeld den folgenden Text genau so ein, wie er hier angezeigt wird:

   fetch compute.googleapis.com/Location
   | metric 'compute.googleapis.com/global_dns/request_count'
   | every 1d
   | within 7d
   

5. Klicken Sie auf Abfrage ausführen.

   In der Google Cloud Konsole wird ein Diagramm der beiden Messwerte (zonal_dns_ready und zonal_dns_risky) sowie die entsprechende Anzahl der Anfragen für jeden Messwert im ausgewählten Zeitraum angezeigt.

   

6. Prüfen Sie den Wert für den Messwert zonal_dns_risky.

   • Wenn der Wert 0 ist, kann das Projekt zu zonalem DNS migriert werden. Sie können das Projekt migrieren, wie unter Projekte migrieren, die für zonales DNS bereit sind beschrieben.
   • Wenn der Wert eine Zahl ungleich null ist, z. B. 0.02k wie im vorherigen Screenshot gezeigt, gibt es einige Abfragen, die nach der Migration zu zonalem DNS möglicherweise nicht funktionieren. Das Projekt ist nicht bereit für die Migration. Fahren Sie mit der Anleitung unter Inkompatible Anfragen korrigieren fort.

Mit zonalem DNS kompatible Projekte migrieren

Verwenden Sie eine der folgenden Optionen, um Projekte zu migrieren, die auf zonales DNS umgestellt werden können:

• Klicken Sie in der Google Cloud -Konsole auf die Schaltfläche Zonale DNS verwenden.

  1. Wenn Sie die Seite VM-Instanzen für Ihr Projekt aufrufen und Ihr Projekt für die Migration bereit ist (mit zonalen DNS-Abfragen kompatibel), enthält das Banner eine Empfehlung zur Verwendung von zonalem DNS. Diese Empfehlung basiert auf der internen DNS-Nutzung im Projekt, ist aber auf die letzten 30 Tage beschränkt.

     

     Wenn Sie auf die Schaltfläche Zonales DNS verwenden klicken, werden die Projektmetadaten so aktualisiert, dass zonales DNS verwendet wird.

  2. Optional: VM-Metadaten aufrufen und abfragen, um die Metadatenänderung zu bestätigen.

• Ändern Sie die Projektmetadaten manuell, um zonales DNS zu verwenden.

  1. Aktivieren Sie zonales DNS für Ihre Instanzen. Legen Sie hierfür den Metadateneintrag vmDnsSetting für das Projekt fest. Nachdem Sie diesen Metadateneintrag festgelegt haben, kann auf Ihre Compute-Instanzen nur über ihre zonalen DNS-Namen (VM_NAME.ZONE.c.PROJECT_ID.internal) zugegriffen werden, wenn Suchpfade verwendet werden. Die Instanzen behalten weiterhin sowohl den zonalen als auch den globalen Suchpfad bei, ihre globalen DNS-Namen, die ZONE nicht als Teil des internen DNS-Namens enthalten, funktionieren jedoch nicht mehr. Nur Instanzen in derselben Region und demselben Projekt können mit dem globalen Namen aufeinander zugreifen, wenn diese Einstellung aktiviert ist.

     Console

     1. Wenn Sie die Einstellung auf Projektebene aktualisieren möchten, rufen Sie in derGoogle Cloud Console die Compute Engine-Seite Metadaten auf.

        Zur Seite „Benutzerdefinierte Metadaten“

     2. Klicken Sie auf edit Bearbeiten.

     3. Wenn ein Schlüssel mit dem Wert VmDnsSetting vorhanden ist, ändern Sie seinen Wert in ZonalOnly.

     4. Wenn kein Schlüssel mit dem Wert VmDnsSetting vorhanden ist, klicken Sie auf add_box Element hinzufügen.

        • Geben Sie im Feld Schlüssel VmDnsSetting ein.
        • Geben Sie im Feld Wert den Wert ZonalOnly ein.

     5. Klicken Sie auf Speichern, um die benutzerdefinierten Metadateneinträge zu ändern.

     gcloud

     1. Verwenden Sie den Befehl project-info add-metadata, um die Metadateneinstellung für das aktuelle Projekt zu aktualisieren.

        gcloud compute project-info add-metadata \
            --metadata vmDnsSetting=ZonalOnly
        

     2. Optional: Verwenden Sie den folgenden Befehl, um die Metadateneinstellungen für ein Projekt zu prüfen:

        gcloud compute project-info describe --project=PROJECT_ID --flatten="vmDnsSetting"
        

        Ersetzen Sie PROJECT_ID durch den Namen des Projekts, das Sie abfragen möchten.

     REST

     Wenn Sie die Metadateneinstellung auf Projektebene aktualisieren möchten, erstellen Sie eine POST-Anfrage mit der Methode projects.setCommonInstanceMetadata.

     1. Optional: Für ein optimistisches Sperrverfahren können Sie optional einen Fingerabdruck angeben.

        Ein Fingerabdruck ist eine Reihe zufälliger Zeichen, die von Compute Engine erstellt wird. Dieser Fingerabdruck ändert sich nach jeder Anfrage. Geben Sie einen falschen an, wird Ihre Anfrage abgelehnt.

        Wenn Sie keinen Fingerabdruck angeben, wird keine Konsistenzprüfung durchgeführt. Die projects.setCommonInstanceMetadata-Anfrage ist dann erfolgreich. Wenn Sie die Methode instances.setMetadata verwenden, ist immer ein Fingerabdruck erforderlich.

        Rufen Sie die Methode project.get auf, um den aktuellen Fingerabdruck eines Projekts abzurufen.

        GET https://compute.googleapis.com/compute/v1/projects/PROJECT_ID
        

        Die Ausgabe sieht etwa so aus:

        {
         "name": "myproject",
         "commonInstanceMetadata": {
           "kind": "compute#metadata",
           "fingerprint": "FikclA7UBC0=",
           ...
         }
        }
        

     2. Senden Sie eine POST-Anfrage an die Methode projects.setCommonInstanceMetadata, um das Metadaten-Schlüssel/Wert-Paar festzulegen:

        POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/setCommonInstanceMetadata
        
        {
        "fingerprint": "FikclA7UBC0=",
        "items": [
          {
          "key": "vmDnsSetting",
          "value": "ZonalOnly"
          }
        ]
        }
        

        Ersetzen Sie PROJECT_ID durch Ihre Projekt-ID.

  2. Nachdem Sie den Metadateneintrag vmDnsSetting für Ihr Projekt konfiguriert haben, aktualisieren Sie die DHCP-Lease für jede Instanz in diesem Projekt. Dazu können Sie die Instanz neu starten, auf den Ablauf der Freigabe warten oder einen der folgenden Befehle ausführen:

     Linux-Instanzen

     sudo dhclient -v -r
     

     Windows-Instanzen

     ipconfig /renew
     

  3. Prüfen, ob Ihr Projekt zonales DNS verwendet.

Inkompatible Anfragen korrigieren

Wenn ein Projekt nicht für die Migration bereit ist, wurde innerhalb eines bestimmten Zeitraums, z. B. in den letzten 30 Tagen, mindestens eine inkompatible DNS-Abfrage gestellt. Inkompatible Abfragen können die folgenden Attribute haben:

• Compute-Instanz in einem anderen Projekt aufrufen
• Anruf an eine Compute-Instanz in einer anderen Region

Wenn Ihr Projekt inkompatible Anfragen enthält, wird auf der Seite VM-Instanzen der Google Cloud Console das folgende Banner angezeigt:

Um alle inkompatiblen Abfragen zu korrigieren, empfehlen wir, den zonalen vollständig qualifizierten Domainnamen (FQDN) der Quellinstanz in der Abfrage zu verwenden. So wird sichergestellt, dass die Abfrageauflösung nach der Migration des Projekts zu zonalem DNS nicht unterbrochen wird.

So beheben Sie das Problem:

1. Mit dem Log-Explorer können Sie auf die globale DNS-Nutzung für Compute-Instanzen in Ihrem Projekt zugreifen und sie abfragen.

   Zum Log-Explorer

2. Wählen Sie das Projekt aus.

3. Wenden Sie die Filter für Ressourcen- und Lognamen an:

   1. Klicken Sie auf Ressource.
   2. Wählen Sie im Dialogfeld Ressource auswählen die Option VM-Instanz aus und klicken Sie dann auf Übernehmen.
   3. Klicken Sie auf Logname.

   4. Wählen Sie im Dialogfeld Lognamen auswählen die Option gdnsusage aus und klicken Sie auf Übernehmen.

   Alternativ können Sie Folgendes in das Abfragefeld eingeben:

      resource.type="gce_instance"
      log_name="projects/PROJECT_ID/logs/compute.googleapis.com%2Fgdnsusage"
     

4. Im Bereich Abfrageergebnisse hat jede Abfrage ein Feld jsonPayload. Jedes jsonPayload-Feld enthält die folgenden Informationen:

   • Der Name der Quell-VM, ihre Projekt-ID und der Name der Zone.
   • Der Name der Ziel-VM, ihre Projekt-ID und der Name der Zone.

   • Eine Debug-Meldung mit Informationen dazu, wie die globale DNS-Abfrage aktualisiert werden kann, die nicht mit zonalen DNS-Namen aufgelöst werden kann. Diese Abfragen blockieren die Migration und sollten behoben werden.

     "To use Zonal DNS, update the Global DNS query sent from the source VM
     VM_NAME.c.PROJECT_ID.internal to the following zonal
     FQDN: VM_NAME.ZONE.c.PROJECT_ID.internal"
     

   • Eine Anzahl von Anfragen, die angibt, wie viele migrationsblockierende Anfragen die Quell-VM an diesem Tag an die Ziel-VM sendet.

   Der folgende Screenshot zeigt die Feldinformationen jsonPayload auf der Console-Seite des Log-Explorers.

   

5. Anhand der Informationen in jsonPayload, die Sie im vorherigen Schritt abgerufen haben, können Sie ermitteln, welchen FQDN Sie verwenden müssen, um Ihre globalen DNS-Anfragen manuell so zu aktualisieren, dass zonales DNS verwendet wird, und das Projekt für die Migration vorzubereiten. Die häufigsten Anwendungsfälle für die Aktualisierung des FQDN und die Behebung von Kompatibilitätsproblemen sind:

   • Interne DNS-Namen vom Metadatenserver: Es ist keine Aktion erforderlich, da sich der zurückgegebene DNS-Name unmittelbar nach der Migration zu zonalem DNS in einen zonalen FQDN ändert. Wenn der DNS-Name im Cache gespeichert ist, müssen Sie nur einen weiteren Aufruf ausführen, um den Cache-Wert zu aktualisieren.
   • Interne DNS-Namen, die für den Zugriff auf VMs in einer anderen Region verwendet werden: Wenn Sie eine Anwendung haben, die die internen DNS-Namen für VMs in verschiedenen Regionen verwendet, können Sie die DHCP-Richtlinie oder Konfigurationsdatei so ändern, dass die Zone in der anderen Region enthalten ist.
   • Hartcodierter globaler FQDN: Wenn Sie eine Anwendung haben, die hartcodierte globale FQDN-Namen für VMs verwendet, können Sie den Aufruf in der Anwendung so aktualisieren, dass stattdessen der interne DNS-Name oder der zonale FQDN verwendet wird. Sie können diese Änderung durch eine Codeänderung oder eine Konfigurationsänderung in Terraform vornehmen.
   • VMs in Dienstprojekten, die ein freigegebene VPC-Netzwerk verwenden: Zum Auflösen von DNS-Namen von VMs in Dienstprojekten, die ein freigegebene VPC-Netzwerk verwenden, müssen Sie die zonalen FQDNs der VMs verwenden.

6. Nachdem Sie die globalen DNS-Abfragen so aktualisiert haben, dass zonales DNS verwendet wird, gehen Sie so vor:

   1. Verwenden Sie die Seite „Log-Explorer“, um die globale DNS-Nutzung noch einmal abzufragen. Nachdem Sie alle blockierenden globalen DNS-Abfragen behoben haben, sollten in den Abfrageergebnissen keine Debug-Logs mehr angezeigt werden.

   2. Prüfen Sie den Überwachungs-Messwert noch einmal, um zu sehen, ob alle inkompatiblen DNS-Anfragen entfernt wurden.

Globale DNS-Logs im Log-Explorer ansehen

Im Log-Explorer werden hauptsächlich globale DNS-Logs für Projekte mit Abfragen angezeigt, die nicht mit zonalem DNS kompatibel sind. Mithilfe dieser Logs können Sie diese problematischen Anfragen vor der Migration identifizieren und analysieren.

Sie können den Log-Explorer auch für diese inkompatiblen Abfragen verwenden, um Folgendes zu tun:

• Dashboards erstellen: Visualisieren Sie Ihre inkompatiblen globalen DNS-Abfragemuster, um Einblicke in das Kommunikationsverhalten Ihrer Anwendung zu erhalten.
• Logs zusammenfassen: Analysieren Sie DNS-Logs in Ihrer gesamten Organisation, um allgemeine Trends und potenzielle Verbesserungsbereiche zu ermitteln.

Prüfen, ob sich eine Änderung am zonalen DNS auf Ihr Projekt auswirkt

Nach der Migration zu zonalem DNS ist es wichtig, zu prüfen, ob Ihre Anwendungen und Dienste weiterhin ordnungsgemäß funktionieren. Da sich durch zonale DNS-Namen die Auflösung interner DNS-Namen ändert, kann es bei einigen Anwendungen, die auf globale DNS-Namen angewiesen sind, zu Problemen kommen.

Im folgenden Abschnitt wird beschrieben, wie Sie nach potenziellen Auswirkungen suchen und diese beheben können:

1. Befehlszeilenkommunikation zwischen Instanzen

   Aufgabe: Pingen Sie eine Instanz von einer anderen Instanz aus mit der gcloud CLI an.

   gcloud compute ssh VM-A --command "ping VM-B"
   

   Möglicher Fehler: „Could not resolve host“ (Host konnte nicht aufgelöst werden) – Das bedeutet, dass VM-A die IP-Adresse für VM-B nicht finden kann.

   Lösung: Aktualisieren Sie den Hostnamen, den Sie für VM-B verwenden, auf den vollständig qualifizierten Domainnamen (FQDN), der den Zonennamen enthält: INSTANCE_NAME.ZONE.c.PROJECT_ID.internal

2. Instanzkommunikation in Compute Engine-Diensten

   Aufgabe: Wenn Sie Systemdiagnosen für verwaltete Instanzgruppen (MIGs) verwenden, die auf internen DNS-Namen basieren, prüfen Sie, ob die Systemdiagnosen erfolgreich sind.

   Möglicher Fehler: „Systemdiagnose fehlgeschlagen“ – Dies weist darauf hin, dass das Ziel der Systemdiagnose aufgrund von Problemen bei der DNS-Auflösung nicht erreicht werden kann.

   Lösung: Achten Sie darauf, dass bei der Systemdiagnose der FQDN der Zielinstanz verwendet wird, einschließlich des Zonennamens.

3. Anwendungsspezifische Anwendungsfälle

   Viele Anwendungen sind für Aufgaben wie die folgenden auf internes DNS angewiesen:

   • Verbindung zu Datenbanken herstellen (z. B. Cloud SQL)

   • Interaktion mit Nachrichtenwarteschlangen (z. B. Pub/Sub)

   • Mögliche Fehler: Diese variieren je nach Anwendung, können aber Folgendes umfassen:

     • „Es konnte keine Verbindung zu SERVICE_NAME hergestellt werden“
     • „Zeitüberschreitung der Verbindung“
     • „No such host is known“ (Es ist kein solcher Host bekannt)

   • Lösung: Prüfen Sie die Konfiguration Ihrer Anwendung, um sicherzustellen, dass beim Verweisen auf Dienste der FQDN (einschließlich des Zonennamens) verwendet wird.

Zur Verwendung des globalen DNS zurückkehren

Sie können die Migration zu zonalem DNS rückgängig machen, indem Sie den standardmäßigen internen DNS-Typ wieder auf globales DNS ändern. Das ist auf Organisations-, Projekt-, Instanz- oder Containerebene möglich.

Zur Verwendung des globalen DNS für ein Projekt zurückkehren

So setzen Sie ein Projekt auf die Verwendung des globalen DNS zurück:

1. Fügen Sie den Metadaten des Projekts Folgendes hinzu: vmDnsSetting=GlobalDefault.

   Informationen zum Festlegen von Werten für Projektmetadaten finden Sie unter Benutzerdefinierte Metadaten festlegen und entfernen.

2. Prüfen Sie, ob für eine der Instanzen im Projekt der Metadatenwert vmDnsSetting auf ZonalOnly festgelegt ist.

   gcloud compute instances describe INSTANCE_NAME --flatten="metadata[]"
   

   Ersetzen Sie INSTANCE_NAME durch den Namen der Instanz, die Sie prüfen möchten.

3. Aktualisieren Sie die DHCP-Freigabe für jede Instanz. Dazu können Sie die Instanz neu starten, auf den Ablauf der Freigabe warten oder einen der folgenden Befehle im Gastbetriebssystem ausführen:

   • Linux-Instanzen: sudo dhclient -v -r
   • Windows Server-Instanz: ipconfig /renew

Zur Verwendung des globalen DNS für eine Instanz zurückkehren

Führen Sie die folgenden Schritte aus, um für eine bestimmte Instanz das globale DNS wiederherzustellen.

1. Aktualisieren Sie die Metadaten der Instanz, um vmDnsSetting=GlobalDefault einzuschließen.

   Informationen zum Festlegen von Werten für Compute Engine-Instanzmetadaten finden Sie unter Benutzerdefinierte Metadaten festlegen und entfernen.

2. Starten Sie das Netzwerk der Instanz mit einem der folgenden Befehle neu, um die Änderung der DNS-Konfiguration zu erzwingen:

   • Für Container-Optimized OS oder Ubuntu:

     sudo systemctl restart systemd-networkd
     

   • Für CentOS, RedHat EL, Fedora CoreOS oder Rocky Linux:

     sudo systemctl restart network
     

     oder

     sudo systemctl restart NetworkManager.service
     

   • Für Debian:

     sudo systemctl restart networking
     

   • Für Linux-Systeme mit nmcli:

     sudo nmcli networking off
     sudo nmcli networking on
     

   • Für Windows:

     ipconfig /renew
     

Zur Verwendung eines globalen DNS für einen Container zurückkehren

Wenn Sie Ihre Anwendung in Containern, in Google Kubernetes Engine oder in einer flexiblen App Engine-Umgebung ausführen, wird die DNS-Konfiguration in den Containereinstellungen möglicherweise erst automatisch aktualisiert, nachdem Sie die Container neu gestartet haben. So deaktivieren Sie zonales DNS für diese Container-Apps:

1. Legen Sie die Projektmetadateneinstellung vmDnsSetting für die Projekte, zu denen die Container und VMs gehören, auf GlobalDefault fest.

2. Starten Sie die Container neu, damit die DNS-Einstellungen in den ursprünglichen Zustand zurückgesetzt werden.

Fehlerbehebung bei der Migration vom globalen DNS zum zonalen DNS

Wenn Sie Probleme mit der Migration haben, lesen Sie die Anleitung zur Fehlerbehebung.

Nächste Schritte

• Informationen zur Beziehung zwischen Organisationen, Ordnern und Projekten finden Sie in der Google Cloud Ressourcenhierarchie.
• Weitere Informationen zum internen DNS für Compute Engine.