Entender o recurso personalizado ClusterCIDRConfig

Visão geral

O ClusterCIDRConfig é um recurso de alocação de CIDR personalizado que permite alocar mais intervalos de endereços IP para pods dinamicamente.

O gerenciamento de endereços IP (IPAM, na sigla em inglês) permite o uso eficiente de sub-redes IP e evita sobreposições em intervalos de endereços, o que evita conflitos e interrupções de rede. O Kubernetes atribui CIDRs de pod por nó, que são usados como endereços IP para os pods em execução nesse nó.

O NodeIPAM atual do Kubernetes tem as seguintes limitações:

• Todos os CIDRs do pod são alocados de um CIDR de cluster. Você precisa especificar todo o intervalo de endereços IP responsável pelo maior cluster no momento da criação dele. Essa limitação pode desperdiçar endereços IP.

• Se você aumentar o tamanho do cluster, será difícil adicionar mais endereços IP.

• O CIDR do cluster é um intervalo grande. Pode ser difícil encontrar um bloco contíguo de endereços IP que satisfaça as necessidades do cluster.

• Cada nó recebe um intervalo de IP de tamanho fixo dentro de um cluster. Se os nós forem de tamanhos e capacidades diferentes, não será possível alocar um intervalo de pod maior para um nó com capacidade maior e um intervalo menor para nós com capacidade menor. Isso desperdiça muitos endereços IP. Para um cluster grande com muitos nós, esse desperdício é agravado em todos os nós no cluster.

Com a funcionalidade ClusterCIDRConfig, é possível evitar a atribuição de um grande bloco CIDR a um cluster, mapear o tamanho do cluster para a escala dos pods e, assim, preservar endereços IP. É possível salvar endereços IP usando ClusterCIDRConfigs com combinações diferentes de CIDR e perNodeMaskSize. O recurso ClusterCIDRConfig é compatível com:

• Vários blocos CIDR descontínuos para CIDR de cluster em um nível mais granular

• Afinidade de nó de blocos CIDR

• Diferentes tamanhos de blocos alocados para os nós

O Google Distributed Cloud usa a funcionalidade ClusterCIDRConfig nos seguintes recursos:

• Rede de pilha dupla IPv4/IPv6

• Implementar o modelo de rede no modo IPv4 plano

• Implementar um modelo de rede no modo plano com suporte do BGP

Cluster.spec.clusterNetwork.pods.cidrBlocks é um campo opcional e não é definido por padrão. Você precisa defini-lo se algum dos recursos da lista anterior não o tiver definido. Por exemplo, ele é necessário quando os clusters são criados no modo de ilha IPv4 e precisa ser especificado porque é usado como um CIDR de roteamento nativo.

A tabela a seguir lista o uso do comportamento de campo Cluster.spec.clusterNetwork.pods.cidrBlocks do ClusterCIDRConfig para diferentes modos de rede.

Modo de rede	Valor ClusterCIDRConfig
Ilha IPv4 (padrão)	(Campo obrigatório) Especifique Cluster.spec.clusterNetwork.pods.cidrBlocks.
IPv4 plano (padrão)	Cluster.spec.clusterNetwork.pods.cidrBlocks são completamente ignorados e podem ser ignorados. Os usuários precisam definir explicitamente ClusterCIDRConfigs (por nó, pool de nós e/ou cluster).
Pilha dupla (Ilha IPv4, IPv4 plano)	Especifique o CIDR IPv4. Não especifique CIDR IPv6 em Cluster.spec.clusterNetwork.pods.cidrBlocks. Especifique ClusterCIDRConfigs com CIDRs IPv4 e IPv6. O CIDR IPv4 configurado em todos os ClusterCIDRConfigs precisa ser igual ao CIDR IPv4 de Cluster.spec.clusterNetwork.pods.cidrBlocks, incluindo o valor PerNodeMask para IPv4. Para mais informações sobre ClusterCIDRConfig e exemplos sobre como usá-lo, consulte Exemplos: Dualstack (ilha IPv4, plano IPv6)
Pilha dupla (IPv4 plano, IPv6 plano)	Você pode ignorar Cluster.spec.clusterNetwork.pods.cidrBlocks, porque eles são completamente ignorados. Você precisa definir explicitamente ClusterCIDRConfigs (por nó, pool de nós e/ou cluster) com CIDRs IPv4 e IPv6.

Como configurar o recurso alocador de CIDR personalizado de ClusterCIDRConfig

ClusterCIDRConfig

Ao configurar o recurso alocador de CIDR ClusterCIDRConfig personalizado, considere os seguintes pontos:

• A atribuição de CIDR de pod de um ClusterCIDRConfig específico para um nó é baseada em seletores de rótulo. Isso é semelhante ao mecanismo nodeSelector usado para programar pods em um nó.

• Você precisa configurar o ClusterCIDRConfig durante o processo de criação do cluster no arquivo YAML de configuração do cluster. Depois de especificar o ClusterCIDRConfigs, não será possível modificar os valores posteriormente.

• É possível especificar vários ClusterCIDRConfigs com CIDRs sobrepostos.

• Se nenhum ClusterCIDRConfig correspondente for encontrado para um nó, ele permanecerá em um estado NotReady até que um ClusterCIDRConfig com rótulos correspondentes seja criado.

• Se a melhor correspondência, ClusterCIDRConfig, não tiver mais CIDRs disponíveis para alocação, o próximo melhor CIDR será escolhido e os CIDRs de pods serão alocados dos CIDRs disponíveis.

• No caso do modelo de pilha dupla, se você quiser atribuir CIDRs de pod de pilha dupla aos nós, faça o seguinte:

  • Configurar CIDRs IPv4 e IPv6 no ClusterCIDRConfig.

  • Verifique se todos os ClusterCIDRConfig têm CIDRs DualStack, se vários ClusterCIDRConfig estiverem configurados.

  • Verifique se os CIDRs IPv4 e IPv6 configurados têm o mesmo número de endereços IP alocáveis por nó.

  Por exemplo, 32 - spec.IPv4.PerNodeMaskSize == 128 - spec.IPv6.PerNodeMaskSize.

  spec.IPv4.PerNodeMaskSize = 24

  spec.IPv6.PerNodeMaskSize = 120

  Assim, 32 - 24 == 128 - 120, já que a diferença é 8.

• Vários ClusterCIDRConfigs podem corresponder aos rótulos do nodeSelector aos rótulos dos nós.

Regras de atribuição ClusterCIDRConfig

Para determinar qual ClusterCIDRConfig é usado para atribuir CIDRs de pod ao nó atual, use as regras de quebra de vínculo a seguir. Implemente essas regras na ordem especificada. Implemente a próxima regra somente se o empate não for quebrado pela regra anterior.

1. Escolha o ClusterCIDRConfig em que o NodeSelector corresponde à maioria dos rótulos no nó. Por exemplo, {'node.kubernetes.io/instance-type':'medium', 'rack': 'rack1'} (Match Count: 2) é escolhido antes de {'node.kubernetes.io/instance-type': 'medium'}. (Match Count: 1).

2. Escolha o ClusterCIDRConfig com o menor número possível de CIDRs de pod alocáveis. Por exemplo, {CIDR: "10.0.0.0/16", PerNodeMaskSize: "16"} (1 possible Pod CIDR) é escolhido antes de {CIDR: "192.168.0.0/20", PerNodeMaskSize: "22"} (4 possible Pod CIDRs).

3. Escolha o ClusterCIDRConfig com o menor número de endereços IP que o PerNodeMaskSize. Por exemplo, 27 (2^(32-27)= 32 endereços IP) escolhidos antes de 25 (2^(32-25)=128 endereços IP).

4. Escolha o ClusterCIDRConfig, cujo rótulo do NodeSelector correspondente tem um valor alfanumérico mais baixo. Por exemplo, {'kubernetes.io/hostname': 'node-1'} é escolhido em vez de {'node.kubernetes.io/instance-type':'medium'}.

5. Escolha o ClusterCIDRConfig com o IP CIDR com um valor menor. Independentemente de ser uma configuração IPv4 ou DualStack, apenas os CIDRs IPv4 são comparados. Por exemplo, {CIDR: "10.0.0.0/16"} is picked over {CIDR: "192.168.0.0/16"}.

Exemplos de configuração

Essa seção lista exemplos de configuração para Cluster e ClusterCIDRConfig para todos os modos de rede.

Atenção: não use esses exemplos no estado em que se encontram. Substitua os intervalos de endereços por valores apropriados para sua rede.

Exemplos: IPv4 Island Mode (padrão)

Configuração de cluster (padrão)

    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)
  

Exemplos: modo plano IPv4

Configuração do 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

Exemplo 1: configurar por nó ClusterCIDRConfig

    ---
    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

  

Exemplo 2: exemplo de especificação de um PodCIDR de largura em NodePool

Observação: os dois modos de IP simples têm restrições diferentes:

• Para IP estático plano (sem BGP): só pode ser usado se todos os nós estão no mesmo domínio de camada 2.
• Para IP plano dinâmico (com BGP): pode ser usado mesmo quando os nós abrangem vários subdomínios.

    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
  

Exemplo 3: configurar o PodCIDR em todo o cluster: nenhum nodeSelector está configurado

Observação: os dois modos de IP simples têm restrições diferentes:

• Para IP estático plano (sem BGP): só pode ser usado se todos os nós estão no mesmo domínio de camada 2.
• Para IP plano dinâmico (com BGP): pode ser usado mesmo quando os nós abrangem vários subdomínios.

    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
  

Exemplos: Dualstack (IPv4 ilha, IPv6 plano)

Configuração do 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

Exemplo 1: configurar por nó ClusterCIDRConfig

    ---
    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
    

Exemplo 2: exemplo de especificação de um PodCIDR de largura em NodePool

Observação: os dois modos de IP simples têm restrições diferentes:

• Para IP estático plano (sem BGP): só pode ser usado se todos os nós estão no mesmo domínio de camada 2.
• Para IP plano dinâmico (com BGP): pode ser usado mesmo quando os nós abrangem vários subdomínios.

    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
    

Exemplo 3: configurar o PodCIDR em todo o cluster: nenhum nodeSelector está configurado

Observação: os dois modos de IP simples têm restrições diferentes:

• Para IP estático plano (sem BGP): só pode ser usado se todos os nós estão no mesmo domínio de camada 2.
• Para IP plano dinâmico (com BGP): pode ser usado mesmo quando os nós abrangem vários subdomínios.

    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
    

Exemplos: Dualstack (IPv4 plano, IPv6 plano)

Configuração do 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

Exemplo 1: configurar por nó ClusterCIDRConfig

Observação: os dois modos de IP simples têm restrições diferentes:

• Para IP estático plano (sem BGP): só pode ser usado se todos os nós estão no mesmo domínio de camada 2.
• Para IP plano dinâmico (com BGP): pode ser usado mesmo quando os nós abrangem vários subdomínios.

    ---
    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
    

Exemplo 2: exemplo de especificação de um PodCIDR de largura em NodePool

Observação: os dois modos de IP simples têm restrições diferentes:

• Para IP estático plano (sem BGP): só pode ser usado se todos os nós estão no mesmo domínio de camada 2.
• Para IP plano dinâmico (com BGP): pode ser usado mesmo quando os nós abrangem vários subdomínios.

    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
    

Exemplo 3: configurar o PodCIDR em todo o cluster: nenhum nodeSelector está configurado

    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