Funzionalità di networking di Distributed Cloud connesso

Questa pagina descrive le funzionalità di networking di Google Distributed Cloud connected, incluse le subnet, le sessioni di peering BGP e il bilanciamento del carico.

Le procedure descritte in questa pagina si applicano solo ai rack Distributed Cloud connesso, ad eccezione del bilanciamento del carico, che si applica sia ai rack Distributed Cloud connesso sia ai server Distributed Cloud connesso.

Networking dual-stack IPv4/IPv6

Distributed Cloud connesso consente di creare cluster che utilizzano il networking dual-stack IPv4/IPv6. Per usufruire di questa funzionalità, devi ordinare Distributed Cloud con la rete dual-stack IPv4/IPv6 abilitata. Non puoi riconfigurare un deployment solo IPv4 esistente di Distributed Cloud connesso al networking a doppio stack IPv4/IPv6. Per verificare se il tuo deployment supporta il networking dual-stack IPv4/IPv6, segui le istruzioni in Recuperare informazioni su una macchina e controlla il valore restituito dell'etichetta dualstack_capable.

In un cluster a doppio stack, lo stack IPv4 utilizza la modalità isola, mentre lo stack IPv6 utilizza la modalità flat. Per questo motivo, devi specificare singoli indirizzi IPv6 di nodi e pod discreti che appartengono alla stessa subnet. Per saperne di più, consulta Modelli di rete in modalità flat e isolata.

Ad esempio, se i nodi connessi a Distributed Cloud e altre macchine locali si trovano nello stesso dominio di livello 2, puoi specificare i blocchi CIDR IPv6 per il cluster nel seguente modo:

Scopo del blocco Intervallo di blocchi Dimensione del blocco
Subnet IPv6 fd12::/56 2^72
Pod fd12::1:0/59 2^69
Servizi fd12::2:0/59 2^69

Questo esempio presuppone quanto segue:

  • I blocchi CIDR di nodi, pod e servizi appartengono alla superrete fd:12::/56.
  • Gli indirizzi IP di nodi, pod e servizi sono subnet del blocco CIDR specificato.
  • Nessuna delle subnet si sovrappone.

Il networking a doppio stack IPv4/IPv6 richiede il bilanciamento del carico di livello 2 per il peering BGP IPv4 e il bilanciamento del carico di livello 3 per il peering IPv6. Per ulteriori informazioni, vedi Bilanciamento del carico.

Per saperne di più sul deployment di workload su cluster dual-stack IPv4/IPv6, consulta quanto segue:

Abilita l'API Distributed Cloud Edge Network

Prima di poter configurare il networking in un deployment connesso di Distributed Cloud, devi abilitare l'API Distributed Cloud Edge Network. Per farlo, completa i passaggi descritti in questa sezione. Per impostazione predefinita, i server Distributed Cloud connesso vengono spediti con l'API Distributed Cloud Edge Network già abilitata.

Console

  1. Nella console Google Cloud , vai alla pagina API Distributed Cloud Edge Network.

    Abilitare l'API

  2. Fai clic su Attiva.

gcloud

Utilizza il seguente comando:

gcloud services enable edgenetwork.googleapis.com

Configura il networking su Distributed Cloud connesso

Questa sezione descrive come configurare i componenti di rete nel deployment connesso a Distributed Cloud.

Ai server Distributed Cloud connesso si applicano le seguenti limitazioni:

  • Puoi configurare solo le subnet e
  • Le subnet supportano solo gli ID VLAN; le subnet basate su CIDR non sono supportate.

Una tipica configurazione di rete per Distributed Cloud Connected è costituita dai seguenti passaggi:

  1. (Facoltativo) Inizializza la configurazione di rete della zona di destinazione, se necessario.

  2. Creare una rete.

  3. Crea una o più subnet all'interno della rete.

  4. Stabilisci sessioni di peering BGP in direzione nord con i router PE utilizzando i collegamenti di interconnessione corrispondenti.

  5. Stabilisci sessioni di peering BGP in direzione sud con i pod che eseguono i tuoi carichi di lavoro utilizzando le subnet corrispondenti.

  6. (Facoltativo) Stabilisci sessioni di peering BGP di loopback per l'alta disponibilità.

  7. Testa la configurazione.

  8. Collega i pod alla rete.

Inizializza la configurazione di rete della zona Distributed Cloud

Devi inizializzare la configurazione di rete della zona connessa a Distributed Cloud immediatamente dopo l'installazione dell'hardware connesso a Distributed Cloud nei tuoi locali. L'inizializzazione della configurazione di rete di una zona è una procedura una tantum.

L'inizializzazione della configurazione di rete di una zona crea un router predefinito denominato default e una rete predefinita denominata default. Configura anche il router default per il peering con tutte le interconnessioni richieste quando hai ordinato l'hardware connesso a Distributed Cloud creando i collegamenti di interconnessione corrispondenti. Questa configurazione fornisce alla tua implementazione connessa a Distributed Cloud una connettività uplink di base alla tua rete locale.

Per le istruzioni, vedi Inizializzare la configurazione di rete di una zona.

Crea una rete

Per creare una nuova rete, segui le istruzioni riportate in Creare una rete. Devi anche creare almeno una subnet all'interno della rete per consentire ai nodi connessi di Distributed Cloud di connettersi alla rete.

Crea una o più subnet

Per creare una subnet, segui le istruzioni riportate in Creare una subnet. Devi creare almeno una subnet nella tua rete per consentire ai nodi di accedere alla rete. La VLAN corrispondente a ogni subnet che crei è disponibile automaticamente per tutti i nodi nella zona.

Per i server connessi a Distributed Cloud, puoi configurare solo le subnet utilizzando gli ID VLAN. Le subnet basate su CIDR non sono supportate.

Definisci sessioni di peering BGP in direzione nord

Quando crei una rete e le relative sottoreti, queste sono locali alla zona connessa a Distributed Cloud. Per attivare la connettività in uscita, devi stabilire almeno una sessione di peering BGP in direzione nord tra la rete e i router di peering perimetrali.

Per stabilire una sessione di peering BGP in direzione nord:

  1. Elenca gli interconnessioni disponibili nella tua zona e poi seleziona l'interconnessione di destinazione per questa sessione di peering.

  2. Crea uno o più allegati di interconnessione sull'interconnessione selezionata. Gli allegati di interconnessione collegano il router che crei nel passaggio successivo all'interconnessione selezionata.

  3. Crea un router. Questo router instrada il traffico tra l'interconnessione e la tua rete utilizzando i collegamenti di interconnessione che hai creato nel passaggio precedente.

  4. Aggiungi un'interfaccia al router per ogni collegamento di interconnessione che hai creato in precedenza in questa procedura. Per ogni interfaccia, utilizza l'indirizzo IP dello switch top-of-rack (ToR) corrispondente nel rack connesso a Distributed Cloud. Per le istruzioni, vedi Stabilire una sessione di peering in direzione nord.

  5. Aggiungi un peer per ogni interfaccia creata sul router nel passaggio precedente.

Stabilisci sessioni di peering BGP in uscita

Per attivare la connettività in entrata ai tuoi carichi di lavoro dalla tua rete locale, devi stabilire una o più sessioni di peering BGP in direzione sud tra i tuoi router di peering edge e la subnet a cui appartengono i tuoi pod. L'indirizzo IP del gateway per ogni subnet è l'indirizzo IP dello switch ToR corrispondente nel rack connesso a Distributed Cloud.

Per stabilire una sessione di peering BGP in direzione sud:

  1. Aggiungi un'interfaccia al router nella rete di destinazione per ogni subnet che vuoi eseguire il provisioning con connettività in entrata. Per istruzioni, vedi Stabilire una sessione di peering in uscita.

  2. Aggiungi un peer per ogni interfaccia creata sul router nel passaggio precedente.

(Facoltativo) Stabilisci sessioni di peering BGP di loopback

Per abilitare la connettività ad alta disponibilità tra i tuoi carichi di lavoro e la tua rete locale, puoi stabilire una sessione di peering BGP di loopback tra il pod di destinazione e entrambi gli switch ToR nel rack connesso a Distributed Cloud. Una sessione di peering loopback stabilisce due sessioni di peering indipendenti per il pod, una con ogni switch ToR.

Per stabilire una sessione di peering BGP di loopback:

  1. Aggiungi un'interfaccia di loopback al router nella rete di destinazione. Per istruzioni, vedi Stabilire una sessione di peering di loopback.

  2. Aggiungi un peer per l'interfaccia di loopback.

Test della configurazione

Per testare la configurazione dei componenti di rete che hai creato, segui questi passaggi:

  1. Controlla lo stato operativo della rete.

  2. Controlla lo stato del provisioning di ogni subnet.

  3. Controlla lo stato di attività delle interconnessioni.

  4. Controlla lo stato operativo degli allegati di interconnessione.

  5. Controlla lo stato operativo del router.

Connettere i pod alla rete

Per connettere i pod alla rete e configurare le funzioni di rete avanzate, segui le istruzioni riportate in Operatore di funzioni di rete. Questa funzionalità non è disponibile per i workload delle macchine virtuali.

(Facoltativo) Configurare l'isolamento della rete del cluster

Distributed Cloud connected supporta l'isolamento della rete del cluster. I nodi assegnati a un cluster isolato dalla rete non possono comunicare con altri nodi all'interno della stessa zona connessa a Distributed Cloud. Per abilitare l'isolamento della rete del cluster, utilizza il flag --enable-cluster-isolation durante la creazione o la modifica di un cluster. Per saperne di più, consulta Creare e gestire cluster.

(Facoltativo) Configurare la modalità Isola

Distributed Cloud connesso supporta la modalità isolata per il sottosistema di rete virtuale. La modalità isolata consente di specificare un intervallo di indirizzi IP isolato sull'interfaccia di rete secondaria di un pod. Questo intervallo di indirizzi isolato è indipendente dall'intervallo di indirizzi della VLAN dell'interfaccia di rete principale. Ai pod configurati per la modalità isolata vengono assegnati solo indirizzi di questo intervallo di indirizzi "isolato". Per saperne di più, consulta Modelli di rete flat e isolati.

L'intervallo di indirizzi IP isolato che specifichi per la modalità isolata non deve entrare in conflitto con i seguenti intervalli di indirizzi IP:

  • Il CIDR VLAN principale per qualsiasi rete configurata nel cluster
  • L'intervallo di indirizzi IP virtuali del bilanciatore del carico specificato nell'annotazione networking.gke.io/gdce-lb-service-vip-cidrs nella risorsa Network
  • Gli intervalli di indirizzi IP utilizzati per la modalità isolata per qualsiasi altra rete nel cluster

Configurare la modalità Isola

Per configurare la modalità isolata a livello di pod, aggiungi l'annotazione networking.gke.io/gdce-pod-cidr alla risorsa personalizzata Network corrispondente. Imposta il valore dell'annotazione sull'intervallo di indirizzi IP isolati di destinazione e applica la risorsa Network modificata al tuo cluster. Ad esempio:

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

Devi anche impostare i seguenti parametri:

  • type deve essere impostato su L3.
  • IPAMMode deve essere impostato su Internal.

Ad esempio:

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

Per verificare che la modalità Isola sia abilitata:

  1. Crea un pod di test e applicalo al cluster. Ad esempio:

    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"]

  2. Recupera l'indirizzo IP del pod:

    kubectl get pod island-pod-tester -o wide

    Il comando restituisce l'indirizzo IP del pod, che rientra nell'intervallo di indirizzi isolato che hai specificato.

Configurare la modalità Isola con il servizio ClusterIP

Per configurare la modalità isolata con il servizio ClusterIP, completa i passaggi della sezione precedente, poi aggiungi l'annotazione networking.gke.io/gke-gateway-clusterip-cidr alla risorsa Network e imposta il relativo valore in base alle tue esigenze aziendali. Gli intervalli di indirizzi specificati nella risorsa Network non devono sovrapporsi. Ad esempio:

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

Bilanciamento del carico

Distributed Cloud connesso viene fornito con le seguenti soluzioni di bilanciamento del carico:

  • Bilanciamento del carico di livello 2 con MetalLB
  • Bilanciamento del carico di livello 3 con i bilanciatori del carico Google Distributed Cloud

Le soluzioni di bilanciamento del carico integrate in Distributed Cloud Connected non possono utilizzare prefissi IP virtuali del servizio Kubernetes sovrapposti. Se hai un deployment connesso di Distributed Cloud esistente che utilizza il bilanciamento del carico MetalLB di livello 2 e vuoi passare al bilanciamento del carico di livello 3 con i bilanciatori del carico Google Distributed Cloud, devi utilizzare un prefisso IP virtuale del servizio che non si sovrapponga al prefisso utilizzato dalla configurazione del bilanciamento del carico MetalLB di livello 2.

Bilanciamento del carico di livello 2 con MetalLB

Distributed Cloud viene fornito con una soluzione di bilanciamento del carico di rete in bundle basata su MetalLB in modalità Layer 2. Puoi utilizzare questa soluzione per esporre i servizi eseguiti nella tua zona Distributed Cloud al mondo esterno utilizzando indirizzi IP virtuali (VIP) nel seguente modo:

  1. L'amministratore di rete pianifica la topologia di rete e specifica la subnet di indirizzi IPv4 e IPv6 virtuali richiesta al momento dell'ordine di Distributed Cloud. Google configura l'hardware Distributed Cloud di conseguenza prima della consegna. Tieni presente quanto segue:
    • Questa subnet VIP è condivisa tra tutti i cluster Kubernetes in esecuzione all'interno della zona Distributed Cloud.
    • Una route per la subnet VIP richiesta viene pubblicizzata tramite le sessioni BGP tra la zona Distributed Cloud e la tua rete locale.
    • Il primo (ID rete), il secondo (gateway predefinito) e l'ultimo (indirizzo di broadcast) indirizzo della subnet sono riservati per la funzionalità di base del sistema. Non assegnare questi indirizzi ai pool di indirizzi delle configurazioni di MetalLB.
    • Ogni cluster deve utilizzare un intervallo VIP separato che rientri nella subnet VIP configurata.
  2. Quando crei un cluster nella tua zona Distributed Cloud, l'amministratore del cluster specifica i pool di indirizzi dei servizi pod e ClusterIP utilizzando la notazione CIDR. L'amministratore di rete fornisce la subnet VIP LoadBalancer appropriata all'amministratore del cluster.

  3. Dopo la creazione del cluster, l'amministratore del cluster configura i pool VIP corrispondenti. Quando crei il cluster, devi specificare i pool VIP utilizzando il flag --external-lb-address-pools. Il flag accetta un file con un payload YAML o JSON nel seguente formato:

     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

    Per specificare un pool di indirizzi VIP, fornisci le seguenti informazioni nel payload:

    • name: un nome descrittivo che identifica in modo univoco questo pool di indirizzi VIP.
    • addresses: un elenco di indirizzi IPv4 e IPv6, intervalli di indirizzi e subnet da includere in questo pool di indirizzi.
    • avoid_buggy_ips: esclude gli indirizzi IP che terminano con .0 o .255.
    • manual_assign: consente di assegnare manualmente gli indirizzi di questo pool nella configurazione del servizio LoadBalancer di destinazione anziché farli assegnare automaticamente dal controller MetalLB.

    Per ulteriori informazioni sulla configurazione dei pool di indirizzi VIP, consulta Specifica i pool di indirizzi nella documentazione di MetalLB.

  4. L'amministratore del cluster crea i servizi Kubernetes LoadBalancer appropriati.

I nodi Distributed Cloud in un singolo pool di nodi condividono un dominio di livello 2 comune e sono quindi anche nodi del bilanciatore del carico MetalLB.

Bilanciamento del carico di livello 3 con i bilanciatori del carico Google Distributed Cloud

Distributed Cloud connected viene fornito con una soluzione di bilanciamento del carico di rete in bundle basata sui bilanciatori del carico in bundle di Google Distributed Cloud in modalità Layer 3 configurati come speaker BGP. Puoi utilizzare questa soluzione per esporre i servizi eseguiti nella zona connessa di Distributed Cloud al mondo esterno utilizzando VIP.

Puoi specificare gli intervalli VIP per i servizi LoadBalancer corrispondenti utilizzando ConfigMap metallb-config. Ad esempio:

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

Nell'esempio precedente, a ogni servizio LoadBalancer che configuri viene assegnato automaticamente un indirizzo IP virtuale dall'intervallo 10.100.10.66/27 specificato in ConfigMap. Questi VIP vengono poi pubblicizzati in direzione nord dai peer BGP di Distributed Cloud configurati sugli switch ToR tramite le risorse BGPPeer.

Quando crei un cluster Distributed Cloud, le seguenti risorse vengono create automaticamente su quel cluster:

  • Una risorsa BGPLoadBalancer che crea un'istanza del bilanciatore del carico BGP.
  • Una risorsa NetworkGatewayGroup che specifica gli indirizzi IP mobili locali da utilizzare per i peer BGP. Questi indirizzi IP vengono impostati automaticamente sugli ultimi due indirizzi IP della subnet del nodo Kubernetes assegnata al cluster.

Con queste risorse in posizione, puoi configurare le sessioni BGP per gli switch ToR di Distributed Cloud configurando le risorse BGPPeer corrispondenti. Per farlo, devi disporre dei numeri di sistema autonomo (ASN) necessari e degli indirizzi IP peer loopback per gli switch ToR. Questi indirizzi IP fungono da endpoint della sessione BGP dello switch ToR nella risorsa di rete predefinita. Tieni presente che il valore del parametro network deve essere pod-network.

Di seguito è riportato un esempio delle due risorse BGPPeer:

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

Configurare l'automazione del bilanciamento del carico BGP di livello 3 per il peering IPv6

Prima di poter iniziare a utilizzare il peering IPv6 sul cluster di rete dual-stack IPv4/IPv6, devi collaborare con l'assistenza Google per abilitare l'automazione del bilanciamento del carico di Google Distributed Cloud nel deployment di Distributed Cloud connesso.

Crea servizio LoadBalancer di livello 3

Dopo aver abilitato l'automazione del bilanciatore del carico Google Distributed Cloud nel deployment di Distributed Cloud connesso, crea un'istanza del servizio LoadBalancer di livello 3. Ad esempio:

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

Controlla lo stato della sessione BGP e dei servizi di bilanciamento del carico

Per controllare lo stato della sessione BGP, utilizza il seguente comando:

kubectl get bgpsessions.networking.gke.io -A

Il comando restituisce un output simile al seguente esempio:

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

Per verificare che i tuoi servizi LoadBalancer vengano pubblicizzati dagli speaker BGP, utilizza questo comando:

kubectl get bgpadvertisedroutes.networking.gke.io -A

Il comando restituisce un output simile al seguente esempio:

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

Ingresso di Distributed Cloud

Oltre al bilanciamento del carico, Distributed Cloud Connected supporta anche le risorse Kubernetes Ingress. Una risorsa Ingress Kubernetes controlla il flusso di traffico HTTP(S) verso i servizi Kubernetes eseguiti sui cluster connessi a Distributed Cloud. L'esempio seguente mostra una risorsa Ingress tipica:

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

Se configurato, il traffico di rete passa attraverso il servizio istio-ingress, a cui per impostazione predefinita viene assegnato un indirizzo IP casuale dai pool VIP specificati nella configurazione di MetalLB. Puoi selezionare un indirizzo IP specifico o un indirizzo IP virtuale dalla configurazione di MetalLB utilizzando il campo loadBalancerIP nella definizione del servizio istio-ingress. Ad esempio:

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

Questa funzionalità non è disponibile sui server connessi di Distributed Cloud.

Disattiva la risorsa Distributed Cloud Ingress predefinita

Per impostazione predefinita, quando crei un cluster connesso a Distributed Cloud, Distributed Cloud configura automaticamente il servizio istio-ingress per il cluster. Hai la possibilità di creare un cluster connesso Distributed Cloud senza il servizio istio-ingress. Per farlo, segui questa procedura.

gcloud

  1. Crea un file di configurazione YAML denominato SystemsAddonConfig.yaml con il seguente contenuto:

    systemAddonsConfig:
 ingress:
   disabled: true

  2. Passa il file SystemsAddonConfig.yaml utilizzando il flag --system-addons-config nel comando di creazione del cluster. Per utilizzare questa funzionalità, devi utilizzare la versione gcloud alpha. Ad esempio:

    gcloud alpha edge-cloud container clusters create MyGDCECluster1 --location us-west1 \
    --system-addons-config=SystemsAddonConfig.yaml

    Per saperne di più sulla creazione di un cluster Distributed Cloud, consulta Crea un cluster.

API

  1. Aggiungi i seguenti contenuti JSON al payload JSON nella richiesta di creazione del cluster:

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

  2. Invia la richiesta di creazione del cluster come descritto in Creare un cluster.

Servizio NodePort

Distributed Cloud connette il servizio Kubernetes NodePort che ascolta le connessioni su un nodo Distributed Cloud a un numero di porta a tua scelta. Il servizio NodePort supporta i protocolli TCP, UDP e SCTP. Ad esempio:

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

Supporto SCTP

Distributed Cloud connected supporta lo Stream Control Transmission Protocol (SCTP) sull'interfaccia di rete principale per il networking interno ed esterno. Il supporto di SCTP include i tipi di servizio NodePort, LoadBalancer e ClusterIP. I pod possono utilizzare SCTP per comunicare con altri pod e risorse esterne. L'esempio seguente illustra come configurare IPERF come servizio ClusterIP utilizzando SCTP:

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

Questa funzionalità non è disponibile sui server connessi di Distributed Cloud.

Moduli kernel SCTP

A partire dalla versione 1.5.0, Distributed Cloud connected configura il modulo del kernel del sistema operativo sctp Edge come caricabile. In questo modo puoi caricare i tuoi stack di protocolli SCTP nello spazio utente del kernel.

Inoltre, Distributed Cloud connected carica i seguenti moduli nel kernel per impostazione predefinita:

Nome modulo Nome configurazione
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 risorsa

Distributed Cloud connesso supporta la risorsa Google Distributed Cloud ClusterDNS per configurare i server dei nomi upstream per domini specifici utilizzando la sezione spec.domains. Per ulteriori informazioni sulla configurazione di questa risorsa, consulta spec.domains.

Questa funzionalità non è disponibile sui server connessi di Distributed Cloud.

Passaggi successivi