Versionsinformationen finden Sie in den Versionshinweisen zu Distributed Cloud Connected.

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Netzwerkfunktionen von Distributed Cloud Connected

Auf dieser Seite werden die Netzwerkfunktionen von Google Distributed Cloud Connected beschrieben, einschließlich Subnetzwerke und Load-Balancing.

Distributed Cloud Edge Network API aktivieren

Bevor Sie die Netzwerkkonfiguration für eine verbundene Bereitstellung von Distributed Cloud vornehmen können, müssen Sie die Distributed Cloud Edge Network API aktivieren. Führen Sie dazu die Schritte in diesem Abschnitt aus. Standardmäßig ist die Distributed Cloud Edge Network API auf Distributed Cloud Connected-Servern bereits aktiviert.

Console

Rufen Sie in der Google Cloud Console die Distributed Cloud Edge Network API Seite auf.

API aktivieren
Klicken Sie auf Aktivieren.

gcloud

Verwenden Sie den folgenden Befehl:

gcloud services enable edgenetwork.googleapis.com

Netzwerkkonfiguration für Distributed Cloud Connected

In diesem Abschnitt wird beschrieben, wie Sie die Netzwerkkomponenten in Ihrer Distributed Cloud Connected-Bereitstellung konfigurieren.

Für Distributed Cloud Connected-Server gelten die folgenden Einschränkungen:

Sie können nur Subnetzwerke konfigurieren.
Subnetzwerke unterstützen nur VLAN-IDs. CIDR-basierte Subnetzwerke werden nicht unterstützt.

Eine typische Netzwerkkonfiguration für Distributed Cloud Connected besteht aus den folgenden Schritten:

Optional: Initialisieren Sie bei Bedarf die Netzwerkkonfiguration der Zielzone.
Netzwerk erstellen
Erstellen Sie ein oder mehrere Subnetzwerke im Netzwerk.
Testen Sie die Konfiguration.
Verbinden Sie Ihre Pods mit dem Netzwerk.

Netzwerkkonfiguration der Distributed Cloud-Zone initialisieren

Sie müssen die Netzwerkkonfiguration Ihrer Distributed Cloud Connected-Zone sofort initialisieren, nachdem Ihre Distributed Cloud Connected-Hardware in Ihren Räumlichkeiten installiert wurde. Die Initialisierung der Netzwerkkonfiguration einer Zone ist ein einmaliger Vorgang.

Durch die Initialisierung der Netzwerkkonfiguration einer Zone wird ein Standardnetzwerk mit dem Namen default erstellt. Diese Konfiguration bietet Ihrer Distributed Cloud Connected-Bereitstellung eine grundlegende Uplink-Verbindung zu Ihrem lokalen Netzwerk.

Eine Anleitung finden Sie unter Netzwerkkonfiguration einer Zone initialisieren.

Netzwerk erstellen

Eine Anleitung zum Erstellen eines neuen Netzwerks finden Sie unter Netzwerk erstellen. Sie müssen auch mindestens ein Subnetzwerk im Netzwerk erstellen, damit Distributed Cloud Connected-Knoten eine Verbindung zum Netzwerk herstellen können.

Ein oder mehrere Subnetzwerke erstellen

Eine Anleitung zum Erstellen eines Subnetzwerks finden Sie unter Subnetzwerk erstellen. Sie müssen mindestens ein Subnetzwerk in Ihrem Netzwerk erstellen, damit Knoten auf das Netzwerk zugreifen können. Das VLAN, das jedem von Ihnen erstellten Subnetzwerk entspricht, ist automatisch für alle Knoten in der Zone verfügbar.

Konfiguration testen

So testen Sie die Konfiguration der von Ihnen erstellten Netzwerkkomponenten:

Pods mit dem Netzwerk verbinden

Eine Anleitung zum Verbinden Ihrer Pods mit dem Netzwerk und zum Konfigurieren erweiterter Netzwerkfunktionen, finden Sie unter Network Function Operator. Diese Funktion ist für virtuelle Maschinen-Arbeitslasten nicht verfügbar.

Optional: Cluster-Netzwerkisolation konfigurieren

Distributed Cloud Connected unterstützt die Cluster-Netzwerkisolation. Knoten, die einem netzwerkisolierten Cluster zugewiesen sind, können nicht mit anderen Knoten in derselben Distributed Cloud Connected-Zone kommunizieren. Verwenden Sie das Flag --enable-cluster-isolation beim Erstellen oder Ändern eines Clusters, um die Cluster-Netzwerkisolation zu aktivieren. Weitere Informationen finden Sie unter Cluster erstellen und verwalten.

Optional: Inselmodus konfigurieren

Distributed Cloud Connected unterstützt den Inselmodus für das virtuelle Netzwerksubsystem. Im Inselmodus können Sie einen isolierten IP-Adressbereich auf der sekundären Netzwerkschnittstelle eines Pods angeben. Dieser isolierte Adressbereich ist unabhängig vom Adressbereich des VLAN der primären Netzwerkschnittstelle. Pods, die für den Inselmodus konfiguriert sind, werden nur Adressen aus diesem isolierten Adressbereich zugewiesen. Weitere Informationen finden Sie unter Netzwerkmodelle im flachen Modus und im Inselmodus.

Der isolierte IP-Adressbereich, den Sie für den Inselmodus angeben, darf sich nicht mit den folgenden IP-Adressbereichen überschneiden:

Der primäre VLAN-CIDR für jedes im Cluster konfigurierte Netzwerk
Der virtuelle IP-Adressbereich des Load-Balancers, der in der Annotation networking.gke.io/gdce-lb-service-vip-cidrs in der Ressource Network angegeben ist
Die IP-Adressbereiche, die für den Inselmodus für andere Netzwerke im Cluster verwendet werden

Inselmodus konfigurieren

Wenn Sie den Inselmodus auf Pod-Ebene konfigurieren möchten, fügen Sie der entsprechenden benutzerdefinierten Ressource Network die Annotation networking.gke.io/gdce-pod-cidr hinzu. Legen Sie den Wert der Annotation auf den isolierten Ziel-IP-Adressbereich fest und wenden Sie die geänderte Ressource Network auf Ihren Cluster an. Beispiel:

networking.gke.io/gdce-pod-cidr: 172.15.10.32/27

Sie müssen auch die folgenden Parameter festlegen:

type muss auf L3 festgelegt sein.
IPAMMode muss auf Internal festgelegt sein.

Beispiel:

apiVersion: networking.gke.io/v1
kind: Network
metadata:
  name: my-network
  annotations:
    # Enable island mode and specify the isolated address range.
    networking.gke.io/gdce-pod-cidr: 172.15.10.32/27
    # Specify the VLAN ID for this secondary network.
    networking.gke.io/gdce-vlan-id: "561"
    # Specify the CIDR block for load balancer services on this network.
    networking.gke.io/gdce-lb-service-vip-cidrs: 172.20.5.180/30
spec:
  # Network type must be L3 for island mode.
  type: L3
  # IPAMMode must be Internal for island mode.
  IPAMMode: Internal
  nodeInterfaceMatcher:
    interfaceName: gdcenet0.561 # The name for the target network interface.
  gateway4: 172.20.5.177 # Gateway IP address; must be unique in this CR.
  externalDHCP4: false
  dnsConfig:
    nameservers:
    - 8.8.8.8

So prüfen Sie, ob der Inselmodus aktiviert ist:

Erstellen Sie einen Test-Pod und wenden Sie ihn auf Ihren Cluster an. Beispiel:

apiVersion: v1
kind: Pod
metadata:
  name: island-pod-tester
  annotations:
    networking.gke.io/interfaces: '[{"interfaceName":"eth1","network":"test-network-vlan561"}]'
    networking.gke.io/default-interface: "eth1"
spec:
  containers:
  - name: sample-container
    image: busybox
    command: ["/bin/sh", "-c", "sleep 3600"]

Rufen Sie die IP-Adresse des Pods ab:
```
kubectl get pod island-pod-tester -o wide
```
Der Befehl gibt die IP-Adresse des Pods zurück, die sich im von Ihnen angegebenen isolierten Adressbereich befindet.

Inselmodus mit dem Dienst `ClusterIP` konfigurieren

Wenn Sie den Inselmodus mit dem Dienst ClusterIP konfigurieren möchten, führen Sie die Schritte im vorherigen Abschnitt aus. Fügen Sie dann der Ressource Network die Annotation networking.gke.io/gke-gateway-clusterip-cidr hinzu und legen Sie ihren Wert entsprechend Ihren geschäftlichen Anforderungen fest. Adressbereiche, die in der Ressource Network angegeben sind, dürfen sich nicht überschneiden. Beispiel:

apiVersion: networking.gke.io/v1
kind: Network
metadata:
  annotations:
    networking.gke.io/gdce-lb-service-vip-cidrs: 172.20.5.180/30
    networking.gke.io/gdce-pod-cidr: 172.15.10.32/27
    networking.gke.io/gdce-vlan-id: "561"
    networking.gke.io/gke-gateway-clusterip-cidr: 10.20.1.0/28
  name: test-network-vlan561
spec:
  IPAMMode: Internal
  dnsConfig:
    nameservers:
    - 8.8.8.8
  externalDHCP4: false
  gateway4: 172.20.5.177
  nodeInterfaceMatcher:
    interfaceName: gdcenet0.561
  type: L3

Load Balancing

Distributed Cloud wird mit einer gebündelten Lösung für das Netzwerk-Load Balancing ausgeliefert, die auf MetalLB im Layer-2-Modus basiert. Mit dieser Lösung können Sie Dienste, die in Ihrer Distributed Cloud-Zone ausgeführt werden, mithilfe von virtuellen IP-Adressen (VIPs) für die Außenwelt verfügbar machen:

Ihr Netzwerkadministrator plant die Netzwerktopologie und gibt beim Bestellen von Distributed Cloud das erforderliche virtuelle IPv4-Adress-Subnetzwerk an. Google konfiguriert Ihre Distributed Cloud-Hardware vor der Auslieferung entsprechend. Beachten Sie Folgendes:
- Dieses VIP-Subnetzwerk wird von allen Kubernetes-Clustern gemeinsam genutzt, die in Ihrer Distributed Cloud-Zone ausgeführt werden.
- Die erste (Netzwerk-ID), zweite (Standardgateway) und letzte (Broadcast Adresse) Adresse im Subnetzwerk sind für die Kernsystem funktionen reserviert. Weisen Sie diese Adressen nicht den Adresspools Ihrer MetalLB-Konfigurationen zu.
- Jeder Cluster muss einen separaten VIP-Bereich verwenden, der sich im konfigurierten VIP-Subnetzwerk befindet.
Wenn Sie einen Cluster in Ihrer Distributed Cloud-Zone erstellen, gibt der Clusteradministrator die Adresspools für Pod und ClusterIP-Dienst mithilfe der CIDR-Notation an. Ihr Netzwerkadministrator stellt dem Clusteradministrator das entsprechende VIP-Subnetzwerk LoadBalancer zur Verfügung.
Nachdem der Cluster erstellt wurde, konfiguriert der Clusteradministrator die entsprechenden VIP-Pools. Sie müssen die VIP-Pools beim Erstellen des Clusters mit dem Flag --external-lb-address-pools angeben. Das Flag akzeptiert eine Datei mit einer YAML- oder JSON-Nutzlast im folgenden Format:
```
 addressPools:
 - name: foo
   addresses:
   - 10.2.0.212-10.2.0.221
   - fd12::4:101-fd12::4:110
   avoid_buggy_ips: true
   manual_assign: false

 - name: bar
   addresses:
   - 10.2.0.202-10.2.0.203
   - fd12::4:101-fd12::4:102
   avoid_buggy_ips: true
   manual_assign: false
```
Geben Sie in der Nutzlast die folgenden Informationen an, um einen VIP-Adresspool anzugeben:
- name: ein beschreibender Name, der diesen VIP-Adresspool eindeutig identifiziert.
- addresses: eine Liste von IPv4-Adressen, Adressbereichen und Subnetzwerken, die in diesen Adresspool aufgenommen werden sollen.
- avoid_buggy_ips: schließt IP-Adressen aus, die mit .0 oder .255 enden.
- manual_assign: Ermöglicht Ihnen, Adressen aus diesem Pool manuell in der Konfiguration des Ziel-Dienstes zuzuweisen, anstatt sie automatisch vom MetalLB Controller zuweisen zu lassen.LoadBalancer
Weitere Informationen zum Konfigurieren von VIP-Adresspools finden Sie in der MetalLB-Dokumentation unter Adresspools angeben.
Der Clusteradministrator erstellt die entsprechenden Kubernetes LoadBalancer Dienste.

Distributed Cloud-Knoten in einem einzelnen Knotenpool verwenden eine gemeinsame Layer-2-Domain und sind daher auch MetalLB-Load-Balancer-Knoten. Wenn Sie diese Schritte ausführen, wird das Layer-2-Load-Balancing mit MetalLB automatisch konfiguriert.

`ClusterDNS`-Ressource

Distributed Cloud Connected unterstützt die Google Distributed Cloud-Ressource ClusterDNS zum Konfigurieren vorgelagerter Nameserver für bestimmte Domains mithilfe des Abschnitts spec.domains. Weitere Informationen zum Konfigurieren dieser Ressource finden Sie unter spec.domains.

Nächste Schritte

Netzwerkadressenzuweisung für Pods und Dienste

Netzwerkfunktionen von Distributed Cloud Connected Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.