Pour en savoir plus sur les versions, consultez les notes de version de Distributed Cloud connecté.

Fonctionnalités Mise en réseau de Distributed Cloud connecté

Cette page décrit les fonctionnalités réseau de Google Distributed Cloud connecté, y compris les sous-réseaux, les sessions d'appairage BGP et l'équilibrage de charge.

Les procédures de cette page ne s'appliquent qu'aux racks Distributed Cloud connected, à l'exception de l'équilibrage de charge, qui s'applique à la fois aux racks Distributed Cloud connected et aux serveurs Distributed Cloud connected.

Mise en réseau de la double pile IPv4/IPv6

Distributed Cloud Connected vous permet de créer des clusters qui utilisent la mise en réseau à double pile IPv4/IPv6. Pour profiter de cette fonctionnalité, vous devez commander Distributed Cloud avec la mise en réseau à double pile IPv4/IPv6 activée. Vous ne pouvez pas reconfigurer un déploiement Distributed Cloud existant en mode IPv4 uniquement connecté à une mise en réseau à double pile IPv4/IPv6. Pour vérifier si votre déploiement est compatible avec la mise en réseau à double pile IPv4/IPv6, suivez les instructions de la section Obtenir des informations sur une machine et vérifiez la valeur renvoyée du libellé dualstack_capable.

Dans un cluster à double pile, la pile IPv4 utilise le mode île, tandis que la pile IPv6 utilise le mode plat. Par conséquent, vous devez spécifier des adresses IPv6 de nœud et de pod individuelles et distinctes appartenant au même sous-réseau. Pour en savoir plus, consultez Modèles réseau en mode plat ou en mode île.

Par exemple, si vos nœuds connectés Distributed Cloud et d'autres machines locales résident dans le même domaine de couche 2, vous pouvez spécifier vos blocs CIDR IPv6 pour le cluster comme suit :

Objectif du bloc	Plage de blocs	Taille des blocs
Sous-réseau IPv6	fd12::/56	2^72
Pods	fd12::1:0/59	2^69
Services	fd12::2:0/59	2^69

Cet exemple suppose ce qui suit :

Les blocs CIDR de nœud, de pod et de service appartiennent au superréseau fd:12::/56.
Les adresses IP des nœuds, des pods et des services sont des sous-réseaux du bloc CIDR spécifié.
Aucun sous-réseau ne se chevauche.

La mise en réseau à double pile IPv4/IPv6 nécessite un équilibrage de charge de couche 2 pour le peering BGP IPv4 et un équilibrage de charge de couche 3 pour le peering IPv6. Pour en savoir plus, consultez Équilibrage de charge.

Pour en savoir plus sur le déploiement de charges de travail sur des clusters à double pile IPv4/IPv6, consultez les ressources suivantes :

Activer l'API Distributed Cloud Edge Network

Avant de pouvoir configurer la mise en réseau sur un déploiement connecté de Distributed Cloud, vous devez activer l'API Distributed Cloud Edge Network. Pour ce faire, suivez les étapes décrites dans cette section. Par défaut, les serveurs Distributed Cloud connected sont fournis avec l'API Distributed Cloud Edge Network déjà activée.

Console

Dans la console Google Cloud , accédez à la page API Distributed Cloud Edge Network.

Activer l'API
Cliquez sur Activer.

gcloud

Exécutez la commande suivante :

gcloud services enable edgenetwork.googleapis.com

Configurer le réseau sur Distributed Cloud connecté

Cette section explique comment configurer les composants réseau de votre déploiement Distributed Cloud connecté.

Les limites suivantes s'appliquent aux serveurs connectés Distributed Cloud :

Vous ne pouvez configurer que les sous-réseaux.
Les sous-réseaux ne sont compatibles qu'avec les ID de VLAN. Les sous-réseaux basés sur le CIDR ne sont pas compatibles.

Une configuration réseau typique pour Distributed Cloud Connected comprend les étapes suivantes :

Facultatif : Si nécessaire, initialisez la configuration réseau de la zone cible.
Créer un réseau.
Créez un ou plusieurs sous-réseaux dans le réseau.
Établissez des sessions d'appairage BGP vers le nord avec vos routeurs PE à l'aide des rattachements d'interconnexion correspondants.
Établissez des sessions d'appairage BGP southbound avec les pods qui exécutent vos charges de travail en utilisant les sous-réseaux correspondants.
Facultatif : Établissez des sessions d'appairage BGP de bouclage pour la haute disponibilité.
Testez la configuration.
Connectez vos pods au réseau.

Initialiser la configuration réseau de la zone Distributed Cloud

Vous devez initialiser la configuration réseau de votre zone connectée Distributed Cloud immédiatement après l'installation de votre matériel connecté Distributed Cloud dans vos locaux. L'initialisation de la configuration réseau d'une zone est une procédure ponctuelle.

L'initialisation de la configuration réseau d'une zone crée un routeur par défaut nommé default et un réseau par défaut nommé default. Il configure également le routeur default pour qu'il s'associe à toutes les interconnexions que vous avez demandées lorsque vous avez commandé le matériel connecté Distributed Cloud en créant les rattachements d'interconnexion correspondants. Cette configuration fournit à votre déploiement connecté Distributed Cloud une connectivité d'accès de base à votre réseau local.

Pour obtenir des instructions, consultez Initialiser la configuration réseau d'une zone.

Créer un réseau

Pour créer un réseau, suivez les instructions de la section Créer un réseau. Vous devez également créer au moins un sous-réseau dans le réseau pour permettre aux nœuds connectés Distributed Cloud de se connecter au réseau.

Créer un ou plusieurs sous-réseaux

Pour créer un sous-réseau, suivez les instructions de la section Créer un sous-réseau. Vous devez créer au moins un sous-réseau dans votre réseau pour permettre aux nœuds d'y accéder. Le VLAN correspondant à chaque sous-réseau que vous créez est automatiquement disponible pour tous les nœuds de la zone.

Pour les serveurs connectés Distributed Cloud, vous ne pouvez configurer les sous-réseaux qu'à l'aide d'ID de VLAN. Les sous-réseaux basés sur le CIDR ne sont pas acceptés.

Établir des sessions d'appairage BGP vers le nord

Lorsque vous créez un réseau et ses sous-réseaux correspondants, ils sont locaux à leur zone connectée Distributed Cloud. Pour activer la connectivité sortante, vous devez établir au moins une session d'appairage BGP vers le nord entre le réseau et vos routeurs Edge d'appairage.

Pour établir une session d'appairage BGP vers le nord, procédez comme suit :

Listez les interconnexions disponibles dans votre zone, puis sélectionnez l'interconnexion cible pour cette session d'appairage.
Créez un ou plusieurs rattachements d'interconnexion sur l'interconnexion sélectionnée. Les rattachements d'interconnexion associent le routeur que vous allez créer à l'étape suivante à l'interconnexion sélectionnée.
Créez un routeur. Ce routeur achemine le trafic entre l'interconnexion et votre réseau à l'aide des rattachements d'interconnexion que vous avez créés à l'étape précédente.
Ajoutez une interface au routeur pour chaque rattachement d'interconnexion que vous avez créé précédemment dans cette procédure. Pour chaque interface, utilisez l'adresse IP du commutateur ToR (top-of-rack) correspondant dans votre rack connecté Distributed Cloud. Pour obtenir des instructions, consultez Établir une session d'appairage northbound.
Ajoutez un pair pour chaque interface que vous avez créée sur le routeur à l'étape précédente.

Établir des sessions d'appairage BGP en direction sud

Pour activer la connectivité entrante à vos charges de travail depuis votre réseau local, vous devez établir une ou plusieurs sessions de peering BGP vers le sud entre vos routeurs de périphérie de peering et le sous-réseau auquel appartiennent vos pods. L'adresse IP de la passerelle pour chaque sous-réseau correspond à l'adresse IP du commutateur ToR correspondant dans le rack connecté à Distributed Cloud.

Pour établir une session d'appairage BGP en direction sud :

Ajoutez une interface au routeur dans le réseau cible pour chaque sous-réseau que vous souhaitez provisionner avec une connectivité entrante. Pour obtenir des instructions, consultez Établir une session d'appairage southbound.
Ajoutez un pair pour chaque interface que vous avez créée sur le routeur à l'étape précédente.

Facultatif : Établir des sessions de peering BGP en boucle

Pour activer une connectivité à haute disponibilité entre vos charges de travail et votre réseau local, vous pouvez établir une session d'appairage BGP en boucle entre le pod cible et les deux commutateurs ToR de votre rack connecté Distributed Cloud. Une session d'appairage en boucle établit deux sessions d'appairage indépendantes pour le pod, une avec chaque commutateur ToR.

Pour établir une session d'appairage BGP en boucle, procédez comme suit :

Ajoutez une interface de bouclage au routeur du réseau cible. Pour obtenir des instructions, consultez la section Établir une session d'appairage en boucle.
Ajoutez un pair pour l'interface de bouclage.

Tester votre configuration

Pour tester la configuration des composants réseau que vous avez créés, procédez comme suit :

Connecter vos pods au réseau

Pour connecter vos pods au réseau et configurer des fonctions réseau avancées, suivez les instructions de l'opérateur de fonction réseau. Cette fonctionnalité n'est pas disponible pour les charges de travail des machines virtuelles.

(Facultatif) Configurer l'isolation du réseau du cluster

Distributed Cloud connecté est compatible avec l'isolation du réseau de clusters. Les nœuds attribués à un cluster isolé du réseau ne peuvent communiquer avec aucun autre nœud de la même zone connectée Distributed Cloud. Pour activer l'isolation du réseau de cluster, utilisez l'option --enable-cluster-isolation lorsque vous créez ou modifiez un cluster. Pour en savoir plus, consultez Créer et gérer des clusters.

(Facultatif) Configurer le mode île

Distributed Cloud connected est compatible avec le mode île pour son sous-système de mise en réseau virtuelle. Le mode île vous permet de spécifier une plage d'adresses IP isolée sur l'interface réseau secondaire d'un pod. Cette plage d'adresses isolée est indépendante de la plage d'adresses du VLAN de l'interface réseau principale. Les pods configurés pour le mode île ne se voient attribuer que des adresses provenant de cette plage d'adresses "île" isolée. Pour en savoir plus, consultez Modèles réseau en mode plat ou en mode île.

La plage d'adresses IP isolée que vous spécifiez pour le mode Île ne doit pas entrer en conflit avec les plages d'adresses IP suivantes :

Plage CIDR du VLAN principal pour tout réseau configuré dans le cluster
Plage d'adresses IP virtuelles de l'équilibreur de charge spécifiée dans l'annotation networking.gke.io/gdce-lb-service-vip-cidrs de la ressource Network
Plages d'adresses IP utilisées pour le mode île pour les autres réseaux du cluster

Configurer le mode Île

Pour configurer le mode Île au niveau du pod, ajoutez l'annotation networking.gke.io/gdce-pod-cidr à la ressource personnalisée Network correspondante. Définissez la valeur de l'annotation sur la plage d'adresses IP isolées cibles et appliquez la ressource Network modifiée à votre cluster. Exemple :

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

Vous devez également définir les paramètres suivants :

type doit être défini sur L3.
IPAMMode doit être défini sur Internal.

Exemple :

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

Pour vérifier que le mode Île est activé, procédez comme suit :

Créez un pod de test et appliquez-le à votre cluster. Exemple :

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

Obtenez l'adresse IP du pod :
```
kubectl get pod island-pod-tester -o wide
```
La commande renvoie l'adresse IP du pod, qui se trouve dans la plage d'adresses isolée que vous avez spécifiée.

Configurer le mode Île avec le service `ClusterIP`

Pour configurer le mode Île avec le service ClusterIP, suivez les étapes de la section précédente, puis ajoutez l'annotation networking.gke.io/gke-gateway-clusterip-cidr à votre ressource Network et définissez sa valeur en fonction de vos besoins commerciaux. Les plages d'adresses spécifiées dans la ressource Network ne doivent pas se chevaucher. Exemple :

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

Équilibrage de charge

Distributed Cloud connecté est fourni avec les solutions d'équilibrage de charge suivantes :

Équilibrage de charge de couche 2 avec MetalLB
Équilibrage de charge de couche 3 avec les équilibreurs de charge Google Distributed Cloud

Les solutions d'équilibrage de charge intégrées à Distributed Cloud connected ne peuvent pas utiliser de préfixes d'adresses IP virtuelles de service Kubernetes qui se chevauchent. Si vous disposez d'un déploiement Distributed Cloud connecté existant qui utilise l'équilibrage de charge MetalLB de couche 2 et que vous souhaitez passer à l'équilibrage de charge de couche 3 avec les équilibreurs de charge Google Distributed Cloud, vous devez utiliser un préfixe d'adresse IP virtuelle de service qui ne chevauche pas le préfixe utilisé par votre configuration d'équilibrage de charge MetalLB de couche 2.

Équilibrage de charge de couche 2 avec MetalLB

Distributed Cloud est fourni avec une solution d'équilibrage de charge réseau groupée basée sur MetalLB en mode couche 2. Vous pouvez utiliser cette solution pour exposer les services qui s'exécutent dans votre zone Distributed Cloud au monde extérieur en utilisant des adresses IP virtuelles (VIP) comme suit :

Votre administrateur réseau planifie la topologie du réseau et spécifie le sous-réseau d'adresses IPv4 et IPv6 virtuelles requis lors de la commande de Distributed Cloud. Google configure votre matériel Distributed Cloud en conséquence avant la livraison. Tenez compte des points suivants :
- Ce sous-réseau d'adresses IP virtuelles est partagé entre tous les clusters Kubernetes qui s'exécutent dans votre zone Distributed Cloud.
- Une route pour le sous-réseau VIP demandé est annoncée via les sessions BGP entre la zone Distributed Cloud et votre réseau local.
- Les première (ID réseau), deuxième (passerelle par défaut) et dernière (adresse de diffusion) adresses du sous-réseau sont réservées aux fonctionnalités principales du système. N'attribuez pas ces adresses aux pools d'adresses de vos configurations MetalLB.
- Chaque cluster doit utiliser une plage d'adresses IP virtuelles distincte qui se trouve dans le sous-réseau d'adresses IP virtuelles configuré.
Lorsque vous créez un cluster dans votre zone Distributed Cloud, votre administrateur de cluster spécifie les pools d'adresses de service de pod et ClusterIP à l'aide de la notation CIDR. Votre administrateur réseau fournit le sous-réseau VIP LoadBalancer approprié à l'administrateur de votre cluster.
Une fois le cluster créé, l'administrateur du cluster configure les pools d'adresses IP virtuelles correspondants. Vous devez spécifier les pools d'adresses IP virtuelles à l'aide de l'option --external-lb-address-pools lorsque vous créez le cluster. L'indicateur accepte un fichier avec une charge utile YAML ou JSON au format suivant :
```
 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
```
Pour spécifier un pool d'adresses VIP, fournissez les informations suivantes dans la charge utile :
- name : nom descriptif qui identifie de manière unique ce pool d'adresses IP virtuelles.
- addresses : liste des adresses, plages d'adresses et sous-réseaux IPv4 et IPv6 à inclure dans ce pool d'adresses.
- avoid_buggy_ips : exclut les adresses IP qui se terminent par .0 ou .255.
- manual_assign : vous permet d'attribuer manuellement des adresses de ce pool dans la configuration du service LoadBalancer cible au lieu de les faire attribuer automatiquement par le contrôleur MetalLB.
Pour en savoir plus sur la configuration des pools d'adresses IP virtuelles, consultez Spécifier des pools d'adresses dans la documentation MetalLB.
L'administrateur du cluster crée les services LoadBalancer Kubernetes appropriés.

Les nœuds Distributed Cloud d'un même pool de nœuds partagent un domaine de couche 2 commun et sont donc également des nœuds d'équilibreur de charge MetalLB.

Équilibrage de charge de couche 3 avec les équilibreurs de charge Google Distributed Cloud

Distributed Cloud connecté est fourni avec une solution d'équilibrage de charge réseau groupée basée sur les équilibreurs de charge groupés Google Distributed Cloud en mode couche 3 configurés en tant que speakers BGP. Vous pouvez utiliser cette solution pour exposer les services qui s'exécutent dans votre zone connectée Distributed Cloud au monde extérieur à l'aide d'adresses IP virtuelles.

Vous pouvez spécifier les plages d'adresses IP virtuelles pour les services LoadBalancer correspondants à l'aide du fichier ConfigMap metallb-config. Exemple :

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

Dans l'exemple précédent, chaque service LoadBalancer que vous configurez se voit automatiquement attribuer une adresse IP virtuelle à partir de la plage 10.100.10.66/27 spécifiée dans le fichier ConfigMap. Ces VIP sont ensuite annoncées vers le nord par les speakers BGP du cloud distribué configurés sur les commutateurs ToR via les ressources BGPPeer.

Lorsque vous créez un cluster Distributed Cloud, les ressources suivantes sont automatiquement créées sur ce cluster :

Une ressource BGPLoadBalancer qui instancie l'équilibreur de charge BGP.
Ressource NetworkGatewayGroup qui spécifie les adresses IP flottantes locales à utiliser pour les routeurs BGP. Ces adresses IP sont automatiquement définies sur les deux dernières adresses IP du sous-réseau de nœuds Kubernetes attribué au cluster.

Une fois ces ressources en place, vous pouvez configurer des sessions BGP sur les commutateurs ToR Distributed Cloud en configurant les ressources BGPPeer correspondantes. Pour ce faire, vous devez disposer des numéros de système autonome (ASN) et des adresses IP de rebouclage des pairs pour les commutateurs ToR. Ces adresses IP servent de points de terminaison de session BGP du commutateur ToR sur la ressource réseau par défaut. N'oubliez pas que la valeur du paramètre network doit être pod-network.

Voici un exemple des deux ressources 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

Configurer l'automatisation de l'équilibrage de charge BGP de couche 3 pour l'appairage IPv6

Avant de pouvoir commencer à utiliser le peering IPv6 sur votre cluster de mise en réseau à double pile IPv4/IPv6, vous devez contacter l'assistance Google pour activer l'automatisation de l'équilibrage de charge Google Distributed Cloud sur votre déploiement Distributed Cloud connecté.

Créer un service `LoadBalancer` de couche 3

Après avoir activé l'automatisation de l'équilibreur de charge Google Distributed Cloud sur votre déploiement Distributed Cloud connecté, instanciez le service LoadBalancer de couche 3. Exemple :

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

Vérifier l'état de la session BGP et des services d'équilibrage de charge

Pour vérifier l'état de votre session BGP, exécutez la commande suivante :

kubectl get bgpsessions.networking.gke.io -A

La commande renvoie un résultat semblable à l'exemple suivant :

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

Pour vérifier que vos services LoadBalancer sont annoncés par les routeurs BGP, utilisez la commande suivante :

kubectl get bgpadvertisedroutes.networking.gke.io -A

La commande renvoie un résultat semblable à l'exemple suivant :

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

Entrée Distributed Cloud

En plus de l'équilibrage de charge, Distributed Cloud connected est également compatible avec les ressources Kubernetes Ingress. Une ressource Ingress Kubernetes contrôle le flux de trafic HTTP(S) vers les services Kubernetes qui s'exécutent sur vos clusters connectés Distributed Cloud. L'exemple suivant illustre une ressource Ingress typique :

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

Une fois configuré, le trafic réseau transite par le service istio-ingress, auquel est attribuée par défaut une adresse IP aléatoire à partir des pools d'adresses IP virtuelles spécifiés dans votre configuration MetalLB. Vous pouvez sélectionner une adresse IP spécifique ou une adresse IP virtuelle à partir de la configuration MetalLB en utilisant le champ loadBalancerIP dans la définition de service istio-ingress. Exemple :

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

Cette fonctionnalité n'est pas disponible sur les serveurs connectés Distributed Cloud.

Désactiver la ressource Distributed Cloud `Ingress` par défaut

Par défaut, lorsque vous créez un cluster connecté Distributed Cloud, Distributed Cloud configure automatiquement le service istio-ingress pour le cluster. Vous pouvez créer un cluster connecté Distributed Cloud sans le service istio-ingress. Pour cela, procédez comme suit :

gcloud

Créez un fichier de configuration YAML nommé SystemsAddonConfig.yaml avec le contenu suivant :
```
systemAddonsConfig:
 ingress:
   disabled: true
```
Transmettez le fichier SystemsAddonConfig.yaml à l'aide de l'option --system-addons-config dans votre commande de création de cluster. Vous devez utiliser la version gcloud alpha pour utiliser cette fonctionnalité. Exemple :
```
gcloud alpha edge-cloud container clusters create MyGDCECluster1 --location us-west1 \
    --system-addons-config=SystemsAddonConfig.yaml
```
Pour en savoir plus sur la création d'un cluster Distributed Cloud, consultez Créer un cluster.

API

Ajoutez le contenu JSON suivant à la charge utile JSON de votre requête de création de cluster :
```
"systemAddonConfig" {
   "ingress" {
           "disabled": true
   }
}
```
Envoyez la demande de création de cluster comme décrit dans Créer un cluster.

Service NodePort

Distributed Cloud Connected est compatible avec le service Kubernetes NodePort qui écoute les connexions sur un nœud Distributed Cloud sur le port de votre choix. Le service NodePort est compatible avec les protocoles TCP, UDP et SCTP. Exemple :

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

Compatibilité SCTP

Distributed Cloud Connected est compatible avec le protocole SCTP (Stream Control Transmission Protocol) sur l'interface réseau principale pour la mise en réseau interne et externe. La compatibilité avec SCTP inclut les types de services NodePort, LoadBalancer et ClusterIP. Les pods peuvent utiliser SCTP pour communiquer avec d'autres pods et ressources externes. L'exemple suivant montre comment configurer IPERF en tant que service ClusterIP à l'aide de 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

Cette fonctionnalité n'est pas disponible sur les serveurs connectés Distributed Cloud.

Modules de noyau SCTP

À partir de la version 1.5.0, Distributed Cloud connecté configure le module de noyau de l'OS Edge sctp comme chargeable. Cela vous permet de charger vos propres piles de protocoles SCTP dans l'espace utilisateur du noyau.

De plus, Distributed Cloud connecté charge les modules suivants dans le noyau par défaut :

Nom du module	Nom de la configuration
`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`

Ressource `ClusterDNS`

Distributed Cloud connecté est compatible avec la ressource Google Distributed Cloud ClusterDNS pour configurer les serveurs de noms en amont pour des domaines spécifiques à l'aide de la section spec.domains. Pour en savoir plus sur la configuration de cette ressource, consultez spec.domains.

Cette fonctionnalité n'est pas disponible sur les serveurs connectés Distributed Cloud.

Étapes suivantes

Attribution d'adresses réseau de pod et de service

Fonctionnalités Mise en réseau de Distributed Cloud connecté Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

Mise en réseau de la double pile IPv4/IPv6

Activer l'API Distributed Cloud Edge Network

Console

gcloud

Configurer le réseau sur Distributed Cloud connecté

Initialiser la configuration réseau de la zone Distributed Cloud

Créer un réseau

Créer un ou plusieurs sous-réseaux

Établir des sessions d'appairage BGP vers le nord

Établir des sessions d'appairage BGP en direction sud

Facultatif : Établir des sessions de peering BGP en boucle

Tester votre configuration

Connecter vos pods au réseau

(Facultatif) Configurer l'isolation du réseau du cluster

(Facultatif) Configurer le mode île

Configurer le mode Île

Configurer le mode Île avec le service ClusterIP

Équilibrage de charge

Équilibrage de charge de couche 2 avec MetalLB

Équilibrage de charge de couche 3 avec les équilibreurs de charge Google Distributed Cloud

Configurer l'automatisation de l'équilibrage de charge BGP de couche 3 pour l'appairage IPv6

Créer un service LoadBalancer de couche 3

Vérifier l'état de la session BGP et des services d'équilibrage de charge

Entrée Distributed Cloud

Désactiver la ressource Distributed Cloud Ingress par défaut

gcloud

API

Service NodePort

Compatibilité SCTP

Modules de noyau SCTP

Ressource ClusterDNS

Étapes suivantes

Fonctionnalités Mise en réseau de Distributed Cloud connecté

Configurer le mode Île avec le service `ClusterIP`

Créer un service `LoadBalancer` de couche 3

Désactiver la ressource Distributed Cloud `Ingress` par défaut

Ressource `ClusterDNS`