Distributed Cloud-Netzwerkfunktionen

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

Distributed Cloud Edge Network API aktivieren

Bevor Sie Distributed Cloud-Netzwerke konfigurieren können, müssen Sie die Distributed Cloud Edge Network API aktivieren. Führen Sie dazu die Schritte in diesem Abschnitt aus.

Console

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

    API aktivieren

  2. Klicken Sie auf Aktivieren.

gcloud

Verwenden Sie den folgenden Befehl:

gcloud services enable edgenetwork.googleapis.com

Distributed Cloud-Netzwerke konfigurieren

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

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

  1. Optional: Initialisieren Sie bei Bedarf die Netzwerkkonfiguration der Zielzone.

  2. Erstellen Sie ein Netzwerk.

  3. Erstellen Sie ein oder mehrere Subnetze im Netzwerk.

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

  5. Richten Sie mithilfe der entsprechenden Subnetze BGP-Peering-Sitzungen in Richtung Süden mit den Pods ein, auf denen Ihre Arbeitslasten ausgeführt werden.

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

  7. Testen Sie die Konfiguration.

  8. Verbinden Sie Ihre 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 nachdem Ihre Distributed Cloud-Hardware in Ihren Räumlichkeiten installiert wurde.
  • Sie haben auf eine vorhandene Distributed Cloud-Bereitstellung ein Upgrade auf Distributed Cloud Version 1.3.0 oder höher durchgeführt, haben aber nicht an der privaten Vorschau der Distributed Cloud Edge Network API teilgenommen.

Durch die Initialisierung der Netzwerkkonfiguration einer Zone werden ein Standardrouter mit dem Namen default und ein Standardnetzwerk mit dem Namen default erstellt. Außerdem wird der Router default so konfiguriert, dass er ein Peering mit allen Interconnects durchführt, die Sie bei der Bestellung der Distributed Cloud-Hardware angefordert haben, indem entsprechende Interconnect-Anhänge erstellt werden. 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 Subnetz im Netzwerk erstellen, damit Distributed Cloud-Knoten eine Verbindung zum Netzwerk herstellen können.

Ein oder mehrere Subnetze 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 Subnetz entspricht, ist automatisch für alle Knoten in der Zone verfügbar.

BGP-Peering-Sitzungen in Richtung Norden einrichten

Wenn Sie ein Netzwerk und die entsprechenden Subnetze erstellen, sind diese lokal für die Distributed Cloud-Zone. Um ausgehende Verbindungen zu aktivieren, 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. Listen Sie die in Ihrer Zone verfügbaren Interconnects auf und wählen Sie dann den Ziel-Interconnect für diese Peering-Sitzung aus.

  2. Erstellen Sie einen oder mehrere Interconnect-Anhänge für den ausgewählten Interconnect. Interconnect-Anhänge verknüpfen den Router, den Sie im nächsten Schritt erstellen, mit dem ausgewählten Interconnect.

  3. Erstellen Sie einen Router. Dieser Router leitet Traffic zwischen dem Interconnect und Ihrem Netzwerk weiter. Dazu verwendet er die Interconnect-Anhänge, 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 Top-of-Rack-Switches (ToR) in Ihrem Distributed Cloud-Rack. Eine Anleitung finden Sie unter Peering-Sitzung in Richtung Norden einrichten.

  5. Fügen Sie einen Peer hinzu für jede Schnittstelle, die Sie im vorherigen Schritt auf dem Router erstellt haben.

BGP-Peering-Sitzungen in Richtung Süden einrichten

Um eingehende Konnektivität von Ihrem lokalen Netzwerk zu Ihren Arbeitslasten zu ermöglichen, 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 Subnetz ist die IP-Adresse des entsprechenden ToR-Switches in Ihrem Distributed Cloud-Rack.

So richten Sie eine BGP-Peering-Sitzung in Richtung Süden ein:

  1. Fügen Sie dem Router im Zielnetzwerk für jedes Subnetzwerk, das Sie mit eingehender Konnektivität bereitstellen möchten, eine Schnittstelle hinzu. Eine Anleitung finden Sie unter Peering-Sitzung in Richtung Süden 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 einrichten

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-Peering-Sitzung 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 hinzu für die Loopback-Schnittstelle.

Konfiguration testen

So testen Sie die Konfiguration der von Ihnen erstellten Netzwerkkomponenten:

  1. Prüfen Sie den Betriebsstatus des Netzwerks.

  2. Prüfen Sie den Bereitstellungsstatus der einzelnen Subnetze.

  3. Prüfen Sie den Betriebsstatus der Interconnects.

  4. Prüfen Sie den Betriebsstatus der Interconnect-Anhänge.

  5. Prüfen Sie den Betriebsstatus des Routers.

Pods mit dem Netzwerk verbinden

Eine Anleitung zum Verbinden Ihrer Pods mit dem Netzwerk und zum Konfigurieren erweiterter Netzwerkfunktionen finden Sie unter folgen Sie den Anweisungen in 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) für die Außenwelt verfügbar machen:

  1. Ihr Netzwerkadministrator plant die Netzwerktopologie und gibt beim Bestellen von Distributed Cloud das erforderliche virtuelle IPv4-Adress-Subnetz 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-Subnetz 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 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-Subnetz befindet.
  2. 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 LoadBalancer-VIP-Subnetz 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 ConfigMap metallb-config im Namespace metallb-system mit dem Befehl kubectl edit oder kubectl replace bearbeiten. Verwenden Sie nicht den Befehl kubectl apply, 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 Services.

Distributed Cloud-Knoten in einem einzelnen Knotenpool verwenden eine gemeinsame Layer-2-Domain und sind daher auch MetalLB-Load-Balancer-Knoten. Distributed Cloud-Knoten der Steuerungsebene, die auf Google Cloud ausgeführt werden, fungieren nicht als Load-Balancer-Knoten.

Distributed Cloud-Ingress

Neben dem 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 auf Ihren Distributed Cloud-Clustern ausgeführt werden. Das folgende Beispiel veranschaulicht 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 konfiguriert, fließt der Netzwerkverkehr über den Dienst istio-ingress, 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 Dienstdefinition istio-ingress verwenden. Beispiel:

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

Standard-Ingress-Ressource von Distributed Cloud deaktivieren

Wenn Sie einen Distributed Cloud-Cluster erstellen, konfiguriert Distributed Cloud standardmäßig den Dienst istio-ingress für den Cluster. Sie haben die Möglichkeit, einen Distributed Cloud-Cluster ohne den Dienst istio-ingress 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 zur Clustererstellung. Sie müssen die Version gcloud alpha 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 zur Clustererstellung den folgenden JSON-Inhalt hinzu:

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

  2. Senden Sie die Anfrage zur Clustererstellung wie unter Cluster erstellen beschrieben.

SCTP-Unterstützung

Distributed Cloud 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. Das folgende Beispiel veranschaulicht, 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

SCTP-Kernelmodule

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

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

Modulname Name der Konfiguration
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 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