**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](#hybrid-nodes-concepts-traffic-flows-kubelet-to-cp) + [Ambiente de gerenciamento do EKS para nó híbrido (servidor do `kubelet`)](#hybrid-nodes-concepts-traffic-flows-cp-to-kubelet) + [Pods em execução em nós híbridos para o ambiente de gerenciamento do EKS](#hybrid-nodes-concepts-traffic-flows-pods-to-cp) + [Ambiente de gerenciamento do EKS para pods executados em um nó híbrido (webhooks)](#hybrid-nodes-concepts-traffic-flows-cp-to-pod) + [Pod-to-Pod em execução em nós híbridos](#hybrid-nodes-concepts-traffic-flows-pod-to-pod) + [Pods em nós da nuvem para pods em nós híbridos (tráfego leste-oeste)](#hybrid-nodes-concepts-traffic-flows-east-west) ## `kubelet` de nó híbrido para o ambiente de gerenciamento do EKS ![\[Kubelet de nó híbrido para o ambiente de gerenciamento do EKS\]](http://docs.aws.amazon.com/pt_br/eks/latest/userguide/images/hybrid-nodes-kubelet-to-cp-public.png) ### Solicitação **1. `kubelet` 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`) ![\[Ambiente de gerenciamento do EKS para nó híbrido\]](http://docs.aws.amazon.com/pt_br/eks/latest/userguide/images/hybrid-nodes-cp-to-kubelet.png) ### 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 ![\[Pods em execução em nós híbridos para o ambiente de gerenciamento do EKS\]](http://docs.aws.amazon.com/pt_br/eks/latest/userguide/images/hybrid-nodes-pod-to-cp.png) ### 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: 1. O pacote atinge primeiro a cadeia de `KUBE-SERVICES`, que contém regras que correspondem ao ClusterIP e à porta de cada serviço. 1. A regra de correspondência salta para a cadeia `KUBE-SVC-XXX` do serviço do `kubernetes` (pacotes destinados a `172.16.0.1:443`), que contém regras de balanceamento de carga. 1. A regra de balanceamento de carga seleciona aleatoriamente uma das cadeias `KUBE-SEP-XXX` para a ENI do ambiente de gerenciamento de IPs (`10.0.0.132` ou `10.0.1.23`). 1. A cadeia `KUBE-SEP-XXX` selecionada tem a regra real que altera o IP de destino do IP do serviço para o IP selecionado. Isso é chamado de conversão de endereços de rede de destino (DNAT). 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) ![\[Ambiente de gerenciamento do EKS para pods executados em um nó híbrido\]](http://docs.aws.amazon.com/pt_br/eks/latest/userguide/images/hybrid-nodes-cp-to-pod.png) 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: + A VPC deve ter rotas para os CIDRs dos pods remotos apontando para o gateway on-premises + Sua rede on-premises deve ter rotas para CIDRs de pods que direcionem o tráfego para os nós específicos que hospedam esses pods + Sem essa configuração de roteamento, os webhooks e outros serviços similares executados em pods em nós híbridos não seriam acessíveis no ambiente de gerenciamento do EKS. ## Pod-to-Pod em execução em nós híbridos ![\[Pod-to-Pod em execução em nós híbridos\]](http://docs.aws.amazon.com/pt_br/eks/latest/userguide/images/hybrid-nodes-pod-to-pod.png) 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: 1. **Processamento de rede de nós**: a pilha de rede do nó 1 roteia o pacote com base em seu destino (`10.80.0.3`) 1. **Entrega de rede local**: + Se os dois nós estiverem na mesma rede de camada 2, o pacote será enviado diretamente para o nó 2 + Se estiverem em sub-redes diferentes, o pacote será encaminhado primeiro para o roteador local 1. **Manipulação do roteador**: o roteador encaminha o pacote com base em sua tabela de roteamento, entregando-o ao nó 2 **3. Processamento do nó de recebimento** Quando o pacote encapsulado chega ao nó 2 (`10.80.0.3`): 1. A pilha de rede do nó o recebe e o identifica como um pacote VXLAN (porta UDP `4789`) 1. O pacote é passado para a interface VXLAN da CNI para processamento **4. Desencapsulamento VXLAN** A CNI no nó 2 processa o pacote VXLAN: 1. Ela remove os cabeçalhos externos (Ethernet, IP, UDP e VXLAN) 1. Ela extrai o pacote interno original 1. O pacote agora está de volta à sua forma original: ``` +------------------+-----------------+-------------+-----------------+ | 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: 1. Identifica que esse IP pertence a um pod local 1. Encaminha o pacote pelas interfaces virtuais apropriadas 1. Entrega o pacote ao namespace de rede do pod B ### Resposta Quando o pod B responde ao pod A, todo o processo acontece no sentido inverso: 1. O pod B envia um pacote para o pod A (`10.85.1.56`) 1. A CNI do nó 2 o encapsula com VXLAN, definindo o destino para o nó 1 (`10.80.0.2`) 1. O pacote encapsulado é entregue ao nó 1 1. A CNI do nó 1 o desencapsula e fornece a resposta original ao pod A ## Pods em nós da nuvem para pods em nós híbridos (tráfego leste-oeste) ![\[Pods em nós da nuvem para pods em nós híbridos\]](http://docs.aws.amazon.com/pt_br/eks/latest/userguide/images/hybrid-nodes-east-west.png) ### 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: + A VPC deve ter rotas para os CIDRs dos pods remotos apontando para o gateway on-premises + Sua rede on-premises deve ter rotas para CIDRs de pods que direcionem o tráfego para os nós específicos que hospedam esses pods.