Ajudar a melhorar esta página

Para contribuir com este guia de usuário, escolha o link Editar esta página no GitHub, disponível no painel direito de cada página.

Fluxos de tráfego de rede para nós híbridos

Esta página detalha os fluxos de tráfego de rede para o EKS Hybrid Nodes com diagramas que mostram os caminhos de rede de ponta a ponta para os diferentes tipos de tráfego.

Os seguintes fluxos de tráfego são abrangidos:

kubelet de nó híbrido para o ambiente de gerenciamento do EKS

Solicitação

1kubelet. Inicia a solicitação

Quando o kubelet em um nó híbrido precisa se comunicar com o ambiente de gerenciamento do EKS (por exemplo, para informar o status do nó ou obter especificações do pod), ele usa o arquivo kubeconfig fornecido durante o registro do nó. Esse arquivo kubeconfig tem o URL do endpoint do servidor de API (o nome DNS do Route 53) em vez de endereços IP diretos.

O kubelet executa uma pesquisa de DNS para o endpoint (por exemplo, https://xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.gr7.us-west-2.eks.amazonaws.com ). Em um cluster de acesso público, isso se resolve para um endereço IP público (por exemplo, 54.239.118.52) que pertence ao serviço do EKS executado na AWS. O kubelet então cria uma solicitação HTTPS segura para esse endpoint. Veja como seria o pacote inicial:

+--------------------+---------------------+-----------------+
| IP Header          | TCP Header          | Payload         |
| Src: 10.80.0.2     | Src: 52390 (random) |                 |
| Dst: 54.239.118.52 | Dst: 443            |                 |
+--------------------+---------------------+-----------------+

2. Roteamento de roteador local

Como o IP de destino é um endereço IP público e não faz parte da rede local, o kubelet envia esse pacote para o gateway padrão (o roteador on-premises local). O roteador examina o IP de destino e determina que é um endereço IP público.

Para tráfego público, o roteador normalmente encaminha o pacote para um gateway da internet ou roteador de borda que processa o tráfego de saída para a internet. Isso é omitido no diagrama e dependerá de como sua rede on-premises está configurada. O pacote atravessa a infraestrutura de rede on-premises e, por fim, chega à rede do provedor de serviços de Internet.

3. Entrega para o ambiente de gerenciamento do EKS

O pacote trafega pela internet pública e pelas redes de trânsito até chegar à rede da AWS. A rede da AWS roteia o pacote para o endpoint do serviço do EKS na região apropriada. Quando o pacote chega ao serviço do EKS, ele é encaminhado para o ambiente de gerenciamento real do EKS do cluster.

Esse roteamento pela internet pública é diferente do caminho privado roteado por VPC que veremos em outros fluxos de tráfego. A principal diferença é que, ao usar o modo de acesso público, o tráfego do kubelet on-premises (embora não dos pods) para o ambiente de gerenciamento do EKS não passa pela VPC. Em vez disso, ele usa a infraestrutura global da internet.

Resposta

Depois que o ambiente de gerenciamento do EKS processa a solicitação do kubelet, ele envia uma resposta de volta:

3. O ambiente de gerenciamento do EKS envia uma resposta

O ambiente de gerenciamento do EKS cria um pacote de resposta. Esse pacote tem o IP público como origem e o IP do nó híbrido como destino:

+--------------------+---------------------+-----------------+
| IP Header          | TCP Header          | Payload         |
| Src: 54.239.118.52 | Src: 443            |                 |
| Dst: 10.80.0.2     | Dst: 52390          |                 |
+--------------------+---------------------+-----------------+

2. Roteamento da internet

O pacote de resposta viaja de volta pela internet, seguindo o caminho de roteamento determinado pelos provedores de serviços de Internet, até chegar ao roteador de borda da rede on-premises.

1. Entrega local

O roteador on-premises recebe o pacote e reconhece o IP de destino (10.80.0.2) como pertencente à rede local. Ele encaminha o pacote por meio da infraestrutura de rede local até chegar ao nó híbrido de destino, onde o kubelet recebe e processa a resposta.

kube-proxy de nó híbrido para o ambiente de gerenciamento do EKS

Se você habilitar o acesso ao endpoint público para o cluster, o tráfego de retorno usará a internet pública. Esse tráfego é proveniente de kube-proxy no nó híbrido e se destina ao ambiente de gerenciamento do EKS e segue o mesmo caminho do tráfego do kubelet até o ambiente de gerenciamento do EKS.

Ambiente de gerenciamento do EKS para nó híbrido (servidor do kubelet)

Solicitação

1. O servidor de API do EKS Kubernetes inicia a solicitação

O servidor de API do EKS Kubernetes recupera o endereço IP do nó (10.80.0.2) do status do objeto do nó. Em seguida, ele encaminha essa solicitação por meio da ENI na VPC, pois o IP de destino pertence ao CIDR do nó remoto configurado (10.80.0.0/16). Veja como seria o pacote inicial:

+-----------------+---------------------+-----------------+
| IP Header       | TCP Header          | Payload         |
| Src: 10.0.0.132 | Src: 67493 (random) |                 |
| Dst: 10.80.0.2  | Dst: 10250          |                 |
+-----------------+---------------------+-----------------+

2. Processamento de rede da VPC

O pacote sai da ENI e entra na camada de rede da VPC, onde é direcionado para o gateway da sub-rede para roteamento adicional.

3. Pesquisa da tabela de rotas da VPC

A tabela de rotas da VPC para a sub-rede que contém a ENI do ambiente de gerenciamento do EKS tem uma rota específica (a segunda no diagrama) para o CIDR do nó remoto. Com base nessa regra de roteamento, o pacote é direcionado para o gateway de VPC para on-premises.

4. Trânsito entre limites

O gateway transfere o pacote além do limite de nuvem por meio de sua conexão estabelecida (como Direct Connect ou VPN) para a rede on-premises.

5. Recepção de rede on-premises

O pacote chega ao roteador on-premises local que processa o tráfego da sub-rede em que os nós híbridos estão localizados.

6. Entrega final

O roteador local identifica que o endereço IP de destino (10.80.0.2) pertence à rede conectada diretamente e encaminha o pacote diretamente para o nó híbrido de destino, onde o kubelet recebe e processa a solicitação.

Resposta

Depois que o kubelet do nó híbrido processa a solicitação, ele envia de volta uma resposta seguindo o mesmo caminho no sentido inverso:

+-----------------+---------------------+-----------------+
| IP Header       | TCP Header          | Payload         |
| Src: 10.80.0.2  | Src: 10250          |                 |
| Dst: 10.0.0.132 | Dst: 67493          |                 |
+-----------------+---------------------+-----------------+

6. kubelet Envia resposta

O kubelet no nó híbrido (10.80.0.2) cria um pacote de resposta com o IP de origem inicial como o destino. O destino não pertence à rede local, então é enviado para o gateway padrão do host, que é o roteador local.

5. Roteamento de roteador local

O roteador determina que o IP de destino (10.0.0.132) pertence a 10.0.0.0/16, que tem uma rota apontando para o gateway que se conecta à AWS.

4. Retorno entre limites

O pacote viaja de volta pela mesma conexão on-premises para a VPC (como Direct Connect ou VPN), cruzando o limite da nuvem na direção inversa.

3. Roteamento da VPC

Quando o pacote chega à VPC, as tabelas de rotas identificam que o IP de destino pertence a um CIDR da VPC. O pacote é roteado dentro da VPC.

2. Entrega da rede da VPC

A camada de rede da VPC encaminha o pacote para a sub-rede com a ENI do ambiente de gerenciamento do EKS (10.0.0.132).

1. Recepção da ENI

O pacote chega à ENI do ambiente de gerenciamento do EKS anexado ao servidor de API do Kubernetes, completando a viagem de ida e volta.

Pods em execução em nós híbridos para o ambiente de gerenciamento do EKS

Sem CNI NAT

Solicitação

Os pods geralmente se comunicam com o servidor de API do Kubernetes por meio do serviço do kubernetes. O IP do serviço é o primeiro IP do CIDR de serviço do cluster. Essa convenção permite que os pods que precisam ser executados antes que o CoreDNS esteja disponível cheguem ao servidor de API, por exemplo, a CNI. As solicitações saem do pod com o IP do serviço como destino. Por exemplo, se o CIDR de serviço for 172.16.0.0/16, o IP do serviço será 172.16.0.1.

1. Pod inicia a solicitação

O pod envia uma solicitação para o IP de serviço (172.16.0.1) do kubernetes na porta do servidor de API (443) de uma porta de origem aleatória. O pacote seria assim:

+-----------------+---------------------+-----------------+
| IP Header       | TCP Header          | Payload         |
| Src: 10.85.1.56 | Src: 67493 (random) |                 |
| Dst: 172.16.0.1 | Dst: 443            |                 |
+-----------------+---------------------+-----------------+

2. Processamento da CNI

A CNI detecta que o IP de destino não pertence a nenhum CIDR de pod que ele gerencia. Como o NAT de saída está desabilitado, a CNI passa o pacote para a pilha da rede do host sem modificá-lo.

3. Processamento de rede de nós

O pacote entra na pilha de rede do nó, onde os hooks netfilter acionam as regras de iptables definidas pelo kube-proxy. Várias regras se aplicam na seguinte ordem:

Depois que essas regras são aplicadas, supondo que o IP da ENI do ambiente de gerenciamento do EKS selecionado seja 10.0.0.132, o pacote fica assim:

+-----------------+---------------------+-----------------+
| IP Header       | TCP Header          | Payload         |
| Src: 10.85.1.56 | Src: 67493 (random) |                 |
| Dst: 10.0.0.132 | Dst: 443            |                 |
+-----------------+---------------------+-----------------+

O nó encaminha o pacote para seu gateway padrão porque o IP de destino não está na rede local.

4. Roteamento de roteador local

O roteador local determina que o IP de destino (10.0.0.132) pertence ao CIDR da VPC (10.0.0.0/16) e o encaminha para o gateway conectado à AWS.

5. Trânsito entre limites

O pacote viaja pela conexão estabelecida (como Direct Connect ou VPN) além do limite da nuvem até a VPC.

6. Entrega da rede da VPC

A camada de rede da VPC roteia o pacote para a sub-rede correta em que a ENI do ambiente de gerenciamento do EKS (10.0.0.132) está localizado.

7. Recepção da ENI

O pacote chega à ENI do ambiente de gerenciamento do EKS anexado ao servidor de API do Kubernetes.

Resposta

Depois que o ambiente de gerenciamento do EKS processa a solicitação, ele envia uma resposta de volta ao pod:

7. Servidor de API envia resposta

O servidor de API do EKS Kubernetes cria um pacote de resposta com o IP de origem inicial como o destino. O pacote seria assim:

+-----------------+---------------------+-----------------+
| IP Header       | TCP Header          | Payload         |
| Src: 10.0.0.132 | Src: 443            |                 |
| Dst: 10.85.1.56 | Dst: 67493          |                 |
+-----------------+---------------------+-----------------+

Como o IP de destino pertence ao CIDR do pod remoto configurado (10.85.0.0/16), ele o envia por meio da ENI na VPC com o roteador da sub-rede como o próximo salto.

6. Roteamento da VPC

A tabela de rotas da VPC contém uma entrada para o CIDR do pod remoto (10.85.0.0/16), direcionando esse tráfego para o gateway de VPC para on-premises.

5. Trânsito entre limites

O gateway transfere o pacote além do limite de nuvem por meio de sua conexão estabelecida (como Direct Connect ou VPN) para a rede on-premises.

4. Recepção de rede on-premises

O pacote chega ao seu roteador on-premises local.

3. Entrega ao nó

A tabela do roteador tem uma entrada para 10.85.1.0/24 com 10.80.0.2 como o próximo salto, entregando o pacote para o nosso nó.

2. Processamento de rede de nós

À medida que o pacote é processado pela pilha de rede do nó, conntrack (uma parte de netfilter) combina o pacote com a conexão estabelecida inicialmente pelo pod. Como o DNAT foi aplicado originalmente, conntrack reverte o DNAT reescrevendo o IP de origem do IP do ENI do plano de controle do EKS para o IP do serviço kubernetes:

+-----------------+---------------------+-----------------+
| IP Header       | TCP Header          | Payload         |
| Src: 172.16.0.1 | Src: 443            |                 |
| Dst: 10.85.1.56 | Dst: 67493          |                 |
+-----------------+---------------------+-----------------+

1. Processamento da CNI

A CNI identifica que o IP de destino pertence a um pod em sua rede e entrega o pacote ao namespace correto da rede do pod.

Esse fluxo mostra por que os CIDRs de pods remotos devem ser roteáveis adequadamente da VPC até o nó específico que hospeda cada pod. Todo o caminho de retorno depende do roteamento adequado dos IPs do pod nas redes na nuvem e on-premises.

Com CNI NAT

Esse fluxo é muito semelhante ao fluxo sem CNI NAT, mas com uma diferença fundamental: a CNI aplica o NAT de origem (SNAT) ao pacote antes de enviá-lo para a pilha de rede do nó. Isso altera o IP de origem do pacote para o IP do nó, permitindo que o pacote seja roteado de volta para o nó sem exigir configuração adicional de roteamento.

Solicitação

1. Pod inicia a solicitação

O pod envia uma solicitação para o IP de serviço (172.16.0.1) do kubernetes na porta do servidor de API do EKS Kubernetes (443) de uma porta de origem aleatória. O pacote seria assim:

+-----------------+---------------------+-----------------+
| IP Header       | TCP Header          | Payload         |
| Src: 10.85.1.56 | Src: 67493 (random) |                 |
| Dst: 172.16.0.1 | Dst: 443            |                 |
+-----------------+---------------------+-----------------+

2. Processamento da CNI

A CNI detecta que o IP de destino não pertence a nenhum CIDR de pod que ele gerencia. Como o NAT de saída está habilitado, a CNI aplica o SNAT ao pacote, alterando o IP de origem para o IP do nó antes de passá-lo para a pilha de rede do nó:

+-----------------+---------------------+-----------------+
| IP Header       | TCP Header          | Payload         |
| Src: 10.80.0.2  | Src: 67493 (random) |                 |
| Dst: 172.16.0.1 | Dst: 443            |                 |
+-----------------+---------------------+-----------------+

Observação: a CNI e as iptables são mostradas no exemplo como blocos separados para maior clareza, mas, na prática, é possível que algumas CNIs usem as iptables para aplicar o NAT.

3. Processamento de rede de nós

Aqui, as regras de iptables definidas pelo kube-proxy se comportam da mesma forma que no exemplo anterior, balanceando a carga do pacote para uma das ENIs do ambiente de gerenciamento do EKS. O pacote agora ficaria assim:

+-----------------+---------------------+-----------------+
| IP Header       | TCP Header          | Payload         |
| Src: 10.80.0.2  | Src: 67493 (random) |                 |
| Dst: 10.0.0.132 | Dst: 443            |                 |
+-----------------+---------------------+-----------------+

O nó encaminha o pacote para seu gateway padrão porque o IP de destino não está na rede local.

4. Roteamento de roteador local

O roteador local determina que o IP de destino (10.0.0.132) pertence ao CIDR da VPC (10.0.0.0/16) e o encaminha para o gateway conectado à AWS.

5. Trânsito entre limites

O pacote viaja pela conexão estabelecida (como Direct Connect ou VPN) além do limite da nuvem até a VPC.

6. Entrega da rede da VPC

A camada de rede da VPC roteia o pacote para a sub-rede correta em que a ENI do ambiente de gerenciamento do EKS (10.0.0.132) está localizado.

7. Recepção da ENI

O pacote chega à ENI do ambiente de gerenciamento do EKS anexado ao servidor de API do Kubernetes.

Resposta

Depois que o ambiente de gerenciamento do EKS processa a solicitação, ele envia uma resposta de volta ao pod:

7. Servidor de API envia resposta

O servidor de API do EKS Kubernetes cria um pacote de resposta com o IP de origem inicial como o destino. O pacote seria assim:

+-----------------+---------------------+-----------------+
| IP Header       | TCP Header          | Payload         |
| Src: 10.0.0.132 | Src: 443            |                 |
| Dst: 10.80.0.2  | Dst: 67493          |                 |
+-----------------+---------------------+-----------------+

Como o IP de destino pertence ao CIDR do nó remoto configurado (10.80.0.0/16), ele o envia por meio da ENI na VPC com o roteador da sub-rede como o próximo salto.

6. Roteamento da VPC

A tabela de rotas da VPC contém uma entrada para o CIDR do nó remoto (10.80.0.0/16), direcionando esse tráfego para o gateway de VPC para on-premises.

5. Trânsito entre limites

O gateway transfere o pacote além do limite de nuvem por meio de sua conexão estabelecida (como Direct Connect ou VPN) para a rede on-premises.

4. Recepção de rede on-premises

O pacote chega ao seu roteador on-premises local.

3. Entrega ao nó

O roteador local identifica que o endereço IP de destino (10.80.0.2) pertence à sua rede conectada diretamente e encaminha o pacote diretamente para o nó híbrido de destino.

2. Processamento de rede de nós

À medida que o pacote é processado pela pilha de rede do nó, o conntrack (uma parte de netfilter) combina o pacote com a conexão que o pod estabeleceu inicialmente e, como o DNAT foi aplicado originalmente, ele reverte isso regravando o IP de origem do IP da ENI do ambiente de gerenciamento do EKS para o IP do serviço kubernetes:

+-----------------+---------------------+-----------------+
| IP Header       | TCP Header          | Payload         |
| Src: 172.16.0.1 | Src: 443            |                 |
| Dst: 10.80.0.2  | Dst: 67493          |                 |
+-----------------+---------------------+-----------------+

1. Processamento da CNI

A CNI identifica que esse pacote pertence a uma conexão em que ele aplicou anteriormente o SNAT. Ele reverte o SNAT, alterando o IP de destino de volta para o IP do pod:

+-----------------+---------------------+-----------------+
| IP Header       | TCP Header          | Payload         |
| Src: 172.16.0.1 | Src: 443            |                 |
| Dst: 10.85.1.56 | Dst: 67493          |                 |
+-----------------+---------------------+-----------------+

A CNI detecta que o IP de destino pertence a um pod em sua rede e entrega o pacote ao namespace correto da rede do pod.

Esse fluxo mostra como o CNI NAT pode simplificar a configuração, permitindo que os pacotes sejam roteados de volta ao nó sem exigir roteamento adicional para os CIDRs do pod.

Ambiente de gerenciamento do EKS para pods executados em um nó híbrido (webhooks)

Esse padrão de tráfego é mais comum em webhooks, em que o ambiente de gerenciamento do EKS precisa iniciar conexões diretamente com servidores de webhook executados em pods em nós híbridos. Os exemplos incluem a validação e a mutação de webhooks de admissão, que são chamados pelo servidor de API durante os processos de validação ou mutação de recursos.

Solicitação

1. O servidor de API do EKS Kubernetes inicia a solicitação

Quando um webhook é configurado no cluster e uma operação de API relevante o aciona, o servidor de API do EKS Kubernetes precisa fazer uma conexão direta com o pod do servidor do webhook. O servidor de API primeiro consulta o endereço IP do pod no recurso do serviço ou do endpoint associado ao webhook.

Supondo que o pod do webhook esteja sendo executado em um nó híbrido com o IP 10.85.1.23, o servidor de API do EKS Kubernetes criará uma solicitação HTTPS para o endpoint do webhook. O pacote inicial é enviado pela ENI do ambiente de gerenciamento do EKS na VPC porque o IP de destino 10.85.1.23 pertence ao CIDR do pod remoto configurado (10.85.0.0/16). O pacote seria assim:

+-----------------+---------------------+-----------------+
| IP Header       | TCP Header          | Payload         |
| Src: 10.0.0.132 | Src: 41892 (random) |                 |
| Dst: 10.85.1.23 | Dst: 8443           |                 |
+-----------------+---------------------+-----------------+

2. Processamento de rede da VPC

O pacote sai da ENI do ambiente de gerenciamento do EKS e entra na camada de rede da VPC com o roteador da sub-rede como o próximo salto.

3. Pesquisa da tabela de rotas da VPC

A tabela de rotas da VPC para a sub-rede que contém a ENI do ambiente de gerenciamento do EKS contém uma rota específica para o CIDR do pod remoto (10.85.0.0/16). Essa regra de roteamento direciona o pacote para o gateway de VPC para on-premises (por exemplo, um gateway privado virtual para conexões Direct Connect ou VPN):

Destination     Target
10.0.0.0/16     local
10.85.0.0/16    vgw-id (VPC-to-onprem gateway)

4. Trânsito entre limites

O gateway transfere o pacote além do limite de nuvem por meio de sua conexão estabelecida (como Direct Connect ou VPN) para a rede on-premises. O pacote mantém seus endereços IP iniciais de origem e de destino à medida que atravessa essa conexão.

5. Recepção de rede on-premises

O pacote chega ao seu roteador on-premises local. O roteador consulta sua tabela de roteamento para determinar como acessar o endereço 10.85.1.23. Para que isso funcione, sua rede on-premises deve ter rotas para os CIDRs dos pods que direcionem o tráfego para o nó híbrido apropriado.

Nesse caso, a tabela de rotas do roteador contém uma entrada indicando que a sub-rede 10.85.1.0/24 pode ser acessada por meio do nó híbrido com o IP 10.80.0.2:

Destination     Next Hop
10.85.1.0/24    10.80.0.2

6. Entrega ao nó

Com base na entrada da tabela de roteamento, o roteador encaminha o pacote para o nó híbrido (10.80.0.2). Quando o pacote chega ao nó, ele está igual a quando o servidor de API do EKS Kubernetes o enviou, com o IP de destino ainda sendo o IP do pod.

7. Processamento da CNI

A pilha de rede do nó recebe o pacote e, vendo que o IP de destino não é o IP do próprio nó, o passa para a CNI para processamento. A CNI identifica que o IP de destino pertence a um pod executado localmente nesse nó e encaminha o pacote para o pod correto por meio das interfaces virtuais apropriadas:

Original packet -> node routing -> CNI -> Pod's network namespace

O servidor do webhook no pod recebe a solicitação e a processa.

Resposta

Depois que o pod do webhook processa a solicitação, ele envia de volta uma resposta seguindo o mesmo caminho no sentido inverso:

7. Pod envia resposta

O pod do webhook cria um pacote de resposta com seu próprio IP como a origem e o solicitante original (a ENI do ambiente de gerenciamento do EKS) como o destino:

+-----------------+---------------------+-----------------+
| IP Header       | TCP Header          | Payload         |
| Src: 10.85.1.23 | Src: 8443           |                 |
| Dst: 10.0.0.132 | Dst: 41892          |                 |
+-----------------+---------------------+-----------------+

A CNI identifica que esse pacote foi enviado para uma rede externa (e não para um pod local) e passa o pacote para a pilha de rede do nó com o IP de origem original preservado.

6. Processamento de rede de nós

O nó determina que o IP de destino (10.0.0.132) não está na rede local e encaminha o pacote para seu gateway padrão (o roteador local).

5. Roteamento de roteador local

O roteador local consulta sua tabela de roteamento e determina que o IP de destino (10.0.0.132) pertence ao CIDR da VPC (10.0.0.0/16). Ele encaminha o pacote para o gateway conectado à AWS.

4. Trânsito entre limites

O pacote viaja de volta pela mesma conexão on-premises para a VPC, cruzando o limite da nuvem na direção inversa.

3. Roteamento da VPC

Quando o pacote chega à VPC, as tabelas de rotas identificam que o IP de destino pertence a uma sub-rede dentro da VPC. O pacote é roteado adequadamente dentro da VPC.

2. e 1. Recepção da ENI do ambiente de gerenciamento do EKS

O pacote chega à ENI anexada ao servidor de API do EKS Kubernetes, completando a viagem de ida e volta. O servidor de API recebe a resposta do webhook e continua processando a solicitação original da API com base nessa resposta.

Esse fluxo de tráfego demonstra por que os CIDRs de pods remotos devem ser configurados e roteados adequadamente:

Pod-to-Pod em execução em nós híbridos

Esta seção explica como os pods executados em diferentes nós híbridos se comunicam entre si. Este exemplo pressupõe que a CNI usa VXLAN para encapsulamento, o que é comum para CNIs como Cilium ou Calico. O processo geral é semelhante para outros protocolos de encapsulamento, como Geneve ou IP-in-IP.

Solicitação

1. Pod A inicia a comunicação

O pod A (10.85.1.56) no nó 1 deseja enviar tráfego para o pod B (10.85.2.67) no nó 2. Veja como seria o pacote inicial:

+------------------+-----------------+-------------+-----------------+
| Ethernet Header  | IP Header       | TCP/UDP     | Payload         |
| Src: Pod A MAC   | Src: 10.85.1.56 | Src: 43721  |                 |
| Dst: Gateway MAC | Dst: 10.85.2.67 | Dst: 8080   |                 |
+------------------+-----------------+-------------+-----------------+

2. CNI intercepta e processa o pacote

Quando o pacote do pod A deixa seu namespace de rede, a CNI o intercepta. A CNI consulta sua tabela de roteamento e determina: - O IP de destino (10.85.2.67) pertence ao CIDR do pod - Este IP não está no nó local, mas pertence ao nó 2 (10.80.0.3) - O pacote precisa ser encapsulado com VXLAN.

A decisão de encapsular é fundamental porque a rede física subjacente não sabe como rotear os CIDRs de pods diretamente, ela só sabe como rotear o tráfego entre os IPs dos nós.

A CNI encapsula todo o pacote original dentro de um quadro VXLAN. Isso cria efetivamente um “pacote dentro de um pacote” com novos cabeçalhos:

+-----------------+----------------+--------------+------------+---------------------------+
| Outer Ethernet  | Outer IP       | Outer UDP    | VXLAN      | Original Pod-to-Pod       |
| Src: Node1 MAC  | Src: 10.80.0.2 | Src: Random  | VNI: 42    | Packet (unchanged         |
| Dst: Router MAC | Dst: 10.80.0.3 | Dst: 8472    |            | from above)               |
+-----------------+----------------+--------------+------------+---------------------------+

Pontos-chave sobre esse encapsulamento: - O pacote externo é endereçado do nó 1 (10.80.0.2) para o nó 2 (10.80.0.3) - A porta UDP 8472 é a porta VXLAN usada por padrão pelo Cilium - O VXLAN Network Identifier (VNI) identifica a qual rede de sobreposição esse pacote pertence - Todo o pacote original (com o IP do pod A como origem e o IP do pod B como destino) é preservado intacto por dentro

O pacote encapsulado agora entra na pilha de rede regular do nó 1 e é processado da mesma forma que qualquer outro pacote:

3. Processamento do nó de recebimento

Quando o pacote encapsulado chega ao nó 2 (10.80.0.3):

4. Desencapsulamento VXLAN

A CNI no nó 2 processa o pacote VXLAN:

+------------------+-----------------+-------------+-----------------+
| Ethernet Header  | IP Header       | TCP/UDP     | Payload         |
| Src: Pod A MAC   | Src: 10.85.1.56 | Src: 43721  |                 |
| Dst: Gateway MAC | Dst: 10.85.2.67 | Dst: 8080   |                 |
+------------------+-----------------+-------------+-----------------+

A CNI no nó 2 examina o IP de destino (10.85.2.67) e:

Resposta

Quando o pod B responde ao pod A, todo o processo acontece no sentido inverso:

Pods em nós da nuvem para pods em nós híbridos (tráfego leste-oeste)

Solicitação

1. Pod A inicia a comunicação

O pod A (10.0.0.56) no nó EC2 deseja enviar tráfego para o pod B (10.85.1.56) no nó híbrido. Veja como seria o pacote inicial:

+-----------------+---------------------+-----------------+
| IP Header       | TCP Header          | Payload         |
| Src: 10.0.0.56  | Src: 52390 (random) |                 |
| Dst: 10.85.1.56 | Dst: 8080           |                 |
+-----------------+---------------------+-----------------+

Com a CNI da VPC, o pod A tem um IP do CIDR da VPC e está diretamente anexado a uma ENI na instância do EC2. O namespace de rede do pod está conectado à rede da VPC, então o pacote entra diretamente na infraestrutura de roteamento da VPC.

2. Roteamento da VPC

A tabela de rotas da VPC contém uma rota específica para o CIDR do pod remoto (10.85.0.0/16), direcionando esse tráfego para o gateway de VPC para on-premises:

Destination     Target
10.0.0.0/16     local
10.85.0.0/16    vgw-id (VPC-to-onprem gateway)

Com base nessa regra de roteamento, o pacote é direcionado para o gateway que se conecta à rede on-premises.

3. Trânsito entre limites

O gateway transfere o pacote além do limite de nuvem por meio de sua conexão estabelecida (como Direct Connect ou VPN) para a rede on-premises. O pacote mantém seus endereços IP iniciais de origem e destino durante o trânsito.

4. Recepção de rede on-premises

O pacote chega ao seu roteador on-premises local. O roteador consulta a tabela de roteamento para determinar o próximo salto para acessar o endereço 10.85.1.56. Seu roteador on-premises deve ter rotas para os CIDRs dos pods que direcionem o tráfego para o nó híbrido apropriado.

A tabela do roteador tem uma entrada indicando que a sub-rede 10.85.1.0/24 pode ser acessada por meio do nó híbrido com IP 10.80.0.2:

Destination     Next Hop
10.85.1.0/24    10.80.0.2

5. Processamento de rede de nós

O roteador encaminha o pacote para o nó híbrido (10.80.0.2). Quando o pacote chega ao nó, ele ainda tem o IP do pod A como a origem e o IP do pod B como o destino.

6. Processamento da CNI

A pilha de rede do nó recebe o pacote e, vendo que o IP de destino não é seu, o passa para a CNI para processamento. A CNI identifica que o IP de destino pertence a um pod executado localmente nesse nó e encaminha o pacote para o pod correto por meio das interfaces virtuais apropriadas:

Original packet -> node routing -> CNI -> Pod B's network namespace

O pod B recebe o pacote e o processa conforme necessário.

Resposta

6. Pod B envia resposta

O pod B cria um pacote de resposta com seu próprio IP como a origem e o IP do pod A como o destino:

+-----------------+---------------------+-----------------+
| IP Header       | TCP Header          | Payload         |
| Src: 10.85.1.56 | Src: 8080           |                 |
| Dst: 10.0.0.56  | Dst: 52390          |                 |
+-----------------+---------------------+-----------------+

A CNI identifica que esse pacote é destinado a uma rede externa e o passa para a pilha de rede do nó.

5. Processamento de rede de nós

O nó determina que o IP de destino (10.0.0.56) não pertence à rede local e encaminha o pacote para seu gateway padrão (o roteador local).

4. Roteamento de roteador local

O roteador local consulta sua tabela de roteamento e determina que o IP de destino (10.0.0.56) pertence ao CIDR da VPC (10.0.0.0/16). Ele encaminha o pacote para o gateway conectado à AWS.

3. Trânsito entre limites

O pacote viaja de volta pela mesma conexão on-premises para a VPC, cruzando o limite da nuvem na direção inversa.

2. Roteamento da VPC

Quando o pacote chega à VPC, o sistema de roteamento identifica que o IP de destino pertence a uma sub-rede dentro da VPC. O pacote é roteado pela rede da VPC em direção à instância do EC2 que hospeda o pod A.

1. Pod A recebe resposta

O pacote chega à instância do EC2 e é entregue diretamente ao pod A por meio da ENI anexada. Como a CNI da VPC não usa rede de sobreposição para pods na VPC, nenhum desencapsulamento adicional é necessário. O pacote chega com os cabeçalhos originais intactos.

Esse fluxo de tráfego leste-oeste demonstra por que os CIDRs de pods remotos devem ser configurados adequadamente e roteáveis em ambas as direções: