Distributed Cloud-Netzwerkfunktionen

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

Die Verfahren auf dieser Seite gelten nur für Distributed Cloud-Racks, mit Ausnahme des Lastenausgleichs, der sowohl für Distributed Cloud-Racks als auch für Distributed Cloud-Netzwerkserver gilt.

Distributed Cloud Edge Network API aktivieren

Bevor Sie das Distributed Cloud-Netzwerk konfigurieren 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-Server mit der bereits aktivierten Distributed Cloud Edge Network API ausgeliefert.

Console

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

    API aktivieren

  2. Klicken Sie auf Aktivieren.

gcloud

Verwenden Sie den folgenden Befehl:

gcloud services enable edgenetwork.googleapis.com

Distributed Cloud-Netzwerk konfigurieren

In diesem Abschnitt wird beschrieben, wie Sie die Netzwerkkomponenten von Distributed Cloud konfigurieren.

Für Distributed Cloud Servers 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 besteht aus den folgenden Schritten:

  1. Optional: Initialisieren Sie die Netzwerkkonfiguration der Zielzone, falls erforderlich.

  2. Netzwerk erstellen

  3. Erstellen Sie ein oder mehrere Subnetzwerke im Netzwerk.

  4. Richten Sie BGP-Peering-Sitzungen in Richtung Norden mit Ihren PE-Routern ein. Verwenden Sie dazu die entsprechenden Interconnect-Anhänge.

  5. Richten Sie Southbound-BGP-Peering-Sitzungen mit den Pods ein, in denen Ihre Arbeitslasten ausgeführt werden. Verwenden Sie dazu die entsprechenden Subnetzwerke.

  6. Optional: Erstellen Sie Loopback-BGP-Peering-Sitzungen für Hochverfügbarkeit.

  7. Testen Sie die Konfiguration.

  8. Verbinde deine Pods mit dem Netzwerk.

Optional: Netzwerkkonfiguration der Distributed Cloud-Zone initialisieren

Sie müssen die Netzwerkkonfiguration Ihrer Distributed Cloud-Zone in den folgenden Fällen initialisieren:

  • Unmittelbar nach der Installation Ihrer Distributed Cloud-Hardware in Ihren Räumlichkeiten.
  • Sie haben ein Upgrade auf Distributed Cloud-Version 1.3.0 oder höher in einer vorhandenen Distributed Cloud-Bereitstellung durchgeführt, haben aber nicht an der privaten Vorschau der Distributed Cloud Edge Network API teilgenommen.

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-Hardware angefordert haben, eine Peer-Beziehung eingeht. Dazu werden entsprechende Interconnect-Anhänge erstellt. Diese Konfiguration bietet Ihrer Distributed Cloud-Bereitstellung eine grundlegende Uplink-Verbindung zu Ihrem lokalen Netzwerk.

Die Initialisierung der Netzwerkkonfiguration einer Zone ist ein einmaliger Vorgang. Eine vollständige 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 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 Distributed Cloud-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 sie lokal für die Distributed Cloud-Zone. 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:

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

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

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

  4. 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 Distributed Cloud-Rack. Eine Anleitung finden Sie unter Northbound-Peering-Sitzung einrichten.

  5. 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 BGP-Peering-Sitzungen in Richtung Süden 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 Distributed Cloud-Rack.

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

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

  2. 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 Distributed Cloud-Rack einrichten. Bei einer Loopback-Peering-Sitzung werden zwei unabhängige Peering-Sitzungen für den Pod eingerichtet, eine mit jedem ToR-Switch.

So richten Sie eine Loopback-BGP-Peeringsitzung ein:

  1. Fügen Sie dem Router im Zielnetzwerk eine Loopback-Schnittstelle hinzu. Eine Anleitung finden Sie unter Loopback-Peering-Sitzung einrichten.

  2. Fügen Sie einen Peer für die Loopback-Schnittstelle hinzu.

Konfiguration testen

So testen Sie die Konfiguration der von Ihnen erstellten Netzwerkkomponenten:

  1. Prüfe den Betriebsstatus des Netzwerks.

  2. Bereitstellungsstatus der einzelnen Subnetzwerke prüfen

  3. Betriebsstatus der Interconnects prüfen:

  4. Betriebsstatus der Interconnect-Anhänge prüfen

  5. Betriebsstatus des Routers prüfen

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.

Load Balancing

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:

  1. 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-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.
  2. Wenn Sie einen Cluster in Ihrer Distributed Cloud-Zone erstellen, gibt Ihr Clusteradministrator die Pod- und ClusterIP-Dienstadresspools in CIDR-Notation an. Ihr Netzwerkadministrator stellt dem Clusteradministrator das entsprechende LoadBalancer-VIP-Subnetzwerk zur Verfügung.

  3. Nachdem der Cluster erstellt wurde, konfiguriert der Clusteradministrator die entsprechenden VIP-Pools. Bei Clustern mit Remote-Steuerungsebene müssen Sie die metallb-config-ConfigMap im metallb-system-Namespace mit dem Befehl kubectl edit oder kubectl replace bearbeiten. Verwenden Sie den Befehl kubectl apply nicht, da Distributed Cloud Ihre Änderungen sonst überschreibt.

    Das folgende Beispiel veranschaulicht eine solche Konfiguration:

    # metallb-config.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  namespace: metallb-system
  name: metallb-config
data:
  config: |
    address-pools:
    - name: default
      protocol: layer2
      addresses:
      - 192.168.1.2-192.168.1.254

    Bei Clustern mit lokaler Steuerungsebene müssen Sie die VIP-Pools beim Erstellen des Clusters mit dem Flag --external-lb-ipv4-address-pools angeben. Weitere Informationen finden Sie unter Überlebensmodus.

  4. 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. Distributed Cloud-Knoten der Steuerungsebene, die aufGoogle Cloud ausgeführt werden, fungieren nicht als Load-Balancer-Knoten.

Distributed Cloud-Ingress

Zusätzlich zum Load Balancing unterstützt Distributed Cloud auch Kubernetes-Ingress-Ressourcen. Eine Kubernetes-Ingress-Ressource steuert den Fluss von HTTP(S)-Traffic zu Kubernetes-Diensten, die in Ihren Distributed Cloud-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 istio-ingress-Dienst konfiguriert ist, fließt der Netzwerk-Traffic durch ihn. Ihm wird standardmäßig eine zufällige IP-Adresse aus den in Ihrer MetalLB-Konfiguration angegebenen VIP-Pools zugewiesen. 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 Distributed Cloud-Servern nicht verfügbar.

Standardmäßige Distributed Cloud-Ressource Ingress deaktivieren

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

gcloud

  1. Erstellen Sie eine YAML-Konfigurationsdatei mit dem Namen SystemsAddonConfig.yaml und folgendem Inhalt:

    systemAddonsConfig:
 ingress:
   disabled: true

  2. Ü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

  1. Fügen Sie der JSON-Nutzlast in Ihrer Anfrage zum Erstellen eines Clusters den folgenden JSON-Inhalt hinzu:

    "systemAddonConfig" {
   "ingress" {
           "disabled": true
   }
}

  2. Senden Sie die Anfrage zum Erstellen des Clusters, wie unter Cluster erstellen beschrieben.

SCTP-Unterstützung

Distributed Cloud unterstützt das Stream Control Transmission Protocol (SCTP) auf der primären Netzwerkschnittstelle sowohl für interne als auch für 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 Distributed Cloud-Servern nicht verfügbar.

SCTP-Kernelmodule

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

Außerdem lädt Distributed Cloud 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 unterstützt die Google Distributed Cloud-Ressource ClusterDNS zum Konfigurieren von Upstream-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 Distributed Cloud-Servern nicht verfügbar.

Nächste Schritte