Cloud Native Network 2.0

Definição do modelo

Desenvolvido pelo CCE, o Cloud Native Network 2.0 integra profundamente Interfaces de rede elásticas (ENIs) e sub-ENIs da Virtual Private Cloud (VPC). Os endereços IP do contêiner são alocados a partir do bloco CIDR da VPC. A rede de passagem do ELB é suportada para direcionar solicitações de acesso a contêineres. Grupos de segurança e IPs elásticos (EIPs) são obrigados a oferecer alto desempenho.

Figura 1 Cloud Native Network 2.0

Comunicação pod a pod

• Pods em nós do BMS usam ENIs, enquanto pods em nós do ECS usam sub-ENIs. Sub-ENIs são anexadas a ENIs através de sub-interfaces de VLAN.
• No mesmo nó: os pacotes são encaminhados por meio da ENI ou sub-ENI da VPC.
• Entre os nós: os pacotes são encaminhados por meio da ENI ou sub-ENI da VPC.

Observações e restrições

Este modelo de rede está disponível apenas para clusters do CCE Turbo.

Vantagens e desvantagens

Vantagens

• Como a rede de contêineres usa diretamente a VPC, é fácil localizar problemas de rede e fornecer o mais alto desempenho.
• As redes externas em numa VPC não podem ser conectadas diretamente aos endereços IP do contêiner.
• Os recursos de balanceamento de carga, grupo de segurança e EIP fornecidos pela VPC podem ser usados diretamente pelos pods.

Desvantagens

A rede de contêineres usa diretamente a VPC, que ocupa o espaço de endereço da VPC. Portanto, você deve planejar corretamente o bloco CIDR do contêiner antes de criar um cluster.

Cenários de aplicações

• Requisitos de alto desempenho e uso de outros recursos de rede da VPC: o Cloud Native Network 2.0 usa diretamente a VPC, que oferece quase o mesmo desempenho que a rede da VPC. Portanto, aplica-se a cenários com altos requisitos de largura de banda e latência, como transmissão ao vivo e venda em flash de comércio eletrônico.
• Rede em grande escala: o Cloud Native Network 2.0 é compatível com um máximo de 2.000 nós do ECS e 100.000 contêineres.

Gerenciamento de endereços IP de contêiner

No modelo Cloud Native Network 2.0, os nós do BMS usam ENIs e os nós do ECS usam sub-ENIs.

• O endereço IP do pod é alocado diretamente da sub-rede da VPC configurada para a rede de contêineres. Você não precisa alocar um pequeno segmento de rede independente ao nó.
• Para adicionar um nó do ECS a um cluster, vincule primeiro a ENI que transporta a sub-ENI. Depois que a ENI é vinculado, você pode vincular a sub-ENI.
• Número de ENIs vinculadas a um nó ECS: número máximo de sub-ENIs que podem ser vinculadas ao node/64. O valor é arredondado para cima.
• ENI vinculadas a um nó do ECS = número de ENIs utilizadas para suportar sub-ENIs + número de sub-ENIs utilizadas atualmente por pods + número de sub-ENIs
• ENIs vinculadas a um nó do BMS = búmero de ENIs atualmente usadas por pods + número de ENIs pré-vinculadas
• Quando um pod é criado, uma ENI disponível é alocada aleatoriamente do pool de ENI pré-vinculada do nó.
• Quando o pod é excluído, a ENI é liberada de volta para o pool de ENI do nó.
• Quando um nó é excluído, as ENIs são liberadas de volta para o pool e as sub-ENIs são excluídas.

O Cloud Native Network 2.0 é compatível com políticas de pré-vinculação da ENI dinâmica e baseada em limites. A tabela a seguir lista os cenários.

• Para clusters de 1.19.16-r2, 1.21.5-r0, 1.23.3-r0 to 1.19.16-r4, 1.21.7-r0 e 1.23.5-r0, somente os parâmetros nic-minimum-target e nic-warm-target são suportados. A política de pré-vinculação baseada em limiares tem prioridade sobre a política de pré-vinculação dinâmica da ENI.
• Para conjuntos de 1.19.16-r4, 1.21.7-r0, 1.23.5-r0, 1.25.1-r0 ou posterior, os parâmetros anteriores são suportados. A política dinâmica de pré-vinculação da ENI tem prioridade sobre a política de pré-vinculação baseada em limites.

Figura 2 Política dinâmica de pré-vinculação da ENI

O CCE fornece quatro parâmetros para a política de pré-vinculação dinâmica da ENI. Defina esses parâmetros corretamente.

Os parâmetros anteriores oferecem suporte à configuração global no nível do cluster e às configurações personalizadas no nível do pool de nós. Este último tem prioridade sobre o primeiro.

Quando um pod é criado, uma ENI ociosa (a mais antiga não utilizada) é preferencialmente alocado do pool. Se nenhuma ENI ociosa estiver disponível, uma newsub-ENI será vinculada ao pod.

Quando o pod é excluído, a ENI correspondente é liberada de volta ao pool de ENI vinculada do nó, entra em um período de resfriamento de 2 minutos e pode ser vinculada a outro pod. Se a ENI não estiver vinculada a nenhum pod dentro de 2 minutos, ela será liberada.

Figura 3 Política baseada em limites

O CCE fornece um parâmetro de configuração para os algoritmos de limite. Você pode definir esse parâmetro com base no plano de serviço, na escala do cluster e no número de ENIs que podem ser vinculadas a um nó.

• Limite baixo do número de ENIs vinculadas: o padrão é 0, indicando o número mínimo de ENIs (não utilizadas) vinculadas a um nó. Número mínimo de ENIs pré-vinculadas num nó ECS = número de ENIs vinculadas ao nó no limite baixo x número de sub-ENIs no nó. Número mínimo de ENIs pré-vinculadas num nó do BMS = número de ENIs vinculadas ao nó no limite baixo x número de ENIs no nó.
• Limite elevado do número de ENIs vinculadas: o padrão é 0, indicando o número máximo de ENIs que podem ser vinculadas a um nó. Se o número de ENIs vinculadas a um nó exceder o valor desse parâmetro, o sistema desvinculará as ENIs ociosas. Número máximo de ENIs vinculadas num nó do ECS = número de ENIs vinculada no limite elevado x número de sub-ENIs no nó. Número máximo de ENIs pré-vinculadas num nó do BMS = número de ENIs vinculadas no limite elevado x número de ENIs no nó.

O componente de rede de contêineres mantém um pool de ENI escalável para cada nó.

• Se o número de ENIs vinculadas (ENIs pré-vinculadas usadas) for menor que o número de ENIs pré-vinculadas no limite baixo, as ENIs serão vinculadas até que os dois números sejam iguais.
• Se o número de ENIs vinculadas (ENIs pré-vinculadas utilizadas) for superior ao número de ENIs pré-vinculadas no limite elevado e o número de ENIs pré-vinculadas for superior a 0, as ENI pré-vinculadas que não são utilizadas durante mais de 2 minutos serão libertas periodicamente até que o número de ENIs vinculadas = número de ENIs pré-vinculadas no limite elevado ou o número de ENIs utilizadas seja superior ao número de ENIs pré-vinculadas no limite elevado e o número de ENIs pré-vinculadas no nó é 0.

Recomendação para planejamento de blocos CIDR

Conforme descrito em Estrutura de rede do cluster, os endereços de rede em um cluster podem ser divididos em três partes: rede de nó, rede de contêineres e rede de serviço. Ao planejar endereços de rede, considere os seguintes aspectos:

• Os três blocos CIDR não podem se sobrepor. Caso contrário, ocorre um conflito. Todas as sub-redes (incluindo aquelas criadas a partir do bloco CIDR secundário) na VPC em que o cluster reside não podem entrar em conflito com o contêiner e os blocos CIDR de Serviço.
• Certifique-se de que cada bloco CIDR tenha endereços IP suficientes.
  • Os endereços IP no bloco CIDR do nó devem corresponder à escala do cluster. Caso contrário, os nós não podem ser criados devido a endereços IP insuficientes.
  • Os endereços IP no bloco CIDR do contêiner devem corresponder à escala de serviço. Caso contrário, os pods não podem ser criados devido a endereços IP insuficientes.

No modelo Cloud Native Network 2.0, o bloco CIDR do contêiner e o bloco CIDR do nó compartilham os endereços de rede em uma VPC. Recomenda-se que a sub-rede do contêiner e a sub-rede do nó não usem a mesma sub-rede. Caso contrário, contêineres ou nós podem não ser criados devido a recursos IP insuficientes.

Além disso, uma sub-rede pode ser adicionada ao bloco CIDR do contêiner depois que um cluster é criado para aumentar o número de endereços IP disponíveis. Nesse caso, certifique-se de que a sub-rede adicionada não entra em conflito com outras sub-redes no bloco CIDR do contêiner.

Figura 4 Configurar os blocos CIDR (ao criar o cluster)

Exemplo de acesso ao Cloud Native Network 2.0

Crie um cluster do CCE Turbo, que contenha três nós do ECS.

Acesse a página de detalhes de um nó. Você pode ver que o nó tem uma ENI primária e uma ENI estendida, e ambas são ENIs. A ENI estendida pertence ao bloco CIDR do contêiner e é usado para montar uma sub-ENI no pod.

Figura 5 ENIs de nó

Crie uma Implementação no cluster.

kind: Deployment
apiVersion: apps/v1
metadata:
  name: example
  namespace: default
spec:
  replicas: 6
  selector:
    matchLabels:
      app: example
  template:
    metadata:
      labels:
        app: example
    spec:
      containers:
        - name: container-0
          image: 'nginx:perl'
          resources:
            limits:
              cpu: 250m
              memory: 512Mi
            requests:
              cpu: 250m
              memory: 512Mi
      imagePullSecrets:
        - name: default-secret

Visualize o pod criado.

$ kubectl get pod -owide
NAME                       READY   STATUS    RESTARTS   AGE   IP            NODE         NOMINATED NODE   READINESS GATES
example-5bdc5699b7-54v7g   1/1     Running   0          7s    10.1.18.2     10.1.0.167   <none>           <none>
example-5bdc5699b7-6dzx5   1/1     Running   0          7s    10.1.18.216   10.1.0.186   <none>           <none>
example-5bdc5699b7-gq7xs   1/1     Running   0          7s    10.1.16.63    10.1.0.144   <none>           <none>
example-5bdc5699b7-h9rvb   1/1     Running   0          7s    10.1.16.125   10.1.0.167   <none>           <none>
example-5bdc5699b7-s9fts   1/1     Running   0          7s    10.1.16.89    10.1.0.144   <none>           <none>
example-5bdc5699b7-swq6q   1/1     Running   0          7s    10.1.17.111   10.1.0.167   <none>           <none>

Os endereços IP de todos os pods são sub-ENIs, que são montados na ENI (ENI estendida) do nó.

Por exemplo, a ENI estendida do nó 10.1.0.167 é 10.1.17.172. Na página Network Interfaces do Console de rede, você pode ver que três sub-ENIs estão montadas na ENI estendida 10.1.17.172, que é o endereço IP do pod.

Figura 6 ENIs de pod

Na VPC, o endereço IP do pod pode ser acessado com êxito.