Projekte für die Verwendung des zonalen DNS aktualisieren

In diesem Dokument wird erläutert, wie Sie ein vorhandenes Projekt vom globalen DNS zum zonalen DNS migrieren. Zonales DNS erhöht die Zuverlässigkeit, indem Ausfälle innerhalb von Zonen isoliert werden, um Unterbrechungen bei wichtigen Diensten wie der Instanzerstellung und der automatischen Fehlerbehebung zu vermeiden.

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 bei Compute Engine authentifizieren. Wählen Sie dazu eine der folgenden Optionen aus:

    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. Install the Google Cloud CLI, then initialize it by running the following command: 

      gcloud init
    2. Set a default region and zone.

      3. REST

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

        Install the Google Cloud CLI, then initialize it by running the following command: 

        gcloud init

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

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 zonalem DNS erforderlich sind. Erweitern Sie den Abschnitt Erforderliche Berechtigungen, um die erforderlichen Berechtigungen anzuzeigen:

Erforderliche Berechtigungen

Für die Migration von Projekten zur Verwendung des zonalen DNS sind die folgenden Berechtigungen erforderlich:

  • Prüfen Sie, ob globale DNS-Namen und VM-Metadaten vorhanden sind: compute.projects.get
  • Metadaten für eine VM festlegen: compute.instances.setMetadata
  • Projektweite Metadaten festlegen: compute.projects.setCommonInstanceMetadata
  • Wenn Ihre VMs Dienstkonten verwenden: iam.serviceAccounts.actAs

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

Projekt zu zonalem DNS migrieren

Führen Sie die folgenden Schritte aus, um ein Projekt auf die Verwendung des zonalen DNS umzustellen:

  1. Prüfen, ob Ihr Projekt standardmäßig globales DNS verwendet
  2. Migrationsbereitschaft Ihrer Projekte anhand der Abfrageanalyse ermitteln
  3. Projekte migrieren, die mit zonalem DNS kompatibel sind
  4. Inkompatible Abfragen beheben
  5. Überwachen Sie globale DNS-Protokolle, um die Migrationsbereitschaft zu bestätigen.
  6. Restliche 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 Ihre Projekte, um festzustellen, ob sie von der Verwendung des globalen DNS zu zonalem 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.

Console

  1. Rufen Sie in der Google Cloud Console die Seite Metadaten der Compute Engine auf.

    Zur Seite "Metadaten"

  2. Rufen Sie auf dem Tab Metadaten die Einstellung vmdnssetting auf, falls vorhanden. Der zugewiesene Wert gibt an, ob das Projekt standardmäßig globales DNS verwendet.

    • GlobalDefault: Im Projekt ist globales DNS aktiviert.
    • ZonalOnly: Im Projekt ist das zonale DNS aktiviert. Dieses Projekt muss nicht migriert werden.

    Wenn die vmdnssetting-Metadateneinstellung nicht aufgeführt ist, prüfen Sie, ob Ihre Organisation standardmäßig globales DNS verwendet.

gcloud

Führen Sie den folgenden gcloud CLI-Befehl aus, um den Wert von vmDnsSetting zu prüfen.

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

Ersetzen Sie PROJECT_ID durch den Namen des Projekts.

Der zurückgegebene Wert gibt an, ob das Projekt standardmäßig globales DNS verwendet.

  • GLOBAL_DEFAULT: Im Projekt ist globales DNS aktiviert.
  • ZONAL_ONLY: Im Projekt ist das zonale DNS aktiviert. Dieses Projekt muss nicht migriert werden.

REST

Prüfen Sie den Wert von vmDnsSetting mit der Methode projects.get. In diesem Beispiel wird der Abfrageparameter fields verwendet, um nur die Felder einzubeziehen, die Sie sehen möchten.

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

Ersetzen Sie PROJECT_ID durch die Projekt-ID.

Der Wert von vmDnsSetting gibt an, ob das Projekt standardmäßig globales DNS verwendet.

  • GLOBAL_DEFAULT: Im Projekt ist globales DNS aktiviert.
  • ZONAL_ONLY: Im Projekt ist das zonale DNS aktiviert. Dieses Projekt muss nicht migriert werden.

Migrationsbereitschaft eines Projekts anhand der Abfrageanalyse bestimmen

Um zu beurteilen, ob ein Projekt ohne Codeänderungen oder Änderungen an der Verwendung des globalen DNS zu zonalem DNS migriert werden kann, wird Google Cloud Ihr DNS-Abfrageverlauf analysiert. Diese Analyse enthält die folgenden Messwerte, die die Projektkompatibilität mit zonalem DNS angeben:

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

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

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

  1. Rufen Sie in der Google Cloud Console die Seite 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 den folgenden Text genau so in das Abfrageeingabefeld ein:

    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 Console wird ein Diagramm mit den beiden Messwerten (zonal_dns_ready und zonal_dns_risky) und der entsprechenden Anzahl von Abfragen angezeigt, die im angegebenen Zeitraum für jeden Messwert ausgeführt wurden.

    Screenshot des Diagramms für Messwerte zur globalen DNS-Nutzung

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

    • Wenn der Wert 0 ist, kann das Projekt zu einem zonalen DNS migriert werden. Sie können das Projekt wie unter Projekte migrieren, die für zonales DNS bereit sind beschrieben migrieren.
    • 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 den Schritten unter Inkompatible Abfragen korrigieren fort.

Projekte migrieren, die mit zonalem DNS kompatibel sind

Verwenden Sie eine der folgenden Optionen, um Projekte zu migrieren, die für die Umstellung auf zonales DNS bereit sind:

  • Klicken Sie in der Google Cloud Console auf die Schaltfläche Zonales 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.

      Ein Screenshot des Banners „Bereit für die Migration zu zonalem DNS“ in der Console

      Wenn Sie auf die Schaltfläche Zonal-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 dazu den Metadateneintrag vmDnsSetting für das Projekt fest. Nachdem Sie diesen Metadateneintrag festgelegt haben, kann bei Verwendung von Suchpfaden nur über die zonalen DNS-Namen (VM_NAME.ZONE.c.PROJECT_ID.internal) auf Ihre Compute-Instanzen zugegriffen 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. Wenn diese Einstellung aktiviert ist, können nur Instanzen in derselben Region und im selben Projekt über den globalen Namen miteinander kommunizieren.

      Console

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

        Zur Seite „Benutzerdefinierte Metadaten“

      2. Klicken Sie auf  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 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 Änderungen an den benutzerdefinierten Metadateneinträgen abzuschließen.

      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 zu abfragenden Projekts.

      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 in 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-Freigabe 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 in Ihrem Projekt zonales DNS verwendet wird

Inkompatible Abfragen korrigieren

Wenn ein Projekt nicht für die Migration bereit ist, bedeutet das, dass innerhalb eines bestimmten Zeitraums, z. B. der letzten 30 Tage, mindestens eine inkompatible DNS-Abfrage erfolgt ist. Inkompatible Abfragen können die folgenden Attribute haben:

  • Eine Compute-Instanz in einem anderen Projekt aufrufen
  • Eine Compute-Instanz in einer anderen Region aufrufen

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

Banner, das darauf hinweist, dass Ihr Projekt nicht für die Migration zu zonalem DNS bereit ist

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

So beheben Sie Inkompatibilitäten bei Abfragen:

  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 dann 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 jsonPayload-Feld. Jedes jsonPayload-Feld enthält die folgenden Informationen:

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

    • Eine Debug-Nachricht mit Informationen zum Aktualisieren der globalen DNS-Abfrage, die nicht mithilfe zonaler 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 Abfrageanzahl, die angibt, wie viele Migrationsblockierungsabfragen 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.

    Screenshot der jsonPayload in den Ergebnissen der Log-Abfrage von gdnsusage

  5. Verwenden Sie die Informationen in der jsonPayload, die Sie im vorherigen Schritt erhalten haben, um den FQDN zu ermitteln, mit dem Sie Ihre globalen DNS-Abfragen manuell auf die Verwendung des zonalen DNS aktualisieren und das Projekt für die Migration vorbereiten können. Die häufigsten Anwendungsfälle für die Aktualisierung des FQDN und die Behebung von Kompatibilitätsproblemen sind:

    • Interne DNS-Namen vom Metadatenserver: Es sind keine Maßnahmen erforderlich, da sich der zurückgegebene DNS-Name unmittelbar nach der Migration zu zonalen DNS-Namen in einen zonalen FQDN ändert. Wenn der DNS-Name im Cache ist, müssen Sie nur noch einmal aufrufen, um den Cachewert 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 innerhalb der Anwendung so aktualisieren, dass stattdessen der interne DNS-Name oder der zonale FQDN verwendet wird. Sie können diese Änderung durch eine Code- oder Konfigurationsänderung in Terraform vornehmen.
    • VMs in Dienstprojekten, die ein freigegebenes VPC-Netzwerk verwenden: Zum Auflösen der DNS-Namen von VMs in Dienstprojekten, die ein freigegebenes VPC-Netzwerk verwenden, müssen Sie die zonalen FQDNs der VMs verwenden.

  6. Nachdem Sie die globalen DNS-Abfragen auf die Verwendung von zonalem DNS umgestellt haben, gehen Sie so vor:

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

    2. Prüfen Sie noch einmal den Messwert für die Überwachung, um festzustellen, ob alle inkompatiblen DNS-Abfragen 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 dem zonalen DNS kompatibel sind. Anhand dieser Logs können Sie diese problematischen Abfragen 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: Sie können Ihre inkompatiblen globalen DNS-Abfragemuster visualisieren, um Einblicke in das Kommunikationsverhalten Ihrer Anwendung zu erhalten.
  • Logs zusammenfassen: Analysieren Sie DNS-Logs für Ihre gesamte Organisation, um allgemeine Trends und potenzielle Verbesserungsmöglichkeiten zu erkennen.

Prüfen, ob eine Änderung am zonalen DNS Auswirkungen auf Ihr Projekt hat

Nach der Migration zum zonalen DNS müssen Sie prüfen, ob Ihre Anwendungen und Dienste weiterhin ordnungsgemäß funktionieren. Da zonales DNS die Auflösung interner DNS-Namen ändert, können bei einigen Anwendungen Probleme auftreten, wenn sie globale DNS-Namen verwenden.

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

  1. Befehlszeilenkommunikation

    Aufgabe: Versuchen Sie, mit der gcloud CLI einen Ping von einer Instanz zu einer anderen Instanz zu senden.

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

    Potenzieller Fehler: „Could not resolve host“ (Host konnte nicht aufgelöst werden): VM-A kann die IP-Adresse für VM-B nicht finden.

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

  2. Instanzkommunikation innerhalb von 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 bedeutet, dass die Systemdiagnose aufgrund von Problemen bei der DNS-Auflösung ihr Ziel nicht erreichen kann.

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

  3. Anwendungsspezifische Anwendungsfälle

    Viele Anwendungen nutzen das interne DNS für Aufgaben wie die folgenden:

    • Verbindungen 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:

      • „Verbindung zu SERVICE_NAME nicht möglich“
      • „Zeitüberschreitung der Verbindung“
      • „Kein solcher Host ist bekannt“

    • Lösung: Prüfen Sie die Konfiguration Ihrer Anwendung, um sicherzustellen, dass bei der Verschlüsselung von Diensten der FQDN (einschließlich des Zonennamens) verwendet wird.

Zur Verwendung des globalen DNS zurückkehren

Sie können die Migration zum zonalen DNS rückgängig machen, indem Sie den standardmäßigen internen DNS-Typ wieder in „Globales DNS“ ändern. Sie können dies auf Organisations-, Projekt-, Instanz- oder Containerebene tun.

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

Führen Sie die folgenden Schritte aus, um ein Projekt wieder auf die Verwendung des globalen DNS umzustellen.

  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 keine 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 auf jeder 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 wieder das globale DNS zu verwenden.

  1. Aktualisieren Sie die Metadaten der Instanz, um vmDnsSetting=GlobalDefault einzubeziehen.

    Informationen zum Festlegen von Metadatenwerten für Compute-Instanzen 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 das zonale DNS für diese Container-Apps:

  1. Legen Sie die Projektmetadateneinstellung vmDnsSetting in den Projekten, 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 bei der Migration Probleme auftreten, lesen Sie den Leitfaden zur Fehlerbehebung.

Nächste Schritte