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

Présentation

Dans un modèle de réseau en mode plat, les pods possèdent des adresses IP uniques dans les clusters. Assurez-vous que les CIDR des pods attribués sont uniques et 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 autres CIDR de pods dans 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 n'importe quelle 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 ses différences avec le modèle de réseau insulaire par défaut, consultez la section Modèles de réseau en mode plat ou en mode insulaire.

Les modèles de réseau en mode plat sont de deux types ᐧ un réseau en mode statique et 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.

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 les CIDR des pods 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 le mode plat avec BGP, consultez la section Implémenter un modèle de réseau en mode plat avec BGP.

Comprendre la joignabilité de l'adresse IP du pod

En mode réseau plat statique pour IPv4, l'accessibilité par adresse 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 des pods configurés doivent provenir du sous-réseau des nœuds. Par exemple, les nœuds d'un cluster utilisent le sous-réseau 222.1.0.0/16, puis sélectionnent un sous-réseau plus petit dans le sous-réseau réservé aux 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.

Mettre en œuvre un réseau statique en mode plat

Par défaut, un 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 ne se termine pas.

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 qui apparaissent 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 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 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 atteindre les pods. Cette limitation s'applique également aux clusters doublestack lorsque l'IPv6 est créé et en mode plat sans BGP. Pour en savoir plus, consultez la section Comprendre la joignabilité de l'adresse IP du pod.
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, 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é de l'adresse IP du pod.