Terway vs. Flannel - Container Service for Kubernetes: Central de Documentação do Alibaba Cloud

ACK oferece o Terway para redes de alto desempenho baseadas em ENI e o Flannel para clusters mais simples com roteamento via VPC.

Desenvolvido pela Alibaba Cloud, o Terway utiliza ENIs para a rede dos pods e fornece recursos como aceleração de rede baseada em eBPF, NetworkPolicy, além de vSwitches e grupos de segurança no nível do pod. É ideal para cenários que exigem grande escala de nós, alto desempenho de rede e segurança robusta, como computação de alto desempenho (HPC), jogos e microsserviços.
O Flannel é um plugin CNI open source. No ACK, ele opera no modo de rede VPC da Alibaba Cloud e encaminha pacotes diretamente pela tabela de rotas da VPC. Recomendado para clusters de pequena escala que precisam de uma rede simplificada, sem controle granular da rede de contêineres.

Importante

Instale um plugin CNI ao criar o cluster. Não é possível alterar o plugin posteriormente.
No Flannel, o ALB Ingress encaminha requisições apenas para serviços NodePort e LoadBalancer. Serviços ClusterIP não são suportados.

Item	Terway	Flannel
Desempenho de rede	O Terway supera o Flannel da comunidade em TCP RR, UDP PPS, largura de banda e latência. Nota Os dados de teste são valores teóricos baseados em instâncias ecs.ebmg5s.24xlarge e podem variar conforme o ambiente. Consulte a Comunidade Cloud Native da Alibaba Cloud. O Terway suporta o modo de ENI exclusiva, no qual cada pod possui uma ENI dedicada para garantir desempenho superior de rede. Indicado para cenários como HPC, jogos e microsserviços. O Terway também oferece o modo de ENI compartilhada com aceleração DataPath V2, uma evolução da solução IPVLAN. Para tráfego intracluster, o DataPath V2 utiliza eBPF para contornar a pilha de rede do nó e proporcionar acesso mais rápido. Nota No modo DataPath V2, os dados de conntrack do contêiner ficam armazenados em um mapa eBPF. Assim como o conntrack do Linux, ele emprega um algoritmo LRU que remove os registros mais antigos quando o mapa está cheio. Otimize as configurações de conntrack para evitar a ultrapassagem dos limites de conexão.
Cota de nós	O número máximo de nós em um cluster Terway depende do limite de capacidade do cluster. Cluster ACK Pro: suporta 5.000 nós por padrão e até 15.000 nós no máximo. Cluster ACK Basic: 10 nós.	A quantidade máxima de nós em um cluster Flannel varia conforme as entradas na tabela de rotas da VPC e o limite de capacidade do cluster. A tabela de rotas da VPC aceita 200 entradas por padrão, podendo chegar a 1.000 após aumento de cota. Como cada nó consome uma entrada, um cluster Flannel comporta até 1.000 nós. Cluster ACK Pro: suporta 200 nós por padrão e até 1.000 nós no máximo. Cluster ACK Basic: 10 nós.
Pods por nó	Os pods utilizam as ENIs do nó. O limite de pods por nó depende do tipo de instância e de métricas como ENIs e número de endereços IPv4 privados por ENI. Por exemplo, uma instância Otimizada para computação c7 (ecs.c7.4xlarge, 16 vCPUs, 32 GiB): No modo de ENI compartilhada, o nó executa no máximo 210 pods. No modo de ENI exclusiva, o nó executa no máximo 7 pods. Embora as instâncias Otimizada para computação c6 e Otimizada para computação c7 tenham a mesma quantidade de ENIs, uma instância Otimizada para computação c6 roda até 140 pods no modo de ENI compartilhada, pois possui menos endereços IPv4 privados por ENI. Consulte Calcular a cota de pods por nó.	O número máximo de pods por nó depende do parâmetro Number of Pods per Node e da máscara de sub-rede do Container CIDR Block. Por exemplo, se o bloco CIDR de pods de um cluster ACK Pro for 172.16.0.0/20, cada nó poderá executar até 256 pods e o cluster suportará até 16 nós. Importante Não é possível alterar o número máximo de nós em um cluster Flannel após a criação.
Bloco CIDR de pods	O bloco CIDR de pods é alocado a partir do bloco CIDR da VPC e consome muitos endereços IP da VPC. Planeje uma VPC com endereços IP suficientes. O bloco CIDR de pods e o CIDR de serviço devem ser independentes e não podem se sobrepor. Os blocos CIDR não podem ser modificados. É possível expandir o bloco CIDR de pods adicionando vSwitches.	O bloco CIDR de pods é independente do bloco CIDR da VPC. O Flannel atribui a cada nó uma sub-rede desse bloco para alocação de IPs dos pods. O bloco CIDR de pods, o CIDR de nós (bloco CIDR da VPC) e o CIDR de serviço devem ser independentes e não podem se sobrepor. Os blocos CIDR não podem ser modificados. Não é possível expandir o bloco CIDR de pods.
Segurança de rede	Configure vSwitches e grupos de segurança independentes para os pods. Suporta Kubernetes NetworkPolicy para controle de acesso no nível do contêiner.	Não é possível configurar vSwitches e grupos de segurança independentes para os pods. Não suporta NetworkPolicy.
Dual-stack IPv4/IPv6	Suporta rede dual-stack.	Não suporta rede dual-stack. Nota O ACK utiliza uma versão modificada do plugin Flannel, que nem sempre está sincronizada com a comunidade open source. Consulte as Notas de versão do Flannel.
IP estático de pod	Suporta endereços IP estáticos para pods.	Não suporta endereços IP estáticos para pods.
Persistência de sessão	Como os backends de balanceamento de carga se conectam diretamente aos pods, a persistência de sessão garante a disponibilidade do serviço mesmo que os pods de backend mudem.	Os backends de balanceamento de carga usam NodePort para se conectar aos pods. Se um pod de backend for substituído, o tráfego será interrompido, o que pode causar novas tentativas de serviço.
Comunicação multicluster	Pods em clusters diferentes podem se comunicar se as portas necessárias estiverem abertas nos grupos de segurança.	Não suportado.
Preservação do IP de origem do pod	Quando um pod acessa outros endpoints da VPC, seu IP original é preservado como IP de origem, simplificando a auditoria.	Quando um pod acessa outros endpoints da VPC, seu IP de origem é substituído pelo IP do nó.

Próximas etapas

Os blocos CIDR de pods, serviços e nós não podem ser modificados após a criação do cluster. Seus tamanhos determinam os limites de recursos e afetam a capacidade de implantação. Blocos CIDR separados permitem isolamento de recursos no nível de rede para controle de acesso e roteamento personalizado. Planejar redes para clusters gerenciados pelo ACK antes de criar um cluster.
Após o planejamento da rede:
- Para usar o Terway, instale o plugin CNI Terway durante a criação do cluster.
- Para usar o Flannel, instale o plugin CNI Flannel durante a criação do cluster.

Referências

Para limites de nós do cluster e aumentos de cota, consulte Cotas e limites.
Consulte o FAQ sobre redes de contêineres.