Comprendre la ressource personnalisée ClusterCIDRConfig

Présentation

ClusterCIDRConfig est une ressource d'allocation CIDR personnalisée qui vous permet d'allouer plus de plages d'adresses IP aux pods de manière dynamique.

La gestion des adresses IP (IPAM) permet d'utiliser efficacement les sous-réseaux IP et évite les chevauchements des plages d'adresses, ce qui évite les conflits et les pannes réseau. Kubernetes attribue des CIDR de pod par nœud, qui sont utilisées comme adresses IP pour les pods exécutés sur ce nœud.

Le NodeIPAM Kubernetes actuel présente les limites suivantes :

• Tous les CIDR de pods sont alloués à partir d'un seul CIDR de cluster. Vous devez spécifier l'intégralité de la plage d'adresses IP qui représente le cluster le plus volumineux au moment de la création du cluster. Cette limitation peut gaspiller des 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 étendue. Il peut être difficile de trouver un bloc contigu d'adresses IP répondant aux besoins du cluster.

• Chaque nœud obtient une plage d'adresses IP de taille fixe dans un cluster. Si les nœuds ne possèdent pas la même taille et la même capacité, vous ne pouvez pas allouer une plage de pods plus importante à un nœud donné avec une plus grande capacité et une plage plus petite aux nœuds de moindre capacité. Cela gaspille beaucoup d'adresses IP. Pour un grand cluster avec de nombreux nœuds, ce gaspillage est aggravé sur tous les nœuds du cluster.

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

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

• Affinité des nœuds des blocs CIDR

• Différentes tailles de blocs 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 un modèle de réseau en mode IPv4 plat

• Mise en œuvre d'un modèle de réseau en mode plat avec compatibilité BGP

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

Le tableau suivant présente le comportement du champ Cluster.spec.clusterNetwork.pods.cidrBlocks de ClusterCIDRConfig pour différents modes de réseau.

Mode réseau	Valeur ClusterCIDRConfig
IPv4 île (par défaut)	(Champ obligatoire) Spécifiez Cluster.spec.clusterNetwork.pods.cidrBlocks.
IPv4 plat (par défaut)	Les 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 (IPv4 île, IPv4 plat)	Spécifiez le CIDR IPv4. Ne spécifiez pas de CIDR IPv6 dans Cluster.spec.clusterNetwork.pods.cidrBlocks. Spécifiez des 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 obtenir des exemples d'utilisation, consultez la section Exemples : double pile (IPv4 île, IPv6 plat).
Double pile (IPv4 plat, IPv6 plat)	Vous pouvez ignorer Cluster.spec.clusterNetwork.pods.cidrBlocks, car ils sont complètement ignorés. 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 de CIDR de pod à partir d'un ClusterCIDRConfig spécifique à un nœud est basée sur des sélecteurs d'étiquettes. Ce mécanisme est semblable à celui de nodeSelector utilisé pour programmer des pods sur un nœud.

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

• Vous pouvez spécifier plusieurs ClusterCIDRConfigs avec des CIDR qui se chevauchent.

• Si aucun ClusterCIDRConfig correspondant n'est trouvé pour un nœud, celui-ci reste dans un état "NotReady" (non prêt) jusqu'à ce qu'un ClusterCIDRConfig avec des étiquettes correspondantes soit créé.

• Si le ClusterCIDRConfig correspondant le mieux ne dispose pas de davantage de plages CIDR disponibles pour l'allocation, le CIDR le plus proche est choisi et les CIDR de pod sont alloués à partir des CIDR disponibles.

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

  • Configurez les 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 comportent un nombre égal d'adresses IP allouables 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, car la différence est de 8.

• Plusieurs ClusterCIDRConfigs peuvent faire correspondre les étiquettes du nodeSelector aux étiquettes de nœud.

Règles d'attribution ClusterCIDRConfig

Pour déterminer le ClusterCIDRConfig utilisé pour attribuer des CIDR de pod au nœud actuel, utilisez les règles de détermination suivantes. Implémentez ces règles dans l'ordre indiqué. Implémentez la règle suivante uniquement si l'égalité n'est pas rompue par la règle précédente.

1. Sélectionnez le ClusterCIDRConfig dont le NodeSelector correspond au plus grand nombre d'étiquettes 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. Sélectionnez le ClusterCIDRConfig comportant le plus petit nombre 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 le ClusterCIDRConfig dont PerNodeMaskSize a le plus petit nombre d'adresses IP. Par exemple, 27 (2^(32-27)= 32 adresses IP) sélectionnées avant 25 (2^(32-25)=128 adresses IP).

4. Sélectionnez le ClusterCIDRConfig dont l'étiquette NodeSelector correspondante présente 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 le ClusterCIDRConfig dont l'adresse IP CIDR a une valeur inférieure. Quelle que soit la configuration (IPv4 ou double pile), 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 présente des exemples de configuration de Cluster et ClusterCIDRConfig pour tous les modes de réseau.

Attention : N'utilisez pas ces exemples tels qu'ils apparaissent ici. Remplacez les plages d'adresses par des valeurs adaptées à votre réseau.

Exemples : IPv4 en mode île (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 : IPv4 en mode plat

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 ClusterCIDRConfig par 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 d'un NodePool

Remarque : Les deux modes d'adresse IP plate présentent des contraintes différentes :

• Pour les adresses IP plates statiques (sans BGP) : ne peut être utilisé que si tous les nœuds se trouvent dans le même domaine de couche 2.
• Pour les adresses IP plates dynamiques (avec BGP) : peut être utilisé même lorsque les nœuds couvrent 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 nodeSelector n'est configuré

Remarque : Les deux modes d'adresse IP plate présentent des contraintes différentes :

• Pour les adresses IP plates statiques (sans BGP) : ne peut être utilisé que si tous les nœuds se trouvent dans le même domaine de couche 2.
• Pour les adresses IP plates dynamiques (avec BGP) : peut être utilisé même lorsque les nœuds couvrent 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 : double pile (IPv4 île, 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 ClusterCIDRConfig par 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 d'un NodePool

Remarque : Les deux modes d'adresse IP plate présentent des contraintes différentes :

• Pour les adresses IP plates statiques (sans BGP) : ne peut être utilisé que si tous les nœuds se trouvent dans le même domaine de couche 2.
• Pour les adresses IP plates dynamiques (avec BGP) : peut être utilisé même lorsque les nœuds couvrent 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 nodeSelector n'est configuré

Remarque : Les deux modes d'adresse IP plate présentent des contraintes différentes :

• Pour les adresses IP plates statiques (sans BGP) : ne peut être utilisé que si tous les nœuds se trouvent dans le même domaine de couche 2.
• Pour les adresses IP plates dynamiques (avec BGP) : peut être utilisé même lorsque les nœuds couvrent 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 : double pile (IPv4 plat, IPv6 plat)

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 ClusterCIDRConfig par nœud

Remarque : Les deux modes d'adresse IP plate présentent des contraintes différentes :

• Pour les adresses IP plates statiques (sans BGP) : ne peut être utilisé que si tous les nœuds se trouvent dans le même domaine de couche 2.
• Pour les adresses IP plates dynamiques (avec BGP) : peut être utilisé même lorsque les nœuds couvrent 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 d'un NodePool

Remarque : Les deux modes d'adresse IP plate présentent des contraintes différentes :

• Pour les adresses IP plates statiques (sans BGP) : ne peut être utilisé que si tous les nœuds se trouvent dans le même domaine de couche 2.
• Pour les adresses IP plates dynamiques (avec BGP) : peut être utilisé même lorsque les nœuds couvrent 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 nodeSelector 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