Como planejar a rede de um cluster gerenciado ACK - Container Service for Kubernetes: Central de Documentação do Alibaba Cloud

Planejamento de escala de rede

Região e zona

Todas as zonas de uma região se comunicam pela rede interna, mas permanecem isoladas contra falhas umas das outras. A VPC é um recurso regional e não abrange várias regiões.

Ao selecionar uma região e uma zona, considere os seguintes fatores:

Fator	Descrição
Latência	Implante próximo aos usuários finais para minimizar a latência de rede.
Disponibilidade do serviço	Os serviços da Alibaba Cloud variam conforme a região e a zona. Verifique a disponibilidade na sua região de destino.
Custo	Os preços dos serviços em nuvem variam por região. Escolha uma região adequada ao seu orçamento.
Alta disponibilidade e recuperação de desastres	Para cargas de trabalho que exigem alta disponibilidade, implante em múltiplas zonas dentro da mesma região. Para maior isolamento, implante em várias regiões.
Conformidade	Selecione uma região que atenda aos seus requisitos de residência de dados e regulamentações.

Consulte Regiões disponíveis.

Uma VPC não abrange várias regiões. Para sistemas multirregião, crie uma VPC por região e conecte-as usando conexões de peering de VPC , VPN Gateway ou Cloud Enterprise Network (CEN) . O vSwitch é um recurso zonal.

Quantidade de VPCs

As VPCs são totalmente isoladas. Por padrão, os recursos na mesma VPC se comunicam pela rede privada.

Cenário	Caso de uso
VPC única	Implantações pequenas em uma única região sem necessidade de isolamento. Configurações sensíveis a custos que evitam sobrecarga entre VPCs.
Múltiplas VPCs	Implantações multirregião. Sistemas que exigem isolamento rigoroso (por exemplo, produção e staging). Arquiteturas com várias equipes e gerenciamento independente de recursos.

Cota padrão: 10 VPCs por região. Aumente esse limite pela página Gerenciamento de Cotas ou pelo Quota Center .

Quantidade de vSwitches

O vSwitch é um recurso zonal. Os recursos de nuvem em uma VPC conectam-se a vSwitches, que se comunicam entre si por padrão.

Fator	Orientação
Latência	A latência entre zonas é baixa, mas aumenta com chamadas de sistema complexas e tráfego cruzado. Equilibre alta disponibilidade e latência.
Alta disponibilidade	Crie pelo menos dois vSwitches em zonas diferentes. Se uma zona falhar, a outra continuará atendendo ao tráfego.
Divisão de negócios	Agrupe vSwitches por função (por exemplo, camadas web, lógica e dados). Use um vSwitch público dedicado para serviços voltados à Internet e simplifique as regras de segurança.

Cota padrão: 150 vSwitches por VPC. Aumente esse limite pela página Gerenciamento de Cotas ou pelo Quota Center .

Tamanho do cluster

Número de nós	Caso de uso	Planejamento de VPC	Planejamento de zonas
Menos de 100 nós	Cargas de trabalho não essenciais	VPC única	1 (recomendado 2 ou mais)
100 ou mais nós	Cargas de trabalho gerais que exigem redundância multizona	VPC única	2 ou mais
100 ou mais nós	Cargas de trabalho essenciais que exigem alta confiabilidade em várias regiões	Múltiplas VPCs	2 ou mais

Planejamento de conectividade de rede

Cluster único em uma única VPC

O bloco CIDR de uma VPC é fixo no momento da criação. Atribua blocos CIDR de pods e serviços sem sobreposição para cada cluster.

Múltiplos clusters em uma única VPC

Vários clusters podem compartilhar uma única VPC. Ao planejar os blocos CIDR para cada cluster:

O bloco CIDR da VPC é fixo na criação. Cada cluster deve usar blocos CIDR sem sobreposição para a VPC, serviços e pods.
Os blocos CIDR de pods entre clusters não devem se sobrepor. Os blocos CIDR de serviços são redes virtuais e podem se sobrepor entre clusters.
No modo Flannel, os pacotes dos pods trafegam pela VPC. O ACK adiciona automaticamente rotas para cada bloco CIDR de pod na tabela de rotas da VPC.

Nesta topologia, os pods de um cluster podem acessar pods e instâncias ECS em outros clusters, mas não seus serviços ClusterIP, pois estes são locais ao cluster. Use LoadBalancer ou Ingress para acesso a serviços entre clusters.

Conectividade inter-VPC com múltiplos clusters

Planeje a conectividade inter-VPC para os cenários abaixo.

Implantação multirregião

A VPC é um recurso regional. Para sistemas multirregião, crie uma VPC e um cluster por região e conecte-os usando conexões de peering de VPC, VPN Gateway ou Cloud Enterprise Network (CEN).

Isolamento de múltiplos sistemas de negócios

Para isolamento rigoroso de rede entre sistemas em uma mesma região (como produção e staging), implante cada um em uma VPC separada. Conecte-os usando conexões de peering de VPC, VPN Gateway ou Cloud Enterprise Network (CEN).

Arquitetura multiequipe em larga escala

Implante VPCs separadas por equipe para gerenciar clusters e recursos de forma independente. Essa abordagem simplifica o controle de acesso e aumenta a flexibilidade.

Importante

Para evitar conflitos de IP em configurações inter-VPC com múltiplos clusters, verifique se os blocos CIDR de cada novo cluster não se sobrepõem a:

Qualquer bloco CIDR de VPC na rede conectada
Qualquer bloco CIDR de outro cluster
Qualquer bloco CIDR de pods de outro cluster
Qualquer bloco CIDR de serviços de outro cluster

Conectividade entre cluster na nuvem e data center local

Ao conectar um cluster a um data center local (IDC), os endereços dos pods não devem se sobrepor aos blocos CIDR da VPC roteados para o IDC. Se o IDC precisar de acesso direto aos endereços dos pods, configure rotas no Virtual Border Router (VBR) no lado do IDC.

Planejamento do plugin CNI

O ACK suporta dois plugins CNI: Terway e Flannel. O plugin é imutável após a criação do cluster e determina os recursos de rede disponíveis e a configuração de CIDR.

Escolha um plugin CNI

Escolha o plugin adequado às suas necessidades:

	Terway	Flannel
Mais indicado para	Cargas de trabalho que precisam de NetworkPolicy, IPs fixos para pods, endereços IP elásticos (EIPs) vinculados a pods ou acesso entre clusters	Configurações mais simples onde esses recursos não são necessários
Origem do IP do pod	IPs atribuídos a partir de vSwitches da VPC	IPs atribuídos a partir de um bloco CIDR virtual
Tamanho do pool de IPs	Limitado pelo tamanho do bloco CIDR do vSwitch	Até 65.536 IPs de pods com um bloco CIDR de contêiner /16
IPv6	Suportado	Não suportado

Comparação de recursos

Recurso	Terway	Flannel
NetworkPolicy	Suportado	Não suportado
Pilha dupla IPv4/IPv6	Suportado	Não suportado
IP fixo para pod	Suportado	Não suportado
EIP vinculado ao pod	Suportado	Não suportado
Acesso entre clusters	Suportado (quando os grupos de segurança permitem as portas necessárias)	Não suportado

O ACK utiliza uma versão modificada do plugin Flannel, otimizada para a Alibaba Cloud; ele não acompanha as alterações upstream. Consulte Flannel para o histórico de atualizações.

Consulte Plugins de rede de contêiner Terway vs. Flannel.

Planejamento de blocos CIDR

Modo de rede Terway

No modo Terway, os pods recebem IPs de vSwitches dedicados. Dimensione os blocos CIDR dos vSwitches de pods para acomodar todos os pods em nós e zonas, incluindo margem para atualizações contínuas (rolling upgrades).

terway

Configuration examples

Zona única:

Bloco CIDR da VPC	Bloco CIDR do vSwitch	Bloco CIDR do vSwitch de pods	Bloco CIDR de serviços	Máximo de IPs de pods atribuíveis
192.168.0.0/16	Zona I: 192.168.0.0/19	192.168.32.0/19	172.21.0.0/20	8.192

Multizona:

Bloco CIDR da VPC	Bloco CIDR do vSwitch	Bloco CIDR do vSwitch de pods	Bloco CIDR de serviços	Máximo de IPs de pods atribuíveis
192.168.0.0/16	Zona I: 192.168.0.0/19	192.168.32.0/19	172.21.0.0/20	8.192
	Zona J: 192.168.64.0/19	192.168.96.0/19

VPC

Use um dos seguintes blocos CIDR privados padrão RFC (ou uma sub-rede) como bloco CIDR IPv4 primário da sua VPC: 192.168.0.0/16, 172.16.0.0/12 ou 10.0.0.0/8. Os comprimentos de máscara válidos variam de /8 a /28 (dependendo do bloco). Exemplo: 192.168.0.0/16.

Para implantações com múltiplas VPCs ou nuvem híbrida, use sub-redes com máscara /16 ou menor. Garanta que não haja sobreposição entre VPCs ou com data centers locais.

As VPCs atribuem blocos CIDR IPv6 automaticamente quando você ativa o IPv6. Para usar IPv6 em contêineres, escolha o Terway.

Para usar um intervalo de IP público no bloco CIDR da sua VPC, solicite a cota ack.white_list/supportVPCWithPublicIPRanges no Quota Center .

vSwitch

Os vSwitches hospedam instâncias ECS e lidam com o tráfego entre nós. O bloco CIDR do vSwitch deve ser um subconjunto do bloco CIDR da VPC.

As instâncias ECS obtêm IPs deste bloco CIDR. Dimensione-o para todos os nós.
Múltiplos vSwitches em uma mesma VPC não devem ter blocos CIDR sobrepostos.
Cada vSwitch de pods deve estar na mesma zona que seu vSwitch de nós correspondente.

vSwitch de pods

O vSwitch de pods atribui IPs aos pods e gerencia o tráfego deles. Seu bloco CIDR deve ser um subconjunto do bloco CIDR da VPC.

Dimensione para o número máximo esperado de pods, mais uma margem para atualizações.
O bloco CIDR do vSwitch de pods não deve se sobrepor ao bloco CIDR de serviços.

Bloco CIDR de serviços

Importante

O bloco CIDR de serviços é imutável após a criação do cluster.

O bloco CIDR de serviços define o intervalo de IP para serviços ClusterIP. Cada serviço recebe um IP.

Os IPs de serviços são acessíveis apenas dentro do cluster, não externamente.
O bloco CIDR de serviços não deve se sobrepor ao bloco CIDR do vSwitch nem ao bloco CIDR do vSwitch de pods.

Bloco CIDR IPv6 de serviços (quando a pilha dupla IPv6 está ativada)

Use um Unique Local Address (ULA) no intervalo fc00::/7. O comprimento do prefixo deve estar entre /112 e /120.
Corresponda ao número de endereços utilizáveis no bloco CIDR de serviços.

Modo de rede Flannel

No modo Flannel, os IPs dos pods vêm de um bloco CIDR de contêiner virtual, não vinculado a nenhum vSwitch. Os pacotes dos pods trafegam pela VPC, e o ACK adiciona automaticamente rotas para cada bloco CIDR de pod na tabela de rotas da VPC.

Flannel network diagram

Configuration example

Bloco CIDR da VPC	Bloco CIDR do vSwitch	Bloco CIDR de contêiner	Bloco CIDR de serviços	Máximo de IPs de pods atribuíveis
192.168.0.0/16	192.168.0.0/24	172.20.0.0/16	172.21.0.0/20	65.536

VPC

Use um dos seguintes blocos CIDR privados padrão RFC (ou uma sub-rede) como bloco CIDR IPv4 primário da sua VPC: 192.168.0.0/16, 172.16.0.0/12 ou 10.0.0.0/8. Os comprimentos de máscara válidos variam de /8 a /28 (dependendo do bloco). Para implantações com múltiplas VPCs ou nuvem híbrida, use uma máscara /16 ou menor, sem sobreposições entre VPCs ou com data centers locais.

Para usar um intervalo de IP público no bloco CIDR da sua VPC, solicite a cota ack.white_list/supportVPCWithPublicIPRanges no Quota Center .

vSwitch

As instâncias ECS obtêm IPs deste bloco CIDR. Dimensione-o para todos os nós.
Múltiplos vSwitches em uma mesma VPC não devem ter blocos CIDR sobrepostos.

Bloco CIDR de contêiner

Importante

O bloco CIDR de contêiner é imutável após a criação do cluster.

Este bloco CIDR virtual atribui IPs aos pods em todo o cluster.

Não está vinculado a nenhum vSwitch.
Não deve se sobrepor ao bloco CIDR do vSwitch nem ao bloco CIDR de serviços.

Por exemplo, se o bloco CIDR da sua VPC for 172.16.0.0/12, não use 172.16.0.0/16 ou 172.17.0.0/16 para o bloco CIDR de contêiner, pois ambos estão contidos em 172.16.0.0/12.

Bloco CIDR de serviços

Importante

O bloco CIDR de serviços é imutável após a criação do cluster.

O bloco CIDR de serviços define o intervalo de IP para serviços ClusterIP.

Os IPs de serviços são acessíveis apenas dentro do cluster.
O bloco CIDR de serviços não deve se sobrepor ao bloco CIDR do vSwitch nem ao bloco CIDR de contêiner.

Próximos passos

Usar blocos CIDR secundários da VPC: Configure SNAT em um NAT Gateway e atualize as regras do grupo de segurança ao expandir com blocos CIDR secundários ou novas zonas.
Planejamento de contas: Planeje a estrutura de contas para isolar permissões e cargas de trabalho conforme seu negócio cresce.
Planejamento de capacidades de segurança: Defina controles de segurança com base na sua topologia de conectividade de rede e nos requisitos de segurança.
Planejamento de recuperação de desastres: Estruture a recuperação de desastres com base na arquitetura do seu negócio para proteger dados e garantir continuidade.
Acessar o servidor de API pela Internet: Exponha o servidor de API do seu cluster à Internet usando um endereço IP elástico (EIP).
Ativar acesso de saída à Internet para o cluster: Configure SNAT para acesso de saída a recursos públicos, como registros de imagens ou bibliotecas de dependências.
FAQ sobre gerenciamento de rede: Problemas comuns de rede em clusters gerenciados ACK.