Comprendre la ressource personnalisée ClusterCIDRConfig

Présentation

ClusterCIDRConfig est une ressource d'allocation CIDR personnalisée qui vous permet d'allouer dynamiquement davantage de plages d'adresses IP aux pods.

La gestion des adresses IP permet une utilisation efficace des sous-réseaux IP et évite les chevauchements dans les plages d'adresses, ce qui évite les conflits et les pannes de réseau. Kubernetes attribue des CIDR de pods par nœud, qui sont utilisés comme adresses IP pour les pods exécutés sur ce nœud.

Actuellement, NodeIPAM Kubernetes présente les limites suivantes:

• Tous les CIDR des pods sont alloués à partir d'un CIDR de cluster. Vous devez spécifier la plage d'adresses IP entière représentant le cluster le plus grand au moment de sa création. Cette limitation peut entraîner un gaspillage d'adresses IP.

• Si vous augmentez la taille du cluster, il sera difficile d'ajouter d'autres adresses IP.

• Le CIDR du cluster est une plage large. Il peut être difficile de trouver un bloc d'adresses IP contigu répondant aux besoins du cluster.

• Chaque nœud obtient une plage d'adresses IP de taille fixe au sein d'un cluster. Si les nœuds ont des tailles et une capacité différentes, vous ne pouvez pas allouer une plage de pods plus étendue à un nœud donné ayant une capacité supérieure et une plage plus petite à des nœuds de capacité inférieure. Cela gaspille beaucoup d'adresses IP. Pour un cluster volumineux comportant de nombreux nœuds, ce gaspillage est aggravé sur tous les nœuds du cluster.

La fonctionnalité ClusterCIDRConfig vous permet d'éviter d'attribuer un bloc CIDR volumineux à un cluster, de mapper la taille de votre cluster à l'échelle de vos pods, et donc de conserver les adresses IP. Vous pouvez enregistrer des adresses IP en utilisant ClusterCIDRConfigs avec différentes combinaisons de CIDR et perNodeMaskSize. La ressource ClusterCIDRConfig est compatible avec les éléments suivants:

• Plusieurs blocs CIDR d'adresses IP non contiguës pour le CIDR du cluster à un niveau plus précis

• Affinité de nœud pour les blocs CIDR

• Différentes tailles de bloc allouées aux nœuds

Google Distributed Cloud utilise la fonctionnalité ClusterCIDRConfig dans les fonctionnalités suivantes:

• Mise en réseau de la double pile IPv4/IPv6

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

• Implémenter un modèle de réseau en mode plat compatible avec BGP

Cluster.spec.clusterNetwork.pods.cidrBlocks est un champ facultatif et n'est pas défini par défaut. Vous devez la définir si elle n'est pas définie dans l'une des caractéristiques de la liste précédente. Par exemple, elle est obligatoire lorsque les clusters sont créés en mode île IPv4 et doit être spécifiée, car elle est utilisée comme CIDR de routage natif.

Le tableau suivant répertorie l'utilisation du comportement du champ Cluster.spec.clusterNetwork.pods.cidrBlocks de ClusterCIDRConfig pour différents modes de réseau.

Mode réseau	Valeur ClusterCIDRConfig
Île IPv4 (par défaut)	(Champ obligatoire) Spécifiez Cluster.spec.clusterNetwork.pods.cidrBlocks.
IPv4 Flat (par défaut)	Les champs Cluster.spec.clusterNetwork.pods.cidrBlocks sont complètement ignorés et peuvent être ignorés. Les utilisateurs doivent définir explicitement des ClusterCIDRConfigs (par nœud, par pool de nœuds et/ou par cluster).
Double pile (île IPv4, IPv4 plat)	Spécifiez le CIDR IPv4. Ne spécifiez pas le CIDR IPv6 dans Cluster.spec.clusterNetwork.pods.cidrBlocks. Spécifiez les ClusterCIDRConfigs avec des CIDR IPv4 et IPv6. Le CIDR IPv4 configuré dans tous les ClusterCIDRConfigs doit être identique au CIDR IPv4 de Cluster.spec.clusterNetwork.pods.cidrBlocks, y compris la valeur PerNodeMask pour IPv4. Pour en savoir plus sur ClusterCIDRConfig et voir des exemples d'utilisation, consultez la section Exemples: Dualstack (île IPv4, IPv6 Flat)
Double pile (IPv4 plat, IPv6 plat)	Vous pouvez ignorer les Cluster.spec.clusterNetwork.pods.cidrBlocks, car elles sont complètement ignorées. Vous devez définir explicitement des ClusterCIDRConfigs (par nœud, par pool de nœuds et/ou par cluster) avec des CIDR IPv4 et IPv6.

Configurer la ressource d'allocation CIDR personnalisée ClusterCIDRConfig

ClusterCIDRConfig

Lorsque vous configurez la ressource d'allocation CIDR personnalisée ClusterCIDRConfig, tenez compte des points suivants:

• L'attribution d'un CIDR de pod à un nœud à partir d'un ClusterCIDRConfig spécifique est basée sur des sélecteurs d'étiquettes. Cette méthode est semblable au mécanisme de sélecteur de nœud utilisé pour planifier les pods sur un nœud.

• Vous devez configurer l'objet ClusterCIDRConfig lors du processus de création du cluster dans le fichier YAML de configuration du cluster. Une fois que vous avez spécifié ClusterCIDRConfig, vous ne pouvez plus modifier les valeurs.

• Vous pouvez spécifier plusieurs ClusterCIDRConfigs dont les CIDR se chevauchent.

• Si aucun ClusterCIDRConfig correspondant n'est trouvé pour un nœud, celui-ci reste à l'état NotReady jusqu'à ce qu'un ClusterCIDRConfig avec les libellés correspondants soit créé.

• Si le ClusterCIDRConfig qui correspond le mieux n'a pas plus de CIDR disponibles pour l'allocation, le meilleur CIDR suivant est choisi et les CIDR de pods sont alloués à partir des CIDR disponibles.

• Dans le cas d'un modèle à double pile, si vous souhaitez attribuer des CIDR de pods à double pile aux nœuds, procédez comme suit:

  • Configurez des CIDR IPv4 et IPv6 dans ClusterCIDRConfig.

  • Assurez-vous que tous les ClusterCIDRConfig disposent de CIDR DualStack, si plusieurs ClusterCIDRConfig sont configurés.

  • Assurez-vous que les CIDR IPv4 et IPv6 configurés disposent d'un nombre égal d'adresses IP pouvant être allouées par nœud.

  Par exemple : 32 - spec.IPv4.PerNodeMaskSize == 128 - spec.IPv6.PerNodeMaskSize

  spec.IPv4.PerNodeMaskSize = 24

  spec.IPv6.PerNodeMaskSize = 120

  Ainsi, 32 - 24 == 128 - 120, puisque la différence est de 8.

• Plusieurs ClusterCIDRConfigs peuvent faire correspondre les étiquettes de nodeSelector aux étiquettes des nœuds.

Règles d'attribution du ClusterCIDRConfig

Pour déterminer quel ClusterCIDRConfig est utilisé pour attribuer les CIDR des pods au nœud actuel, utilisez les règles de départage suivantes. Implémentez ces règles dans l'ordre indiqué. Ne mettez en œuvre la règle suivante que si l'égalité n'est pas rompue par la règle précédente.

1. Choisissez le ClusterCIDRConfig dont le sélecteur de nœud correspond au plus grand nombre de libellés sur le nœud. Par exemple, {'node.kubernetes.io/instance-type':'medium', 'rack': 'rack1'} (Match Count: 2) est sélectionné avant {'node.kubernetes.io/instance-type': 'medium'}. (Match Count: 1).

2. Choisissez le ClusterCIDRConfig ayant le moins de CIDR de pods pouvant être alloués. Par exemple, {CIDR: "10.0.0.0/16", PerNodeMaskSize: "16"} (1 possible Pod CIDR) est sélectionné avant {CIDR: "192.168.0.0/20", PerNodeMaskSize: "22"} (4 possible Pod CIDRs).

3. Sélectionnez la ClusterCIDRConfig dont PerNodeMaskSize a le moins d'adresses IP. Par exemple, 27 (2^(32-27)= 32 adresses IP) sélectionnées avant 25 (2^(32-25)=128 adresses IP).

4. Choisissez le ClusterCIDRConfig dont l'étiquette NodeSelector correspondante a une valeur alphanumérique inférieure. Par exemple, {'kubernetes.io/hostname': 'node-1'} est choisi plutôt que {'node.kubernetes.io/instance-type':'medium'}.

5. Sélectionnez la ClusterCIDRConfig dont l'adresse IP CIDR a une valeur inférieure. Qu'il s'agisse d'une configuration IPv4 ou DualStack, seuls les CIDR IPv4 sont comparés. Par exemple, {CIDR: "10.0.0.0/16"} is picked over {CIDR: "192.168.0.0/16"}.

Exemples de configuration

Cette section répertorie des exemples de configuration pour Cluster et ClusterCIDRConfig pour tous les modes de mise en réseau.

Attention :N'utilisez pas les exemples présentés ici. Remplacez les plages d'adresses par des valeurs adaptées à votre réseau.

Exemples: Mode île IPv4 (par défaut)

Configuration du cluster (par défaut)

    apiVersion: baremetal.cluster.gke.io/v1
    kind: Cluster
    metadata:
      name: bm-cluster
      namespace: cluster-default
    spec:
    ...
      clusterNetwork:
        # Pods specify the IP ranges from which pod networks are allocated.
        pods:
          cidrBlocks:
          - 192.168.0.0/16
        services:
          cidrBlocks:
          - 10.96.0.0/12

      ... (other cluster config omitted)
  

Exemples: mode plat IPv4

Configuration du cluster

  apiVersion: baremetal.cluster.gke.io/v1
  kind: Cluster
  metadata:
    name: bm-cluster
    namespace: cluster-default
  spec:
  ...
    clusterNetwork:
      flatIPv4: true
      services:
        cidrBlocks:
        - 10.96.0.0/12

    ... (other cluster config omitted)
  

ClusterCIDRConfig

Exemple 1: Configurer par ClusterCIDRConfig de nœud

    ---
    apiVersion: baremetal.cluster.gke.io/v1alpha1
    kind: ClusterCIDRConfig
    metadata:
      name: range-node1
      namespace: cluster-default    # Cluster namespace
    spec:
      ipv4:
        cidr: "222.1.0.0/24"
        perNodeMaskSize: 24
      nodeSelector:
        matchLabels:
          kubernetes.io/hostname: node-1
    —
    apiVersion: baremetal.cluster.gke.io/v1alpha1
    kind: ClusterCIDRConfig
    metadata:
      name: range-node2
      namespace: cluster-default
    spec:
      ipv4:
        cidr: "222.1.1.0/24"
        perNodeMaskSize: 24
      nodeSelector:
        matchLabels:
          kubernetes.io/hostname: node-2
    —
    apiVersion: baremetal.cluster.gke.io/v1alpha1
    kind: ClusterCIDRConfig
    metadata:
      name: range-node3
      namespace: cluster-default
    spec:
      ipv4:
        cidr: "222.1.2.0/24"
        perNodeMaskSize: 24
      nodeSelector:
        matchLabels:
          kubernetes.io/hostname: node-3

  

Exemple 2: Exemple de spécification d'un PodCIDR à l'échelle de NodePool

Remarque:Les deux modes d'adresses IP plates présentent des contraintes différentes :

• Pour l'adresse IP statique statique (sans BGP): ne peut être utilisé que si tous les nœuds se trouvent dans le même domaine de couche 2.
• Pour l'adresse IP plat dynamique (avec BGP): peut être utilisée même lorsque les nœuds s'étendent sur plusieurs sous-domaines.

    apiVersion: baremetal.cluster.gke.io/v1alpha1
    kind: ClusterCIDRConfig
    metadata:
      name: nodepool-wide-1
      namespace: cluster-default
    spec:
      ipv4:
        cidr: "222.2.0.0/18"
        perNodeMaskSize: 24
      nodeSelector:
        matchLabels:
          baremetal.cluster.gke.io/node-pool: workers
  

Exemple 3: Configurer PodCIDR à l'échelle du cluster - Aucun sélecteur de nœuds n'est configuré

Remarque:Les deux modes d'adresses IP plates présentent des contraintes différentes :

• Pour l'adresse IP statique statique (sans BGP): ne peut être utilisé que si tous les nœuds se trouvent dans le même domaine de couche 2.
• Pour l'adresse IP plat dynamique (avec BGP): peut être utilisée même lorsque les nœuds s'étendent sur plusieurs sous-domaines.

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

Exemples: Dualstack (île IPv4, IPv6 plat)

Configuration du cluster

  apiVersion: baremetal.cluster.gke.io/v1
  kind: Cluster
  metadata:
    name: bm-cluster
    namespace: cluster-default
  spec:
  ...
    clusterNetwork:
      # Pods specify the IP ranges from which pod networks are allocated.
      pods:
        cidrBlocks:
        - 192.168.0.0/16
      services:
        cidrBlocks:
        - 10.96.0.0/12
        # Additional IPv6 cidrBlock, determines if the cluster is DualStack
        - 2620:0:1000:2630:5:2::/112

    ... (other cluster config omitted)
  

ClusterCIDRConfig

Exemple 1: Configurer par ClusterCIDRConfig de nœud

    ---
    apiVersion: baremetal.cluster.gke.io/v1alpha1
    kind: ClusterCIDRConfig
    metadata:
      name: range-node1
      namespace: cluster-default    # Cluster namespace
    spec:
      ipv4:
        cidr: "192.168.0.0/16"
        perNodeMaskSize: 24
      ipv6:
        cidr: "2222:1::/120"
        perNodeMaskSize: 120
      nodeSelector:
        matchLabels:
          kubernetes.io/hostname: node-1
    —
    apiVersion: baremetal.cluster.gke.io/v1alpha1
    kind: ClusterCIDRConfig
    metadata:
      name: range-node2
      namespace: cluster-default
    spec:
      ipv4:
        cidr: "192.168.0.0/16"
        perNodeMaskSize: 24
      ipv6:
        cidr: "2222:2::/120"
        perNodeMaskSize: 120
      nodeSelector:
        matchLabels:
          kubernetes.io/hostname: node-2
    —
    apiVersion: baremetal.cluster.gke.io/v1alpha1
    kind: ClusterCIDRConfig
    metadata:
      name: range-node3
      namespace: cluster-default
    spec:
      ipv4:
        cidr: "192.168.0.0/16"
        perNodeMaskSize: 24
      ipv6:
        cidr: "2222:3::/120"
        perNodeMaskSize: 120
      nodeSelector:
        matchLabels:
          kubernetes.io/hostname: node-3
    

Exemple 2: Exemple de spécification d'un PodCIDR à l'échelle de NodePool

Remarque:Les deux modes d'adresses IP plates présentent des contraintes différentes :

• Pour l'adresse IP statique statique (sans BGP): ne peut être utilisé que si tous les nœuds se trouvent dans le même domaine de couche 2.
• Pour l'adresse IP plat dynamique (avec BGP): peut être utilisée même lorsque les nœuds s'étendent sur plusieurs sous-domaines.

    apiVersion: baremetal.cluster.gke.io/v1alpha1
    kind: ClusterCIDRConfig
    metadata:
      name: nodepool-wide-1
      namespace: cluster-default
    spec:
      ipv4:
        cidr: "192.168.0.0/16"
        perNodeMaskSize: 24
      ipv6:
        cidr: "2222:3::/112"
        perNodeMaskSize: 118
      nodeSelector:
        matchLabels:
          baremetal.cluster.gke.io/node-pool: workers
    

Exemple 3: Configurer PodCIDR à l'échelle du cluster - Aucun sélecteur de nœuds n'est configuré

Remarque:Les deux modes d'adresses IP plates présentent des contraintes différentes :

• Pour l'adresse IP statique statique (sans BGP): ne peut être utilisé que si tous les nœuds se trouvent dans le même domaine de couche 2.
• Pour l'adresse IP plat dynamique (avec BGP): peut être utilisée même lorsque les nœuds s'étendent sur plusieurs sous-domaines.

    apiVersion: baremetal.cluster.gke.io/v1alpha1
    kind: ClusterCIDRConfig
    metadata:
      name: cluster-wide-1
      namespace: cluster-default
    spec:
      ipv4:
        cidr: "192.168.0.0/16"
        perNodeMaskSize: 24
      ipv6:
        cidr: "2222:3::/112"
        perNodeMaskSize: 120
    

Exemples: Dualstack (IPv4 Flat, IPv6 Flat)

Configuration du cluster

    apiVersion: baremetal.cluster.gke.io/v1
    kind: Cluster
    metadata:
      name: bm-cluster
      namespace: cluster-default
    spec:
    ...
      clusterNetwork:
        flatIPv4: true
        services:
          cidrBlocks:
          - 10.96.0.0/12
          # Additional IPv6 cidrBlock, determines if the cluster is DualStack
          - 2620:0:1000:2630:5:2::/112

      ... (other cluster config omitted)
  

ClusterCIDRConfig

Exemple 1: Configurer par ClusterCIDRConfig de nœud

Remarque:Les deux modes d'adresses IP plates présentent des contraintes différentes :

• Pour l'adresse IP statique statique (sans BGP): ne peut être utilisé que si tous les nœuds se trouvent dans le même domaine de couche 2.
• Pour l'adresse IP plat dynamique (avec BGP): peut être utilisée même lorsque les nœuds s'étendent sur plusieurs sous-domaines.

    ---
    apiVersion: baremetal.cluster.gke.io/v1alpha1
    kind: ClusterCIDRConfig
    metadata:
      name: range-node1
      namespace: cluster-default    # Cluster namespace
    spec:
      ipv4:
        cidr: "222.1.0.0/24"
        perNodeMaskSize: 24
      ipv6:
        cidr: "2222:1::/120"
        perNodeMaskSize: 120
      nodeSelector:
        matchLabels:
          kubernetes.io/hostname: node-1
    —
    apiVersion: baremetal.cluster.gke.io/v1alpha1
    kind: ClusterCIDRConfig
    metadata:
      name: range-node2
      namespace: cluster-default
    spec:
      ipv4:
        cidr: "222.1.1.0/24"
        perNodeMaskSize: 24
      ipv6:
        cidr: "2222:2::/120"
        perNodeMaskSize: 120
      nodeSelector:
        matchLabels:
          kubernetes.io/hostname: node-2
    —
    apiVersion: baremetal.cluster.gke.io/v1alpha1
    kind: ClusterCIDRConfig
    metadata:
      name: range-node3
      namespace: cluster-default
    spec:
      ipv4:
        cidr: "222.1.2.0/24"
        perNodeMaskSize: 24
      ipv6:
        cidr: "2222:3::/120"
        perNodeMaskSize: 120
      nodeSelector:
        matchLabels:
          kubernetes.io/hostname: node-3
    

Exemple 2: Exemple de spécification d'un PodCIDR à l'échelle de NodePool

Remarque:Les deux modes d'adresses IP plates présentent des contraintes différentes :

• Pour l'adresse IP statique statique (sans BGP): ne peut être utilisé que si tous les nœuds se trouvent dans le même domaine de couche 2.
• Pour l'adresse IP plat dynamique (avec BGP): peut être utilisée même lorsque les nœuds s'étendent sur plusieurs sous-domaines.

    apiVersion: baremetal.cluster.gke.io/v1alpha1
    kind: ClusterCIDRConfig
    metadata:
      name: nodepool-wide-1
      namespace: cluster-default
    spec:
      ipv4:
        cidr: "222.2.0.0/18"
        perNodeMaskSize: 24
      ipv6:
        cidr: "2222:3::/112"
        perNodeMaskSize: 118
      nodeSelector:
        matchLabels:
          baremetal.cluster.gke.io/node-pool: workers
    

Exemple 3: Configurer PodCIDR à l'échelle du cluster - Aucun sélecteur de nœuds n'est configuré

    apiVersion: baremetal.cluster.gke.io/v1alpha1
    kind: ClusterCIDRConfig
    metadata:
      name: cluster-wide-1
      namespace: cluster-default
    spec:
      ipv4:
        cidr: "222.3.0.0/16"
        perNodeMaskSize: 24
      ipv6:
        cidr: "2222:3::/112"
        perNodeMaskSize: 120