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.

Hinweis

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

Mit den folgenden Methoden können Sie die gcloud-Einstellungen festlegen:

  • Verwenden Sie gcloud init, wenn Sie die Standardeinstellungen ansehen möchten.
  • Verwenden Sie gcloud config, um Ihre Projekt-ID, Zone und Region individuell festzulegen.

gcloud init verwenden

Wenn Sie die Fehlermeldung One of [--zone, --region] must be supplied: Please specify location erhalten, führen Sie diesen Abschnitt aus.

  1. Führen Sie gcloud init aus und folgen Sie der Anleitung:

    gcloud init

    Wenn Sie SSH auf einem Remote-Server verwenden, können Sie mit dem Flag --console-only verhindern, dass mit dem Befehl ein Browserfenster geöffnet wird:

    gcloud init --console-only
  2. Folgen Sie der Anleitung, um gcloud zur Verwendung Ihres Google Cloud-Kontos zu autorisieren.
  3. Erstellen Sie eine neue Konfiguration oder wählen Sie eine vorhandene aus.
  4. Wählen Sie ein Google Cloud-Projekt aus.
  5. Wählen Sie eine Compute Engine-Standardzone für zonale Cluster oder eine Region für regionale oder Autopilot-Cluster aus.

gcloud config verwenden

  • Legen Sie Ihre standardmäßige Projekt-ID fest:
    gcloud config set project PROJECT_ID
  • Wenn Sie mit zonalen Clustern arbeiten, legen Sie die Standardzone für Compute Engine fest:
    gcloud config set compute/zone COMPUTE_ZONE
  • Wenn Sie mit Autopilot oder regionalen Clustern arbeiten, legen Sie die Compute-Standardregion fest:
    gcloud config set compute/region COMPUTE_REGION
  • Aktualisieren Sie gcloud auf die neueste Version:
    gcloud components update

Verfahren

Mit den folgenden Verfahren erstellen Sie einen VPC-nativen Cluster und überprüfen die konfigurierten Pod- und Service-IP-Adressbereiche.

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 \
      --region=region \
      --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 \
      --region=region \
      --enable-ip-alias \
      --subnetwork=subnet-name \
      --cluster-secondary-range-name=secondary-range-pods \
      --services-secondary-range-name=secondary-range-services
    

Ersetzen Sie die Platzhalter durch gültige Werte:

  • cluster-name ist der Name des GKE-Clusters.
  • region ist die Region, in der der Cluster erstellt wird. Zum Erstellen eines zonalen Clusters ersetzen Sie dieses Flag durch --zone=zone, wobei zone eine Google Cloud-Zone ist.
  • subnet-name ist 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 ist 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 ist 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 ist 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 ist 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 Services des Clusters.

Console

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

    Zur Seite "Google Kubernetes Engine"

  2. Klicken Sie auf Erstellen.

  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 ein (Beispiel: 10.0.0.0/14).

  9. Geben Sie im Feld Dienstadressbereich einen Dienstbereich ein (Beispiel: 10.4.0.0/19).

  10. Konfigurieren Sie den Cluster nach Bedarf.

  11. Klicken Sie auf Erstellen.

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,

  },
  ...
}

Dabei gilt:

  • "clusterIpv4CidrBlock" ist die Größe bzw. der Ort des CIDR-Bereichs für Pods. Bestimmt die Größe des sekundären Bereichs für Pods und kann in der CIDR-Notation IP-Adresse/Größe (z. B. 10.0.0.0/14)/Größe (z. B./14) angegeben sein. Ein leerer Bereich mit der angegebenen Größe wird aus dem verfügbaren Bereich in der VPC ausgewählt. Wird dieses Feld leer gelassen, wird ein gültiger Bereich gefunden und mit einer Standardgröße erstellt.
  • "servicesIpv4CidrBlock" ist die Größe bzw. der Ort des CIDR-Bereichs für Dienste. Siehe Beschreibung von "clusterIpv4CidrBlock".
  • "clusterSecondaryRangeName" ist 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 (z. B. das mit dem Flag --subnetwork angegebene Subnetzwerk).
  • "serviceSecondaryRangeName" ist der Name des sekundären Bereichs für Dienste. Der sekundäre Bereich muss bereits vorhanden sein und zu dem Subnetzwerk gehören, das dem Cluster zugeordnet ist (z. B. das mit dem Flag --subnetwork angegebene Subnetzwerk).

Terraform

Mit einem Terraform-Modul können Sie ganz einfach einen VPC-nativen Cluster über Terraform erstellen.

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

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

  project_id        = "project-id"
  name              = "cluster-name"
  region            = "region"
  network           = "network-name"
  subnetwork        = "subnet-name"
  ip_range_pods     = "secondary-range-pods"
  ip_range_services = "secondary-range-services"
}

Dabei gilt:

  • project-id ist die ID des Projekts, in dem der Cluster erstellt wird.
  • cluster-name ist der Name des GKE-Clusters.
  • region ist die Region, in der der Cluster erstellt wird.
  • network-name ist der Name eines vorhandenen Netzwerks.
  • subnet-name ist 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 ist 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 ist 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 Services des Clusters.

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.

gcloud

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

gcloud container clusters create cluster-name \
    --region=region \
    --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.
  • region ist die Region, in der der Cluster erstellt wird. Zum Erstellen eines zonalen Clusters ersetzen Sie dieses Flag durch --zone=zone, wobei zone eine GKE-Zone ist.
  • subnet-name ist 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 ist 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). Damit wird der primäre IP-Adressbereich des Subnetzes für Knoten erstellt. 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 ist 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 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 ist 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 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.

Private 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.

Private 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 TCP/UDP-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 TCP/UDP-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

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 öffentlichen 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 privat verwendete öffentliche IP-Adressbereiche für den Pod-CIDR verwenden, würde dies dazu führen, dass die SNAT-Regeln auf den Pod-zu-Pod-Traffic angewendet werden. Um dies zu vermeiden, haben Sie zwei Möglichkeiten:

Beispielcluster mit privat verwendeten öffentlichen Bereichen

Im folgenden Beispiel wird gcloud verwendet, um einen Cluster zu erstellen, der privat wiederverwendete öffentliche IP-Adressbereiche verwendet. Sie müssen das folgende Flag verwenden:

  • --enable-ip-alias: Hiermit wird ein VPC-nativer Cluster erstellt, der erforderlich ist, wenn Sie öffentliche IP-Adressbereiche privat verwenden.

Dieser Befehl erstellt einen VPC-nativen privaten Cluster,

  • dessen Knoten den primären IP-Adressbereich 10.0.0.0/24 des Subnetzes verwenden,
  • dessen Pods den öffentlichen IP-Adressbereich 5.0.0.0/16 als sekundären IP-Adressbereich des Subnetzes für Pods verwenden und
  • dessen Services den öffentlichen IP-Adressbereich 5.1.0.0/16 als sekundären IP-Adressbereich des Subnetzes für Services verwenden.
gcloud container clusters create cluster-name \
  --enable-ip-alias \
  --enable-private-nodes \
  --disable-default-snat \
  --zone=zone \
  --create-subnetwork name=cluster-subnet,range=10.0.0.0/24 \
  --cluster-ipv4-cidr=5.0.0.0/16 \
  --services-ipv4-cidr=5.1.0.0/16 \
  --master-ipv4-cidr=master-CIDR

Pod- und Dienstbereiche prüfen

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

gcloud

So prüfen Sie den Cluster:

gcloud container clusters describe cluster-name

Sehen Sie in der Befehlsausgabe unter dem Feld ipAllocationPolicy nach:

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

Console

So überprüfen Sie den Cluster:

  1. Rufen Sie in der 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.

Die Ressource "projects/[PROJECT_NAME]/regions/XXX/subnetworks/default" ist nicht bereit

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 das Feld "resource.secondaryIpRanges [1].ipCidrRange": "XXX". Ungültiger IPCidrRange: XXX steht im Konflikt mit bestehendem Subnetzwerk "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.

Kein ausreichender freier IP-Bereich für Pod

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.

Einem vorhandenen Cluster können keine neuen Knoten hinzugefügt werden.

Mögliche Ursachen

Der nicht zugewiesene Bereich innerhalb des Pod-IP-Adressbereichs ist nicht groß genug für die im Cluster angeforderten Knoten. Wenn der Pod-IP-Adressbereich eines Clusters beispielsweise eine Netzmaske mit der Größe /23 (512 Adressen) hat und die maximale Anzahl an Pods pro Knoten 110 lautet, können Sie nicht mehr als zwei Knoten erstellen. Jedem Knoten wird ein Alias-IP-Adressbereich mit einer Netzmaske der Größe /24 zugewiesen.

Lösungen

Sie können dem Cluster Pod-IP-Bereiche mit unveränderten Multi-Pod-CIDR hinzufügen.

Erstellen Sie einen Ersatzcluster, nachdem Sie primäre und sekundäre IP-Adressbereiche in der richtigen Größe überprüft und geplant haben. Weitere Informationen finden Sie unter IP-Bereiche für VPC-native Cluster und IP-Bereichsplanung.

Wenn sich der Cluster nicht ersetzen lässt, können Sie das Problem unter Umständen umgehen, wenn Sie einen neuen Knotenpool mit einer kleineren maximalen Anzahl von Pods pro Knoten erstellen. Migrieren Sie Arbeitslasten nach Möglichkeit in diesen Knotenpool und löschen Sie dann den vorherigen Knotenpool. Durch die Reduzierung der maximalen Anzahl von 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.

Prüfen, ob Standard-SNAT aktiviert ist

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

gcloud container clusters describe cluster-name

Ersetzen Sie cluster-name durch den Namen Ihres Clusters.

Die Ausgabe enthält das Feld disableDefaultSnat, das etwa so aussieht:

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 die Clusterkonfiguration.

Debugging in 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. Der Beispielausgabe von iptables zur IP-Maskierung können Sie entnehmen, wie Sie iptables-Regeln auflisten können und was die Standardregeln sind. 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 Agent für die IP-Maskierung 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.

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. Legacy-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 TCP/UDP-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.

Nächste Schritte