Implémenter un modèle de réseau en mode IPv4 plat

Présentation

Les modèles de réseau en mode plat sont de deux types ⩍ réseau en mode statique et un réseau en mode dynamique (utilisant le protocole Border Gateway Protocol). Le mode plat statique peut être utilisé lorsque les nœuds s'étendent sur un seul domaine de Couche 2. Pour les nœuds couvrant plusieurs domaines de couche 2, utilisez le mode IP plat avec BGP.

Dans un modèle de réseau en mode plat, les pods ont des adresses IP uniques sur l'ensemble des clusters. Assurez-vous que les CIDR attribués aux pods sont uniques et qu'ils ne chevauchent pas d'autres sous-réseaux. Par exemple, les adresses IP ne peuvent pas chevaucher les adresses IP utilisées pour les nœuds ou les CIDR des autres pods dans d'autres clusters. Ces adresses IP sont accessibles en externe. Par conséquent, les pods de n'importe quel nœud peuvent communiquer avec tous les pods de tous les autres nœuds. La communication du pod vers une adresse IP externe ne nécessite pas de traduction d'adresse réseau (NAT). Pour en savoir plus sur le modèle de réseau en mode plat et le comparer au modèle de réseau insulaire par défaut, consultez la section Modèles de réseau en mode plat ou insulaire.

Utilisez un modèle de réseau en mode plat lorsque vous disposez d'un espace d'adressage IP volumineux et que vous pouvez attribuer un CIDR de pod unique à un cluster. Vous pouvez configurer dynamiquement les CIDR des pods à l'aide des ClusterCIDRConfigs. Vous pouvez ajouter ou supprimer des ClusterCIDRConfigs après la création du cluster. Pour en savoir plus sur ClusterCIDRConfig et voir des exemples d'utilisation, consultez la page Comprendre la ressource personnalisée ClusterCIDRConfig.

Pour en savoir plus sur le mode plat avec BGP, consultez la section Implémenter un modèle de réseau en mode plat compatible avec BGP.

Comprendre la joignabilité des adresses IP des pods

En mode réseau plat statique pour IPv4, la joignabilité des adresses IP des pods est basée sur les paquets du protocole ARP (Address Resolution Protocol). Par conséquent, les adresses IP des pods ne sont accessibles que lorsque les pods se trouvent dans le même domaine de couche 2. Les nœuds doivent appartenir au même domaine de couche 2. Les adresses IP que vous spécifiez pour vos pods (à l'aide de ClusterCIDRConfigs) doivent se trouver dans le même sous-réseau que les nœuds du cluster. Les CIDR configurés pour les pods doivent provenir du sous-réseau des nœuds. Par exemple, le sous-réseau 222.1.0.0/16 est utilisé par les nœuds d'un cluster, puis sélectionnez un sous-réseau plus petit dans le sous-réseau pour les pods (222.1.2.0/24). Assurez-vous qu'aucune autre ressource de votre cluster n'utilise une adresse IP de la plage allouée à vos pods.

La section suivante décrit la configuration des réseaux en mode plat pour IPv4.

Implémenter un réseau statique en mode plat

Par défaut, le cluster Google Distributed Cloud est créé en mode île. Cette section explique comment configurer la mise en réseau en mode plat pour votre cluster.

Pour déployer un cluster avec un modèle de réseau en mode plat, apportez les modifications suivantes au fichier de configuration du cluster:

La mise en réseau à plat ne peut être activée pour un cluster que lors de sa création. Pour créer un cluster avec une mise en réseau en mode plat, procédez comme suit:

  1. Modifiez le fichier de configuration du cluster pour ajouter clusterNetwork.flatIPv4 et définissez-le sur true.

    Lorsque vous activez la mise en réseau en mode plat, le CIDR des pods spécifié dans le fichier de configuration du cluster (clusterNetwork.pods.cidrBlocks) est ignoré.

  2. Ajoutez un fichier manifeste ClusterCIDRConfig au fichier de configuration du cluster.

    Dans le fichier manifeste ClusterCIDRConfig, incluez les informations suivantes:

    • metadata.namespace: espace de noms de votre cluster.

    • spec.ipv4.cidr: plage d'adresses IP au format de bloc CIDR à utiliser pour les pods de votre cluster. Cette plage doit provenir du même sous-réseau que les nœuds du cluster.

    • perNodeMaskSize: les vérifications préliminaires du cluster vérifient que la valeur perNodeMaskSize est suffisante pour provisionner le nombre de pods spécifié dans maxPodsPerNode.

    • nodeSelector: si aucun libellé de nœud ne correspond à la valeur nodeSelector, le rapprochement des nœuds reste en attente et la création du cluster ne se termine pas.

L'extrait suivant d'un fichier de configuration de cluster montre comment mettre en œuvre une mise en réseau en mode plat sans être compatible avec BGP. Les CIDR qui apparaissent dans cet extrait ne sont que des exemples. Vous devrez les remplacer par vos propres CIDR. Lorsque vous remplacez les CIDR par les vôtres, assurez-vous qu'ils répondent aux critères de joignabilité des pods, comme spécifié dans la section Comprendre la joignabilité des adresses IP des pods.

---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: flat-mode
  namespace: cluster-flat-mode
spec:
... (other cluster config omitted)

...
  # Cluster networking configuration
  clusterNetwork:
    flatIPv4: true
    services:
      cidrBlocks:
      - 10.96.0.0/12
... (other cluster config omitted)

...
---
apiVersion: baremetal.cluster.gke.io/v1alpha1
kind: ClusterCIDRConfig
metadata:
  name: cluster-wide-1
  namespace: cluster-flat-mode
spec:
  ipv4:
    cidr: "222.1.0.0/16"
    perNodeMaskSize: 24

Limites

Le réseau statique en mode plat pour Google Distributed Cloud présente les limites suivantes:

  • Les pods utilisant des réseaux en mode plat sont accessibles au sein du domaine unique de couche 2. Toute autre machine qui ne se trouve pas dans le cluster, mais qui appartiennent au même domaine de couche 2, peut également atteindre les pods. Cette limitation existe également pour IPv6 lorsque des clusters à double pile sont créés et lorsque IPv6 est en mode plat sans BGP. Pour en savoir plus, consultez la section Comprendre la joignabilité des adresses IP des pods.

  • Le contrôleur Google Distributed Cloud IPAM suit la disponibilité des adresses IP dans les CIDR des pods configurés. Il ne suit pas les adresses IP déjà utilisées par d'autres appareils. Par conséquent, aucune autre adresse IP du domaine de couche 2 ne doit interférer avec les CIDR des pods. Pour en savoir plus, consultez la section Comprendre la joignabilité des adresses IP des pods.