VPC-nativen Cluster erstellen

Autopilot Standard

---

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.

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

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 gcloud components update ab.
  Hinweis: Legen Sie für vorhandene Installationen der gcloud CLI die compute/region- und compute/zone-Attribute fest. Durch das Festlegen von Standardspeicherorten können Sie in der gcloud CLI Fehler wie One of [--zone, --region] must be supplied: Please specify location vermeiden.

Beschränkungen

• Sie können einen VPC-nativen Cluster nicht in einen routenbasierten Cluster konvertieren und umgekehrt auch keinen routenbasierten Cluster in einen VPC-nativen 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 unveränderlichen Zustand zu versetzen. Sie können jedoch zusätzliche Pod-IP-Adressbereiche erstellen, indem Sie nicht zusammenhängende CIDRs mit mehreren Pods verwenden.

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
  

• So verwenden Sie die Zuweisungsmethode für sekundäre Bereiche Vom Nutzer verwaltet:

  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
  

Dabei gilt:

• 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 (2¹⁸ Adressen) aus. Der automatisch ausgewählte Bereich wird nach dem Zufallsprinzip aus 10.0.0.0/8 (einem Bereich von 2²⁴ 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 angegebenen

Console

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

   Zur Seite "Google Kubernetes Engine"

2. Klicken Sie auf Erstellen und dann im Bereich „Standard“ oder „Autopilot“ auf Konfigurieren.

3. Klicken Sie im Navigationsbereich unter Cluster auf Netzwerk.

4. Wählen Sie 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"
}

Dabei gilt:

• 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 im angegebenen
• SECONDARY_RANGE_SERVICES: der Name eines vorhandenen sekundären IP-Adressbereichs im angegebenen

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. Dies bestimmt die Größe des sekundären Bereichs für Pods und kann in CIDR-Notation angegeben werden, z. B. 10.0.0.0/14. 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.

Cluster erstellen und IP-Adressbereich der Steuerungsebene auswählen

Standardmäßig verwenden Cluster mit Private Service Connect den primären Subnetzbereich, um die interne IP-Adresse bereitzustellen, die dem Endpunkt der Steuerungsebene zugewiesen ist. Sie können diese Standardeinstellung überschreiben, wenn Sie nur während der Clustererstellung einen anderen Subnetzbereich auswählen. In den folgenden Abschnitten erfahren Sie, wie Sie einen Cluster mit Private Service Connect erstellen und den Subnetzbereich überschreiben.

gcloud

Cluster mit Private Service Connect erstellen, die als öffentlich definiert sind

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

Fügen Sie das Flag --enable-private-nodes hinzu, um den Private Service Connect-Cluster als privat zu erstellen.

Ersetzen Sie Folgendes:

• CLUSTER_NAME ist der Name des GKE-Clusters.
• SUBNET_NAME: Der Name eines vorhandenen Subnetzes.
• COMPUTE_LOCATION: der Compute Engine-Standort für den Cluster.

GKE erstellt einen Cluster mit Private Service Connect.

Erstellen Sie einen Cluster, der als privat definiert ist:

In GKE Version 1.29 und höher können Sie einen Cluster mit Private Service Connect erstellen:

gcloud container clusters create CLUSTER_NAME --enable-ip-alias \
    --enable-private-nodes  \
    --private-endpoint-subnetwork=SUBNET_NAME \
    --region=COMPUTE_REGION

Ersetzen Sie Folgendes:

• CLUSTER_NAME ist der Name des GKE-Clusters.
• SUBNET_NAME: Der Name eines vorhandenen Subnetzes. Wenn Sie keinen Wert für das Flag private-endpoint-subnetwork angeben, aber master-ipv4-cidr verwenden, erstellt GKE ein neues Subnetz, das die von Ihnen in master-ipv4-cidr definierten Werte verwendet. GKE verwendet das neue Subnetz, um die interne IP-Adresse für die Steuerungsebene bereitzustellen.
• COMPUTE_LOCATION: der Compute Engine-Standort für den Cluster.

Console

Erstellen Sie einen als öffentlich definierten Cluster:

Um der Steuerungsebene eines neuen Clusters ein Subnetz zuzuweisen, müssen Sie zuerst ein Subnetz hinzufügen. Gehen Sie dann so vor:

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

   Zur Seite „Google Kubernetes Engine“

2. Klicken Sie auf Erstellen.

3. Klicken Sie unter „Standard“ oder „Autopilot“ auf Konfigurieren.

4. Geben Sie unter Name den Clusternamen ein.

5. Klicken Sie für Standardcluster im Navigationsbereich unter Cluster auf Netzwerk.

6. Führen Sie im Abschnitt IPv4-Netzwerkzugriff die folgenden Schritte aus:

   1. Zum Erstellen eines GKE-Clusters als öffentlich wählen Sie Öffentlicher Cluster aus.
   2. Wählen Sie zum Erstellen eines GKE-Clusters als privat die Option Privater Cluster aus.

   In beiden Fällen können Sie später den Modus der Clusterisolierung ändern, wenn Sie die Clusterkonfiguration bearbeiten.

7. Klicken Sie im Bereich Erweiterte Netzwerkoptionen das Kästchen Standardsubnetz des privaten Endpunkts der Steuerungsebene überschreiben an.

8. Wählen Sie in der Liste Subnetz des privaten Endpunkts das erstellte Subnetz aus.

9. Klicken Sie auf Fertig. Fügen Sie bei Bedarf weitere autorisierte Netzwerke hinzu.

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.

Hinweis: Wenn Sie freigegebene VPC verwenden, können Sie den Cluster und das Subnetz nicht gleichzeitig erstellen. Stattdessen muss ein Netzwerkadministrator im freigegebenen 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

So erstellen Sie einen VPC-nativen Cluster und ein Subnetz gleichzeitig:

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

Dabei gilt:

• 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 2¹⁸ Adressen. Der automatisch ausgewählte Bereich wird nach dem Zufallsprinzip aus 10.0.0.0/8 (einem Bereich mit 2²⁴ 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 der Google Cloud Console 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.

Hinweis: 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.

IP-Adressbereiche außerhalb von RFC 1918 verwenden

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

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.

IP-Adressbereiche außerhalb von RFC 1918 sind mit privaten Clustern und mit nicht privaten Clustern kompatibel.

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 ist nur dann möglich, wenn Sie den Cluster ersetzen.

• 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 öffentliche IP-Adressbereiche aktivieren

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

Für GKE-Cluster können bestimmte öffentliche IP-Adressbereiche als interne Subnetz-IP-Adressbereiche genutzt werden. Sie können jede öffentliche IP-Adresse privat verwenden, mit Ausnahme bestimmter eingeschränkter Bereiche, die in der VPC-Netzwerkdokumentation beschrieben werden.

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

Privat verwendete öffentliche Bereiche sind Subnetzbereiche. Sie können diese 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 öffentliche 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 öffentlichen 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 öffentliche IP-Adressbereiche privat verwendet werden. Der Wechsel zu oder das Beenden der Nutzung von privat verwendeten öffentlichen IP-Adressen ist nur dann möglich, wenn Sie den Cluster ersetzen.

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

• Erstellen Sie Ihren Cluster mit dem Flag --disable-default-snat. Weitere Informationen zu diesem Flag finden Sie unter IP-Maskierung in GKE.
• Konfigurieren Sie die configMap ip-masq-agent so, dass in der Liste nonMasqueradeCIDRs mindestens die Pod-CIDR, die Service-CIDR und das Subnetz des Knotens enthalten sind.

IPv4/IPv6-Dual-Stack-Netzwerk zum Erstellen eines Dual-Stack-Clusters verwenden

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

Sie können einen Cluster mit IPv4/IPv6-Dual-Stack-Netzwerk in einem neuen oder vorhandenen Dual-Stack-Subnetz erstellen.

In diesem Abschnitt werden die folgenden Aufgaben erläutert:

• Erstellen Sie ein Dual-Stack-Subnetz (verfügbar in Autopilot-Clustern ab Version 1.25 und Standardclustern ab Version 1.24).
• Aktualisieren Sie ein vorhandenes Subnetz auf ein Dual-Stack-Subnetz (verfügbar in Autopilot-Clustern ab Version 1.25 und Standardcluster ab Version 1.24).
• Erstellen Sie einen Cluster mit Dual-Stack-Netzwerk (verfügbar in Autopilot-Clustern ab Version 1.25 und Standardclustern ab Version 1.24). 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.
• 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).

Weitere Informationen zu den Vorteilen und Anforderungen von GKE-Clustern mit Dual-Stack-Netzwerk finden Sie in der Dokumentation zu VPC-nativen Clustern.

Hinweis: Bevor Sie Dual-Stack-Cluster einrichten, empfehlen wir Ihnen, sich über die Limits und Einschränkungen von Dual-Stack-Netzwerken zu informieren.

Dual-Stack-Subnetz erstellen

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

Dabei gilt:

• SUBNET_NAME: der Name des ausgewählten Subnetzes.
• ACCESS_TYPE: die Routbarkeit des öffentlichen Internets. Verwenden Sie INTERNAL für private Cluster und EXTERNAL für öffentliche Cluster. 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:
  • Es muss sich um ein VPC-Netzwerk im benutzerdefinierten Modus handeln. Weitere Informationen finden Sie unter VPC-Netzwerk vom automatischen Modus in den benutzerdefinierten Modus versetzen.
  • Wenn Sie den ACCESS_TYPE durch INTERNAL ersetzen, muss das Netzwerk eindeutige lokale IPv6-Unicast-Adressen (ULA) verwenden.
• 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.

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

Dabei gilt:

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

Cluster mit Dual-Stack-Netzwerk erstellen

Zum Erstellen eines Clusters mit einem vorhandenen Dual-Stack-Subnetz können Sie gcloud CLI oder die Google Cloud Console 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. Weitere Informationen finden Sie unter Dual-Stack-Subnetz erstellen.

    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
  

  Dabei gilt:

  • CLUSTER_NAME ist der Name des neuen Clusters.
  • 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 Subnetzes.
  • COMPUTE_LOCATION: der Compute Engine-Standort für den Cluster.

Console

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

   Zur Seite „Google Kubernetes Engine“

2. Klicken Sie auf Erstellen.

3. Klicken Sie unter „Standard“ oder „Autopilot“ auf Konfigurieren.

4. Konfigurieren Sie den Cluster nach Bedarf.

5. Klicken Sie im Navigationsbereich unter Cluster auf Netzwerk.

6. Wählen Sie 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.

• 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 private Cluster und EXTERNAL für öffentliche Cluster. 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:
    • Es muss sich um ein VPC-Netzwerk im benutzerdefinierten Modus handeln. Weitere Informationen finden Sie unter VPC-Netzwerk vom automatischen Modus in den benutzerdefinierten Modus versetzen.
    • Wenn Sie den ACCESS_TYPE durch INTERNAL ersetzen, muss das Netzwerk eindeutige lokale IPv6-Unicast-Adressen (ULA) verwenden.
  • 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 in einem vorhandenen Cluster aktualisieren

Sie können den Stacktyp einer vorhandenen VM ändern. 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. GKE-Cluster, die von Version 1.24 auf Version 1.25 oder 1.26 aktualisiert wurden, erhalten bei der Aktivierung eines Dual-Stack-Netzwerks möglicherweise Validierungsfehler. 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-nativen Clusters 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. Rufen Sie in der Google Cloud Console die Seite Google Kubernetes Engine auf.

   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.

IPv4/IPv6-Dual-Stack-Dienst erstellen

Sie können einen IPv4/IPv6-Dual-Stack-Dienst vom Typ ClusterIP oder NodePort erstellen. Neue GKE-Cluster mit Version 1.29 oder höher unterstützen Dual-Stack-Dienste vom Typ LoadBalancer. Weitere Informationen finden Sie unter IPv4/IPv6-Dual-Stack-LoadBalancer-Dienst.

Für jeden dieser Diensttypen können Sie die Felder ipFamilies und ipFamilyPolicy entweder als IPv4, IPv6 oder als Dual-Stack definieren. Weitere Informationen finden Sie unter IPv4/IPv6-Dual-Stack-Dienste.

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 private IPv6-Adressen und EXTERNAL für öffentliche 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. Rufen Sie in der Google Cloud Console die Seite Google Kubernetes Engine auf.

   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.

Fehlerbehebung

Dieser Abschnitt enthält Hinweise zum Beheben von Problemen im Zusammenhang mit VPC-nativen Clustern. Sie können auch Statistiken zur GKE-IP-Adressauslastung ansehen.

Die Standardnetzwerkressource ist nicht bereit

Symptome

Es kann eine Fehlermeldung wie die folgende angezeigt werden:

projects/[PROJECT_NAME]/regions/XXX/subnetworks/default

Mögliche Ursachen

Es laufen mehrere Vorgänge im selben Subnetz. Beispielsweise wird ein anderer VPC-nativer Cluster erstellt oder ein sekundärer Bereich wird im Subnetz hinzugefügt oder gelöscht.

Lösung

Führen Sie den Befehl noch einmal aus.

Ungültiger Wert für IPCidrRange

Symptome

Es kann eine Fehlermeldung wie die folgende angezeigt werden:

resource.secondaryIpRanges[1].ipCidrRange': 'XXX'. Invalid IPCidrRange: XXX conflicts with existing subnetwork 'default' in region 'XXX'

Mögliche Ursachen

Ein anderer VPC-nativer Cluster wird zur gleichen Zeit erstellt und versucht, dieselben Bereiche im selben VPC-Netzwerk zuzuweisen.

Der gleiche sekundäre Bereich wird dem Subnetzwerk im selben VPC-Netzwerk hinzugefügt.

Lösung

Wenn dieser Fehler beim Erstellen des Clusters zurückgegeben wird und keine sekundären Bereiche angegeben wurden, führen Sie den Befehl zum Erstellen des Clusters noch einmal aus.

Zu wenig freier IP-Adressbereich für Pods

Symptome

Der Cluster hängt längere Zeit in einem Bereitstellungsstatus fest.

Bei der Clustererstellung wird ein Fehler der verwalteten Instanzgruppe (Managed Instance Group, MIG) ausgegeben.

Wenn Sie einem Cluster einen oder mehrere Knoten hinzufügen, wird der folgende Fehler angezeigt:

[IP_SPACE_EXHAUSTED] Instance 'INSTANCE_NAME' creation failed: IP space of 'projects/PROJECT_ID/regions/REGION/subnetworks/SUBNET_NAME-SECONDARY_RANGE_NAME' is exhausted.

Mögliche Ursachen

Knoten-IP-Adresse ausgeschöpft:Der primäre IP-Adressbereich des Ihrem Cluster zugewiesenen Subnetzes hat keine verfügbaren IP-Adressen. Dies geschieht normalerweise, wenn Knotenpools skaliert oder große Cluster erstellt werden.

Pod-IP-Adressenauslastung: Der Ihrem Cluster zugewiesene Pod-CIDR-Bereich ist voll. Dies tritt auf, wenn die Anzahl der Pods die Kapazität des Pod-CIDR überschreitet, insbesondere bei einer hohen Pod-Dichte pro Knoten oder großen Bereitstellungen.

Spezifische Namenskonventionen für Subnetze: Anhand der Art und Weise, wie ein Subnetz in einer Fehlermeldung benannt wird, können Sie herausfinden, ob das Problem auf den Knoten-IP-Adressbereich zurückzuführen ist, in dem die Knoten selbst ihre IP-Adresse) oder den IP-Adressbereich des Pods, in dem die Container innerhalb der Pods ihre IP-Adressen abrufen.

Sekundäre Bereichserschöpfung (Autopilot): In Autopilot-Clustern werden sekundäre Bereiche, die für Pod-IP-Adressen zugewiesen sind, aufgrund von Skalierung oder hoher Pod-Dichte erschöpft.

Lösung

Erfassen Sie die folgenden Informationen zu Ihrem GKE-Cluster: Name, Version der Steuerungsebene, Modus (Standard oder Autopilot), der zugehörige VPC-Name, Subnetzname und CIDR. Notieren Sie sich außerdem die Standard- und zusätzlichen IPv4-Bereiche für Cluster-Pods (einschließlich Namen und CIDRs), ob VPC-natives Traffic-Routing aktiviert ist, und die maximale Anzahl von Pods pro Knoten auf Cluster- und Knotenpool-Ebene (falls zutreffend). Beachten Sie alle betroffenen Knotenpools und ihre spezifischen IPv4-Pod-IP-Adressbereiche und die maximalen Anzahl von Pods pro Knoten, wenn sie sich von den clusterweiten Einstellungen unterscheiden. Notieren Sie außerdem die Standard- und benutzerdefinierten Konfigurationen (falls vorhanden) für die maximale Anzahl von Pods pro Knoten in der Knotenpoolkonfiguration.

Problem mit Erschöpfung der IP-Adresse prüfen

• Network Intelligence Center: Prüfen Sie die Pod-IP-Adressbereiche im Network Intelligence Center für Ihren GKE-Cluster auf hohe IP-Adresszuweisungsraten.

  Wenn Sie in den Pod-Bereichen in Network Intelligence Center eine hohe IP-Adresszuweisungsrate beobachten, ist Ihr Pod-IP-Adressbereich aufgebraucht.

  Wenn die Pod-IP-Adressbereiche normale Zuweisungsraten anzeigen, aber weiterhin IP-Adressen erschöpft sind, ist der IP-Adressbereich des Knotens wahrscheinlich aufgebraucht.

• Audit-Logs: Prüfen Sie das Feld resourceName in den IP_SPACE_EXHAUSTED-Einträgen und vergleichen Sie es mit Subnetznamen oder Namen sekundärer Pod-IP-Adressbereiche.

• Prüfen Sie, ob der erschöpfte IP-Adressbereich der Knoten-IP-Adressbereich oder der Pod-IP-Adressbereich ist.

  Um zu überprüfen, ob es sich bei dem erschöpften IP-Adressbereich um den IP-Adressbereich des Knotens oder den IP-Adressbereich des Pods handelt, prüfen Sie, ob der Wert von resourceName im ipSpaceExhausted-Teil eines IP_SPACE_EXHAUSTED-Logeintrags mit dem Namen des Subnetzes oder dem Namen des sekundären IPv4-Adressbereichs für Pods korreliert, die in dem betroffenen GKE-Cluster verwendet werden.

  Wenn der Wert von resourceName das Format "[Subnet_name]" hat, ist der IP-Adressbereich des Knotens ausgeschöpft. Wenn der Wert von resourceName das Format "[Subnet_name]-[Name_of_Secondary_IPv4_range_for_pods]-[HASH_8BYTES]" hat, ist der Pod-IP-Adressbereich ausgeschöpft.

  Hinweis: GKE kürzt lange Strings, die im Subnetznamen und im Namen des sekundären IPv4-Adressbereichs für Pods verwendet werden, auf 15 Zeichen.

Beheben Sie die Erschöpfung der Pod-IP-Adressen:

• Größe des vorhandenen Pod-CIDR anpassen: Erhöhen Sie die Größe des aktuellen Pod-IP-Adressbereichs. Sie können dem Cluster Pod-IP-Bereiche mit unveränderten Multi-Pod-CIDR hinzufügen.
• Zusätzliche Subnetze erstellen: Fügen Sie dem Cluster Subnetze mit dedizierten Pod-CIDRs hinzu.

Reduzieren Sie die Pods pro Knoten, um IP-Adressen freizugeben:

• Erstellen Sie einen neuen Knotenpool mit einer kleineren maximalen Anzahl von Pods pro Knoten.
• Migrieren Sie Arbeitslasten in diesen Knotenpool und löschen Sie dann den vorherigen Knotenpool. Durch die Reduzierung der maximalen Anzahl an Pods pro Knoten können Sie mehr Knoten in einem festen sekundären IP-Adressbereich für Pods unterstützen. Informationen zu den entsprechenden Berechnungen finden Sie unter Sekundärer IP-Adressbereich des Subnetzes für Pods und Knotenbegrenzungsbereiche.

Ausschöpfung der IP-Adressen von Adressknoten:

• IP-Adressplanung prüfen: Prüfen Sie, ob der IP-Adressbereich des Knotens Ihren Skalierungsanforderungen entspricht.
• Neuen Cluster erstellen (falls erforderlich): Wenn der IP-Adressbereich des Knotens stark eingeschränkt ist, erstellen Sie einen Ersatzcluster mit der entsprechenden Größe des IP-Adressbereichs. Weitere Informationen finden Sie unter IP-Bereiche für VPC-native Cluster und IP-Bereichsplanung.

Prüfen, ob Standard-SNAT deaktiviert ist

Verwenden Sie den folgenden Befehl, um den Status von Standard-SNAT zu prüfen:

gcloud container clusters describe CLUSTER_NAME

Ersetzen Sie CLUSTER_NAME durch den Namen Ihres Clusters.

Die entsprechende Ausgabe sieht etwa so aus:

networkConfig:
  disableDefaultSnat: true
  network: ...

--disable-default-snat kann ohne --enable-ip-alias nicht verwendet werden.

Diese Fehlermeldung und must disable default sNAT (--disable-default-snat) before using public IP address privately in the cluster bedeuten, dass Sie beim Erstellen des Clusters explizit das Flag --disable-default-snat setzen sollten, da Sie in Ihrem privaten Cluster öffentliche IP-Adressen verwenden.

Wenn Fehlermeldungen wie cannot disable default sNAT ... angezeigt werden, kann die Standard-SNAT in Ihrem Cluster nicht deaktiviert werden. Prüfen Sie Ihre Clusterkonfiguration, um dieses Problem zu beheben.

Debugging von Cloud NAT mit deaktiviertem Standard-SNAT

Wenn Sie einen privaten Cluster mit dem Flag --disable-default-snat erstellt und Cloud NAT für den Internetzugriff eingerichtet haben und kein Traffic von Ihren Pods zum Internet angezeigt wird, vergewissern Sie sich, dass der Pod-Bereich in der Cloud NAT-Konfiguration enthalten ist.

Wenn ein Problem mit der Pod-zu-Pod-Kommunikation auftritt, prüfen Sie die iptables-Regeln der Knoten. Achten Sie dabei darauf, dass die Pod-Bereiche nicht durch iptables-Regeln maskiert werden.

Weitere Informationen finden Sie in der Dokumentation zur GKE-IP-Maskierung.

Wenn Sie keinen IP-Maskierungs-Agent für den Cluster konfiguriert haben, sorgt GKE automatisch dafür, dass die Pod-zu-Pod-Kommunikation nicht maskiert wird. Wenn jedoch ein IP-Maskierungs-Agent konfiguriert ist, werden die Standardregeln für die IP-Maskierung überschrieben. Prüfen Sie, ob im IP-Maskierungs-Agent zusätzliche Regeln konfiguriert sind, um die Maskierung der Pod-Bereiche zu ignorieren.

Die Netzwerkkommunikation des Dual-Stack-Clusters funktioniert nicht wie erwartet

Mögliche Ursachen

Die vom GKE-Cluster erstellten Firewallregeln enthalten nicht die zugewiesenen IPv6-Adressen.

Lösung

Sie können die Firewallregel so prüfen:

1. Prüfen Sie den Inhalt der Firewallregel:

   gcloud compute firewall-rules describe FIREWALL_RULE_NAME
   

   Ersetzen Sie FIREWALL_RULE_NAME durch den Namen der Firewallregel.

   Jeder Dual-Stack-Cluster erstellt eine Firewallregel, durch die Knoten und Pods miteinander kommunizieren können. Der Inhalt der Firewallregel sieht in etwa so aus:

   allowed:
   - IPProtocol: esp
   - IPProtocol: ah
   - IPProtocol: sctp
   - IPProtocol: tcp
   - IPProtocol: udp
   - IPProtocol: '58'
   creationTimestamp: '2021-08-16T22:20:14.747-07:00'
   description: ''
   direction: INGRESS
   disabled: false
   enableLogging: false
   id: '7326842601032055265'
   kind: compute#firewall
   logConfig:
     enable: false
   name: gke-ipv6-4-3d8e9c78-ipv6-all
   network: https://www.googleapis.com/compute/alpha/projects/my-project/global/networks/alphanet
   priority: 1000
   selfLink: https://www.googleapis.com/compute/alpha/projects/my-project/global/firewalls/gke-ipv6-4-3d8e9c78-ipv6-all
   selfLinkWithId: https://www.googleapis.com/compute/alpha/projects/my-project/global/firewalls/7326842601032055265
   sourceRanges:
   - 2600:1900:4120:fabf::/64
   targetTags:
   - gke-ipv6-4-3d8e9c78-node
   

   Der Wert sourceRanges muss mit subnetIpv6CidrBlock übereinstimmen. Der Wert targetTags muss mit den Tags auf den GKE-Knoten übereinstimmen. Um dieses Problem zu beheben, aktualisieren Sie die Firewallregeln mit den ipAllocationPolicy-Blockierungsinformationen des Clusters.

Nächste Schritte

• GKE-Netzwerkübersicht
• Informationen zum internen Load-Balancing
• Autorisierte Netzwerke für Masterzugriff erstellen
• Cluster-Netzwerkrichtlinien erstellen