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 ᐧ un 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 s'étendant sur plusieurs domaines de couche 2, utilisez le mode d'adresse IP plat avec BGP.

Dans un modèle de réseau en mode plat, les pods disposent d'adresses IP uniques sur l'ensemble des 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 chevaucher les adresses IP utilisées pour les nœuds ou les autres CIDR des pods d'autres clusters. Ces adresses IP sont accessibles en externe et les pods de n'importe quel nœud peuvent donc 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 ses différences avec le modèle de réseau insulaire par défaut, consultez la section Modèles de réseau plat et en mode insulaire.

Utilisez un modèle de réseau en mode plat lorsque vous disposez d'un espace d'adressage IP important 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 obtenir 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 Mettre en œuvre un modèle de réseau en mode plat compatible avec BGP.

Comprendre la joignabilité de l'adresse IP des pods

En mode réseau plat statique pour IPv4, la joignabilité 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 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 des pods configurés doivent provenir du sous-réseau des nœuds. Par exemple, 222.1.0.0/16 est utilisé par les nœuds d'un cluster, puis sélectionne 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.

Comment implémenter un réseau statique en mode plat

Par défaut, le cluster GKE sur Bare Metal est créé dans une 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:

La mise en réseau en mode 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:

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éliminaires de la création 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 n'est pas terminée.

L'extrait de fichier de configuration de cluster suivant montre comment mettre en œuvre une mise en réseau en mode plat sans prise en charge de BGP. Les CIDR figurant 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 spécifiés 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 GKE sur Bare Metal 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 dans le même domaine de couche 2, peut également atteindre les pods. Cette limitation existe également pour IPv6 lorsque des clusters doublestack sont créés et lorsque le protocole 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 IPAM GKE sur Bare Metal 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, toute autre adresse IP du domaine de couche 2 ne doit pas interférer avec les CIDR des pods. Pour en savoir plus, consultez la section Comprendre la joignabilité des adresses IP des pods.