VPC-nativen Cluster erstellen

Auf dieser Seite wird beschrieben, wie VPC-native Cluster in Google Kubernetes Engine (GKE) konfiguriert werden.

Weitere Informationen zu den Vorteilen und Anforderungen von VPC-nativen Clustern finden Sie in der Übersicht für VPC-native Cluster.

Für GKE Autopilot-Cluster sind VPC-native Netzwerke standardmäßig aktiviert und können nicht überschrieben werden.

Hinweise

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 diesen Task 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. In früheren gcloud CLI-Versionen werden die Befehle in diesem Dokument möglicherweise nicht unterstützt.

Beschränkungen

  • Sie können einen VPC-nativer Cluster nicht in einen routenbasierten Cluster konvertieren und umgekehrt auch keinen routenbasierten Cluster in einen VPC-nativer Cluster konvertieren.

  • Für VPC-native Cluster sind VPC-Netzwerke erforderlich. Alte Netzwerke werden nicht unterstützt.

  • Wie bei allen GKE-Clustern sind Dienstadressen (ClusterIP) nur innerhalb des Clusters verfügbar. Wenn Sie von VM-Instanzen außerhalb des Clusters, aber innerhalb des VPC-Netzwerks und der Region des Clusters auf einen Kubernetes-Dienst zugreifen müssen, erstellen Sie einen internen Passthrough-Network-Load-Balancer.

  • Wenn Sie alle Pod-IP-Adressen in einem Subnetz verwenden, können Sie den sekundären IP-Adressbereich des Subnetzes nicht ersetzen, ohne den Cluster in einen instabilen Zustand zu versetzen. Sie können jedoch zusätzliche Pod-IP-Adressbereiche erstellen, indem Sie nicht zusammenhängende CIDRs mit mehreren Pods verwenden.

Cluster erstellen

In diesem Abschnitt wird beschrieben, wie Sie die folgenden Aufgaben beim Erstellen eines Clusters ausführen:

  • Cluster und Subnetz gleichzeitig erstellen
  • Erstellen Sie einen Cluster in einem vorhandenen Subnetz.
  • Erstellen Sie einen Cluster und wählen Sie den IP-Adressbereich der Steuerungsebene aus.
  • Erstellen Sie einen Cluster mit Dual-Stack-Netzwerk in einem neuen Subnetz (verfügbar in Autopilot-Clustern ab Version 1.25 und Standardclustern ab Version 1.24).
  • Erstellen Sie gleichzeitig einen Dual-Stack-Cluster und ein Dual-Stack-Subnetz (verfügbar in Autopilot-Clustern ab Version 1.25 und Standardclustern ab Version 1.24).

Sie können auch einen Cluster erstellen und die automatische IP-Adressverwaltung in Ihrem Cluster aktivieren (Vorschau). In diesem Fall erstellt GKE automatisch Subnetze und verwaltet IP-Adressen für Sie. Weitere Informationen finden Sie unter Automatische IP-Adressverwaltung verwenden.

Nachdem Sie den Cluster erstellt haben, können Sie den Zugriff auf die Steuerungsebene des Clusters ändern. Weitere Informationen finden Sie unter Netzwerkisolation in GKE anpassen.

Cluster und Subnetz gleichzeitig erstellen

In der folgenden Anleitung erfahren Sie, wie Sie einen VPC-nativen GKE-Cluster und ein Subnetz gleichzeitig erstellen. Die Zuweisungsmethode für sekundäre Bereiche lautet "Von GKE verwaltet", wenn Sie diese beiden Schritte mit einem einzigen Befehl ausführen.

Wenn Sie eine freigegebene VPC verwenden, können Sie den Cluster und das Subnetz nicht gleichzeitig erstellen. Stattdessen muss ein Netzwerkadministrator im freigegebene VPC-Hostprojekt zuerst das Subnetz erstellen. Dann können Sie den Cluster in einem vorhandenen Subnetz mit der Zuweisungsmethode für sekundäre Bereiche "Vom Nutzer verwaltet" erstellen.

gcloud

Führen Sie den folgenden Befehl aus, um einen VPC-nativer Cluster und ein Subnetz gleichzeitig zu erstellen:

gcloud container clusters create CLUSTER_NAME \
    --location=COMPUTE_LOCATION \
    --enable-ip-alias \
    --create-subnetwork name=SUBNET_NAME,range=NODE_IP_RANGE \
    --cluster-ipv4-cidr=POD_IP_RANGE \
    --services-ipv4-cidr=SERVICES_IP_RANGE

Ersetzen Sie Folgendes:

  • CLUSTER_NAME ist der Name des GKE-Clusters.
  • COMPUTE_LOCATION: der Compute Engine-Standort für den Cluster.
  • SUBNET_NAME: Der Name des zu erstellenden Subnetzes. Die Region des Subnetzes entspricht der Region des Clusters (oder der Region, die den zonalen Cluster enthält). Verwenden Sie einen leeren String (name=""), wenn GKE einen Namen für Sie erzeugen soll.
  • NODE_IP_RANGE: Ein IP-Adressbereich in CIDR-Notation, z. B. 10.5.0.0/20, oder die Größe der Subnetzmaske eines CIDR-Blocks, z. B. /20. Dies wird verwendet, um den primären IP-Adressbereich des Subnetzes für Knoten zu erstellen. Wenn keine Angabe gemacht wird, wählt GKE einen verfügbaren IP-Bereich in der VPC mit der Größe /20 aus.
  • POD_IP_RANGE: Ein IP-Adressbereich in CIDR-Notation, z. B. 10.0.0.0/14, oder die Größe der Subnetzmaske eines CIDR-Blocks, z. B. /14. Damit wird der sekundäre IP-Adressbereich des Subnetzes für Pods erstellt. Wenn keine Angabe gemacht wird, verwendet GKE einen zufällig ausgewählten /14-Bereich mit 218 Adressen. Der automatisch ausgewählte Bereich wird nach dem Zufallsprinzip aus 10.0.0.0/8 (einem Bereich mit 224 Adressen) ausgewählt und enthält keine IP-Adressbereiche, die VMs zugewiesen sind, keine vorhandenen Routen und keine Bereiche, die anderen Clustern zugewiesen sind. Der automatisch ausgewählte Bereich kann einen Konflikt mit reservierten IP-Adressen, dynamischen Routen oder Routen in VPCs auslösen, die eine Peering-Verbindung zu diesem Cluster haben. Wenn Sie einen dieser Fälle verwenden, sollten Sie --cluster-ipv4-cidr angeben, um Konflikte zu vermeiden.
  • SERVICES_IP_RANGE: Ein IP-Adressbereich in CIDR-Notation, z. B. 10.4.0.0/19, oder die Größe der Subnetzmaske eines CIDR-Blocks, z. B. /19. Damit wird der sekundäre IP-Adressbereich des Subnetzes für Services erstellt. Wenn keine Angabe gemacht wird, verwendet GKE /20, die Standardgröße für Service-IP-Adressbereiche.

Console

Sie können mit derGoogle Cloud -Konsole einen Cluster und ein Subnetz nicht gleichzeitig erstellen. Erstellen Sie stattdessen zuerst ein Subnetz und dann den Cluster in einem vorhandenen Subnetz.

API

Definieren Sie zum Erstellen eines VPC-nativen Clusters ein IPAllocationPolicy-Objekt in Ihrer Clusterressource:

{
  "name": CLUSTER_NAME,
  "description": DESCRIPTION,
  ...
  "ipAllocationPolicy": {
    "useIpAliases": true,
    "createSubnetwork": true,
    "subnetworkName": SUBNET_NAME
  },
  ...
}

Im Feld createSubnetwork wird automatisch ein Subnetzwerk für den Cluster erstellt und bereitgestellt. Das Feld subnetworkName ist optional. Wird kein Name angegeben, wird der Name für das Subnetzwerk automatisch ausgewählt.

Nachdem Sie den Cluster erstellt haben, können Sie den Zugriff auf die Steuerungsebene des Clusters ändern. Weitere Informationen finden Sie unter Netzwerkisolation in GKE anpassen.

Cluster in einem vorhandenen Subnetz erstellen

In der folgenden Anleitung wird gezeigt, wie Sie einen VPC-nativen GKE-Cluster in einem vorhandenen Subnetz mit der gewünschten Zuweisungsmethode für sekundäre Bereiche erstellen.

gcloud

  • So verwenden Sie die Zuweisungsmethode für sekundäre Bereiche Von GKE verwaltet:

    gcloud container clusters create CLUSTER_NAME \
    --location=COMPUTE_LOCATION \
    --enable-ip-alias \
    --subnetwork=SUBNET_NAME \
    --cluster-ipv4-cidr=POD_IP_RANGE \
    --services-ipv4-cidr=SERVICES_IP_RANGE

  • Wenn Sie die Zuweisungsmethode für sekundäre Bereiche Vom Nutzer verwaltet verwenden möchten, führen Sie den folgenden Befehl aus:

    gcloud container clusters create CLUSTER_NAME \
    --location=COMPUTE_LOCATION \
    --enable-ip-alias \
    --subnetwork=SUBNET_NAME \
    --cluster-secondary-range-name=SECONDARY_RANGE_PODS \
    --services-secondary-range-name=SECONDARY_RANGE_SERVICES

Ersetzen Sie Folgendes:

  • CLUSTER_NAME ist der Name des GKE-Clusters.
  • COMPUTE_LOCATION: der Compute Engine-Standort für den Cluster.
  • SUBNET_NAME: Der Name eines vorhandenen Subnetzes. Der primäre IP-Adressbereich des Subnetzes wird für Knoten verwendet. Das Subnetz muss sich in derselben Region befinden wie der Cluster. Wenn keine Angabe gemacht wird, versucht GKE, ein Subnetz im VPC-Netzwerk default in der Region des Clusters zu verwenden.
  • Wenn die Zuweisungsmethode für sekundäre Bereiche Von GKE verwaltet lautet:
    • POD_IP_RANGE: Ein IP-Adressbereich in CIDR-Notation, z. B. 10.0.0.0/14, oder die Größe der Subnetzmaske eines CIDR-Blocks, z. B. /14. Damit wird der sekundäre IP-Adressbereich des Subnetzes für Pods erstellt. Wenn Sie die Option --cluster-ipv4-cidr weglassen, wählt GKE automatisch einen /14-Bereich (218 Adressen) aus. Der automatisch ausgewählte Bereich wird nach dem Zufallsprinzip aus 10.0.0.0/8 (einem Bereich von 224 Adressen) ausgewählt und enthält keine IP-Adressbereiche, die VMs zugewiesen sind, keine vorhandenen Routen und keine Bereiche, die anderen Clustern zugewiesen sind. Der automatisch ausgewählte Bereich kann einen Konflikt mit reservierten IP-Adressen, dynamischen Routen oder Routen in VPCs auslösen, die eine Peering-Verbindung zu diesem Cluster haben. Wenn Sie einen dieser Fälle verwenden, sollten Sie --cluster-ipv4-cidr angeben, um Konflikte zu vermeiden.
    • SERVICES_IP_RANGE: ein IP-Adressbereich in CIDR-Notation (z. B. 10.4.0.0/19) oder die Größe der Subnetzmaske eines CIDR-Blocks (z. B. /19). Damit wird der sekundäre IP-Adressbereich des Subnetzes für Services erstellt.
  • Wenn die Zuweisungsmethode für sekundäre Bereiche Vom Nutzer verwaltet lautet:
    • SECONDARY_RANGE_PODS: der Name eines vorhandenen sekundären IP-Adressbereichs im angegebenen Subnetz SUBNET_NAME. GKE verwendet den gesamten sekundären IP-Adressbereich des Subnetzes für die Pods des Clusters.
    • SECONDARY_RANGE_SERVICES: der Name eines vorhandenen sekundären IP-Adressbereichs im SUBNET_NAME.

Console

  1. Rufen Sie in der Google Cloud Console die Seite Autopilot-Cluster erstellen auf.

    Zur Seite „Autopilot-Cluster erstellen“

    Sie können diese Aufgabe auch erledigen, indem Sie einen Standardcluster erstellen.

  2. Klicken Sie im Navigationsbereich unter Cluster auf Netzwerk.
  3. Konfigurieren Sie unter Zugriff auf die Steuerungsebene den Zugriff auf die Endpunkte der Steuerungsebene.
  4. Wählen Sie im Bereich Clusternetzwerk in der Drop-down-Liste Netzwerk eine VPC aus.
  5. Wählen Sie in der Drop-down-Liste Knotensubnetz ein Subnetz für den Cluster aus.
  6. Achten Sie darauf, dass das Kästchen neben VPC-natives Traffic-Routing aktivieren (verwendet Alias-IP-Adresse) aktiviert ist.
  7. Klicken Sie das Kästchen Sekundäre Bereiche automatisch erstellen an, wenn die Zuweisungsmethode für sekundäre Bereiche von GKE verwaltet werden soll. Deaktivieren Sie dieses Kästchen, wenn Sie bereits sekundäre Bereiche für das ausgewählte Subnetz erstellt haben und die Zuweisungsmethode für sekundäre Bereiche vom Nutzer verwaltet werden soll.
  8. Geben Sie im Feld Pod-Adressbereich einen Pod-Bereich wie 10.0.0.0/14 ein.
  9. Geben Sie im Feld Dienstadressbereich einen Dienstbereich ein, z. B. 10.4.0.0/19.
  10. Konfigurieren Sie den Cluster.
  11. Klicken Sie auf Erstellen.

Terraform

Mit einem Terraform-Modul können Sie einen VPC-nativen Cluster mit Terraform erstellen.

Sie können Ihrer Terraform-Konfiguration beispielsweise den folgenden Block hinzufügen:

module "gke" {
  source  = "terraform-google-modules/kubernetes-engine/google"
  version = "~> 12.0"

  project_id        = "PROJECT_ID"
  name              = "CLUSTER_NAME"
  region            = "COMPUTE_LOCATION"
  network           = "NETWORK_NAME"
  subnetwork        = "SUBNET_NAME"
  ip_range_pods     = "SECONDARY_RANGE_PODS"
  ip_range_services = "SECONDARY_RANGE_SERVICES"
}

Ersetzen Sie Folgendes:

  • PROJECT_ID: Ihre Projekt-ID.
  • CLUSTER_NAME ist der Name des GKE-Clusters.
  • COMPUTE_LOCATION: der Compute Engine-Standort für den Cluster. Bei Terraform die Compute Engine-Region.
  • NETWORK_NAME: Der Name eines vorhandenen Netzwerks.
  • SUBNET_NAME: Der Name eines vorhandenen Subnetzes. Der primäre IP-Adressbereich des Subnetzes wird für Knoten verwendet. Das Subnetz muss sich in derselben Region befinden wie der Cluster.
  • SECONDARY_RANGE_PODS: der Name eines vorhandenen sekundären IP-Adressbereichs in SUBNET_NAME.
  • SECONDARY_RANGE_SERVICES: der Name eines vorhandenen sekundären IP-Adressbereichs in SUBNET_NAME.

API

Definieren Sie beim Erstellen eines VPC-nativen Clusters ein IPAllocationPolicy-Objekt. Sie können auf vorhandene sekundäre Subnetz-IP-Adressbereiche verweisen oder CIDR-Blöcke angeben. Verweisen Sie auf vorhandene sekundäre Subnetz-IP-Adressbereiche, um einen Cluster zu erstellen, dessen Zuweisungsmethode für sekundäre Bereiche "Vom Nutzer verwaltet" lautet. Geben Sie CIDR-Blöcke an, wenn die Zuweisungsmethode für Bereiche "Von GKE verwaltet" sein soll.

{
  "name": CLUSTER_NAME,
  "description": DESCRIPTION,
  ...
  "ipAllocationPolicy": {
    "useIpAliases": true,
    "clusterIpv4CidrBlock"      : string,
    "servicesIpv4CidrBlock"     : string,
    "clusterSecondaryRangeName" : string,
    "servicesSecondaryRangeName": string,

  },
  ...
}

Dieser Befehl enthält die folgenden Werte:

  • "clusterIpv4CidrBlock": Der CIDR-Bereich für Pods. Damit wird die Größe des sekundären Bereichs für Pods bestimmt. Sie kann in CIDR-Notation wie 10.0.0.0/14 angegeben werden. Ein leerer Bereich mit der angegebenen Größe wird aus dem verfügbaren Bereich in Ihrer VPC ausgewählt. Wird dieses Feld leer gelassen, wird ein gültiger Bereich gefunden und mit einer Standardgröße erstellt.
  • "servicesIpv4CidrBlock": der CIDR-Bereich für Dienste. Siehe Beschreibung von "clusterIpv4CidrBlock".
  • "clusterSecondaryRangeName": der Name des sekundären Bereichs für Pods. Der sekundäre Bereich muss bereits vorhanden sein und zu dem Subnetzwerk gehören, das dem Cluster zugeordnet ist.
  • "serviceSecondaryRangeName": Der Name des sekundären Bereichs für Services. Der sekundäre Bereich muss bereits vorhanden sein und zu dem Subnetzwerk gehören, das dem Cluster zugeordnet ist.

Nachdem Sie den Cluster erstellt haben, können Sie den Zugriff auf die Steuerungsebene des Clusters ändern. Weitere Informationen finden Sie unter Netzwerkisolation in GKE anpassen.

Cluster erstellen und IP-Adressbereich der Steuerungsebene auswählen

Standardmäßig verwenden Cluster in Version 1.29 oder höher den primären Subnetzbereich, um die interne IP-Adresse bereitzustellen, die dem Endpunkt der Steuerungsebene zugewiesen ist. Sie können diese Standardeinstellung nur bei der Clustererstellung überschreiben, indem Sie einen anderen Subnetzbereich auswählen.

In den folgenden Abschnitten wird gezeigt, wie Sie einen Cluster erstellen und den Subnetzbereich überschreiben.

gcloud

gcloud container clusters create CLUSTER_NAME \
    --enable-private-nodes \
    --private-endpoint-subnetwork=SUBNET_NAME \
    --location=COMPUTE_LOCATION

Wobei:

  • Das Flag enable-private-nodes ist optional und weist GKE an, den Cluster mit privaten Knoten zu erstellen.
  • Mit dem Flag private-endpoint-subnetwork wird der IP-Adressbereich des internen Endpunkts der Steuerungsebene definiert. Sie können das Flag master-ipv4-cidr anstelle des Flags private-endpoint-subnetwork verwenden, um die interne IP-Adresse für die Steuerungsebene bereitzustellen. Berücksichtigen Sie bei der Auswahl des zu verwendenden Flags die folgenden Konfigurationen:
    • Wenn Sie einen Cluster mit dem Flag enable-private-nodes erstellen, sind die Flags master-ipv4-cidr und private-endpoint-subnetwork optional.
    • Wenn Sie das Flag private-endpoint-subnetwork verwenden, stellt GKE den internen Endpunkt der Steuerungsebene mit einer IP-Adresse aus dem von Ihnen definierten Bereich bereit.
    • Wenn Sie das Flag master-ipv4-cidr verwenden, erstellt GKE ein neues Subnetz aus den von Ihnen angegebenen Werten. GKE stellt den internen Endpunkt der Steuerungsebene mit einer IP-Adresse aus diesem neuen Bereich bereit.
    • Wenn Sie die Flags private-endpoint-subnetwork und master-ipv4-cidr weglassen, stellt GKE den internen Endpunkt der Steuerungsebene mit einer IP-Adresse aus dem sekundären Cluster-Subnetzwerk bereit.

Ersetzen Sie Folgendes:

  • CLUSTER_NAME ist der Name des GKE-Clusters.
  • SUBNET_NAME: Der Name eines vorhandenen Subnetzes, in dem die interne IP-Adresse bereitgestellt werden soll.
  • COMPUTE_LOCATION: der Compute Engine-Standort für den Cluster.

GKE erstellt einen Cluster mit Private Service Connect. Nachdem Sie den Cluster erstellt haben, können Sie den Zugriff auf die Steuerungsebene des Clusters ändern. Weitere Informationen finden Sie unter Netzwerkisolation in GKE anpassen.

Console

Um der Steuerungsebene eines neuen Clusters ein Subnetz zuzuweisen, müssen Sie zuerst ein Subnetz hinzufügen. Führen Sie diese Schritte aus:

  1. Rufen Sie in der Google Cloud Console die Seite Autopilot-Cluster erstellen auf.

    Zur Seite „Autopilot-Cluster erstellen“

    Sie können diese Aufgabe auch erledigen, indem Sie einen Standardcluster erstellen.

  2. Klicken Sie unter „Standard“ oder „Autopilot“ auf Konfigurieren.
  3. Geben Sie unter Name den Clusternamen ein.
  4. Klicken Sie im Navigationsbereich unter Cluster auf Netzwerk.
  5. Konfigurieren Sie unter Zugriff auf die Steuerungsebene den Zugriff auf die Endpunkte der Steuerungsebene.
  6. Klicken Sie im Bereich Clusternetzwerk das Kästchen Standardsubnetz des privaten Endpunkts der Steuerungsebene überschreiben an.
  7. Wählen Sie in der Liste Subnetz des privaten Endpunkts das erstellte Subnetz aus.
  8. Klicken Sie auf Fertig. Fügen Sie bei Bedarf weitere autorisierte Netzwerke hinzu.

Projektmetadaten für sekundäre IP-Adressbereiche

Wenn Sie einen GKE-Cluster erstellen oder aktualisieren, fügt GKE automatisch Metadateneinträge auf Projektebene wie google_compute_project_metadata hinzu, um die Nutzung sekundärer IP-Adressbereiche zu verfolgen, auch in freigegebene VPC-Umgebungen. Diese Metadaten bestätigen, dass GKE IP-Adressen für Pods und Dienste korrekt zuweist, was Konflikte verhindert.

GKE verwaltet diese Metadaten automatisch.

Die Metadaten haben das folgende Format:

key:   gke-REGION-CLUSTER_NAME-GKE_UID-secondary-ranges
value: pods:SHARED_VPC_NETWORK:SHARED_VPC_SUBNETWORK:CLUSTER_PODS_SECONDARY_RANGE_NAME

Dabei gilt:

  • REGION: Die Google Cloud Region, in der sich der Cluster befindet.

  • CLUSTER_NAME ist der Name des GKE-Clusters.

  • GKE_UID: Eine eindeutige Kennung für den GKE-Cluster.

  • VPC_NETWORK: der Name des VPC-Netzwerks, das vom Cluster verwendet wird.

  • VPC_SUBNETWORK: der Name des Subnetzwerks im VPC-Netzwerk, das vom Cluster verwendet wird.

  • CLUSTER_PODS_SECONDARY_RANGE_NAME: der Name des sekundären IP-Adressbereichs, der für die Pods des Clusters verwendet wird.

Cluster mit Dual-Stack-Netzwerk erstellen

Sie können einen Cluster mit IPv4/IPv6-Dual-Stack-Netzwerk in einem neuen oder vorhandenen Dual-Stack-Subnetz erstellen. Dual-Stack-Subnetze sind in Autopilot-Clustern ab Version 1.25 und Standardclustern ab Version 1.24 verfügbar. Dual-Stack-Subnetze werden in Windows Server-Knotenpools nicht unterstützt.

Bevor Sie Dual-Stack-Cluster einrichten, empfehlen wir Ihnen, Folgendes zu tun:

In diesem Abschnitt erstellen Sie zuerst ein Dual-Stack-Subnetz und verwenden es dann, um einen Cluster zu erstellen.

  1. Führen Sie den folgenden Befehl aus, um ein Dual-Stack-Subnetz zu erstellen:

    gcloud compute networks subnets create SUBNET_NAME \
    --stack-type=ipv4-ipv6 \
    --ipv6-access-type=ACCESS_TYPE \
    --network=NETWORK_NAME \
    --range=PRIMARY_RANGE \
    --region=COMPUTE_REGION

    Ersetzen Sie Folgendes:

    • SUBNET_NAME: der Name des ausgewählten Subnetzes.
    • ACCESS_TYPE: die Routbarkeit des öffentlichen Internets. Verwenden Sie INTERNAL für interne IPv6-Adressen oder EXTERNAL für externe IPv6-Adressen. Wenn --ipv6-access-type nicht angegeben ist, ist der Standardzugriffstyp EXTERNAL.
    • NETWORK_NAME: der Name des Netzwerks mit dem neuen Subnetz. Dieses Netzwerk muss die folgenden Bedingungen erfüllen:
    • PRIMARY_RANGE: der primäre IPv4-IP-Adressbereich für das neue Subnetz in CIDR-Notation. Weitere Informationen finden Sie unter Subnetzbereiche.
    • COMPUTE_REGION. die Compute-Region für den Cluster.

  2. Zum Erstellen eines Clusters mit einem Dual-Stack-Subnetz können Sie entweder die gcloud CLI oder die Google Cloud -Konsole verwenden:

gcloud

  • Führen Sie für Autopilot-Cluster den folgenden Befehl aus:

      gcloud container clusters create-auto CLUSTER_NAME \
      --location=COMPUTE_LOCATION \
      --network=NETWORK_NAME \
      --subnetwork=SUBNET_NAME

    Ersetzen Sie Folgendes:

    • CLUSTER_NAME: Der Name Ihres neuen Autopilot-Clusters.
    • COMPUTE_LOCATION: der Compute Engine-Standort für den Cluster.
    • NETWORK_NAME: der Name eines VPC-Netzwerks, das das Subnetz enthält. Dieses VPC-Netzwerk muss ein VPC-Netzwerk im benutzerdefinierten Modus sein. Weitere Informationen finden Sie unter VPC-Netzwerk vom automatischen Modus in den benutzerdefinierten Modus versetzen.

    • SUBNET_NAME: der Name des Dual-Stack-Subnetzes.

      GKE Autopilot-Cluster verwenden standardmäßig einen Dual-Stack-Cluster, wenn Sie ein Dual-Stack-Subnetz verwenden. Nach der Clustererstellung können Sie den Autopilot-Cluster auf reines IPv4 aktualisieren.

  • Führen Sie für Standardcluster den folgenden Befehl aus:

    gcloud container clusters create CLUSTER_NAME \
    --enable-ip-alias \
    --enable-dataplane-v2 \
    --stack-type=ipv4-ipv6 \
    --network=NETWORK_NAME \
    --subnetwork=SUBNET_NAME \
    --location=COMPUTE_LOCATION

    Ersetzen Sie Folgendes:

Console

  1. Rufen Sie in der Google Cloud Console die Seite Autopilot-Cluster erstellen auf.

    Zur Seite „Autopilot-Cluster erstellen“

    Sie können diese Aufgabe auch erledigen, indem Sie einen Standardcluster erstellen.

  2. Klicken Sie unter „Standard“ oder „Autopilot“ auf Konfigurieren.
  3. Konfigurieren Sie den Cluster nach Bedarf.
  4. Klicken Sie im Navigationsbereich unter Cluster auf Netzwerk.
  5. Konfigurieren Sie unter Zugriff auf die Steuerungsebene den Zugriff auf die Endpunkte der Steuerungsebene.
  6. Wählen Sie im Abschnitt Cluster-Netzwerk in der Liste Netzwerk den Namen Ihres Netzwerks aus.
  7. Wählen Sie in der Liste Knotensubnetz den Namen Ihres Dual-Stack-Subnetzes aus.

  8. Wählen Sie für Standardcluster das Optionsfeld IPv4 und IPv6 (Dual Stack) aus. Diese Option ist nur verfügbar, wenn Sie ein Dual-Stack-Subnetz ausgewählt haben.

    Autopilot-Cluster verwenden standardmäßig einen Dual-Stack-Cluster, wenn Sie ein Dual-Stack-Subnetz verwenden.

  9. Klicken Sie auf Erstellen.

Dual-Stack-Cluster und Subnetz gleichzeitig erstellen

Sie können ein Subnetz und einen Dual-Stack-Cluster gleichzeitig erstellen. GKE erstellt ein IPv6-Subnetz und weist dem Subnetz einen externen IPv6-Primärbereich zu.

Wenn Sie eine freigegebene VPC verwenden, können Sie den Cluster und das Subnetz nicht gleichzeitig erstellen. Stattdessen muss ein Netzwerkadministrator im freigegebene VPC-Hostprojekt zuerst das Dual-Stack-Subnetz erstellen.

  • Führen Sie für Autopilot-Cluster den folgenden Befehl aus:

    gcloud container clusters create-auto CLUSTER_NAME \
    --location=COMPUTE_LOCATION \
    --network=NETWORK_NAME \
    --create-subnetwork name=SUBNET_NAME

    Ersetzen Sie Folgendes:

    • CLUSTER_NAME: Der Name Ihres neuen Autopilot-Clusters.
    • COMPUTE_LOCATION: der Compute Engine-Standort für den Cluster.
    • NETWORK_NAME: der Name eines VPC-Netzwerks, das das Subnetz enthält. Dieses VPC-Netzwerk muss ein VPC-Netzwerk im benutzerdefinierten Modus sein, das eindeutige lokale IPv6-Unicast-Adressen (ULA) verwendet. Weitere Informationen finden Sie unter VPC-Netzwerk vom automatischen Modus in den benutzerdefinierten Modus versetzen.
    • SUBNET_NAME: der Name des neuen Subnetzes. GKE kann das Subnetz basierend auf Ihren Organisationsrichtlinien erstellen:
      • Wenn Ihre Organisationsrichtlinien Dual-Stack zulassen und das Netzwerk im benutzerdefinierten Modus ist, erstellt GKE ein Dual-Stack-Subnetz und weist dem Subnetz einen externen IPv6-Primärbereich zu.
      • Wenn Ihre Organisationsrichtlinien das Dual-Stack nicht zulassen oder wenn sich das Netzwerk im automatischen Modus befindet, erstellt GKE ein Single-Stack-Subnetz (IPv4).

  • Führen Sie für Standardcluster den folgenden Befehl aus:

    gcloud container clusters create CLUSTER_NAME \
    --enable-ip-alias \
    --stack-type=ipv4-ipv6 \
    --ipv6-access-type=ACCESS_TYPE \
    --network=NETWORK_NAME \
    --create-subnetwork name=SUBNET_NAME,range=PRIMARY_RANGE \
    --location=COMPUTE_LOCATION

    Ersetzen Sie Folgendes:

    • CLUSTER_NAME: der Name des neuen Clusters, den Sie auswählen.
    • ACCESS_TYPE: Die Routbarkeit des öffentlichen Internets. Verwenden Sie INTERNAL für interne IPv6-Adressen oder EXTERNAL für externe IPv6-Adressen. Wenn --ipv6-access-type nicht angegeben ist, ist der Standardzugriffstyp EXTERNAL.
    • NETWORK_NAME: der Name des Netzwerks mit dem neuen Subnetz. Dieses Netzwerk muss die folgenden Bedingungen erfüllen:
    • SUBNET_NAME: der Name des neuen Subnetzes, das Sie auswählen.
    • PRIMARY_RANGE: der primäre IPv4-Adressbereich für das neue Subnetz in CIDR-Notation. Weitere Informationen finden Sie unter Subnetzbereiche.
    • COMPUTE_LOCATION: der Compute Engine-Standort für den Cluster.

Stacktyp aktualisieren

Sie können den Stacktyp eines vorhandenen Clusters ändern oder ein vorhandenes Subnetz in ein Dual-Stack-Subnetz aktualisieren.

Stacktyp in einem vorhandenen Cluster aktualisieren

Bevor Sie den Stacktyp in einem vorhandenen Cluster ändern, beachten Sie die folgenden Einschränkungen:

  • Das Ändern des Stack-Typs wird in neuen GKE-Clustern mit Version 1.25 oder höher unterstützt. Bei GKE-Clustern, die von Version 1.24 auf Version 1.25 oder 1.26 aktualisiert wurden, können Validierungsfehler auftreten, wenn Sie ein Dual-Stack-Netzwerk aktivieren. Wenden Sie sich bei Fehlern an das Google Cloud Supportteam.

  • Das Ändern des Stack-Typs ist ein störender Vorgang, da GKE sowohl Komponenten auf der Steuerungsebene als auch auf Knoten neu startet.

  • GKE berücksichtigt beim Neuerstellen von Knoten die konfigurierten Wartungsfenster. Dies bedeutet, dass der Cluster-Stack-Typ bis zum nächsten Wartungsfenster nicht im Cluster verfügbar ist. Wenn Sie nicht warten möchten, können Sie den Knotenpool auch manuell aktualisieren. Dazu geben Sie für das Flag --cluster-version die GKE-Version an, die bereits auf der Steuerungsebene ausgeführt wird. Wenn Sie diese Problemumgehung verwenden, müssen Sie die gcloud CLI verwenden. Weitere Informationen finden Sie unter Hinweise für Wartungsfenster.

  • Durch das Ändern des Stack-Typs wird die IP-Familie vorhandener Services nicht automatisch geändert. Dabei gelten folgende Bedingungen:

    • Wenn Sie einen einzelnen Stack in Dual-Stack ändern, bleiben die vorhandenen Services im Status eines einzelnen Stacks erhalten.
    • Wenn Sie einen Dual-Stack in einen einzelnen Stack ändern, werden die vorhandenen Services mit IPv6-Adressen in einen Fehlerzustand versetzt. Löschen Sie den Dienst und erstellen Sie einen Dienst mit den richtigen ipFamilies. Weitere Informationen finden Sie in einem Beispiel für die Einrichtung eines Deployments.

Zum Aktualisieren eines vorhandenen VPC-nativer Cluster können Sie die gcloud CLI oder die Google Cloud Console verwenden:

gcloud

Führen Sie dazu diesen Befehl aus:

  gcloud container clusters update CLUSTER_NAME \
      --stack-type=STACK_TYPE \
      --location=COMPUTE_LOCATION

Ersetzen Sie Folgendes:

  • CLUSTER_NAME: der Name des Clusters, den Sie aktualisieren möchten.
  • STACK_TYPE: der Stack-Typ. Ersetzen Sie ihn durch einen der folgenden Werte:
    • ipv4: zum Aktualisieren eines Dual-Stack-Clusters auf einen reinen IPv4-Cluster. GKE verwendet den primären IPv4-Adressbereich des Subnetzes des Clusters.
    • ipv4-ipv6: zum Aktualisieren eines vorhandenen IPv4-Clusters auf Dual-Stack. Sie können einen Cluster nur dann in Dual-Stack ändern, wenn das zugrunde liegende Subnetz Dual-Stack unterstützt. Weitere Informationen finden Sie unter Vorhandenes Subnetz auf ein Dual-Stack-Subnetz aktualisieren.
  • COMPUTE_LOCATION: der Compute Engine-Standort für den Cluster.

Console

  1. Öffnen Sie in der Google Cloud Console die Seite Google Kubernetes Engine.

    Zur Seite "Google Kubernetes Engine"

  2. Klicken Sie neben dem Cluster, den Sie bearbeiten möchten, auf Aktionen und dann auf Bearbeiten.

  3. Klicken Sie im Abschnitt Netzwerk neben Stack-Typ auf Bearbeiten.

  4. Klicken Sie im Dialogfeld Stack-Typ bearbeiten das Kästchen für den Cluster-Stack-Typ an, den Sie benötigen.

  5. Klicken Sie auf Änderungen speichern.

Aktualisieren Sie ein vorhandenes Subnetz auf ein Dual-Stack-Subnetz (verfügbar in Autopilot-Clustern ab Version 1.25 und Standardclustern ab Version 1.24).

Vorhandenes Subnetz auf ein Dual-Stack-Subnetz aktualisieren

Führen Sie den folgenden Befehl aus, um ein vorhandenes Subnetz auf ein Dual-Stack-Subnetz zu aktualisieren. Das Aktualisieren eines Subnetzes wirkt sich nicht auf vorhandene IPv4-Cluster im Subnetz aus.

gcloud compute networks subnets update SUBNET_NAME \
    --stack-type=ipv4-ipv6 \
    --ipv6-access-type=ACCESS_TYPE \
    --region=COMPUTE_REGION

Ersetzen Sie Folgendes:

  • SUBNET_NAME: der Name des Subnetzes.
  • ACCESS_TYPE: die Routbarkeit des öffentlichen Internets. Verwenden Sie INTERNAL für interne IPv6-Adressen oder EXTERNAL für externe IPv6-Adressen. Wenn --ipv6-access-type nicht angegeben ist, ist der Standardzugriffstyp EXTERNAL.
  • COMPUTE_REGION. die Compute-Region für den Cluster.

Stack-Typ-, Pod- und Service-IP-Adressbereiche prüfen

Nachdem Sie einen VPC-nativen Cluster erstellt haben, können Sie dessen Pod- und Dienstbereiche überprüfen.

gcloud

So überprüfen Sie den Cluster:

gcloud container clusters describe CLUSTER_NAME

Die Ausgabe hat einen ipAllocationPolicy-Block. Das Feld stackType beschreibt den Typ der Netzwerkdefinition. Für jeden Typ werden die folgenden Netzwerkinformationen angezeigt:

  • IPv4-Netzwerkinformationen:

    • clusterIpv4Cidr ist der sekundäre Bereich für Pods.
    • servicesIpv4Cidr ist der sekundäre Bereich für Services.

  • IPv6-Netzwerkinformationen (wenn ein Cluster ein Dual-Stack-Netzwerk hat):

    • ipv6AccessType: Die Routbarkeit des öffentlichen Internets. INTERNAL für interne IPv6-Adressen und EXTERNAL für externe IPv6-Adressen.
    • subnetIpv6CidrBlock: Der sekundäre IPv6-Adressbereich für das neue Subnetz.
    • servicesIpv6CidrBlock: Der Adressbereich, der den IPv6-Diensten im Dual-Stack-Cluster zugewiesen ist.

Console

So überprüfen Sie den Cluster:

  1. Öffnen Sie in der Google Cloud Console die Seite Google Kubernetes Engine.

    Zur Seite "Google Kubernetes Engine"

  2. Klicken Sie in der Clusterliste auf den Namen des Clusters, den Sie inspizieren möchten.

Die sekundären Bereiche werden im Bereich Netzwerk angezeigt:

  • Pod-Adressbereich ist der sekundäre Bereich für Pods.
  • Dienstadressbereich ist der sekundäre Bereich für Dienste.

Cluster löschen

Folgen Sie der Anleitung unter Cluster löschen, um Ihren Cluster zu löschen.

GKE versucht, das erstellte Subnetzwerk zu bereinigen, wenn der Cluster gelöscht wird. Wenn das Subnetzwerk jedoch von anderen Ressourcen verwendet wird, löscht GKE das Subnetzwerk nicht und Sie müssen die Lebensdauer des Subnetzwerks selbst verwalten.

Erweiterte Konfiguration für interne IP-Adressen

In den folgenden Abschnitten wird beschrieben, wie Sie private IP-Adressbereiche außerhalb von RFC 1918 verwenden und wie Sie privat verwendete öffentliche IP-Adressbereiche aktivieren.

IP-Adressbereiche außerhalb von RFC 1918 verwenden

GKE-Cluster können private IP-Adressbereiche außerhalb des RFC 1918-Bereichs für Knoten, Pods und Services verwenden. Unter Gültige Bereiche in der Dokumentation zu VPC-Netzwerken finden Sie eine Liste von privaten Bereichen außerhalb von RFC 1918, die als interne IP-Adressen für Subnetzbereiche verwendet werden können.

Diese Funktion wird von Windows Server-Knotenpools nicht unterstützt.

Private Bereiche außerhalb von RFC 1918 sind Subnetzbereiche. Sie können sie ausschließlich oder in Verbindung mit RFC 1918-Subnetzbereichen verwenden. Knoten, Pods und Services verwenden weiterhin Subnetzbereiche, wie unter IP-Bereiche für VPC-native Cluster beschrieben. Wenn Sie andere Bereiche als RFC 1918 verwenden, müssen Sie Folgendes beachten:

  • Subnetzbereiche müssen manuell oder über GKE zugewiesen werden, bevor die Knoten des Clusters erstellt werden, auch wenn Bereiche außerhalb von RFC 1918 verwendet werden. Der Wechsel zu oder das Beenden der Nutzung von Subnetzbereichen außerhalb von RFC 1918 für Knoten- oder Dienst-IP-Adressen in einem vorhandenen Cluster ist nur dann möglich, wenn Sie den Cluster ersetzen. Sie können einem vorhandenen VPC-nativer Cluster jedoch zusätzliche Pod-CIDR-Bereiche hinzufügen, einschließlich Nicht-RFC 1918-Bereichen. Weitere Informationen zum Hinzufügen zusätzlicher Pod-CIDR-Bereiche finden Sie unter IP-Adressbereiche eines GKE-Clusters erweitern.

  • Interne Passthrough-Network-Load-Balancer verwenden nur IP-Adressen aus dem primären IP-Adressbereich des Subnetzes. Der primäre IP-Adressbereich Ihres Subnetzes darf nicht RFC 1918 sein, wenn Sie einen internen Passthrough-Network-Load-Balancer mit einer Adresse außerhalb von RFC 1918 erstellen möchten.

Bei Zielen außerhalb des Clusters treten möglicherweise Probleme beim Empfang von Traffic aus privaten Bereichen außerhalb von RFC 1918 auf. Beispielsweise werden private RFC 1112-Bereiche (Klasse E) üblicherweise als Multicast-Adressen verwendet. Wenn ein Ziel außerhalb Ihres Clusters keine Pakete verarbeiten kann, deren Quellen private IP-Adressen außerhalb des RFC 1918-Bereichs sind, können Sie so vorgehen:

  • Verwenden Sie einen RFC 1918-Bereich für den primären IP-Adressbereich des Subnetzes. Auf diese Weise verwenden Knoten im Cluster RFC 1918-Adressen.

  • Achten Sie darauf, dass in Ihrem Cluster der IP-Masquerade-Agent ausgeführt wird und dass die Ziele nicht in der Liste nonMasqueradeCIDRs enthalten sind. Auf diese Weise werden die Ziele der von Pods gesendeten Pakete in Knotenadressen geändert (SNAT), die sich in RFC 1918 befinden.

Privat verwendete externe IP-Adressbereiche aktivieren

Für GKE-Cluster können bestimmte externe IP-Adressbereiche als interne Subnetz-IP-Adressbereiche genutzt werden. Sie können jede externe IP-Adresse privat verwenden, mit Ausnahme bestimmter eingeschränkter Bereiche, die in der VPC-Netzwerkdokumentation beschrieben werden. Diese Funktion wird von Windows Server-Knotenpools nicht unterstützt.

Der Cluster muss ein VPC-nativer Cluster sein, um privat verwendete externe IP-Adressbereiche nutzen zu können. Routenbasierte Cluster werden nicht unterstützt.

Privat verwendete externe Bereiche sind Subnetzbereiche. Sie können sie ausschließlich oder in Verbindung mit anderen Subnetzbereichen mit privaten Adressen verwenden. Knoten, Pods und Services verwenden weiterhin Subnetzbereiche, wie unter IP-Bereiche für VPC-native Cluster beschrieben. Beachten Sie Folgendes, wenn Sie externe IP-Adressen privat wiederverwenden:

  • Wenn Sie einen externen IP-Adressbereich als Subnetzbereich verwenden, kann Ihr Cluster nicht mehr mit Systemen im Internet kommunizieren, die diesen externen Bereich verwenden. Der Bereich wird zu einem internen IP-Adressbereich im VPC-Netzwerk des Clusters.

  • Subnetzbereiche müssen manuell oder über GKE zugewiesen werden, bevor die Knoten des Clusters erstellt werden, auch wenn externe IP-Adressbereiche privat verwendet werden. Der Wechsel zu oder das Beenden der Nutzung von Subnetzbereichen außerhalb von RFC 1918 für Knoten- oder Dienst-IP-Adressen in einem vorhandenen Cluster ist nur dann möglich, wenn Sie den Cluster ersetzen. Sie können einem vorhandenen VPC-nativer Cluster jedoch zusätzliche Pod-CIDR-Bereiche hinzufügen, einschließlich Bereiche, die nicht RFC 1918 entsprechen. Weitere Informationen zum Hinzufügen zusätzlicher Pod-CIDR-Bereiche finden Sie unter IP-Adressbereiche eines GKE-Clusters erweitern.

GKE implementiert SNAT standardmäßig auf den Knoten in externen IP-Zielen. Wenn Sie den Pod-CIDR für die Verwendung externer IP-Adressen konfiguriert haben, werden die SNAT-Regeln auf den Pod-zu-Pod-Traffic angewendet. Um dies zu vermeiden, haben Sie zwei Möglichkeiten:

Bei Standardclustern mit Clusterversion 1.14 oder höher funktionieren beide Optionen. Wenn Ihre Clusterversion älter als 1.14 ist, können Sie nur die zweite Option verwenden (ip-masq-agent konfigurieren).

Nächste Schritte