Les clusters Anthos sur Bare Metal sont désormais Google Distributed Cloud (logiciel uniquement) pour Bare Metal. Pour en savoir plus, consultez la présentation du produit.

Mettre en œuvre 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 réseau en mode dynamique (à l'aide de Border Gateway Protocol). Le modèle en mode plat statique peut être utilisé lorsque les nœuds couvrent 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 disposent d'adresses IP uniques sur tous les clusters. Assurez-vous que les CIDR des pods attribués sont uniques et ne chevauchent aucun autre sous-réseau. Par exemple, les adresses IP ne peuvent pas se chevaucher avec les adresses IP utilisées pour les nœuds ou les autres CIDR des pods dans d'autres clusters. Ces adresses IP sont accessibles de l'extérieur. 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 entre le pod et 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 sur la comparaison avec le modèle de réseau en mode île par défaut, consultez la section Modèles réseau en mode plat ou en mode île.

Utilisez un modèle de réseau en mode plat lorsque vous disposez d'un espace d'adresse IP important et que vous pouvez attribuer un CIDR des pods unique à un cluster. Vous pouvez configurer les CIDR de pod de manière dynamique à 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 obtenir des exemples d'utilisation, consultez la section Comprendre la ressource personnalisée ClusterCIDRConfig.

Pour en savoir plus sur le mode plat avec BGP, consultez la section Mise en œuvre d'un modèle de réseau en mode plat avec compatibilité BGP.

Comprendre l'accessibilité d'adresse IP des pods

Dans le mode réseau plat statique pour IPv4, l'accessibilité des adresses IP des pods est basée sur les paquets ARP (Address Resolution Protocol). Par conséquent, les adresses IP des pods ne sont accessibles que lorsqu'ils 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 des pods configurées doivent provenir du sous-réseau des nœuds. Par exemple, si le sous-réseau 222.1.0.0/16 est utilisé par les nœuds d'un cluster, sélectionnez un sous-réseau plus petit à l'intérieur de ce sous-réseau pour les pods, comme 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.

Comment mettre en œuvre un réseau statique en mode plat

Par défaut, le cluster Google Distributed Cloud est créé dans un modèle de mise en réseau 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 :

Vous ne pouvez activer la mise en réseau en mode plat que lors de la création du cluster. Pour créer un cluster avec une mise en réseau en mode plat, procédez comme suit :

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é.
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éalables à la création du cluster s'assurent 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, la réconciliation des nœuds reste en attente et la création du cluster n'est pas terminée.

L'extrait suivant d'un fichier de configuration de cluster montre comment mettre en œuvre une mise en réseau en mode plat sans compatibilité BGP. Les CIDR qui figurent dans cet extrait ne sont que des exemples et 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 d'accessibilité des pods, comme indiqué dans la section Comprendre l'accessibilité d'adresse 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

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

Les pods utilisant des réseaux en mode plat seraient accessibles dans le domaine de couche 2 unique. Toute autre machine qui ne se trouve pas dans le cluster, mais dans le même domaine de couche 2, peut également accéder aux pods. Cette limitation existe également pour IPv6 lors de la création de clusters à double pile et lorsque IPv6 est en mode plat sans BGP. Pour en savoir plus, consultez la section Comprendre l'accessibilité d'adresse IP des pods.
Le contrôleur IPAM de Google Distributed Cloud 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, toutes les autres adresses IP du domaine de couche 2 ne doivent pas interférer avec les CIDR des pods. Pour en savoir plus, consultez la section Comprendre l'accessibilité d'adresse IP des pods.