Container Service for Kubernetes:Terway network plugin

Antes de começar

Compreenda os modos de operação do Terway, planeje a rede e crie um cluster.

Leia Networking overview e Terway vs. Flannel CNI plugins e escolha um plugin de rede.

Planeje os blocos CIDR e crie um cluster. Consulte ACK managed cluster network planning.

Faturamento

O plugin Terway é gratuito, mas seus pods consomem uma pequena quantidade de recursos em cada nó. Para informações sobre o faturamento dos serviços cloud do ACK, consulte Cloud resource costs.

Notas de uso

O arquivo eni-config contém parâmetros críticos do sistema. modifique ou exclua campos não permitidos pode causar interrupções na rede ou falhas na criação de pods. Para parâmetros personalizáveis, consulte Customize Terway parameters.

O Terway usa CRDs para rastrear o status dos recursos. Não modifique esses recursos do sistema, pois alterações não autorizadas podem causar interrupções na rede ou falhas na criação de pods.

Número máximo de pods por nó

O número máximo de pods por nó depende da quantidade de interfaces de rede elásticas (ENIs) compatíveis com o tipo de instância ECS. Cada nó deve atender a um limite mínimo de pods para ingressar no cluster.

instale o plugin de rede Terway

Ao criar um cluster, selecione o plugin de rede Terway. Não é possível alterar o plugin de rede posteriormente.

1. Acesse o ACK console. No painel de navegação à esquerda, clique em Clusters.

2. Na página Clusters, clique em Create Kubernetes Cluster.

3. É necessário que você configure os parâmetros de rede do Terway. Para outros parâmetros, consulte Create an ACK managed cluster.

   Parâmetro	Descrição
   IPv6 Dual-stack	Por favor, selecione Enable e crie um cluster dual-stack com suporte a IPv4 e IPv6. Este recurso está disponível apenas para o Kubernetes 1.22 ou posterior e é compatível apenas com o Terway. Não pode ser usado com o recurso elastic Remote Direct Memory Access (eRDMA) O cluster é compatível com os protocolos IPv4 e IPv6. No entanto, a comunicação entre os nós de trabalho e o plano de controle ainda utiliza endereços IPv4. Certifique-se de que: A VPC do cluster seja compatível com o dual-stack IPv6. Ao usar o Terway no modo de ENI compartilhada, o tipo de instância do nó deve ser compatível com IPv6 e ter o mesmo número de endereços IPv4 e IPv6 suportados.
   VPC	A VPC para o cluster.
   Network Plug-in	Por favor, selecione Terway.
   DataPath V2	Ative a aceleração DataPath V2, que utiliza um caminho de encaminhamento de tráfego diferente do modo padrão de ENI compartilhada para aceleração de rede. Consulte Best practices for Terway with Datapath V2. Nota Em novos clusters com Kubernetes 1.34 ou posterior que utilizam o DataPath V2, o kube-proxy deixa de ser executado nos nós do Terway. Este modo inclui suporte integrado a portmap. Consulte Configure a custom CNI chain. O DataPath V2 é compatível apenas com as seguintes imagens de sistema operacional e requer o kernel Linux 5.10 ou posterior: Alibaba Cloud Linux 4 Alibaba Cloud Linux 3 (todas as versões) ContainerOS Ubuntu Quando ativado, o contêiner de políticas em cada nó consome cerca de 0,5 núcleos de CPU e 512 MB de memória, e esse consumo aumenta conforme o tamanho do cluster. Limite padrão de CPU: 1 núcleo; sem limite de memória. No modo DataPath V2, as informações do conntrack são armazenadas em um mapa eBPF com evição LRU. Configure os limites do mapa com base na sua carga de trabalho para evitar a ultrapassagem do limite de conexões. Consulte Optimize conntrack configurations in Terway mode.
   NetworkPolicy support	Para ativar, selecione esta opção para ativar o NetworkPolicy nativo do Kubernetes. Nota A partir do Terway v1.9.2, o NetworkPolicy em novos clusters utiliza eBPF com DataPath V2 para o plano de dados. O recurso que permite gerenciar NetworkPolicy no console está em preview público. Para usá-lo, envie uma solicitação no Quota Center console.
   Support for ENI Trunking	Para ativar o modo Trunk ENI, selecione permitindo um IP estático, vSwitch dedicado e grupo de segurança separado por pod. Nota É possível ativar o Trunk ENI para ACK managed clusters sem enviar uma solicitação. Para ativar o Trunk ENI em um ACK dedicated cluster, envie primeiro uma solicitação no Quota Center console. Em ACK managed clusters recém-criados com Kubernetes 1.31 ou posterior, o recurso Trunk ENI é ativado automaticamente. Não é necessário selecioná-lo manualmente.
   vSwitch	Os vSwitches para os nós do cluster. É recomendável que você selecione vSwitches de pelo menos três zonas de disponibilidade para alta disponibilidade.
   Pod vSwitch	O bloco CIDR do vSwitch do pod pode se sobrepor ao bloco CIDR do vSwitch do nó. O Terway atribui endereços IP aos pods a partir do bloco CIDR do vSwitch do pod, o que consome recursos de IP da VPC. Se os recursos de IP se esgotarem rapidamente, acesse a página VPC console - vSwitches para verificar quais product cloud, como ECS, SLB e NAT Gateway, estão consumindo os endereços IP.
   Service CIDR	O bloco CIDR para os Services do Kubernetes. Não deve se sobrepor aos blocos CIDR de nós ou pods.
   IPv6 Service CIDR Block	É possível configurar o bloco CIDR do Service IPv6 após ativar o recurso de dual-stack IPv6.

Modos de operação do Terway

O Terway é compatível com os modos de ENI compartilhada e exclusiva, cada um com diferentes compensações entre desempenho e recursos.

Modo de ENI compartilhada e modo de ENI exclusiva

O Terway fornece dois modos para atribuir endereços IP aos pods: modo de ENI compartilhada e modo de ENI exclusiva.

Importante

• A partir do Terway v1.11.0, o modo de ENI é selecionado por pool de nós, e não mais no nível do cluster.

• O sistema operacional do nó usa a ENI primária; o Terway gerencia as demais para a rede dos pods. Não configure essas ENIs manualmente. Se precisar, gerencie ENIs específicas conforme Configure a filter for ENIs.

Item		Modo de ENI compartilhada	Modo de ENI exclusiva
Gerenciamento de endereços IP dos pods	Alocação de ENI	Vários pods compartilham uma ENI.	Cada pod recebe uma ENI dedicada em seu nó.
	Densidade de implantação de pods	Alta densidade, com suporte a centenas de pods em um único nó.	Baixa densidade. Um nó típico tem capacidade para apenas alguns pods.
	Arquitetura de rede
	Caminho de dados	O tráfego entre pods e para o backend do Service passa pela pilha de rede do nó.	O acesso ao Service utiliza a pilha de rede do sistema operacional do nó, mas o tráfego entre pods e para o backend do Service contorna a pilha por meio da ENI dedicada, garantindo melhor desempenho.
Cenários		Cargas de trabalho Kubernetes de uso geral.	Oferece desempenho de rede comparável ao de VMs, ideal para aplicações de alto throughput ou baixa latência.
Aceleração de rede		Compatível com a aceleração de rede do DataPath V2.	Não compatível. A ENI exclusiva já oferece alto desempenho de rede por meio de ENIs dedicadas aos pods.
Suporte a NetworkPolicy		Compatível com o NetworkPolicy nativo do Kubernetes para controle de acesso baseado em políticas. Consulte NetworkPolicy support.	Não compatível com NetworkPolicy.
Configuração de rede no nível do nó		Compatível. Consulte Node-level network configuration.	Compatível. Consulte Node-level network configuration.
Controle de acesso		Com o Trunk ENI ativado, é possível configure a static IP, separate vSwitch, and security group per pod.	Permite configurar um endereço IP estático, um vSwitch separado e um grupo de segurança separado para cada pod.

Aceleração de rede

No modo de ENI compartilhada, é possível ativar a aceleração de rede DataPath V2, que utiliza um caminho de encaminhamento de tráfego diferente para alcançar desempenho superior.

Importante

• O DataPath V2 é uma versão atualizada do antigo modo de aceleração IPvlan+eBPF. No Terway v1.8.0 e posteriores, o DataPath V2 é o único modo de aceleração disponível ao criar um cluster e instale o plugin Terway.

• Os modos de aceleração DataPath V2 e IPvlan+eBPF aplicam-se apenas a pools de nós no modo de ENI compartilhada e não afetam pools de nós no modo de ENI exclusiva.

Recursos do DataPath V2	Descrição
Versões aplicáveis do Terway	Clusters criados com o Terway v1.8.0 ou posterior.
Arquitetura de rede
Caminho de dados acelerado	Quando um pod acessa um Service, o eBPF resolve o endereço IP do Service no endereço IP de um pod de backend. Quando um pod se comunica com um pod em outro nó, o eBPF contorna as pilhas de rede de ambos os nós. Quando um pod se comunica com outro pod no mesmo nó, o tráfego não apenas contorna a pilha de rede do nó, mas também é encaminhado diretamente internamente, sem sair do nó.
Otimização de desempenho	Simplifica o caminho de encaminhamento no host, alcançando desempenho próximo ao do host e latência aproximadamente 30% menor que a do modo padrão. O eBPF substitui o kube-proxy na rede de Services, contornando o iptables/IPVS para reduzir a latência e melhorar a escalabilidade em grandes clusters. O eBPF substitui o iptables na aplicação de NetworkPolicy, evitando o excesso de regras de iptables no host e minimizando o impacto no desempenho.
Uso	Crie um cluster e defina Network Plug-in como Terway e selecione DataPath V2.
Notas de uso	Requer kernel 5.10 ou posterior. Recomenda-se o uso de imagens do sistema operacional Alibaba Cloud Linux. O runtime Sandboxed-Container não é compatível. Limitações no NetworkPolicy: Os seletores CIDR não podem controlar o tráfego para intervalos de IP de pods. Em vez disso, use seletores de pod. A palavra-chave except nos seletores CIDR tem suporte limitado. Evite usá-la. Uma NetworkPolicy de egress pode bloquear o acesso a pods com hostNetwork ativado ou a endereços IP de nós dentro do cluster. O acesso interno do cluster a uma instância SLB pública para um Service LoadBalancer pode falhar devido a loopback. Consulte Why am I unable to access a load balancer?. O acesso hairpin IPv6 não é compatível. Limitações no NodePort: ExternalTrafficPolicy=Local pode bloquear o tráfego. Altere para ExternalTrafficPolicy=Cluster para resolver. Com ExternalTrafficPolicy=Cluster, o SNAT é aplicado ao IP de origem. Intervalo de portas SNAT: 32768 a 65535. O recurso de aceleração eBPF difere da implementação padrão do Linux. Ajuste as configurações dos componentes com base no seu volume de tráfego. Consulte Best practices for Terway Datapath V2 para configurar o monitoramento e os limites do mapa eBPF.

O modo de aceleração IPvlan+eBPF ainda pode estar em uso em clusters mais antigos.

Modo de aceleração IPvlan+eBPF

Recursos do IPvlan+eBPF	Descrição
Versões aplicáveis do Terway	Clusters criados com o Terway v1.7.0 ou anterior.
Arquitetura de rede
Caminho de dados acelerado	Quando um pod acessa um Service, o eBPF é utilizado no namespace de rede do pod para resolver o endereço IP do Service no endereço IP de um pod de backend. Quando um pod se comunica com outro pod, o IPvlan contorna as pilhas de rede de ambos os nós.
Uso	Crie um cluster e defina Network Plug-in como Terway e selecione Pod IPvlan.
Notas de uso	Requer kernel 4.19 ou posterior. Recomenda-se o uso de imagens do sistema operacional Alibaba Cloud Linux. O runtime Sandboxed-Container não é compatível. Limitações no NetworkPolicy: Os seletores CIDR não podem controlar o tráfego para intervalos de IP de pods. Em vez disso, use seletores de pod. A palavra-chave except nos seletores CIDR tem suporte limitado. Evite usá-la. Uma NetworkPolicy de egress pode bloquear o acesso a pods com hostNetwork ativado ou a endereços IP de nós dentro do cluster. O acesso interno do cluster a uma instância SLB pública para um Service LoadBalancer pode falhar devido a loopback. Consulte Why am I unable to access a load balancer?. O acesso hairpin IPv6 não é compatível. Limitações no NodePort: ExternalTrafficPolicy=Local pode bloquear o tráfego. Altere para ExternalTrafficPolicy=Cluster para resolver. Com ExternalTrafficPolicy=Cluster, o SNAT é aplicado ao IP de origem. Intervalo de portas SNAT: 32768 a 65535. O recurso de aceleração eBPF difere do comportamento padrão do Linux. Ajuste as configurações dos componentes com base no seu volume de tráfego. Consulte Best practices for Terway Datapath V2 para configurar o monitoramento e os limites do mapa eBPF.

Controle de acesso

O Terway fornece gerenciamento de tráfego granular por meio de NetworkPolicy e Trunk ENI no modo de ENI compartilhada, e isolamento de ENI por pod no modo de ENI exclusiva.

NetworkPolicy

• Pools de nós no modo de ENI exclusiva não têm suporte a NetworkPolicy.

• Pools de nós no modo de ENI compartilhada têm suporte ao NetworkPolicy nativo do Kubernetes, que permite controlar o tráfego de rede entre pods por meio de regras definidas pelo usuário.

  Crie um cluster e ative o NetworkPolicy definindo Network Plug-in como Terway e selecionando NetworkPolicy support. Consulte Use network policies in ACK clusters.

  Nota

  O recurso que permite gerenciar NetworkPolicy no console está em preview público. Para usá-lo, envie uma solicitação no Quota Center console.

IP estático, vSwitch e grupo de segurança

• Pools de nós no modo de ENI exclusiva têm suporte nativo à atribuição de um endereço IP estático, um vSwitch separado e um grupo de segurança separado para cada pod. Isso permite o gerenciamento granular de tráfego, o isolamento de rede, a configuração de políticas e o gerenciamento de endereços IP.

• Para pools de nós no modo de ENI compartilhada, o recurso opcional Trunk ENI permite configurar um endereço IP estático, um vSwitch separado e um grupo de segurança separado para cada pod.

  Para ativar este recurso, crie seu cluster, defina Network Plug-in como Terway e selecione Support for ENI Trunking. Consulte Configure a static IP address, separate vSwitch, and security group for a pod.

  Nota

  • É possível ativar o Trunk ENI para ACK managed clusters sem enviar uma solicitação. Para ativar o Trunk ENI em um ACK dedicated cluster, envie primeiro uma solicitação no Quota Center console.

  • Em ACK managed clusters recém-criados com Kubernetes 1.31 ou posterior, o recurso Trunk ENI é ativado automaticamente. Não é necessário selecioná-lo manualmente.

  • Após ativar o modo Trunk ENI, os componentes terway-eniip e terway-controlplane são instalados.

Limites de dimensionamento

O Terway utiliza APIs REST de product cloud para gerenciar interfaces de rede de nós e endereços IP. Para limites de taxa de API, consulte a documentação de cada product cloud.

• modo de ENI compartilhada: É possível alocar até 500 nós simultaneamente.

• modo de ENI exclusiva/TrunkENI: É possível alocar até 100 pods simultaneamente.

Essas cotas são fixas.

Configuração do plano de dados

O plano de dados do Terway depende da sequência precisa e da integridade de suas configurações de IP rule, IP route e hooks eBPF no nível do kernel. Alterações não coordenadas por componentes externos — como ajustes de prioridade, substituição de regras ou descarregamento de programas — podem causar interrupções na rede dos pods, ineficácia das políticas de rede e redirecionamento não intencional de tráfego. Valide todos os componentes de terceiros antes da integração para evitar conflitos.

Regras de filtro TC

Regras de IP

Perguntas frequentes

OS Type AliyunLinux4ContainerOptimized is not supported for addons: terway-eniip: required version >= v1.16.4, current version v1.14.3