Single-Stack-IPv6-Cluster erstellen und verwalten

In diesem Dokument wird erläutert, wie Sie Single-Stack-IPv6-Cluster in Google Kubernetes Engine (GKE) erstellen, konfigurieren und verwalten.

Sie können containerisierte Arbeitslasten in einer reinen IPv6-Netzwerkumgebung ausführen, um zu vermeiden, dass der private IPv4-Adressbereich (RFC 1918) erschöpft wird. Wenn Sie einen IPv6-Cluster mit Einzelstack bereitstellen, weisen Sie Ihren Pods, Knoten und Diensten nur IPv6-Adressen zu. Gleichzeitig bleibt die eingehende und ausgehende Verbindung zu internen und externen Ressourcen erhalten.

Übersicht

Wenn Ihre Arbeitslasten skaliert werden und die Clusterdichte zunimmt, kann der private IPv4-Adressbereich schnell erschöpft sein. In reinen IPv4- und Dual-Stack-Clustern benötigt jeder Pod eine IPv4-Adresse. Dies kann die Zuweisung von CIDR-Blöcken in Ihrem VPC-Netzwerk zu einem erheblichen Skalierungsengpass machen.

In GKE-Einzelstack-IPv6-Clustern weisen Sie IPv6-Adressen ausschließlich über die Cluster-Datenebene zu, wodurch IPv4-Adressbeschränkungen vollständig entfernt werden. Worker-Knoten werden auf Single-Stack-IPv6-Compute Engine-VM-Instanzen ausgeführt und Pods und Dienste kommunizieren über IPv6-Verbindungen.

Zuweisung von IP-Adressen (IPAM)

Einzelstack-IPv6-Cluster weisen IPv6-Adressen in Ihrem Subnetzwerk, Ihren Knoten, Pods und Diensten mithilfe der folgenden Präfixgrößen zu:

Ressource CIDR-Blockpräfix Beschreibung
Subnetzwerk /64 Wird als CIDR-Block für ein reines IPv6-Subnetzwerk angegeben.
Knoten /96 Wird von GKE automatisch aus dem CIDR-Block des Subnetzwerks zugewiesen und bietet etwa 4, 29 Milliarden eindeutige IPv6-Adressen pro Knoten.
Pod /112 Wird aus einem Teil des /96-Teilbereichs des Knotens zugewiesen.
Dienst /64 Wird von GKE automatisch für ClusterIP-Dienste aus dem IPv6-Adressbereich 2600:2D00:0:4::0:0/64 zugewiesen.

Externe und interne IPv6-Zugriffstypen

Beim Einrichten des Cluster-Subnetzes können Sie zwischen zwei IPv6-Zugriffstypen wählen, um die Internet-Routbarkeit zu steuern:

  • Intern (ULA): Subnetzwerke mit dem Zugriffstyp INTERNAL verwenden eindeutige lokale Unicast-Adressen (ULA) im Bereich fd20::/20. Die Kommunikation ist auf Ihr VPC-Netzwerk, Peering-Netzwerke und Hybridverbindungen beschränkt. Knoten und Pods können öffentliche IPv6-Internetressourcen nicht direkt erreichen oder direkten eingehenden Internettraffic empfangen.
  • Extern (GUA): Subnetze mit dem Zugriffstyp EXTERNAL verwenden Global Unicast Addresses (GUA). Knoten und Pods werden global eindeutige IPv6-Adressen zugewiesen. Sie können mit öffentlichen IPv6-Internetressourcen sowohl über eingehenden als auch über ausgehenden Traffic kommunizieren, vorbehaltlich der VPC-Firewallregeln und Routingtabellen.

Hinweis

Führen Sie die folgenden Aufgaben aus, bevor Sie beginnen:

  • Aktivieren Sie die Google Kubernetes Engine API.
    • Google Kubernetes Engine API aktivieren
  • Wenn Sie die Google Cloud CLI für diese Aufgabe verwenden möchten, müssen Sie die gcloud CLI installieren und dann initialisieren. Wenn Sie die gcloud CLI bereits installiert haben, rufen Sie die neueste Version mit dem Befehl gcloud components update ab. Ältere gcloud CLI-Versionen unterstützen möglicherweise nicht die Ausführung der Befehle in diesem Dokument.

Anforderungen und Einschränkungen

Wenn Sie Single-Stack-IPv6-Cluster verwenden möchten, müssen die folgenden Anforderungen und Einschränkungen erfüllt sein:

  • Ihr Cluster muss die GKE-Version 1.37.1-gke.3020000 oder höher ausführen.
  • Der Cluster muss ein VPC-nativer Cluster sein, der GKE Dataplane V2 verwendet. Single-Stack-IPv6-Cluster unterstützen keine routenbasierten Cluster.
  • Einzelstack-IPv6-Cluster unterstützen nur Einzelstack-IPv6-VM-Instanzen als Worker-Knoten und keine gemischten oder Dual-Stack-Knotenpools.
  • Sie müssen Cloud DNS als Cluster-DNS-Anbieter (--cluster-dns=clouddns) verwenden. IPv6-Cluster mit einem Stack unterstützen kube-dns nicht.
  • Der Zugriff auf die Steuerungsebene in Single-Stack-IPv6-Clustern erfolgt über zwei verschiedene Pfade:
    • Externe Clients: Clients außerhalb des Clusters (z. B. mit kubectl) greifen über einen domainbasierten Endpunkt über das GKE-Frontend (GKFE) auf die Steuerungsebene zu.
    • Interne Arbeitslasten: Knoten und Pods stellen über Private Service Connect eine sichere Verbindung zur Steuerungsebene her. Um diese Kommunikation zu unterstützen, müssen Sie ein Subnetzwerk mit dem IPv6-Zugriffstyp INTERNAL (--private-endpoint-subnetwork) bereitstellen oder erstellen.
  • In internen (INTERNAL) IPv6-Subnetzwerken können Knoten und Pods Google APIs und Artifact Registry über IPv6 ohne Cloud NAT-Gateway erreichen. Beachten Sie jedoch Folgendes:
    • Wenn Sie externe reine IPv4-Endpunkte (z. B. externe reine IPv4-Container-Registries) erreichen möchten, müssen Sie DNS64 und Cloud NAT (NAT64) konfigurieren.
    • Knoten und Pods in INTERNAL-Subnetzwerken können keine externen öffentlichen IPv6-Endpunkte außerhalb von Google erreichen, da Unique Local Addresses (ULA) im öffentlichen IPv6-Internet nicht routingfähig sind und Cloud NAT die IPv6-zu-IPv6-Übersetzung (NAT66) nicht unterstützt.
  • Einzelstack-IPv6-Cluster unterstützen die Cluster-Flags --private-ipv6-google-access-type und --enable-private-nodes nicht. Konfigurieren Sie stattdessen den privaten Google-Zugriff und die IPv6-Zugriffstypen (INTERNAL oder EXTERNAL) direkt in Ihrem VPC-Subnetz.
  • Single-Stack-IPv6-Cluster unterstützen keine Konfigurationen mit mehreren Subnetzen.
  • Einzelstack-IPv6-Cluster unterstützen GKE Ingress nicht. Verwenden Sie die Gateway API, um Layer-7-Application Load Balancer zu konfigurieren.
  • Die GKE-API für mehrere Netzwerke unterstützt keine IPv6-Pod-Netzwerke. Sekundäre Pod-Netzwerke müssen reine IPv4-Netzwerke sein. Weitere Informationen finden Sie unter Unterstützung mehrerer Netzwerke für Pods.
  • Reine IPv6-Cluster unterstützen Cloud Service Mesh nicht.
  • Sie können Bring your own IPv6 (BYOIPv6) mit Single-Stack-IPv6-Clustern verwenden. Informationen zu den Anforderungen für BYOIPv6-Präfixe finden Sie unter IPv6-Unterpräfixe erstellen und verwenden.

Konfiguration des Metadatenservers für Arbeitslasten

Da Arbeitslasten, die in reinen IPv6-Pods ausgeführt werden, die Standard-IPv4-Metadatenserveradresse (169.254.169.254) nicht erreichen können, müssen Sie die folgenden Anpassungen vornehmen:

  • Konfigurieren Sie Ihre Anwendungen und Clientbibliotheken so, dass sie über den Domainnamen metadata.google.internal (empfohlen) oder die literale ULA-IPv6-Adresse [fd20:ce::254] auf den Metadatenserver zugreifen.

  • Wenn Sie Clientbibliotheken oder Anwendungen mit hartcodierten IPv4-Metadatenserver-Endpunkten verwenden (z. B. frühere Versionen von Google API-Clientbibliotheken), legen Sie die Umgebungsvariable GCE_METADATA_HOST in Ihren Container-Images oder Pod-Spezifikationen fest:

    env:
- name: GCE_METADATA_HOST
  value: "metadata.google.internal"

IPv6-Cluster mit Einzelstack erstellen

Sie können einen Single-Stack-IPv6-Cluster mit der Google Cloud CLI erstellen.

Cluster und Subnetzwerk gleichzeitig erstellen

Wenn Sie keine benutzerdefinierten Subnetzwerke haben, können Sie einen Standard-IPv6-Cluster mit einem Stack erstellen und GKE das erforderliche Knoten-Subnetzwerk und --private-endpoint-subnetwork automatisch mit einem einzigen Befehl bereitstellen lassen.

Führen Sie dazu diesen Befehl aus:

gcloud beta container clusters create CLUSTER_NAME \
    --cluster-version=VERSION \
    --enable-dataplane-v2 \
    --cluster-dns=clouddns \
    --stack-type=ipv6 \
    --network=NETWORK_NAME \
    --create-subnetwork name=SUBNET_NAME \
    --ipv6-access-type=ACCESS_TYPE \
    --location=COMPUTE_LOCATION

Ersetzen Sie Folgendes:

  • CLUSTER_NAME: der Name des neuen Clusters
  • VERSION: GKE-Version 1.37.1-gke.3020000 oder höher.
  • NETWORK_NAME: der Name eines vorhandenen VPC-Netzwerk im benutzerdefinierten Modus.
  • SUBNET_NAME: der Name des neuen Knotensubnetzwerks, das erstellt werden soll.
  • ACCESS_TYPE: die Internet-Routbarkeit des Subnetzwerks. Geben Sie INTERNAL für die private ULA-Adressierung oder EXTERNAL für die öffentliche GUA-Adressierung an. Wenn keine Angabe gemacht wird, ist der Standardwert EXTERNAL.
  • COMPUTE_LOCATION: die Compute-Region oder -Zone für Ihren Cluster.

Standardcluster in benutzerdefinierten Subnetzwerken erstellen

Wenn Sie vorhandene oder benutzerdefinierte Subnetzwerke verwenden möchten, erstellen Sie das VPC-Netzwerk, das PSC-Subnetzwerk der Steuerungsebene und das Knoten-Subnetzwerk, bevor Sie den Cluster erstellen.

  1. Erstellen Sie ein VPC-Netzwerk im benutzerdefinierten Modus mit aktivierten internen ULA-IPv6-Adressen:

    gcloud compute networks create NETWORK_NAME \
    --subnet-mode=CUSTOM \
    --enable-ula-internal-ipv6

  2. Erstellen Sie das dedizierte interne PSC-Subnetzwerk für die Steuerungsebene:

    gcloud compute networks subnets create PSC_SUBNET_NAME \
    --stack-type=ipv6_only \
    --ipv6-access-type=INTERNAL \
    --network=NETWORK_NAME \
    --region=COMPUTE_REGION

    Ersetzen Sie COMPUTE_REGION durch die Region, in der Sie den Cluster bereitstellen (z. B. us-central1). Sie können auch --stack-type=ipv4_ipv6 für das Subnetzwerk der PSC-Steuerungsebene angeben.

  3. Erstellen Sie das Knotensubnetzwerk. Wählen Sie entweder den internen Zugriff (INTERNAL) oder den externen Zugriff (EXTERNAL) aus:

    gcloud compute networks subnets create NODE_SUBNET_NAME \
    --stack-type=ipv6_only \
    --ipv6-access-type=ACCESS_TYPE \
    --network=NETWORK_NAME \
    --region=COMPUTE_REGION

  4. Erstellen Sie den Single-Stack-IPv6-Standardcluster, der auf beide Subnetze verweist:

    gcloud container clusters create CLUSTER_NAME \
    --cluster-version=VERSION \
    --enable-dataplane-v2 \
    --cluster-dns=clouddns \
    --stack-type=ipv6 \
    --network=NETWORK_NAME \
    --subnetwork=NODE_SUBNET_NAME \
    --private-endpoint-subnetwork=PSC_SUBNET_NAME \
    --location=COMPUTE_LOCATION

Autopilot-Cluster in benutzerdefinierten Subnetzwerken erstellen

Autopilot-Cluster übernehmen ihren Stack-Typ automatisch vom Knotensubnetz, das Sie angeben. Wenn Sie ein reines IPv6-Subnetzwerk auswählen, erstellt die GKE einen Single-Stack-IPv6-Autopilot-Cluster.

  1. Sie müssen ein benutzerdefiniertes VPC-Netzwerk, ein internes PSC-Subnetzwerk und ein IPv6-only-Knotensubnetzwerk erstellt haben, wie im vorherigen Abschnitt beschrieben.

  2. Erstellen Sie den Autopilot-Cluster:

    gcloud container clusters create-auto CLUSTER_NAME \
    --cluster-version=VERSION \
    --network=NETWORK_NAME \
    --subnetwork=NODE_SUBNET_NAME \
    --private-endpoint-subnetwork=PSC_SUBNET_NAME \
    --location=COMPUTE_LOCATION

Standardcluster mit verwalteten Knoten erstellen

Sie können auch einen Single-Stack-IPv6-Standardcluster erstellen, der verwaltete Knoten verwendet, die auf Arbeitslastebene konfiguriert sind. Weitere Informationen zum Konfigurieren verwalteter ComputeClasses in Standard-Clustern finden Sie unter Autopilot-Klassen in Standard-Clustern.

Eigene IPv6-Adressen für Knoten und Pods verwenden

Sie können einen Single-Stack-IPv6-Cluster erstellen, dessen Knoten und Pods eigene IPv6-Adressen (BYOIPv6) anstelle von von Google bereitgestellten Adressen verwenden. Erstellen Sie dazu das Knoten-Subnetzwerk mit einem externen IPv6-Adressbereich, der aus einem regionalen IPv6-Unterpräfix Ihres öffentlich delegierten Präfixes (PDP) stammt. Knoten und Pods erhalten dann IPv6-Adressen aus diesem Präfix und kommunizieren über diese Adressen mit dem Internet und untereinander.

  1. Erstellen Sie ein regionales IPv6-Unterpräfix Ihres öffentlich delegierten Präfixes im Modus EXTERNAL_IPV6_SUBNETWORK_CREATION. Weitere Informationen finden Sie unter IPv6-Unterpräfixe erstellen.

  2. Erstellen Sie das Knoten-Subnetzwerk mit dem IPv6-Zugriffstyp EXTERNAL und verweisen Sie mit dem Flag --ip-collection auf das Unterpräfix. Compute Engine weist den /64-IPv6-Adressbereich des Subnetzwerks aus dem Unterpräfix zu:

    gcloud compute networks subnets create NODE_SUBNET_NAME \
    --stack-type=ipv6_only \
    --ipv6-access-type=EXTERNAL \
    --ip-collection=SUB_PREFIX_NAME \
    --network=NETWORK_NAME \
    --region=COMPUTE_REGION

    Ersetzen Sie SUB_PREFIX_NAME durch den Namen des Subpräfixes, das Sie im vorherigen Schritt erstellt haben. Das Unterpräfix muss sich in derselben Region wie das Subnetzwerk befinden. Wenn Sie einen bestimmten /64-Bereich aus dem Subpräfix auswählen möchten, anstatt einen von Compute Engine zuweisen zu lassen, fügen Sie das Flag --external-ipv6-prefix hinzu.

  3. Erstellen Sie den Cluster in diesem Knoten-Subnetzwerk. Folgen Sie dazu der Anleitung unter Standardcluster in benutzerdefinierten Subnetzwerken erstellen oder Autopilot-Cluster in benutzerdefinierten Subnetzwerken erstellen. Das PSC-Steuerungsebenen-Subnetz benötigt keinen BYOIPv6-Adressbereich.

  4. Prüfen Sie nach dem Erstellen des Clusters durch GKE, ob die Knoten und Pods IPv6-Adressen aus Ihrem Präfix haben:

    kubectl get nodes -o wide
kubectl get pods --all-namespaces -o wide

Beachten Sie Folgendes:

  • In diesem Verfahren wird ein Knoten-Subnetzwerk mit dem IPv6-Zugriffstyp EXTERNAL verwendet, sodass Knoten und Pods global routingfähige Adressen aus Ihrem Präfix erhalten. Sie können auch ein Knoten-Subnetzwerk mit dem IPv6-Zugriffstyp INTERNAL verwenden, indem Sie auf ein Unterpräfix im Modus INTERNAL_IPV6_SUBNETWORK_CREATION verweisen. In diesem Fall erhalten Knoten und Pods interne BYOIPv6-Adressen und es gelten die Konnektivitätseinschränkungen des internen IPv6-Zugriffstyps. Weitere Informationen finden Sie unter Verbindung zu externen und privaten Ressourcen herstellen.
  • Informationen zum Bereitstellen von Arbeitslasten auf BYOIPv6-Adressen mit LoadBalancer-Diensten finden Sie unter Bring your own IPv6 addresses (BYOIPv6). Dafür ist kein BYOIPv6-Knotensubnetz erforderlich.
  • Informationen zu den Anforderungen für BYOIPv6-Präfixe finden Sie unter IPv6-Unterpräfixe erstellen und verwenden.

Cluster-Stacktyp prüfen

Listen Sie nach Abschluss der Clustererstellung Ihre Cluster auf, um zu prüfen, ob Ihr Cluster im Single-Stack-IPv6-Modus ausgeführt wird:

gcloud beta container clusters list

Die Ausgabe bestätigt, dass die Spalte STACK_TYPE auf IPV6 gesetzt ist:

NAME               LOCATION       MASTER_VERSION      MASTER_IP                                 MACHINE_TYPE  NODE_VERSION        NUM_NODES  STACK_TYPE  STATUS
v6-only-cluster-1  us-central1-c  1.37.0-gke.1000000  gke-3a3234-123456.us-central1-c.gke.goog  e2-medium     1.37.0-gke.1000000  1          IPV6        RUNNING

Load Balancing in Single-Stack-IPv6-Clustern

Sie können Anwendungen, die in Single-Stack-IPv6-Clustern ausgeführt werden, sowohl mit Layer-7- als auch mit Layer-4-Load-Balancern bereitstellen:

  • Layer-7-Application Load Balancing (Gateway API): Verwenden Sie die Kubernetes Gateway API, um Layer-7-Application Load Balancer (gke-l7-rilb, gke-l7-regional-external-managed oder gke-l7-global-external-managed) bereitzustellen. Diese Gateways können sowohl interne als auch externe IPv4- und IPv6-Clients bedienen und gleichzeitig Traffic transparent an interne reine IPv6-Pod-Endpunkte weiterleiten. Beachten Sie, dass GKE Ingress auf Single-Stack-IPv6-Clustern nicht unterstützt wird. Wenn Sie regionale Gateways (gke-l7-rilb und gke-l7-regional-external-managed) in Single-Stack-IPv6-Clustern bereitstellen, beachten Sie die folgenden Subnetzanforderungen:

    • Nur-Proxy-Subnetzwerk: In IPv6-Einzel-Stack-Clustern muss das regionale Nur-Proxy-Subnetzwerk (--purpose=REGIONAL_MANAGED_PROXY) ein Dual-Stack-Subnetzwerk (--stack-type=IPV4_IPV6) sein. In reinen IPv4- und Dual-Stack-Clustern kann das Subnetzwerk entweder ein reines IPv4- oder ein Dual-Stack-Subnetzwerk sein.
    • Gateway-VIP-Subnetz: Im Gegensatz zu regionalen externen IPv4-Gateways (die keine VIPs aus einem Subnetz zuweisen) erfordern regionale externe IPv6-Gateways (gke-l7-regional-external-managed) ein Subnetz mit EXTERNAL-IPv6-Zugriff und regionale interne Gateways (gke-l7-rilb) ein Subnetz mit INTERNAL-IPv6-Zugriff (oder einen IPv4-Bereich für eine interne IPv4-VIP). Wenn Sie eine sitzungsspezifische regionale Gateway-VIP aus einem benutzerdefinierten Subnetzwerk anstelle des Knoten-Subnetzwerks des Clusters zuweisen möchten, geben Sie den Subnetzwerknamen im Feld spec.default.subnetwork einer GCPGatewayPolicy an, die an das Gateway angehängt ist.

    Eine Konfigurationsanleitung finden Sie unter Gateways bereitstellen.

  • Layer-4-Passthrough-Load-Balancing (Service API): Sie können Arbeitslasten für IPv6-Clients mithilfe von Kubernetes-Diensten verfügbar machen, die mit type: LoadBalancer konfiguriert sind. Je nachdem, ob Ihre Clusterknoten in einem INTERNAL- (ULA) oder EXTERNAL-Subnetzwerk (GUA) ausgeführt werden, müssen Sie möglicherweise ein dediziertes Load-Balancer-Subnetzwerk bereitstellen und mit der Annotation networking.gke.io/load-balancer-subnet darauf verweisen:

Verbindung zu externen und privaten Ressourcen herstellen

Arbeitslasten in Ihrem Single-Stack-IPv6-Cluster müssen häufig mit externen Diensten über das Internet oder mit privaten Diensten in Google Cloudkommunizieren.

Verbindung zu öffentlichen IPv6-Internetressourcen herstellen

Wenn Ihre Clusterknoten in einem Subnetz ausgeführt werden, das mit dem IPv6-Zugriffstyp EXTERNAL (--ipv6-access-type=EXTERNAL) konfiguriert ist, ist die ausgehende und eingehende Verbindung zu öffentlichen IPv6-Endpunkten im Internet standardmäßig aktiviert. Prüfen Sie, ob Ihre VPC-Firewallregeln den erforderlichen IPv6-Traffic zulassen. Weitere Informationen finden Sie unter VPC-Firewallregeln verwenden.

Verbindung zu öffentlichen IPv4-Internetressourcen herstellen (DNS64 und NAT64)

Da Pods in einem IPv6-Cluster mit Einzelstack nur IPv6-Adressen haben, ist für die Verbindung mit öffentlichen IPv4-Internetendpunkten eine Netzwerkübersetzung erforderlich. Sie können Cloud DNS und Cloud NAT in Ihrem VPC-Netzwerk konfigurieren, um eine automatische DNS64- und NAT64-Übersetzung bereitzustellen:

  1. Erstellen Sie eine DNS64-Serverrichtlinie:

    gcloud dns policies create POLICY_NAME \
    --description="DNS64 policy for single-stack IPv6 cluster" \
    --networks=NETWORK_NAME \
    --enable-dns64-all-queries

  2. Erstellen Sie einen Cloud Router in der Region, in der Ihr Cluster bereitgestellt ist:

    gcloud compute routers create ROUTER_NAME \
    --network=NETWORK_NAME \
    --region=COMPUTE_REGION

  3. Erstellen Sie ein Cloud NAT-Gateway, das für die NAT64-Übersetzung konfiguriert ist:

    gcloud compute routers nats create NAT_NAME \
    --router=ROUTER_NAME \
    --region=COMPUTE_REGION \
    --auto-allocate-nat-external-ips \
    --nat64-all-v6-subnet-ip-ranges

    Wenn Sie NAT64 mit bestimmten Subnetzwerken oder manuellen externen IP-Adressen konfigurieren möchten, verwenden Sie --nat64-custom-v6-subnet-ip-ranges und --nat-external-ip-pool.

Weitere Informationen zur Adressübersetzung finden Sie unter DNS64 und NAT64 konfigurieren und DNS64 und NAT64 für 6to4-Konnektivität.

Verbindung zu privaten Diensten über Private Service Connect herstellen

Private Service Connect (PSC) unterstützt die IPv6-zu-IPv4-Adressübersetzung über Endpunkte und Weiterleitungsregeln hinweg. Sie können Arbeitslasten in Ihrem Single-Stack-IPv6-Cluster mit von Google Cloud verwalteten Diensten (z. B. Cloud SQL-Instanzen) oder Diensten von Drittanbietern verbinden:

  1. Reservieren Sie eine statische interne IPv6-Adresse aus dem PSC-Subnetzwerk Ihres Clusters:

    gcloud compute addresses create ADDRESS_NAME \
    --ip-version=IPV6 \
    --subnet=PSC_SUBNET_NAME \
    --region=COMPUTE_REGION

  2. Erstellen Sie eine PSC-Endpunkt-Weiterleitungsregel, die auf den Dienstanhang verweist:

    gcloud compute forwarding-rules create FORWARDING_RULE_NAME \
    --address=ADDRESS_NAME \
    --region=COMPUTE_REGION \
    --network=NETWORK_NAME \
    --target-service-attachment=SERVICE_ATTACHMENT_URL \
    --allow-psc-global-access

  3. Rufen Sie die zugewiesene IPv6-Adresse ab:

    gcloud compute forwarding-rules describe FORWARDING_RULE_NAME \
    --region=COMPUTE_REGION \
    --format='value(IPAddress)'

  4. Verwenden Sie die abgerufene IPv6-Adresse in den Verbindungsstrings Ihrer Anwendung. PSC übersetzt den Traffic, sodass Ihre IPv6-Pods IPv4- oder Dual-Stack-Produzentendienste sicher erreichen können.

Weitere Informationen zur Nutzung veröffentlichter Dienste finden Sie unter Private Service Connect-Endpunkt erstellen und Mit Private Service Connect eine Verbindung zu Cloud SQL herstellen. Wenn Sie einen internen LoadBalancer-Dienst, der in Ihrem Cluster ausgeführt wird, für Nutzer in anderen VPC-Netzwerken mithilfe einer ServiceAttachment-Ressource veröffentlichen möchten, lesen Sie den Hilfeartikel Internen Load Balancer mit Private Service Connect erstellen.

Erweiterte Netzwerkeinstellungen und Beschleuniger

Sie können Single-Stack-IPv6-Cluster mit sekundären Netzwerkschnittstellen für Beschleuniger-Knotenpools und Pods mit mehreren Netzwerken konfigurieren.

Multi-NIC-Beschleunigernetzwerke

In Standard-Single-Stack-IPv6-Clustern können Sie sekundäre Datennetzwerke (RDMA oder DIORITE) mithilfe von automatisiertem Netzwerk (--accelerator-network-profile=auto) oder manueller Multi-Netzwerk-Konfiguration (--additional-node-network) an Beschleuniger-Knotenpools (GPUs und TPUs) anhängen. Sekundäre Schnittstellen können in IPv4-Subnetzen, Dual-Stack-Subnetzen oder reinen IPv6-Subnetzen ausgeführt werden.

Eine detaillierte Anleitung finden Sie unter Knotennetzwerke mit mehreren NICs auf Single-Stack-IPv6-Clustern konfigurieren.

Unterstützung mehrerer Netzwerke für Pods

Single-Stack-IPv6-Cluster unterstützen Multi-Netzwerke für Pods mit den folgenden Merkmalen:

  • Die primäre Pod-Netzwerkschnittstelle (eth0) verwendet ein Single-Stack-IPv6-Netzwerk.
  • Zusätzliche Pod-Netzwerkschnittstellen müssen reine IPv4-Schnittstellen (Layer-3-VPC-Netzwerke) sein. IPv6-Cluster mit einem Stack unterstützen keine IPv6-Pod-Netzwerke auf zusätzlichen Netzwerkschnittstellen.
  • Mit der Pod-Annotation networking.gke.io/default-interface wird die Standardschnittstelle nur für IPv4-Traffic konfiguriert. Für IPv6-Traffic wird keine Standardschnittstelle konfiguriert.

Informationen zum Konfigurieren sekundärer IPv4-Pod-Netzwerke, die von VPC-Subnetzwerken unterstützt werden, finden Sie unter Unterstützung mehrerer Netzwerke für Pods in Single-Stack-IPv6-Clustern einrichten.

Zu IPv6-Einzelstack-Clustern migrieren

Sie können vorhandene IPv4-Cluster oder Dual-Stack-Cluster nicht direkt in Single-Stack-IPv6-Cluster konvertieren oder aktualisieren. Verwenden Sie für die Migration von Arbeitslasten eine Blau/Grün-Migration:

  1. Abhängigkeiten prüfen: Prüfen Sie, ob Anwendungskonfigurationen, Clientbibliotheken und Agents DNS-Namen (z. B. metadata.google.internal) anstelle von hartcodierten IPv4-Adressen verwenden. Konfigurieren Sie GCE_METADATA_HOST, falls erforderlich.
  2. Grünen Cluster bereitstellen: Stellen Sie einen neuen Single-Stack-IPv6-Cluster parallel zu Ihrem vorhandenen Cluster im selben oder in einem Peering-VPC-Netzwerk bereit. Prüfen Sie, ob Cloud DNS, DNS64, Cloud NAT (NAT64) und PSC-Weiterleitungsregeln konfiguriert sind.
  3. Arbeitslasten bereitstellen: Wenden Sie Ihre Kubernetes-Manifeste auf den grünen Cluster an und prüfen Sie, ob Pods gestartet werden und erfolgreich kommunizieren.
  4. Traffic verlagern: Verlagern Sie den Traffic mithilfe Ihrer Load Balancer (Gateway API oder Cloud DNS-Routingrichtlinien) schrittweise vom Legacy-Cluster auf den neuen IPv6-Cluster, während Sie Messwerte und Fehlerraten im Blick behalten.
  5. Legacy-Cluster außer Betrieb nehmen: Nachdem der gesamte Traffic verschoben wurde und der grüne Cluster als stabil verifiziert wurde, leeren und löschen Sie den alten Cluster.

Nächste Schritte