Fonctionnalités de mise en réseau Distributed Cloud

Cette page décrit les fonctionnalités réseau de Google Distributed Cloud, 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, à l'exception de l'équilibrage de charge, qui s'applique à la fois aux racks Distributed Cloud et aux serveurs de mise en réseau Distributed Cloud.

Activer l'API Distributed Cloud Edge Network

Avant de pouvoir configurer la mise en réseau 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 sont fournis avec l'API Distributed Cloud Edge Network déjà activée.

Console

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

    Activer l'API

  2. Cliquez sur Activer.

gcloud

Exécutez la commande suivante :

gcloud services enable edgenetwork.googleapis.com

Configurer la mise en réseau Distributed Cloud

Cette section explique comment configurer les composants réseau Distributed Cloud.

Les limites suivantes s'appliquent aux serveurs 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 type pour Distributed Cloud se compose des étapes suivantes :

  1. Facultatif : Si nécessaire, initialisez la configuration réseau de la zone cible.

  2. Créer un réseau.

  3. Créez un ou plusieurs sous-réseaux dans le réseau.

  4. Établissez des sessions d'appairage BGP vers le nord avec vos routeurs PE à l'aide des rattachements d'interconnexion correspondants.

  5. Établissez des sessions d'appairage BGP southbound avec les pods qui exécutent vos charges de travail en utilisant les sous-réseaux correspondants.

  6. Facultatif : Établissez des sessions d'appairage BGP de bouclage pour la haute disponibilité.

  7. Testez la configuration.

  8. Connectez vos pods au réseau.

Facultatif : Initialiser la configuration réseau de la zone Distributed Cloud

Vous devez initialiser la configuration réseau de votre zone Distributed Cloud dans les cas suivants :

  • Immédiatement après l'installation de votre matériel Distributed Cloud dans vos locaux.
  • Vous avez effectué la mise à niveau vers la version 1.3.0 ou ultérieure de Distributed Cloud sur un déploiement Distributed Cloud existant, mais vous n'avez pas participé à la version Preview privée de l'API Distributed Cloud Edge Network.

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 Distributed Cloud en créant les rattachements d'interconnexion correspondants. Cette configuration fournit à votre déploiement Distributed Cloud une connectivité uplink de base à votre réseau local.

L'initialisation de la configuration réseau d'une zone est une procédure ponctuelle. Pour obtenir des instructions complètes, 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 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 Distributed Cloud, vous ne pouvez configurer des 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 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 :

  1. Listez les interconnexions disponibles dans votre zone, puis sélectionnez l'interconnexion cible pour cette session d'appairage.

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

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

  4. 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 Distributed Cloud. Pour obtenir des instructions, consultez Établir une session d'appairage northbound.

  5. 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 votre rack Distributed Cloud.

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

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

  2. 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 fermée entre le pod cible et les deux commutateurs ToR de votre rack 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 :

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

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

  1. Vérifiez l'état opérationnel du réseau.

  2. Vérifiez l'état du provisionnement de chaque sous-réseau.

  3. Vérifiez l'état opérationnel des interconnexions.

  4. Vérifiez l'état opérationnel des rattachements Interconnect.

  5. Vérifiez l'état opérationnel du routeur.

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.

Équilibrage de charge

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 :

  1. Votre administrateur réseau planifie la topologie du réseau et spécifie le sous-réseau d'adresses IPv4 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é.
  2. Lorsque vous créez un cluster dans votre zone Distributed Cloud, votre administrateur de cluster spécifie les pools d'adresses de service 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.

  3. Une fois le cluster créé, l'administrateur du cluster configure les pools d'adresses IP virtuelles correspondants. Pour les clusters de plan de contrôle à distance, vous devez modifier le fichier ConfigMap metallb-config dans l'espace de noms metallb-system à l'aide de la commande kubectl edit ou kubectl replace. N'utilisez pas la commande kubectl apply, car Distributed Cloud écrasera vos modifications si vous le faites.

    L'exemple suivant illustre une telle configuration :

    # 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

    Pour les clusters de plan de contrôle local, vous devez spécifier les pools d'adresses IP virtuelles à l'aide de l'indicateur --external-lb-ipv4-address-pools lorsque vous créez le cluster. Pour en savoir plus, consultez Mode de survie.

  4. L'administrateur de 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. Les nœuds de plan de contrôle Distributed Cloud qui s'exécutent surGoogle Cloud ne fonctionnent pas comme des nœuds d'équilibreur de charge.

Entrée Distributed Cloud

En plus de l'équilibrage de charge, Distributed Cloud 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 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 Distributed Cloud.

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

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

gcloud

  1. Créez un fichier de configuration YAML nommé SystemsAddonConfig.yaml avec le contenu suivant :

    systemAddonsConfig:
 ingress:
   disabled: true

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

  1. Ajoutez le contenu JSON suivant à la charge utile JSON de votre requête de création de cluster :

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

  2. Envoyez la demande de création de cluster comme décrit dans Créer un cluster.

Compatibilité SCTP

Distributed Cloud 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 Distributed Cloud.

Modules de noyau SCTP

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

En outre, Distributed Cloud 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 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 Distributed Cloud.

Étapes suivantes