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

  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

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:

  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 BGP-Peering-Sitzungen in Richtung Süden mit den Pods ein, in denen Ihre Arbeitslasten ausgeführt werden, indem Sie die entsprechenden Subnetzwerke verwenden.

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

  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 mit Distributed Cloud verbundenen Zone in den folgenden Fällen initialisieren:

  • Unmittelbar nach der Installation Ihrer mit Distributed Cloud verbundenen Hardware in Ihren Räumlichkeiten.
  • Sie haben ein Upgrade auf Distributed Cloud Connected Version 1.3.0 oder höher in einer vorhandenen Distributed Cloud Connected-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 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.

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 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:

  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 mit Distributed Cloud verbundenen 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 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:

  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 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:

  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 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:

  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 der 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. Sie müssen 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.

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

  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.

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