Fonctionnalités de mise en réseau Distributed Cloud

Cette page décrit les fonctionnalités de mise en 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 décrites sur 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 de cette section. Par défaut, les serveurs Distributed Cloud sont livrés avec l'API Distributed Cloud Edge Network déjà activée.

Console

  1. Dans la Google Cloud console, 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 de mise en réseau Distributed Cloud.

Les limites suivantes s'appliquent aux serveurs Distributed Cloud :

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

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

  1. Facultatif : Initialisez la configuration réseau de la zone cible, si nécessaire.

  2. Créez un réseau.

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

  4. Établissez des sessions d'appairage BGP en amont avec vos routeurs PE à l'aide des pièces jointes d'interconnexion correspondantes.

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

  6. Facultatif : Établissez des sessions d'appairage BGP de bouclage pour une 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é une 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é à l'aperçu privé 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. Elle configure également le routeur default pour qu'il s'appaire avec toutes les interconnexions que vous avez demandées lors de la commande du matériel Distributed Cloud en créant les pièces jointes d'interconnexion correspondantes. Cette configuration fournit à votre déploiement Distributed Cloud une connectivité de liaison montante de base à votre réseau local.

L'initialisation de la configuration réseau d'une zone est une procédure unique. 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'accéder au réseau. 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 des CIDR ne sont pas compatibles.

Établir des sessions d'appairage BGP en amont

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 en amont entre le réseau et vos routeurs périphériques d'appairage.

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

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

  2. Créez une ou plusieurs pièces jointes d'interconnexion sur l'interconnexion sélectionnée. Les pièces jointes d'interconnexion associent le routeur que vous créez à 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 pièces jointes d'interconnexion que vous avez créées à l'étape précédente.

  4. Ajoutez une interface au routeur pour chaque pièce jointe d'interconnexion que vous avez créée 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 en amont.

  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 aval

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

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

  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 en aval.

  2. Ajoutez un pair pour chaque interface que vous avez créée sur le routeur à l'étape précédente.

Facultatif : Établir des sessions d'appairage BGP de bouclage

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

Pour établir une session d'appairage BGP de bouclage, procédez comme suit :

  1. Ajoutez une interface de bouclage au routeur dans le réseau cible. Pour obtenir des instructions, consultez Établir une session d'appairage de bouclage.

  2. Ajoutez un pair pour l' interface de bouclage.

Tester la 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 de provisionnement de chaque sous-réseau.

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

  4. Vérifiez l'état opérationnel des pièces jointes d'interconnexion.

  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 à l'aide d'adresses IP virtuelles (VIP) comme suit :

  1. Votre administrateur réseau planifie la topologie 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. Gardez les points suivants à l'esprit :
    • Ce sous-réseau VIP 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 d'adresse) adresses du sous-réseau sont réservées aux fonctionnalités de base du système fonctionnalité. N'attribuez pas ces adresses aux pools d'adresses de vos configurations MetalLB.
    • Chaque cluster doit utiliser une plage VIP distincte qui se trouve dans le sous-réseau VIP 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é à votre administrateur de cluster.

  3. Une fois le cluster créé, l'administrateur de cluster configure les pools VIP correspondants. Pour les clusters de plan de contrôle à distance, vous devez modifier la 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 écrase vos modifications.

    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 VIP à l'aide de l'indicateur --external-lb-ipv4-address-pools lorsque vous créez le cluster. Pour en savoir plus, consultez le mode de survie.

  4. L'administrateur de cluster crée les services Kubernetes LoadBalancer 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 sur Google 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 Ingress Kubernetes. 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 VIP 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 à l'aide du champ loadBalancerIP dans la définition du 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 Ingress Distributed Cloud 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 avez la possibilité de 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'indicateur --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 requête de création de cluster comme décrit dans Créer un cluster.

Compatibilité avec 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 des 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 sctp Edge OS comme chargeable. Cela vous permet de charger vos propres piles de protocoles SCTP dans l'espace utilisateur du noyau.

De plus, 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 ClusterDNS Google Distributed Cloud pour configurer des 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.

Étape suivante