Versionsinformationen finden Sie in den Versionshinweisen zu Distributed Cloud Connected.

Netzwerkfunktionen von Distributed Cloud Connected

Auf dieser Seite werden die Netzwerkfunktionen von Google Distributed Cloud Connected beschrieben, darunter Subnetzwerke, BGP-Peering-Sitzungen und Load Balancing.

Die Verfahren auf dieser Seite gelten nur für Racks, die mit Distributed Cloud Connect verbunden sind, mit Ausnahme des Lastenausgleichs, der sowohl für Racks als auch für Server gilt, die mit Distributed Cloud Connect verbunden sind.

IPv4/IPv6-Dual-Stack-Netzwerk

Mit Distributed Cloud Connected können Sie Cluster erstellen, die IPv4/IPv6-Dual-Stack-Netzwerke verwenden. Wenn Sie diese Funktion nutzen möchten, müssen Sie Distributed Cloud Connected mit aktiviertem Dual-Stack-IPv4/IPv6-Netzwerk bestellen. Sie können eine vorhandene reine IPv4-Bereitstellung von Distributed Cloud, die mit einem IPv4/IPv6-Dual-Stack-Netzwerk verbunden ist, nicht neu konfigurieren. Wenn Sie prüfen möchten, ob Ihre Bereitstellung IPv4/IPv6-Dual-Stack-Netzwerke unterstützt, folgen Sie der Anleitung unter Informationen zu einer Maschine abrufen und prüfen Sie den zurückgegebenen Wert des Labels dualstack_capable.

In einem Dual-Stack-Cluster verwendet der IPv4-Stack den Inselmodus, während der IPv6-Stack den flachen Modus verwendet. Daher müssen Sie einzelne, separate IPv6-Adressen für Knoten und Pods angeben, die zum selben Subnetz gehören. Weitere Informationen finden Sie unter Netzwerkmodelle im flachen Modus und im Inselmodus.

Wenn sich Ihre mit Distributed Cloud verbundenen Knoten und andere lokale Maschinen beispielsweise in derselben Layer 2-Domäne befinden, können Sie die IPv6-CIDR-Blöcke für den Cluster so angeben:

Zweck der Blockierung	Bereich blockieren	Blockgröße
IPv6-Subnetzwerk	fd12::/56	2^72
Pods	fd12::1:0/59	2^69
Dienste	fd12::2:0/59	2^69

In diesem Beispiel wird Folgendes vorausgesetzt:

Die Knoten-, Pod- und Dienst-CIDR-Blöcke gehören zum Supernetzwerk fd:12::/56.
Die Knoten-, Pod- und Dienst-IP-Adressen sind Subnetze des angegebenen CIDR-Blocks.
Keines der Subnetzwerke überschneidet sich.

Für IPv4/IPv6-Dual-Stack-Netzwerke ist Layer 2-Load-Balancing für IPv4-BGP-Peering und Layer 3-Load-Balancing für IPv6-Peering erforderlich. Weitere Informationen finden Sie unter Load-Balancing.

Weitere Informationen zum Bereitstellen von Arbeitslasten in IPv4/IPv6-Dual-Stack-Clustern finden Sie unter:

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 werden Distributed Cloud Connected-Server mit der bereits aktivierten Distributed Cloud Edge Network API ausgeliefert.

Console

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

API aktivieren
Klicken Sie auf Aktivieren.

gcloud

Verwenden Sie den folgenden Befehl:

gcloud services enable edgenetwork.googleapis.com

Netzwerk in Distributed Cloud Connected konfigurieren

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

Für verbundene Server von Distributed Cloud 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 die Netzwerkkonfiguration der Zielzone, falls erforderlich.
Netzwerk erstellen
Erstellen Sie ein oder mehrere Subnetzwerke im Netzwerk.
Richten Sie BGP-Peering-Sitzungen in Richtung Norden mit Ihren PE-Routern ein. Verwenden Sie dazu die entsprechenden Interconnect-Anhänge.
Richten Sie BGP-Peering-Sitzungen in Richtung Süden mit den Pods ein, in denen Ihre Arbeitslasten ausgeführt werden, indem Sie die entsprechenden Subnetzwerke verwenden.
Optional: Erstellen Sie Loopback-BGP-Peering-Sitzungen für Hochverfügbarkeit.
Testen Sie die Konfiguration.
Verbinden Sie Ihre Pods mit dem Netzwerk.

Netzwerkkonfiguration der Distributed Cloud-Zone initialisieren

Sie müssen die Netzwerkkonfiguration Ihrer mit Distributed Cloud verbundenen Zone unmittelbar nach der Installation der mit Distributed Cloud verbundenen Hardware in Ihren Räumlichkeiten initialisieren. Die Initialisierung der Netzwerkkonfiguration einer Zone ist ein einmaliger Vorgang.

Beim Initialisieren der Netzwerkkonfiguration einer Zone werden ein Standardrouter mit dem Namen default und ein Standardnetzwerk mit dem Namen default erstellt. Außerdem wird der default-Router so konfiguriert, dass er mit allen Interconnect-Verbindungen, die Sie bei der Bestellung der Distributed Cloud Connected-Hardware angefordert haben, ein Peering durchführt. Dazu werden entsprechende Interconnect-Anhänge erstellt. Diese Konfiguration bietet Ihrer mit Distributed Cloud verbundenen Bereitstellung eine grundlegende Uplink-Verbindung zu Ihrem lokalen Netzwerk.

Eine Anleitung finden Sie unter Netzwerkkonfiguration einer Zone initialisieren.

Netzwerk erstellen

Folgen Sie der Anleitung unter Netzwerk erstellen, um ein neues Netzwerk zu erstellen. Sie müssen außerdem mindestens ein Subnetzwerk im Netzwerk erstellen, damit verbundene Distributed Cloud-Knoten eine Verbindung zum Netzwerk herstellen können.

Ein oder mehrere Subnetzwerke erstellen

Folgen Sie der Anleitung unter Subnetzwerk erstellen, um ein Subnetzwerk zu erstellen. Sie müssen mindestens ein Subnetz 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.

Bei mit Distributed Cloud verbundenen Servern können Sie Subnetze nur mit VLAN-IDs konfigurieren. CIDR-basierte Subnetzwerke werden nicht unterstützt.

Northbound-BGP-Peering-Sitzungen erstellen

Wenn Sie ein Netzwerk und die zugehörigen Subnetzwerke erstellen, sind diese lokal für die verbundene Zone von Distributed Cloud. Damit ausgehende Verbindungen möglich sind, müssen Sie mindestens eine BGP-Peering-Sitzung in Richtung Norden zwischen dem Netzwerk und Ihren Peering-Edge-Routern einrichten.

So richten Sie eine BGP-Peering-Sitzung in Richtung Norden ein:

List the interconnects available in your zone (Verfügbare Interconnect-Verbindungen in Ihrer Zone auflisten) und wählen Sie dann die Ziel-Interconnect-Verbindung für diese Peering-Sitzung aus.
Erstellen Sie einen oder mehrere Interconnect-Anhänge für die ausgewählte Interconnect-Verbindung. Interconnect-Anhänge verknüpfen den Router, den Sie im nächsten Schritt erstellen, mit der ausgewählten Interconnect-Verbindung.
Router erstellen Dieser Router leitet Traffic zwischen der Interconnect-Verbindung und Ihrem Netzwerk über die Interconnect-Anhänge weiter, die Sie im vorherigen Schritt erstellt haben.
Fügen Sie dem Router für jeden Interconnect-Anhang, den Sie zuvor in diesem Verfahren erstellt haben, eine Schnittstelle hinzu. Verwenden Sie für jede Schnittstelle die IP-Adresse des entsprechenden ToR-Switches (Top-of-Rack) in Ihrem mit Distributed Cloud verbundenen Rack. Eine Anleitung finden Sie unter Northbound-Peering-Sitzung einrichten.
Fügen Sie für jede Schnittstelle, die Sie im vorherigen Schritt auf dem Router erstellt haben, einen Peer hinzu.

Southbound-BGP-Peering-Sitzungen erstellen

Wenn Sie eingehende Verbindungen zu Ihren Arbeitslasten aus Ihrem lokalen Netzwerk zulassen möchten, müssen Sie eine oder mehrere Southbound-BGP-Peering-Sitzungen zwischen Ihren Peering-Edge-Routern und dem Subnetzwerk einrichten, zu dem Ihre Pods gehören. Die Gateway-IP-Adresse für jedes Subnetzwerk ist die IP-Adresse des entsprechenden ToR-Switches in Ihrem mit Distributed Cloud verbundenen Rack.

So richten Sie eine Downstream-BGP-Peering-Sitzung ein:

Fügen Sie dem Router im Zielnetzwerk für jedes Subnetz, das Sie mit eingehender Konnektivität bereitstellen möchten, eine Schnittstelle hinzu. Eine Anleitung finden Sie unter Southbound-Peering-Sitzung einrichten.
Fügen Sie für jede Schnittstelle, die Sie im vorherigen Schritt auf dem Router erstellt haben, einen Peer hinzu.

Optional: Loopback-BGP-Peering-Sitzungen erstellen

Um eine hochverfügbare Verbindung zwischen Ihren Arbeitslasten und Ihrem lokalen Netzwerk zu ermöglichen, können Sie eine Loopback-BGP-Peering-Sitzung zwischen dem Ziel-Pod und beiden ToR-Switches in Ihrem mit Distributed Cloud verbundenen Rack einrichten. Bei einer Loopback-Peering-Sitzung werden zwei unabhängige Peering-Sitzungen für den Pod eingerichtet, eine für jeden ToR-Switch.

So richten Sie eine Loopback-BGP-Peeringsitzung ein:

Fügen Sie dem Router im Zielnetzwerk eine Loopback-Schnittstelle hinzu. Eine Anleitung finden Sie unter Loopback-Peering-Sitzung einrichten.
Fügen Sie einen Peer für die Loopback-Schnittstelle hinzu.

Konfiguration testen

So testen Sie die Konfiguration der von Ihnen erstellten Netzwerkkomponenten:

Pods mit dem Netzwerk verbinden

Wenn Sie Ihre Pods mit dem Netzwerk verbinden und erweiterte Netzwerkfunktionen konfigurieren möchten, folgen Sie der Anleitung unter Network Function Operator. Diese Funktion ist für VM-Arbeitslasten nicht verfügbar.

Optional: Cluster-Netzwerkisolation konfigurieren

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

Optional: Inselmodus konfigurieren

Distributed Cloud Connected unterstützt den Inselmodus für das virtuelle Netzwerk-Subsystem. Im Inselmodus können Sie einen isolierten IP-Adressbereich für die sekundäre Netzwerkschnittstelle eines Pods angeben. Dieser isolierte Adressbereich ist unabhängig vom Adressbereich des primären Netzwerkinterface-VLAN. 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 in der Annotation networking.gke.io/gdce-lb-service-vip-cidrs in der Ressource Network angegebene virtuelle IP-Adressbereich des Load-Balancers
Die IP-Adressbereiche, die für den Inselmodus für alle anderen 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 Annotationswert auf den isolierten Ziel-IP-Adressbereich fest und wenden Sie die geänderte Network-Ressource auf Ihren Cluster an. Beispiel:

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

Außerdem müssen Sie die folgenden Parameter festlegen:

type muss auf L3 gesetzt sein.
IPAMMode muss auf Internal gesetzt 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 `ClusterIP`-Dienst konfigurieren

Wenn Sie den Inselmodus mit dem ClusterIP-Dienst konfigurieren möchten, führen Sie die Schritte im vorherigen Abschnitt aus, fügen Sie dann der Network-Ressource die Annotation networking.gke.io/gke-gateway-clusterip-cidr hinzu und legen Sie ihren Wert entsprechend Ihren geschäftlichen Anforderungen fest. Die in der Ressource Network angegebenen Adressbereiche 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 Connected wird mit den folgenden Load-Balancing-Lösungen ausgeliefert:

Layer-2-Load-Balancing mit MetalLB
Layer-3-Load-Balancing mit Google Distributed Cloud-Load-Balancern

Die in Distributed Cloud Connected integrierten Load-Balancing-Lösungen können keine sich überschneidenden virtuellen IP-Präfixe für Kubernetes-Dienste verwenden. Wenn Sie eine vorhandene verbundene Bereitstellung von Distributed Cloud haben, die Layer-2-MetalLB-Load-Balancing verwendet, und Sie zu Layer-3-Load-Balancing mit Google Distributed Cloud-Load-Balancern wechseln möchten, müssen Sie ein virtuelles IP-Präfix für den Dienst verwenden, das sich nicht mit dem Präfix überschneidet, das von Ihrer Layer-2-MetalLB-Load-Balancing-Konfiguration verwendet wird.

Layer-2-Load-Balancing mit MetalLB

Distributed Cloud wird mit einer gebündelten Network Load Balancing-Lösung 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) nach außen verfügbar machen:

Ihr Netzwerkadministrator plant die Netzwerktopologie und gibt beim Bestellen von Distributed Cloud das erforderliche virtuelle IPv4- und IPv6-Adress-Subnetzwerk an. Google konfiguriert Ihre Distributed Cloud-Hardware vor der Auslieferung entsprechend. Beachten Sie Folgendes:
- Dieses VIP-Subnetz wird von allen Kubernetes-Clustern gemeinsam genutzt, die in Ihrer Distributed Cloud-Zone ausgeführt werden.
- Eine Route für das angeforderte VIP-Subnetzwerk wird über die BGP-Sitzungen zwischen der Distributed Cloud-Zone und Ihrem lokalen Netzwerk angekündigt.
- Die erste (Netzwerk-ID), zweite (Standardgateway) und letzte (Broadcast-Adresse) Adresse im Subnetz sind für die Kernsystemfunktionalität reserviert. Weisen Sie diese Adressen nicht den Adresspools Ihrer MetalLB-Konfigurationen zu.
- Jeder Cluster muss einen separaten VIP-Bereich verwenden, der in das konfigurierte VIP-Subnetzwerk fällt.
Wenn Sie einen Cluster in Ihrer Distributed Cloud-Zone erstellen, gibt der Clusteradministrator die Pod- und ClusterIP-Dienstadresspools in CIDR-Notation an. Ihr Netzwerkadministrator stellt dem Clusteradministrator das entsprechende LoadBalancer-VIP-Subnetzwerk 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 im Nutzlast die folgenden Informationen an, um einen VIP-Adresspool anzugeben:
- name: Ein aussagekräftiger Name, der diesen VIP-Adresspool eindeutig identifiziert.
- addresses: Eine Liste von IPv4- und IPv6-Adressen, Adressbereichen und Subnetzen, die in diesen Adresspool aufgenommen werden sollen.
- avoid_buggy_ips: Schließt IP-Adressen aus, die mit .0 oder .255 enden.
- manual_assign: Damit können Sie Adressen aus diesem Pool manuell in der Konfiguration des Ziel-LoadBalancer-Dienstes zuweisen, anstatt sie automatisch vom MetalLB-Controller zuweisen zu lassen.
Weitere Informationen zum Konfigurieren von VIP-Adresspools finden Sie in der MetalLB-Dokumentation unter Specify address pools.
Der Clusteradministrator erstellt die entsprechenden Kubernetes-LoadBalancer-Dienste.

Distributed Cloud-Knoten in einem einzelnen Knotenpool haben eine gemeinsame Layer 2-Domain und sind daher auch MetalLB-Load-Balancer-Knoten.

Layer-3-Load-Balancing mit Google Distributed Cloud-Load-Balancern

Distributed Cloud Connected wird mit einer gebündelten Netzwerk-Load-Balancing-Lösung ausgeliefert, die auf den gebündelten Load-Balancern von Google Distributed Cloud im Layer 3-Modus basiert, die als BGP-Speaker konfiguriert sind. Mit dieser Lösung können Sie Dienste, die in Ihrer mit Distributed Cloud verbundenen Zone ausgeführt werden, mithilfe von VIPs nach außen verfügbar machen.

Sie können die VIP-Bereiche für die entsprechenden LoadBalancer-Dienste mit der ConfigMap metallb-config angeben. Beispiel:

kind: ConfigMap
apiVersion: v1
data:
  config: |
    address-pools:
    - name: default
      protocol: bgp
      addresses:
      - 10.100.10.66/27
metadata:
  name: metallb-config
  namespace: metallb-system

Im vorherigen Beispiel wird jedem konfigurierten LoadBalancer-Dienst automatisch eine virtuelle IP-Adresse aus dem in der ConfigMap angegebenen Bereich 10.100.10.66/27 zugewiesen. Diese VIPs werden dann von den auf den ToR-Switches konfigurierten Distributed Cloud-BGP-Speakern über die BGPPeer-Ressourcen nach Norden beworben.

Wenn Sie einen Distributed Cloud-Cluster erstellen, werden die folgenden Ressourcen automatisch in diesem Cluster erstellt:

Eine BGPLoadBalancer-Ressource, mit der der BGP-Load-Balancer instanziiert wird.
Eine NetworkGatewayGroup-Ressource, die die lokalen Floating-IP-Adressen angibt, die für die BGP-Speaker verwendet werden sollen. Diese IP-Adressen werden automatisch auf die letzten beiden IP-Adressen des Kubernetes-Knotensubnetzes festgelegt, das dem Cluster zugewiesen ist.

Wenn diese Ressourcen vorhanden sind, können Sie BGP-Sitzungen für die Distributed Cloud-ToR-Switches einrichten, indem Sie entsprechende BGPPeer-Ressourcen konfigurieren. Dazu benötigen Sie die erforderlichen autonomen Systemnummern (Autonomous System Numbers, ASNs) und die Loopback-Peer-IP-Adressen für die ToR-Switches. Diese IP-Adressen dienen als BGP-Sitzungsendpunkte des ToR-Switches in der Standardnetzwerkressource. Der Wert des Parameters network muss pod-network sein.

Hier ein Beispiel für die beiden BGPPeer-Ressourcen:

kind: BGPPeer
apiVersion: networking.gke.io/v1
metadata:
  name: bgppeertor1
  labels:
    cluster.baremetal.gke.io/default-peer: "true"
  namespace: kube-system
spec:
  network: pod-network
  localASN: 64777
  peerASN: 64956
  peerIP: 10.112.0.10
  sessions: 1

kind: BGPPeer
apiVersion: networking.gke.io/v1
metadata:
  name: bgppeertor2
  labels:
    cluster.baremetal.gke.io/default-peer: "true"
  namespace: kube-system
spec:
  network: pod-network
  localASN: 64777
  peerASN: 64956
  peerIP: 10.112.0.11
  sessions: 1

Automatisierung des BGP-Load-Balancing auf Ebene 3 für IPv6-Peering konfigurieren

Bevor Sie IPv6-Peering in Ihrem IPv4/IPv6-Dual-Stack-Netzwerkcluster verwenden können, müssen Sie mit dem Google-Support zusammenarbeiten, um die Automatisierung des Google Distributed Cloud-Load-Balancers in Ihrer Distributed Cloud Connected-Bereitstellung zu aktivieren.

Layer 3-`LoadBalancer`-Dienst erstellen

Nachdem Sie die Automatisierung des Google Distributed Cloud-Load Balancers für Ihre Distributed Cloud Connected-Bereitstellung aktiviert haben, instanziieren Sie den LoadBalancer-Dienst der Schicht 3. Beispiel:

apiVersion: v1
kind: Service
metadata:
  name: my-service
  labels:
    app.kubernetes.io/name: MyApp
spec:
  ipFamilyPolicy: PreferDualStack
  ipFamilies:
  - IPv6
  - IPv4
  selector:
    app.kubernetes.io/name: MyApp
  type: LoadBalancer
  ports:
    - protocol: TCP
      port: 80

Status der BGP-Sitzung und der Load-Balancing-Dienste prüfen

Verwenden Sie den folgenden Befehl, um den Status Ihrer BGP-Sitzung zu prüfen:

kubectl get bgpsessions.networking.gke.io -A

Der Befehl gibt eine Ausgabe ähnlich dem folgenden Beispiel zurück:

NAMESPACE     NAME                                                 LOCAL ASN   PEER ASN   LOCAL IP        PEER IP         STATE            LAST REPORT
kube-system   bgppeertor1-np-den6-120demo-den6-04-6ad5b6f4         64777       64956      10.100.10.61    10.112.0.10     Established      2s
kube-system   bgppeertor2-np-den6-120demo-den6-04-6ad5b6f4         64777       64956      10.100.10.61    10.112.0.11     Established      2s

Verwenden Sie den folgenden Befehl, um zu prüfen, ob Ihre LoadBalancer-Dienste von den BGP-Speakern beworben werden:

kubectl get bgpadvertisedroutes.networking.gke.io -A

Der Befehl gibt eine Ausgabe ähnlich dem folgenden Beispiel zurück:

NAMESPACE      NAME                           PREFIX            METRIC
kube-system    bgplb-default-service-tcp      10.100.10.68/32
kube-system    bgplb-default-service-udp      10.100.10.77/32

Distributed Cloud-Ingress

Zusätzlich zum Load-Balancing werden in Distributed Cloud Connected auch Kubernetes-Ingress-Ressourcen unterstützt. Eine Kubernetes-Ingress-Ressource steuert den Fluss von HTTP(S)-Traffic zu Kubernetes-Diensten, die in Ihren mit Distributed Cloud verbundenen Clustern ausgeführt werden. Das folgende Beispiel zeigt eine typische Ingress-Ressource:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - http:
      paths:
      - backend:
          service:
            name: my-service
            port:
              number: 80
        path: /foo
        pathType: Prefix

Wenn der Dienst konfiguriert ist, fließt der Netzwerkverkehr durch den istio-ingress-Dienst, dem standardmäßig eine zufällige IP-Adresse aus den in Ihrer MetalLB-Konfiguration angegebenen VIP-Pools zugewiesen wird. Sie können eine bestimmte IP-Adresse oder eine virtuelle IP-Adresse aus der MetalLB-Konfiguration auswählen, indem Sie das Feld loadBalancerIP in der istio-ingress-Dienstdefinition verwenden. Beispiel:

apiVersion: v1
kind: service
metadata:
  labels:
    istio: ingress-gke-system
    release: istio
  name: istio-ingress
  namespace: gke-system
spec:
  loadBalancerIP: <targetLoadBalancerIPaddress>

Diese Funktion ist auf verbundenen Servern von Distributed Cloud nicht verfügbar.

Standardmäßige Distributed Cloud-Ressource `Ingress` deaktivieren

Wenn Sie einen verbundenen Distributed Cloud-Cluster erstellen, konfiguriert Distributed Cloud standardmäßig den istio-ingress-Dienst für den Cluster. Sie haben die Möglichkeit, einen verbundenen Distributed Cloud-Cluster ohne den istio-ingress-Dienst zu erstellen. Führen Sie dazu folgende Schritte aus:

gcloud

Erstellen Sie eine YAML-Konfigurationsdatei mit dem Namen SystemsAddonConfig.yaml und folgendem Inhalt:
```
systemAddonsConfig:
 ingress:
   disabled: true
```
Übergeben Sie die Datei SystemsAddonConfig.yaml mit dem Flag --system-addons-config in Ihrem Befehl zum Erstellen eines Clusters. Sie müssen die gcloud alpha-Version verwenden, um diese Funktion nutzen zu können. Beispiel:
```
gcloud alpha edge-cloud container clusters create MyGDCECluster1 --location us-west1 \
    --system-addons-config=SystemsAddonConfig.yaml
```
Weitere Informationen zum Erstellen eines Distributed Cloud-Clusters finden Sie unter Cluster erstellen.

API

Fügen Sie der JSON-Nutzlast in Ihrer Anfrage zum Erstellen eines Clusters den folgenden JSON-Inhalt hinzu:
```
"systemAddonConfig" {
   "ingress" {
           "disabled": true
   }
}
```
Senden Sie die Anfrage zum Erstellen des Clusters, wie unter Cluster erstellen beschrieben.

NodePort-Dienst

Distributed Cloud Connected unterstützt den Kubernetes-Dienst NodePort, der auf einem Distributed Cloud-Knoten an einem Port Ihrer Wahl auf Verbindungen wartet. Der NodePort-Dienst unterstützt die Protokolle TCP, UDP und SCTP. Beispiel:

apiVersion: v1
kind: pod
metadata:
  name: socat-nodeport-sctp
  labels:
    app.kubernetes.io/name: socat-nodeport-sctp
spec:
  containers:
  - name: socat-nodeport-sctp
    ...
    ports:
      - containerPort: 31333
        protocol: SCTP
        name: server-sctp

---

apiVersion: v1
kind: service
metadata:
  name: socat-nodeport-sctp-svc
spec:
  type: NodePort
  selector:
    app.kubernetes.io/name: socat-nodeport-sctp
  ports:
    - port: 31333
      protocol: SCTP
      targetPort: server-sctp
      nodePort: 31333

SCTP-Unterstützung

Distributed Cloud Connected unterstützt das Stream Control Transmission Protocol (SCTP) auf der primären Netzwerkschnittstelle für interne und externe Netzwerke. Die SCTP-Unterstützung umfasst die Diensttypen NodePort, LoadBalancer und ClusterIP. Pods können SCTP verwenden, um mit anderen Pods und externen Ressourcen zu kommunizieren. Im folgenden Beispiel wird gezeigt, wie Sie IPERF als ClusterIP-Dienst mit SCTP konfigurieren:

apiVersion: v1
kind: pod
metadata:
  name: iperf3-sctp-server-client
  labels:
    app.kubernetes.io/name: iperf3-sctp-server-client
spec:
  containers:
  - name: iperf3-sctp-server
    args: ['-s', '-p 31390']
    ports:
      - containerPort: 31390
        protocol: SCTP
        name: server-sctp
  - name: iperf3-sctp-client
    ...

---

apiVersion: v1
kind: service
metadata:
  name: iperf3-sctp-svc
spec:
  selector:
    app.kubernetes.io/name: iperf3-sctp-server-client
  ports:
    - port: 31390
      protocol: SCTP
      targetPort: server-sctp

Diese Funktion ist auf verbundenen Servern von Distributed Cloud nicht verfügbar.

SCTP-Kernelmodule

Ab Version 1.5.0 konfiguriert Distributed Cloud Connected das sctp-EdgeOS-Kernelmodul als ladbar. So können Sie Ihre eigenen SCTP-Protokollstacks in den Kernel-Userspace laden.

Außerdem lädt Distributed Cloud Connected standardmäßig die folgenden Module in den Kernel:

Modulname	Konfigurationsname
`fou`	`CONFIG_NET_FOU`
`nf_conntrack_proto_gre`	`CONFIG_NF_CT_PROTO_GRE`
`nf_conntrack_proto_sctp`	`CONFIG_NF_CT_PROTO_SCTP`
`inotify`	`CONFIG_INOTIFY_USER`
`xt_redirect`	`CONFIG_NETFILTER_XT_TARGET_REDIRECT`
`xt_u32`	`CONFIG_NETFILTER_XT_MATCH_U32`
`xt_multiport`	`CONFIG_NETFILTER_XT_MATCH_MULTIPORT`
`xt_statistic`	`CONFIG_NETFILTER_XT_MATCH_STATISTIC`
`xt_owner`	`CONFIG_NETFILTER_XT_MATCH_OWNER`
`xt_conntrack`	`CONFIG_NETFILTER_XT_MATCH_CONNTRACK`
`xt_mark`	`CONFIG_NETFILTER_XT_MARK`
`ip6table_mangle`	`CONFIG_IP6_NF_MANGLE`
`ip6_tables`	`CONFIG_IP6_NF_IPTABLES`
`ip6table_filter`	`CONFIG_IP6_NF_FILTER`
`ip6t_reject`	`CONFIG_IP6_NF_TARGET_REJECT`
`iptable_mangle`	`CONFIG_IP_NF_MANGLE`
`ip_tables`	`CONFIG_IP_NF_IPTABLES`
`iptable_filter`	`CONFIG_IP_NF_FILTER`

`ClusterDNS`-Ressource

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

Diese Funktion ist auf verbundenen Servern von Distributed Cloud nicht verfügbar.

Nächste Schritte

Zuweisung von Pod- und Dienstnetzwerkadressen

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

IPv4/IPv6-Dual-Stack-Netzwerk

Distributed Cloud Edge Network API aktivieren

Console

gcloud

Netzwerk in Distributed Cloud Connected konfigurieren

Netzwerkkonfiguration der Distributed Cloud-Zone initialisieren

Netzwerk erstellen

Ein oder mehrere Subnetzwerke erstellen

Northbound-BGP-Peering-Sitzungen erstellen

Southbound-BGP-Peering-Sitzungen erstellen

Optional: Loopback-BGP-Peering-Sitzungen erstellen

Konfiguration testen

Pods mit dem Netzwerk verbinden

Optional: Cluster-Netzwerkisolation konfigurieren

Optional: Inselmodus konfigurieren

Inselmodus konfigurieren

Inselmodus mit dem ClusterIP-Dienst konfigurieren

Load Balancing

Layer-2-Load-Balancing mit MetalLB

Layer-3-Load-Balancing mit Google Distributed Cloud-Load-Balancern

Automatisierung des BGP-Load-Balancing auf Ebene 3 für IPv6-Peering konfigurieren

Layer 3-LoadBalancer-Dienst erstellen

Status der BGP-Sitzung und der Load-Balancing-Dienste prüfen

Distributed Cloud-Ingress

Standardmäßige Distributed Cloud-Ressource Ingress deaktivieren

gcloud

API

NodePort-Dienst

SCTP-Unterstützung

SCTP-Kernelmodule

ClusterDNS-Ressource

Nächste Schritte

Netzwerkfunktionen von Distributed Cloud Connected

Inselmodus mit dem `ClusterIP`-Dienst konfigurieren

Layer 3-`LoadBalancer`-Dienst erstellen

Standardmäßige Distributed Cloud-Ressource `Ingress` deaktivieren

`ClusterDNS`-Ressource