**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. # Visão geral do Amazon EKS Hybrid Nodes Nós híbridos Com o *Amazon EKS Hybrid Nodes*, você pode usar a infraestrutura on-premises e de borda como nós nos clusters do Amazon EKS. A AWS gerencia o ambiente de gerenciamento do Kubernetes hospedado na AWS do cluster do Amazon EKS, e você gerencia os nós híbridos que são executados nos ambientes on-premises ou de borda. Isso unifica o gerenciamento do Kubernetes nos ambientes e transfere o gerenciamento do ambiente de gerenciamento do Kubernetes para a AWS das aplicações on-premises e de borda. O Amazon EKS Hybrid Nodes funciona com qualquer hardware on-premises ou máquina virtual, trazendo a eficiência, a escalabilidade e a disponibilidade do Amazon EKS para onde quer que as aplicações precisem ser executadas. Você pode usar uma ampla variedade de recursos do Amazon EKS com o Amazon EKS Hybrid Nodes, incluindo complementos do Amazon EKS, a Identidade de Pods do Amazon EKS, entradas de acesso ao cluster, insights do cluster e suporte estendido à versão do Kubernetes. O Amazon EKS Hybrid Nodes se integra de forma nativa com os serviços da AWS, incluindo o AWS Systems Manager, o AWS IAM Roles Anywhere, o Amazon Managed Service for Prometheus e o Amazon CloudWatch para monitoramento centralizado, registro em log e gerenciamento de identidades. Com o Amazon EKS Hybrid Nodes, não há compromissos iniciais nem taxas mínimas, e você é cobrado por hora pelos recursos de vCPU dos nós híbridos quando eles estão anexados aos clusters do Amazon EKS. Para obter informações sobre preços, consulte [Preços do Amazon EKS](https://aws.amazon.com/eks/pricing/). [![AWS Videos](http://img.youtube.com/vi/https://www.youtube.com/embed/tFn9IdlddBw?rel=0/0.jpg)](http://www.youtube.com/watch?v=https://www.youtube.com/embed/tFn9IdlddBw?rel=0) ## Atributos O EKS Hybrid Nodes apresenta os seguintes recursos de alto nível: + **Ambiente de gerenciamento do Kubernetes gerenciado**: o AWS gerencia o ambiente de gerenciamento do Kubernetes hospedado no AWS do cluster do EKS, e você gerencia os nós híbridos que são executados nos seus ambientes on-premises ou de borda. Isso unifica o gerenciamento do Kubernetes nos ambientes e transfere o gerenciamento do ambiente de gerenciamento do Kubernetes para a AWS das aplicações on-premises e de borda. Ao mover o ambiente de gerenciamento do Kubernetes para a AWS, você pode conservar a capacidade on-premises para suas aplicações e confiar que o ambiente de gerenciamento do Kubernetes escalará com suas workloads. + **Experiência de EKS consistente**: a maioria dos recursos do EKS é compatível com o EKS Hybrid Nodes para proporcionar uma experiência de EKS consistente em ambientes on-premises e na nuvem, incluindo complementos do EKS, Identidade de Pods do EKS, entradas de acesso ao cluster, insights do cluster, suporte estendido a versões do Kubernetes e muito mais. Consulte [Configuração de complementos para nós híbridos](hybrid-nodes-add-ons.md) para obter mais informações sobre os complementos do EKS compatíveis com o EKS Hybrid Nodes. + **Observabilidade e gerenciamento de identidades centralizados**: o EKS Hybrid Nodes se integra de forma nativa com os serviços da AWS, incluindo o AWS Systems Manager, o AWS IAM Roles Anywhere, o Amazon Managed Service for Prometheus e o Amazon CloudWatch para monitoramento centralizado, registro em log e gerenciamento de identidades. + **Burst-to-cloud ou adição de capacidade on-premises**: um único cluster do EKS pode ser usado para executar nós híbridos e nós em regiões da AWS, zonas Locais da AWS ou AWS Outposts para expandir para a nuvem em caso de necessidade (burst-to-cloud) ou adicionar capacidade on-premises aos seus clusters do EKS. Consulte [Considerações sobre clusters de modo misto](hybrid-nodes-webhooks.md#hybrid-nodes-considerations-mixed-mode) para obter mais informações. + **Infraestrutura flexível**: o EKS Hybrid Nodes segue uma abordagem de *traga sua própria infraestrutura* e é agnóstico em relação à infraestrutura utilizada para nós híbridos. É possível executar nós híbridos em máquinas físicas ou virtuais e nas arquiteturas x86 e ARM, o que torna possível a migração de workloads on-premises executadas em nós híbridos entre diferentes tipos de infraestrutura. + **Rede flexível**: com o EKS Hybrid Nodes, a comunicação entre o ambiente de gerenciamento do EKS e os nós híbridos é roteada por meio da VPC e das sub-redes que você passa durante a criação do cluster, o que se baseia no [mecanismo existente](https://docs.aws.amazon.com/eks/latest/best-practices/subnets.html) no EKS para a conexão de rede entre o ambiente de gerenciamento e o nó. Isso é flexível quanto ao seu método de preferência de conectar as redes on-premises a uma VPC na AWS. Há várias [opções documentadas](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/network-to-amazon-vpc-connectivity-options.html) disponíveis, incluindo o AWS VPN Site-to-Site, o AWS Direct Connect e sua própria solução de VPN, e você pode escolher o método que melhor se adapta ao seu caso de uso. ## Limites + Você pode usar até 15 CIDRs para redes remotas de nós e 15 CIDRs para redes remotas de pods por cluster. ## Considerações + O EKS Hybrid Nodes pode ser usado com clusters existentes ou novos do EKS. + O EKS Hybrid Nodes está disponível em todas as regiões da AWS, exceto nas regiões AWS GovCloud (EUA) e nas regiões da AWS na China. + O EKS Hybrid Nodes deve ter uma conexão confiável entre o ambiente on-premises e a AWS. O EKS Hybrid Nodes não é adequado para ambientes desconectados, interrompidos, intermitentes ou limitados (DDIL). Se você estiver executando em um ambiente DDIL, considere o [Amazon EKS Anywhere](https://aws.amazon.com/eks/eks-anywhere/). Consulte as [práticas recomendadas do EKS Hybrid Nodes](https://docs.aws.amazon.com/eks/latest/best-practices/hybrid-nodes-network-disconnections.html) para obter informações sobre como os nós híbridos se comportam durante cenários de desconexão de rede. + Não há suporte à execução do EKS Hybrid Nodes em infraestrutura de nuvem, incluindo as regiões da AWS, as zonas locais da AWS, o AWS Outposts ou outras nuvens. Você será cobrado pela taxa de nós híbridos se executar nós híbridos em instâncias do Amazon EC2. + A cobrança dos nós híbridos começa quando os nós se unem ao cluster do EKS e termina quando os nós são removidos do cluster. Certifique-se de remover os nós híbridos do cluster do EKS caso não os esteja usando. ## Recursos adicionais + [https://www.eksworkshop.com/docs/networking/eks-hybrid-nodes/](https://www.eksworkshop.com/docs/networking/eks-hybrid-nodes/): instruções passo a passo para implantar o EKS Hybrid Nodes em um ambiente de demonstração. + [https://www.youtube.com/watch?v=ZxC7SkemxvU](https://www.youtube.com/watch?v=ZxC7SkemxvU): sessão do AWS re:Invent apresentando o lançamento do EKS Hybrid Nodes com um cliente, mostrando como ele está usando os EKS Hybrid Nodes em seu ambiente. + [https://repost.aws/articles/ARL44xuau6TG2t-JoJ3mJ5Mw/unpacking-the-cluster-networking-for-amazon-eks-hybrid-nodes](https://repost.aws/articles/ARL44xuau6TG2t-JoJ3mJ5Mw/unpacking-the-cluster-networking-for-amazon-eks-hybrid-nodes): artigo explicando vários métodos para configurar redes para o EKS Hybrid Nodes. + [https://aws.amazon.com/blogs/containers/run-genai-inference-across-environments-with-amazon-eks-hybrid-nodes/](https://aws.amazon.com/blogs/containers/run-genai-inference-across-environments-with-amazon-eks-hybrid-nodes/): postagem no blog mostrando como executar a inferência de IA generativa em ambientes com o EKS Hybrid Nodes. # Configuração de pré-requisitos para nós híbridos Pré-requisitos Para usar o Amazon EKS Hybrid Nodes, você deve ter uma conectividade privada do ambiente on-premises de/para a AWS, servidores bare metal ou máquinas virtuais com um sistema operacional compatível e ativações híbridas do AWS IAM Roles Anywhere ou do AWS Systems Manager (SSM) configuradas. Você é responsável por gerenciar esses pré-requisitos durante todo o ciclo de vida dos nós híbridos. + Conectividade de rede híbrida do ambiente on-premises de/para a AWS + Infraestrutura na forma de máquinas físicas ou virtuais + Sistema operacional compatível com nós híbridos + Provedor de credenciais do IAM on-premises configurado ![\[Conectividade de rede de nós híbridos.\]](http://docs.aws.amazon.com/pt_br/eks/latest/userguide/images/hybrid-prereq-diagram.png) ## Conectividade de rede híbrida A comunicação entre o ambiente de gerenciamento do Amazon EKS e os nós híbridos é roteada pela VPC e pelas sub-redes que você passa durante a criação do cluster, que se baseia no [mecanismo existente](https://aws.github.io/aws-eks-best-practices/networking/subnets/) no Amazon EKS do ambiente de gerenciamento para a rede de nós. Há várias [opções documentadas](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/network-to-amazon-vpc-connectivity-options.html) disponíveis para você conectar o ambiente on-premises à VPC, incluindo o AWS VPN Site-to-Site, o AWS Direct Connect ou sua própria conexão da VPN. Consulte os guias de usuário do [AWS VPN Site-to-Site](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html) e do [AWS Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html) para obter mais informações sobre como usar essas soluções para a conexão de rede híbrida. Para uma experiência ideal, recomendamos uma conectividade de rede confiável de pelo menos 100 Mbps e uma latência máxima de ida e vinda de 200 ms para a conexão dos nós híbridos com a região da AWS. Esta é uma orientação geral que engloba a maioria dos casos de uso, mas não é um requisito rigoroso. Os requisitos de largura de banda e latência podem variar dependendo do número de nós híbridos e das características da workload, como tamanho da imagem da aplicação, elasticidade da aplicação, configurações de monitoramento e registro em log e dependências da aplicação no acesso aos dados armazenados em outros serviços da AWS. Recomendamos que você teste com suas próprias aplicações e seus próprios ambientes antes da implantação na produção para validar se a configuração de rede atende aos requisitos das workloads. ## Configuração de rede on-premises Você deve habilitar o acesso à rede de entrada no ambiente de gerenciamento do Amazon EKS para o ambiente on-premises a fim de permitir que o ambiente de gerenciamento do Amazon EKS se comunique com o `kubelet` em execução em nós híbridos e, opcionalmente, com webhooks em execução nos nós híbridos. Além disso, você deve habilitar o acesso à rede de saída para que os nós híbridos e os componentes executados neles se comuniquem com o ambiente de gerenciamento do Amazon EKS. Você pode configurar essa comunicação para permanecer totalmente privada no AWS Direct Connect, no AWS VPN Site-to-Site ou em sua própria conexão da VPN. Os intervalos de endereços Encaminhamento Entre Domínios Sem Classificação (CIDR) utilizados para as redes de nós e pods on-premises devem utilizar intervalos de endereços IPv4 RFC-1918 ou CGNAT. O roteador on-premises deve ser configurado com rotas para os nós on-premises e, opcionalmente, pods. Consulte [Configuração de rede on-premises](hybrid-nodes-networking.md#hybrid-nodes-networking-on-prem) para obter mais informações sobre os requisitos de rede on-premises, incluindo a lista completa de portas e protocolos necessários que devem ser habilitados em seu firewall e ambiente on-premises. ## Configuração do cluster do EKS Para minimizar a latência, recomendamos criar o cluster do Amazon EKS na região da AWS mais próxima do ambiente on-premises ou de borda. Você passa os CIDRs de nós e pods on-premises durante a criação do cluster do Amazon EKS por meio de dois campos de API: `RemoteNodeNetwork` e `RemotePodNetwork`. Talvez seja necessário discutir com a equipe de rede on-premises para identificar os CIDRs de nós e pods on-premises. O CIDR de nós é alocado da rede on-premises, e o CIDR de pods é alocado da interface de rede de contêineres (CNI) que você usa caso esteja utilizando uma rede de sobreposição para a CNI. O Cilium e o Calico usam redes de sobreposição por padrão. Os CIDRs de nós e pods on-premises que você configura nos campos `RemoteNodeNetwork` e `RemotePodNetwork` são usados para configurar o ambiente de gerenciamento do Amazon EKS para rotear o tráfego por meio da VPC para o `kubelet` e os pods em execução nos nós híbridos. Os CIDRs de nós e pods on-premises não podem se sobrepor entre si, com o CIDR da VPC que você passa durante a criação do cluster ou com a configuração do IPv4 do serviço para o cluster do Amazon EKS. Além disso, os Pod CIDRs devem ser exclusivos para cada cluster EKS para que seu roteador on-premises possa rotear o tráfego. Recomendamos usar o acesso de endpoint público ou privado para o endpoint do servidor da API do Kubernetes do Amazon EKS. Se você escolher “Público e Privado”, o endpoint do servidor da API do Kubernetes do Amazon EKS sempre resolverá para os IPs públicos dos nós híbridos em execução fora da VPC, o que pode impedir que os nós híbridos se juntem ao cluster. Quando você usa o acesso ao endpoint público, o endpoint do servidor da API do Kubernetes é resolvido para IPs públicos, e a comunicação dos nós híbridos com o ambiente de gerenciamento do Amazon EKS será roteada pela internet. Quando você escolhe o acesso privado ao endpoint, o endpoint do servidor da API do Kubernetes é resolvido para IPs privados, e a comunicação dos nós híbridos com o ambiente de gerenciamento do Amazon EKS será roteada pelo link de conectividade privada, na maioria dos casos o AWS Direct Connect ou o AWS Site-to-Site VPN. ## Configuração de VPC Você deve configurar a VPC que você passa durante a criação do cluster do Amazon EKS com rotas em sua tabela de roteamento para o nó on-premises e, opcionalmente, redes de pods como o gateway privado virtual (VGW) ou o gateway de trânsito (TGW) como destino. Um exemplo é mostrado abaixo. Substitua `REMOTE_NODE_CIDR` e `REMOTE_POD_CIDR` pelos valores da rede on-premises. | Destination (Destino) | Alvo | Descrição | | --- | --- | --- | | 10,226.0.0/16 | local | O tráfego local para as rotas da VPC dentro da VPC | | REMOTE\$1NODE\$1CIDR | tgw-abcdef123456 | CIDR de nós on-premises, rotear tráfego para o TGW | | REMODE\$1POD\$1CIDR | tgw-abcdef123456 | CIDR de pods on-premises, rotear tráfego para o TGW | ## Configuração do security group Ao criar um cluster, o Amazon EKS cria um grupo de segurança com o nome `eks-cluster-sg--`. Você não pode alterar as regras de entrada desse grupo de segurança de clusters, mas pode restringir as regras de saída. Você deve adicionar um grupo de segurança adicional ao cluster para permitir que o kubelet e, opcionalmente, os webhooks em execução nos nós híbridos façam contato com o ambiente de gerenciamento do Amazon EKS. As regras de entrada necessárias para esse grupo de segurança adicional são mostradas abaixo. Substitua `REMOTE_NODE_CIDR` e `REMOTE_POD_CIDR` pelos valores da rede on-premises. | Nome | ID da regra do grupo de segurança | Versão de IP | Tipo | Protocolo | Intervalo de portas | Origem | | --- | --- | --- | --- | --- | --- | --- | | Entrada de nós on-premises | sgr-abcdef123456 | IPv4 | HTTPS | TCP | 443 | REMOTE\$1NODE\$1CIDR | | Entrada de pods on-premises | sgr-abcdef654321 | IPv4 | HTTPS | TCP | 443 | REMOTE\$1POD\$1CIDR | ## Infraestrutura Você deve ter servidores bare metal ou máquinas virtuais disponíveis para uso como nós híbridos. Os nós híbridos são independentes da infraestrutura subjacente e são compatíveis com as arquiteturas x86 e ARM. O Amazon EKS Hybrid Nodes segue uma abordagem de “traga sua própria infraestrutura”, em que você é responsável por provisionar e gerenciar os servidores bare metal ou as máquinas virtuais que você usa para nós híbridos. Embora não haja um requisito mínimo rigoroso de recursos, recomendamos usar hosts com pelo menos 1 vCPU e 1 GiB de RAM para nós híbridos. ## Sistema operacional O Bottlerocket, o Amazon Linux 2023 (AL2023), o Ubuntu e o RHEL são validados continuamente para uso como o sistema operacional de nós para nós híbridos. O Bottlerocket tem suporte da AWS somente em ambientes VMware vSphere. O AL2023 não é coberto pelos planos do AWS Support quando executado fora do Amazon EC2. O AL2023 só pode ser usado em ambientes virtualizados on-premises. Consulte o [Guia do usuário do Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/ug/outside-ec2.html) para obter mais informações. A AWS oferece suporte à integração de nós híbridos com os sistemas operacionais Ubuntu e RHEL, mas não oferece suporte para os sistemas operacionais em si. Você é responsável pelo provisionamento e gerenciamento do sistema operacional. Quando você estiver testando nós híbridos pela primeira vez, é mais fácil executar a CLI (`nodeadm`) do Amazon EKS Hybrid Nodes em um host já provisionado. Para implantações de produção, recomendamos incluir `nodeadm` nas imagens golden do sistema operacional configurado para ser executado como um serviço systemd para unir automaticamente os hosts aos clusters do Amazon EKS na inicialização do host. ## Provedor de credenciais do IAM on-premises O Amazon EKS Hybrid Nodes usa credenciais temporárias do IAM provisionadas por ativações híbridas do AWS SSM ou pelo AWS IAM Roles Anywhere para se autenticar com o cluster do Amazon EKS. É necessário usar as ativações híbridas do AWS SSM ou o AWS IAM Roles Anywhere com a CLI do Amazon EKS Hybrid Nodes (`nodeadm`). Recomendamos usar as ativações híbridas do AWS SSM caso não tenha uma infraestrutura de chave pública (PKI) existente com uma Certificate Authority (CA) e certificados para seus ambientes on-premises. Se você já tem uma PKI e certificados on-premises, use o AWS IAM Roles Anywhere. Semelhante ao [Perfil do IAM em nós do Amazon EKS](create-node-role.md) para nós em execução no Amazon EC2, você criará um perfil do IAM de nós híbridos com as permissões necessárias para unir nós híbridos aos clusters do Amazon EKS. Caso esteja usando o AWS IAM Roles Anywhere, configure uma política de confiança que permita que o AWS IAM Roles Anywhere assuma o perfil do IAM de nós híbridos, e configure seu usuário do AWS IAM Roles Anywhere com o perfil do IAM de nós híbridos como um perfil assumível. Caso esteja usando o AWS SSM, configure uma política de confiança que permita que o AWS SSM assuma o perfil do IAM de nós híbridos e crie a ativação híbrida com o perfil do IAM de nós híbridos. Confira [Preparar as credenciais para nós híbridos](hybrid-nodes-creds.md) para saber como criar o perfil do IAM de nós híbridos com as permissões necessárias. # Preparar a rede para nós híbridos Preparar a rede Este tópico fornece uma visão geral da configuração de rede que você deve configurar antes de criar o cluster do Amazon EKS e anexar nós híbridos. Este guia pressupõe que você atendeu aos pré-requisitos para conectividade de rede híbrida usando a [AWS Site-to-Site VPN](https://docs.aws.amazon.com/vpn/latest/s2svpn/SetUpVPNConnections.html), o [AWS Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html) ou sua própria solução de VPN. ![\[Conectividade de rede de nós híbridos.\]](http://docs.aws.amazon.com/pt_br/eks/latest/userguide/images/hybrid-prereq-diagram.png) ## Configuração de rede on-premises ### Requisitos mínimos de rede Para uma experiência ideal, recomendamos uma conectividade de rede confiável de pelo menos 100 Mbps e uma latência máxima de ida e vinda de 200 ms para a conexão dos nós híbridos com a região da AWS. Esta é uma orientação geral que engloba a maioria dos casos de uso, mas não é um requisito rigoroso. Os requisitos de largura de banda e latência podem variar dependendo do número de nós híbridos e das características da workload, como tamanho da imagem da aplicação, elasticidade da aplicação, configurações de monitoramento e registro em log e dependências da aplicação no acesso aos dados armazenados em outros serviços da AWS. Recomendamos que você teste com suas próprias aplicações e seus próprios ambientes antes da implantação na produção para validar se a configuração de rede atende aos requisitos das workloads. ### CIDRs de nós e pods on-premises Identifique os CIDRs de nós e pods que você usará para os nós híbridos e as workloads executadas neles. O CIDR de nós é alocado da rede on-premises e o CIDR de pods é alocado da interface de rede de contêineres (CNI), caso esteja usando uma rede de sobreposição para a CNI. Você passa os CIDRs de nós on-premises e, opcionalmente, CIDRs de pods como entradas ao criar o cluster do EKS com os campos `RemoteNodeNetwork` e `RemotePodNetwork`. Seus CIDRs de nós on-premises devem ser roteáveis na rede on-premises. Consulte a seção a seguir para obter informações sobre a roteabilidade do CIDR de pods on-premises. Os blocos CIDR de nós e pods on-premises devem atender aos seguintes requisitos: 1. Estar dentro de um dos intervalos `IPv4` RFC-1918: `10.0.0.0/8`, `172.16.0.0/12` ou `192.168.0.0/16`, ou dentro do intervalo CGNAT definido pela RFC 6598: `100.64.0.0/10`. 1. Não se sobrepor entre si, com o CIDR da VPC do cluster do EKS ou com o CIDR de `IPv4` do serviço do Kubernetes. ### Roteamento de rede de pods on-premises Ao usar o EKS Hybrid Nodes, geralmente recomendamos que você torne seus CIDRs de pods on-premises roteáveis em sua rede on-premises para permitir a comunicação e a funcionalidade completas do cluster entre os ambientes na nuvem e on-premises. **Redes de pods roteáveis** Se você conseguir tornar a rede de pods roteável na rede on-premises, siga as orientações abaixo. 1. Configure o campo `RemotePodNetwork` para o cluster do EKS com o CIDR do pod on-premises, as tabelas de rotas da VPC com o CIDR do pod on-premises e o grupo de segurança do cluster do EKS com o CIDR do pod on-premises. 1. Você pode usar várias técnicas para tornar seu pod CIDR on-premises roteável na rede on-premises, incluindo o Protocolo de Gateway da Borda (BGP), rotas estáticas ou outras soluções de roteamento personalizadas. O BGP é a solução recomendada, pois é mais escalável e fácil de gerenciar do que soluções alternativas, que demandam uma configuração de rota personalizada ou manual. A AWS dá suporte aos recursos do BGP do Cilium e do Calico para anunciar CIDRs do pod. Consulte [Configurar a CNI para nós híbridos](hybrid-nodes-cni.md) e [CIDRs de pods remotos roteáveis](hybrid-nodes-concepts-kubernetes.md#hybrid-nodes-concepts-k8s-pod-cidrs) para obter mais informações. 1. Os webhooks podem ser executados em nós híbridos, pois o ambiente de gerenciamento do EKS é capaz de se comunicar com os endereços IP de pods atribuídos aos webhooks. 1. As workloads executadas em nós de nuvem podem se comunicar diretamente com workloads executadas em nós híbridos no mesmo cluster do EKS. 1. Outros serviços da AWS, como o AWS Application Load Balancers e o Amazon Managed Service for Prometheus, são capazes de se comunicar com workloads executadas em nós híbridos para equilibrar o tráfego da rede e extrair métricas de pods. **Redes de pods não roteáveis** Se você *não* conseguir tornar suas redes de pods roteáveis na rede on-premises, siga as orientações abaixo. 1. Os webhooks não podem ser executados em nós híbridos porque eles exigem uma conectividade do ambiente de gerenciamento do EKS com os endereços IP de pods atribuídos aos webhooks. Nesse caso, recomendamos que você execute webhooks em nós de nuvem no mesmo cluster do EKS que seus nós híbridos. Consulte [Configurar webhooks para nós híbridos](hybrid-nodes-webhooks.md) para obter mais informações. 1. As workloads executadas em nós de nuvem não conseguem se comunicar diretamente com as workloads executadas em nós híbridos ao usar a CNI da VPC para nós de nuvem e o Cilium ou o Calico para nós híbridos. 1. Use a Distribuição de Tráfego de Serviços para manter o tráfego local na zona de onde ele é originado. Para obter mais informações sobre Distribuição de Tráfego de Serviços, consulte [Configurar a Distribuição de Tráfego de Serviços](hybrid-nodes-webhooks.md#hybrid-nodes-mixed-service-traffic-distribution). 1. Configure sua CNI para usar mascaramento de saída ou conversão de endereços de rede (NAT) para o tráfego de pods quando ela sair de seus hosts on-premises. Esta opção está habilitada por padrão no Cilium. O Calico requer que `natOutgoing` seja definido como `true`. 1. Outros serviços da AWS, como o AWS Application Load Balancers e o Amazon Managed Service for Prometheus, não são capazes de se comunicar com workloads executadas em nós híbridos. ### Acesso necessário durante a instalação e atualização de nós híbridos Você deve ter acesso aos domínios a seguir durante o processo de instalação em que instala as dependências dos nós híbridos nos hosts. Esse processo pode ser feito uma vez quando você está criando as imagens do sistema operacional ou em cada host no runtime. Isso inclui a instalação inicial e quando você atualiza a versão do Kubernetes dos nós híbridos. Alguns pacotes são instalados usando o gerenciador de pacotes padrão do sistema operacional. Para AL2023 e RHEL, o `yum` comando é usado para instalar `containerd` , `ca-certificates` , `iptables` e `amazon-ssm-agent` . Para o Ubuntu, `apt` é usado para instalar `containerd` , `ca-certificates` e `iptables` , e `snap` é usado para instalar `amazon-ssm-agent` . | Componente | URL | Protocolo | Porta | | --- | --- | --- | --- | | Artefatos dos nós do EKS (S3) | https://hybrid-assets.eks.amazonaws.com | HTTPS | 443 | | [Endpoints de serviços da VPC](https://docs.aws.amazon.com/general/latest/gr/eks.html) | https://eks.*region*.amazonaws.com | HTTPS | 443 | | [Endpoints de serviços do ECR](https://docs.aws.amazon.com/general/latest/gr/ecr.html) | https://api.ecr.*region*.amazonaws.com | HTTPS | 443 | | Endpoints do ECR do EKS | Consulte [Visualizar registros de imagens de contêineres da Amazon para complementos do Amazon EKS](add-ons-images.md) dos endpoints regionais. | HTTPS | 443 | | Endpoint binário do SSM 1 | https://amazon-ssm-*region*.s3.*region*.amazonaws.com | HTTPS | 443 | | [Endpoint do serviço do SSM](https://docs.aws.amazon.com/general/latest/gr/ssm.html) 1 | https://ssm.*region*.amazonaws.com | HTTPS | 443 | | Endpoint binário do IAM Anywhere 2 | https://rolesanywhere.amazonaws.com | HTTPS | 443 | | [Endpoint do serviço do IAM Anywhere](https://docs.aws.amazon.com/general/latest/gr/rolesanywhere.html) 2 | https://rolesanywhere.*region*.amazonaws.com | HTTPS | 443 | | Endpoints do gerenciador de pacotes do sistema operacional | Os endpoints do repositório de pacotes são específicos do sistema operacional e podem variar de acordo com a região geográfica. | HTTPS | 443 | **nota** 1 O acesso aos endpoints do AWS SSM só será necessário se você estiver usando ativações híbridas do AWS SSM para o provedor de credenciais do IAM on-premises. 2 O acesso aos endpoints do AWS IAM só será necessário se você estiver usando o AWS IAM Roles Anywhere para seu provedor de credenciais do IAM on-premises. ### Acesso necessário para operações contínuas do cluster O acesso à rede a seguir para o firewall on-premises é necessário para operações contínuas do cluster. **Importante** Dependendo da sua escolha de CNI, você precisa configurar regras adicionais de acesso à rede para as portas da CNI. Consulte a [documentação do Cilium](https://docs.cilium.io/en/stable/operations/system_requirements/#firewall-rules) e a [documentação do Calico](https://docs.tigera.io/calico/latest/getting-started/kubernetes/requirements#network-requirements) para obter detalhes. | Tipo | Protocolo | Direção | Porta | Origem | Destino | Usage | | --- | --- | --- | --- | --- | --- | --- | | HTTPS | TCP | Saída | 443 | CIDRs remotos de nós | IPs do cluster de EKS 1 | Kubelet para servidor de API do Kubernetes | | HTTPS | TCP | Saída | 443 | CIDR(s) remoto(s) de pods | IPs do cluster de EKS 1 | Pod para servidor de API do Kubernetes | | HTTPS | TCP | Saída | 443 | CIDRs remotos de nós | [Endpoint do serviço do SSM](https://docs.aws.amazon.com/general/latest/gr/ssm.html) | Atualização de credenciais de ativações híbridas do SSM e heartbeats do SSM a cada cinco minutos | | HTTPS | TCP | Saída | 443 | CIDRs remotos de nós | [Endpoint do serviço do IAM Anywhere](https://docs.aws.amazon.com/general/latest/gr/rolesanywhere.html) | Atualização de credenciais do IAM Roles Anywhere | | HTTPS | TCP | Saída | 443 | CIDR(s) remoto(s) de pods | [Endpoint regional do STS](https://docs.aws.amazon.com/general/latest/gr/sts.html) | Pod para endpoint do STS, necessário somente para IRSA | | HTTPS | TCP | Saída | 443 | CIDRs remotos de nós | [Endpoint do serviço de autenticação do Amazon EKS](https://docs.aws.amazon.com/general/latest/gr/eks.html) | Nó para endpoint de autenticação do Amazon EKS, necessário somente para a Identidade de Pods do Amazon EKS | | HTTPS | TCP | Entrada | 10250 | IPs do cluster de EKS 1 | CIDR(s) remoto(s) de nós | Servidor de API do Kubernetes para kubelet | | HTTPS | TCP | Entrada | Portas de webhook | IPs do cluster de EKS 1 | CIDR(s) remoto(s) de pods | Servidor de API do Kubernetes para webhooks | | HTTPS | TCP e UDP | Entrada e saída | 53 | CIDR(s) remoto(s) de pods | CIDR(s) remoto(s) de pods | Pod para CoreDNS. Caso execute pelo menos uma réplica do CoreDNS na nuvem, você deverá permitir o tráfego de DNS para a VPC em que o CoreDNS está sendo executado. | | Definido pelo usuário | Definido pelo usuário | Entrada e saída | Portas da aplicação | CIDR(s) remoto(s) de pods | CIDR(s) remoto(s) de pods | Pod para Pod | **nota** 1 Os IPs do cluster do EKS. Consulte a seção a seguir sobre as interfaces de rede elástica do Amazon EKS. ### Interfaces de rede do Amazon EKS O Amazon EKS anexa interfaces de rede às sub-redes na VPC que você passa durante a criação do cluster para permitir a comunicação entre o ambiente de gerenciamento do EKS e a VPC. As interfaces de rede que o Amazon EKS cria podem ser encontradas após a criação do cluster no console do Amazon EC2 ou com a AWS CLI. As interfaces de rede originais são excluídas, e novas interfaces de rede são criadas quando as alterações são aplicadas no cluster do EKS, como atualizações de versão do Kubernetes. Você pode restringir o intervalo de IPs das interfaces de rede do Amazon EKS usando tamanhos de sub-rede restritos para as sub-redes que você passa durante a criação do cluster, o que facilita a configuração do firewall on-premises para permitir conectividade de entrada e saída com esse conjunto conhecido e restrito de IPs. Para controlar quais interfaces de rede de sub-redes são criadas, você poderá limitar o número de sub-redes especificadas ao criar um cluster ou atualizar as sub-redes depois de criar o cluster. As interfaces de rede provisionadas pelo Amazon EKS têm uma descrição do formato `Amazon EKS your-cluster-name `. Veja o exemplo abaixo para um comando da AWS CLI que você pode usar para encontrar os endereços IP das interfaces de rede que o Amazon EKS provisiona. Substitua `VPC_ID` pelo ID da VPC que você passa durante a criação do cluster. ``` aws ec2 describe-network-interfaces \ --query 'NetworkInterfaces[?(VpcId == VPC_ID && contains(Description,Amazon EKS))].PrivateIpAddress' ``` ## Configuração de sub-redes e da AWS VPC Os [requisitos existentes de VPC e sub-redes](network-reqs.md) para o Amazon EKS se aplicam a clusters com nós híbridos. Além disso, o CIDR da VPC não pode se sobrepor aos CIDRs de nós e pods on-premises. Você deve configurar rotas na tabela de roteamento da VPC para seu nó on-premises e, opcionalmente, para os CIDRs de pods. Essas rotas devem ser configuradas para rotear o tráfego para o gateway que você está usando para sua conectividade de rede híbrida, que geralmente é um gateway privado virtual (VGW) ou gateway de trânsito (TGW). Caso esteja usando o TGW ou VGW para conectar a VPC ao ambiente on-premises, você deverá criar um anexo do TGW ou VGW para a VPC. Sua VPC deve ter suporte de nomes de host de DNS e resolução de DNS. As etapas a seguir usam a AWS CLI. Você também pode criar esses recursos no Console de gerenciamento da AWS ou com outras interfaces, como o AWS CloudFormation, AWS CDK ou Terraform. ### Etapa 1: criar uma VPC 1. Execute o comando a seguir para criar uma VPC. Realize a troca de VPC\$1CIDR por um intervalo CIDR IPv4 que seja RFC 1918 (privado), CGNAT (RFC 6598) ou não RFC 1918/não CGNAT (público) (por exemplo, 10.0.0.0/16). Observação: a resolução de DNS, que é um requisito do EKS, está habilitada para a VPC por padrão. ``` aws ec2 create-vpc --cidr-block VPC_CIDR ``` 1. Habilite nomes de host DNS para a VPC. Observe que a resolução de DNS está habilitada para a VPC por padrão. Substitua `VPC_ID` pelo ID da VPC que você criou na etapa anterior. ``` aws ec2 modify-vpc-attribute --vpc-id VPC_ID --enable-dns-hostnames ``` ### Etapa 2: criar sub-redes Crie pelo menos duas sub-redes. O Amazon EKS usa essas sub-redes para as interfaces de rede do cluster. Para obter mais informações, consulte os [requisitos e considerações sobre sub-redes](network-reqs.md#network-requirements-subnets). 1. Você pode encontrar as zonas de disponibilidade de uma região da AWS com o comando a seguir. Substitua `us-west-2` pela sua região. ``` aws ec2 describe-availability-zones \ --query 'AvailabilityZones[?(RegionName == us-west-2)].ZoneName' ``` 1. Crie uma sub-rede. Substitua `VPC_ID` pelo ID da VPC. Substitua `SUBNET_CIDR` pelo bloco CIDR da sub-rede (por exemplo, 10.0.1.0/24). Substitua `AZ` pela zona de disponibilidade em que a sub-rede será criada (por exemplo, us-west-2a). As sub-redes que você criar devem estar em ao menos duas diferentes zonas de disponibilidade. ``` aws ec2 create-subnet \ --vpc-id VPC_ID \ --cidr-block SUBNET_CIDR \ --availability-zone AZ ``` ### (Opcional) Etapa 3: anexar a VPC ao gateway de trânsito (TGW) da Amazon VPC ou ao gateway privado virtual (VGW) do AWS Direct Connect. Se você estiver usando um TGW ou VGW, anexe sua VPC ao TGW ou VGW. Para obter mais informações, consulte os [anexos da Amazon VPC em Gateways de trânsito da Amazon VPC](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-vpc-attachments.html) ou as [associações de gateway privado virtual do AWS Direct Connect](https://docs.aws.amazon.com/vpn/latest/s2svpn/how_it_works.html#VPNGateway). **Transit Gateway** Execute o comando a seguir para anexar um gateway de trânsito. Substitua `VPC_ID` pelo ID da VPC. Substitua `SUBNET_ID1` e `SUBNET_ID2` pelos IDs das sub-redes que você criou na etapa anterior. Substitua `TGW_ID` pelo ID do TGW. ``` aws ec2 create-transit-gateway-vpc-attachment \ --vpc-id VPC_ID \ --subnet-ids SUBNET_ID1 SUBNET_ID2 \ --transit-gateway-id TGW_ID ``` **Gateway privado virtual** Execute o comando a seguir para anexar um gateway de trânsito. Substitua `VPN_ID` pelo ID do VGW. Substitua `VPC_ID` pelo ID da VPC. ``` aws ec2 attach-vpn-gateway \ --vpn-gateway-id VPN_ID \ --vpc-id VPC_ID ``` ### (Opcional) Etapa 4: Criar tabela de rotas Você pode modificar a tabela de rotas principal para a VPC ou criar uma tabela de rotas personalizada. As etapas a seguir criam uma tabela de rotas personalizada com as rotas para os CIDRs de nós e pods on-premises. Para obter mais informações, consulte [Tabelas de rotas de sub-redes](https://docs.aws.amazon.com/vpc/latest/userguide/subnet-route-tables.html). Substitua `VPC_ID` pelo ID da VPC. ``` aws ec2 create-route-table --vpc-id VPC_ID ``` ### Etapa 5: criar rotas para nós e pods on-premises Crie rotas na tabela de rotas para cada um dos nós remotos on-premises. Você pode modificar a tabela de rotas principal da VPC ou usar a tabela de rotas personalizada que você criou na etapa anterior. Os exemplos abaixo mostram como criar rotas para os CIDRs de nós e pods on-premises. Nos exemplos, um gateway de trânsito (TGW) é usado para conectar a VPC ao ambiente on-premises. Se você tiver vários CIDRs de nós e pods on-premises, repita as etapas para cada CIDR. + Se você estiver usando um gateway da internet ou um gateway privado virtual (VGW), substitua `--transit-gateway-id` por `--gateway-id`. + Substitua `RT_ID` pelo ID da tabela de rotas que você criou na etapa anterior. + Substitua `REMOTE_NODE_CIDR` pelo intervalo de CIDRs que você usará para os nós híbridos. + Substitua `REMOTE_POD_CIDR` pelo intervalo de CIDRs que você usará para os pods executados em nós híbridos. O intervalo de CIDRs de pods corresponde à configuração da interface de rede de contêineres (CNI), que geralmente usa uma rede de sobreposição on-premises. Para obter mais informações, consulte [Configurar a CNI para nós híbridos](hybrid-nodes-cni.md). + Substitua `TGW_ID` pelo ID do TGW. **Rede remota de nós** ``` aws ec2 create-route \ --route-table-id RT_ID \ --destination-cidr-block REMOTE_NODE_CIDR \ --transit-gateway-id TGW_ID ``` **Rede remota de pods** ``` aws ec2 create-route \ --route-table-id RT_ID \ --destination-cidr-block REMOTE_POD_CIDR \ --transit-gateway-id TGW_ID ``` ### (Opcional) Etapa 6: associar sub-redes à tabela de rotas Caso tenha criado uma tabela de rotas personalizada na etapa anterior, associe cada uma das sub-redes criadas na etapa anterior à tabela de rotas personalizada. Caso esteja modificando a tabela de rotas principal da VPC, as sub-redes serão automaticamente associadas à tabela de rotas principal da VPC, e você poderá pular esta etapa. Execute o comando a seguir para cada uma das sub-redes que você criou nas etapas anteriores. Substitua `RT_ID` pela tabela de rotas que você criou na etapa anterior. Substitua `SUBNET_ID` pelo ID de uma sub-rede. ``` aws ec2 associate-route-table --route-table-id RT_ID --subnet-id SUBNET_ID ``` ## Configuração do grupo de segurança do cluster O acesso a seguir para o grupo de segurança do cluster do EKS é necessário para operações contínuas do cluster. O Amazon EKS cria automaticamente as regras de grupo de segurança de **entrada** necessárias para nós híbridos quando você cria ou atualiza seu cluster com redes remotas de nós e pods configuradas. Como os grupos de segurança permitem todo o tráfego de **saída** por padrão, o Amazon EKS não modifica automaticamente as regras de **saída** do grupo de segurança do cluster para nós híbridos. Se quiser personalizar o grupo de segurança do cluster, você pode limitar o tráfego às regras na tabela a seguir. | Tipo | Protocolo | Direção | Porta | Origem | Destino | Usage | | --- | --- | --- | --- | --- | --- | --- | | HTTPS | TCP | Entrada | 443 | CIDRs remotos de nós | N/D | Kubelet para o servidor de API do Kubernetes | | HTTPS | TCP | Entrada | 443 | CIDRs remotos de pods | N/D | Pods que exigem acesso ao servidor de API do K8s quando a CNI não está usando NAT para o tráfego de pods. | | HTTPS | TCP | Saída | 10250 | N/D | CIDRs remotos de nós | Servidor de API do Kubernetes para Kubelet | | HTTPS | TCP | Saída | Portas de webhook | N/D | CIDRs remotos de pods | Servidor de API do Kubernetes para webhook (se estiver executando webhooks em nós híbridos) | **Importante** **Limites das regras de grupos de segurança**: os grupos de segurança do Amazon EC2 têm no máximo 60 regras de entrada por padrão. As regras de entrada do grupo de segurança podem não se aplicar se o grupo de segurança do cluster se aproximar desse limite. Nesse caso, pode ser necessário adicionar manualmente as regras de entrada ausentes. **Responsabilidade de limpeza do CIDR**: se você remover redes remotas de nós ou pods dos clusters do EKS, o EKS não removerá automaticamente as regras de grupo de segurança correspondentes. Você é responsável por remover manualmente redes remotas de nós ou pods não utilizadas das regras do seu grupo de segurança. Para saber mais sobre o grupo de segurança de cluster criado pelo Amazon EKS, consulte [Exibir os requisitos para grupos de segurança do Amazon EKS em clusters](sec-group-reqs.md). ### (Opcional) Configuração manual de grupos de segurança Se precisar criar grupos de segurança adicionais ou modificar as regras criadas automaticamente, é possível usar os comandos a seguir como referência. Por padrão, o comando abaixo cria um grupo de segurança que permite todo o acesso externo. Você pode restringir o acesso externo para incluir somente as regras acima. Caso esteja pensando em limitar regras de saída, recomendamos testar completamente todas as aplicações e a conectividade de pods antes de aplicar as regras modificadas a um cluster do produção. + No primeiro comando, substitua `SG_NAME` por um nome para o grupo de segurança + No primeiro comando, substitua `VPC_ID` pelo ID da VPC que você criou na etapa anterior + No segundo comando, substitua `SG_ID` pelo ID do grupo de segurança que você criou no primeiro comando + No segundo comando, substitua `REMOTE_NODE_CIDR` e `REMOTE_POD_CIDR` pelos valores dos nós híbridos e da rede on-premises. ``` aws ec2 create-security-group \ --group-name SG_NAME \ --description "security group for hybrid nodes" \ --vpc-id VPC_ID ``` ``` aws ec2 authorize-security-group-ingress \ --group-id SG_ID \ --ip-permissions '[{"IpProtocol": "tcp", "FromPort": 443, "ToPort": 443, "IpRanges": [{"CidrIp": "REMOTE_NODE_CIDR"}, {"CidrIp": "REMOTE_POD_CIDR"}]}]' ``` # Preparar o sistema operacional para nós híbridos Preparar o sistema operacional O Bottlerocket, o Amazon Linux 2023 (AL2023), o Ubuntu e o RHEL são validados continuamente para uso como o sistema operacional de nós para nós híbridos. O Bottlerocket tem suporte da AWS somente em ambientes VMware vSphere. O AL2023 não é coberto pelos planos do AWS Support quando executado fora do Amazon EC2. O AL2023 só pode ser usado em ambientes virtualizados on-premises. Consulte o [Guia do usuário do Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/ug/outside-ec2.html) para obter mais informações. A AWS oferece suporte à integração de nós híbridos com os sistemas operacionais Ubuntu e RHEL, mas não oferece suporte para os sistemas operacionais em si. Você é responsável pelo provisionamento e gerenciamento do sistema operacional. Quando você estiver testando nós híbridos pela primeira vez, é mais fácil executar a CLI (`nodeadm`) do Amazon EKS Hybrid Nodes em um host já provisionado. Para implantações de produção, recomenda-se incluir o `nodeadm` nas imagens do sistema operacional configurado para ser executado como um serviço systemd para unir automaticamente os hosts aos clusters do Amazon EKS na inicialização do host. Se você estiver usando o Bottlerocket como seu sistema operacional de nó no vSphere, não precisará usar `nodeadm`, pois o Bottlerocket já contém as dependências necessárias para nós híbridos e se conectará automaticamente ao cluster configurado na inicialização do host. ## Compatibilidade da versão A tabela abaixo representa as versões do sistema operacional que são compatíveis e validadas para uso como sistema operacional de nó para nós híbridos. Se você estiver usando outras variantes ou versões do sistema operacional que não estão incluídas nesta tabela, então a compatibilidade dos nós híbridos com a variante ou a versão do sistema operacional não é coberta pelo AWS Support. Os nós híbridos são independentes da infraestrutura subjacente e são compatíveis com as arquiteturas x86 e ARM. | Sistema operacional | Versões | | --- | --- | | Amazon Linux | Amazon Linux 2023 (AL2023) | | Bottlerocket | Variantes do VMware v1.37.0 e posteriores que executam o Kubernetes v1.28 e superior | | Ubuntu | Ubuntu 20.04, Ubuntu 22.04 e Ubuntu 24.04 | | Red Hat Enterprise Linux | RHEL 8, RHEL 9 | ## Considerações sobre sistemas operacionais ### Geral + A CLI (`nodeadm`) do Amazon EKS Hybrid Nodes pode ser usada para simplificar a instalação e a configuração dos componentes e dependências dos nós híbridos. Você pode executar o processo `nodeadm install` durante os pipelines de criação de imagens do sistema operacional ou no runtime em cada host on-premises. Para obter mais informações sobre os componentes que o `nodeadm` instala, consulte [Referência do `nodeadm` para nós híbridos](hybrid-nodes-nodeadm.md). + Se você estiver usando um proxy no ambiente on-premises para acessar a internet, é necessária uma configuração adicional do sistema operacional para que os processos de instalação e atualização configurem o gerenciador de pacotes para usar o proxy. Para obter instruções, consulte [Configurar proxy para nós híbridos](hybrid-nodes-proxy.md). ### Bottlerocket + As etapas e ferramentas para conectar um nó do Bottlerocket são diferentes das etapas de outros sistemas operacionais e são abordadas separadamente em [Conectar nós híbridos com o Bottlerocket](hybrid-nodes-bottlerocket.md), em vez das etapas em [Conectar nós híbridos](hybrid-nodes-join.md). + As etapas do Bottlerocket não usam a ferramenta de nós híbridos da CLI, `nodeadm`. + Somente as variantes VMware do Bottlerocket versão v1.37.0 e superior são compatíveis com os nós híbridos do EKS. As variantes de VMware do Bottlerocket estão disponíveis para as versões v1.28 e superiores do Kubernetes. [Outras variantes do Bottlerocket](https://bottlerocket.dev/en/os/1.36.x/concepts/variants) não são aceitas como sistema operacional de nós híbridos. OBSERVAÇÃO: as variantes de VMware do Bottlerocket estão disponíveis apenas para a arquitetura x86\$164. ### Containerd + O Containerd é o runtime de contêiner padrão do Kubernetes e é uma dependência para nós híbridos, bem como para todos os tipos de computação de nós do Amazon EKS. A CLI do Amazon EKS Hybrid Nodes (`nodeadm`) tenta instalar o containerd durante o processo `nodeadm install`. Você pode configurar a instalação do containerd no runtime de `nodeadm install` com a opção da linha de comando `--containerd-source`. As opções válidas são: `none`, `distro` e `docker`. Caso esteja usando o RHEL, o `distro` não será uma opção válida e você pode configurar o `nodeadm` para instalar o build do containerd dos repositórios do Docker, ou pode instalar manualmente o containerd. Ao usar o AL2023 ou o Ubuntu, o `nodeadm` instala por padrão o containerd da distribuição do sistema operacional. Se você não quiser que o nodeadm instale o containerd, use a opção `--containerd-source none`. ### Ubuntu + Caso esteja usando o Ubuntu 24.04, talvez seja necessário atualizar a versão do containerd ou alterar a configuração do AppArmor para adotar uma correção que permita que os pods terminem corretamente. Consulte [Ubuntu \$12065423](https://bugs.launchpad.net/ubuntu/+source/containerd-app/\+bug/2065423). É necessária uma reinicialização para aplicar as alterações no usuário do AppArmor. A versão mais recente do Ubuntu 24.04 tem uma versão atualizada do containerd em seu gerenciador de pacotes com a correção (containerd versão 1.7.19\$1). ### Arm + Se você estiver usando hardware ARM, um processador compatível com ARMv8.2 com a extensão de criptografia (ARMv8.2\$1crypto) é necessário para executar a versão 1.31 e mais recente do complemento kube-proxy do EKS. Todos os sistemas Raspberry Pi anteriores ao Raspberry Pi 5, bem como os processadores baseados em Cortex-A72, não atendem a esse requisito. Como solução alternativa, você pode continuar a usar a versão 1.30 do complemento kube-proxy do EKS até o fim do suporte estendido em julho de 2026, consulte [Calendário de lançamentos do Kubernetes](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html), ou pode usar uma imagem do kube-proxy personalizada do upstream. + A mensagem de erro a seguir no log do kube-proxy indica esta incompatibilidade: ``` Fatal glibc error: This version of Amazon Linux requires a newer ARM64 processor compliant with at least ARM architecture 8.2-a with Cryptographic extensions. On EC2 this is Graviton 2 or later. ``` ## Criar imagens do sistema operacional O Amazon EKS fornece [modelos de exemplo do Packer](https://github.com/aws/eks-hybrid/tree/main/example/packer) que você pode usar para criar imagens do sistema operacional que incluem o `nodeadm` e o configuram para execução na inicialização do host. Esse processo é recomendado para evitar extrair as dependências dos nós híbridos individualmente em cada host e para automatizar o processo de bootstrap dos nós híbridos. Você pode usar os modelos de exemplo do Packer com uma imagem ISO do Ubuntu 22.04, Ubuntu 24.04, RHEL 8 ou RHEL 9 e pode gerar imagens com estes formatos: OVA, Qcow2 ou raw. ### Pré-requisitos Antes de usar os modelos de exemplo do Packer, você deve ter o seguinte instalado na máquina de onde está executando o Packer: + Packer versão 1.11.0 ou posterior. Para obter instruções sobre como instalar o Packer, consulte [Install Packer](https://developer.hashicorp.com/packer/tutorials/docker-get-started/get-started-install-cli) na documentação do Packer. + Se estiver criando OVAs, plug-in do VMware vSphere 1.4.0 ou superior + Se estiver criando imagens `Qcow2` ou raw, plug-in do QEMU versão 1.x ### Definir variáveis de ambiente Antes de executar o build do Packer, defina as variáveis de ambiente a seguir na máquina de onde está executando o Packer. **Geral** As variáveis de ambiente a seguir devem ser definidas para criar imagens com todos os sistemas operacionais e formatos de saída. | Variável de ambiente | Tipo | Descrição | | --- | --- | --- | | PKR\$1SSH\$1PASSWORD | String | O Packer usa as variáveis `ssh_username` e `ssh_password` para usar SSH na máquina criada durante o provisionamento. Isso precisa corresponder às senhas usadas para criar o usuário inicial nos arquivos de kickstart ou user-data do respectivo sistema operacional. O padrão é definido como "builder" ou "ubuntu", dependendo do sistema operacional. Ao definir a senha, certifique-se de alterá-la no arquivo `ks.cfg` ou `user-data` correspondente para que haja correspondência. | | ISO\$1URL | String | URL da ISO a ser usada. Pode ser um link da Web para download de um servidor ou um caminho absoluto para um arquivo local. | | ISO\$1CHECKSUM | String | Soma de verificação associada para a ISO fornecida. | | CREDENTIAL\$1PROVIDER | String | Provedor de credenciais para nós híbridos. Os valores válidos são `ssm` (padrão) para ativações híbridas do SSM e o `iam` para IAM Roles Anywhere | | K8S\$1VERSION | String | Versão do Kubernetes para nós híbridos (por exemplo, `1.31`). Para saber sobre as versões compatíveis com o Kubernetes, consulte [Versões compatíveis com o Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html). | | NODEADM\$1ARCH | String | Arquitetura para `nodeadm install`: Selecione `amd` ou `arm`. | **RHEL** Se você estiver usando o RHEL, as variáveis de ambiente a seguir devem ser definidas. | Variável de ambiente | Tipo | Descrição | | --- | --- | --- | | RH\$1USERNAME | String | Nome de usuário do gerenciador de assinaturas do RHEL | | RH\$1PASSWORD | String | Senha do gerenciador de assinaturas RHEL | | RHEL\$1VERSION | String | Versão ISO do RHEL sendo usada. Os valores válidos são `8` ou `9`. | **Ubuntu** Não são necessárias variáveis de ambiente específicas do Ubuntu. **vSphere** Se você estiver criando um OVA para VMware vSphere, as variáveis de ambiente a seguir deverão ser definidas. | Variável de ambiente | Tipo | Descrição | | --- | --- | --- | | VSPHERE\$1SERVER | String | Endereço do servidor vSphere | | VSPHERE\$1USER | String | Nome de usuário do vSphere | | VSPHERE\$1PASSWORD | String | Senha do vSphere | | VSPHERE\$1DATACENTER | String | Nome do data center do vSphere | | VSPHERE\$1CLUSTER | String | Nome do cluster do vSphere | | VSPHERE\$1DATASTORE | String | Nome do datastore do vSphere | | VSPHERE\$1NETWORK | String | Nome da rede do vSphere | | VSPHERE\$1OUTPUT\$1FOLDER | String | Pasta de saída do vSphere para os modelos | **QEMU** | Variável de ambiente | Tipo | Descrição | | --- | --- | --- | | PACKER\$1OUTPUT\$1FORMAT | String | Formato de saída para o construtor do QEMU. Os valores válidos são `qcow2` e `raw`. | **Validar modelo** Antes de executar o build, valide o modelo com o comando a seguir após definir as variáveis de ambiente. Substitua `template.pkr.hcl` caso esteja usando um nome diferente para o modelo. ``` packer validate template.pkr.hcl ``` ### Criar imagens Crie as imagens com os comandos a seguir e use o sinalizador `-only` para especificar o destino e o sistema operacional para as imagens. Substitua `template.pkr.hcl` caso esteja usando um nome diferente para o modelo. **OVAs para vSphere** **nota** Caso esteja usando o RHEL com o vSphere, você precisará converter os arquivos kickstart em uma imagem OEMDRV e passá-la como uma ISO para inicializar. Para obter mais informações, consulte [Packer Readme](https://github.com/aws/eks-hybrid/tree/main/example/packer#utilizing-rhel-with-vsphere) no Repositório do EKS Hybrid Nodes GitHub. **OVA para Ubuntu** ``` packer build -only=general-build.vsphere-iso.ubuntu22 template.pkr.hcl ``` **OVA para Ubuntu** ``` packer build -only=general-build.vsphere-iso.ubuntu24 template.pkr.hcl ``` **OVA para RHEL** ``` packer build -only=general-build.vsphere-iso.rhel8 template.pkr.hcl ``` **OVA para RHEL** ``` packer build -only=general-build.vsphere-iso.rhel9 template.pkr.hcl ``` **QEMU** **nota** Se você estiver criando uma imagem para uma CPU host específica que não corresponde ao host construtor, consulte a documentação do [QEMU](https://www.qemu.org/docs/master/system/qemu-cpu-models.html) para obter o nome que corresponda à CPU host e use o sinalizador `-cpu` com o nome da CPU host ao executar os comandos a seguir. **Ubuntu 22.04 Qcow2/Raw** ``` packer build -only=general-build.qemu.ubuntu22 template.pkr.hcl ``` **Ubuntu 24.04 Qcow2/Raw** ``` packer build -only=general-build.qemu.ubuntu24 template.pkr.hcl ``` **RHEL 8 Qcow2/Raw** ``` packer build -only=general-build.qemu.rhel8 template.pkr.hcl ``` **RHEL 9 Qcow2/Raw** ``` packer build -only=general-build.qemu.rhel9 template.pkr.hcl ``` ### Passar a configuração do nodeadm por meio dos dados do usuário Você pode passar a configuração para `nodeadm` nos dados do usuário por meio da inicialização da nuvem para configurar e conectar automaticamente os nós híbridos ao cluster do EKS na inicialização do host. Veja abaixo um exemplo de como fazer isso ao usar o VMware vSphere como a infraestrutura para seus nós híbridos. 1. Instale a CLI `govc` seguindo as instruções no [readme do govc](https://github.com/vmware/govmomi/blob/main/govc/README.md) no GitHub. 1. Depois de executar o comando build do Packer na seção anterior e provisionar o modelo, você pode clonar o modelo para criar vários nós diferentes usando o seguinte: Você deve clonar o modelo de cada nova VM que você está criando que será usada para nós híbridos. Substitua as variáveis no comando abaixo pelos valores do seu ambiente. `VM_NAME` no comando abaixo é usado como seu `NODE_NAME` quando você injeta os nomes das VMs por meio do arquivo `metadata.yaml`. ``` govc vm.clone -vm "/PATH/TO/TEMPLATE" -ds="YOUR_DATASTORE" \ -on=false -template=false -folder=/FOLDER/TO/SAVE/VM "VM_NAME" ``` 1. Depois de clonar o modelo para cada uma das suas novas VMs, crie um `userdata.yaml` e `metadata.yaml` para as VMs. Suas VMs podem compartilhar o mesmo `userdata.yaml` e `metadata.yaml` e você os preencherá por VM nas etapas abaixo. A configuração do `nodeadm` é criada e definida na seção `write_files` do `userdata.yaml`. O exemplo abaixo usa as ativações híbridas do AWS SSM como o provedor de credenciais on-premises para nós híbridos. Para obter mais informações sobre a configuração do `nodeadm`, consulte [Referência do `nodeadm` para nós híbridos](hybrid-nodes-nodeadm.md). **userdata.yaml:** ``` #cloud-config users: - name: # username for login. Use 'builder' for RHEL or 'ubuntu' for Ubuntu. passwd: # password to login. Default is 'builder' for RHEL. groups: [adm, cdrom, dip, plugdev, lxd, sudo] lock-passwd: false sudo: ALL=(ALL) NOPASSWD:ALL shell: /bin/bash write_files: - path: /usr/local/bin/nodeConfig.yaml permissions: '0644' content: | apiVersion: node.eks.aws/v1alpha1 kind: NodeConfig spec: cluster: name: # Cluster Name region: # AWS region hybrid: ssm: activationCode: # Your ssm activation code activationId: # Your ssm activation id runcmd: - /usr/local/bin/nodeadm init -c file:///usr/local/bin/nodeConfig.yaml >> /var/log/nodeadm-init.log 2>&1 ``` **metadata.yaml:** Crie um `metadata.yaml` para o ambiente. Mantenha o formato da variável `"$NODE_NAME"` no arquivo, pois ela será preenchida com valores em uma etapa subsequente. ``` instance-id: "$NODE_NAME" local-hostname: "$NODE_NAME" network: version: 2 ethernets: nics: match: name: ens* dhcp4: yes ``` 1. Adicione os arquivos `userdata.yaml` e `metadata.yaml` como strings `gzip+base64` com os comandos a seguir. Os comandos a seguir devem ser executados para cada uma das VMs que você está criando. Substitua `VM_NAME` pelo nome da VM que você está atualizando. ``` export NODE_NAME="VM_NAME" export USER_DATA=$(gzip -c9 metadata.yaml.tmp export METADATA=$(gzip -c9 443/TCP 28h ``` ## Etapa 4: configuração do cluster Como próxima etapa, consulte [Preparar o acesso ao cluster para nós híbridos](hybrid-nodes-cluster-prep.md) para habilitar o acesso para que os nós híbridos se juntem ao cluster. # Habilitar nós híbridos em um cluster existente do Amazon EKS ou modificar a configuração Cluster existente Este tópico fornece uma visão geral das opções disponíveis e descreve o que deve ser considerado ao adicionar, alterar ou remover a configuração de nós híbridos de um cluster do Amazon EKS. Para permitir que um cluster do Amazon EKS use nós híbridos, adicione os intervalos de CIDR de endereços IP do seu nó on-premises e, opcionalmente, a rede de pods na configuração `RemoteNetworkConfig`. O EKS usa essa lista de CIDRs para habilitar a conectividade entre o cluster e suas redes on-premises. Para obter uma lista completa de opções ao atualizar sua configuração de cluster, consulte [UpdateClusterConfig](https://docs.aws.amazon.com/eks/latest/APIReference/API_UpdateClusterConfig.html) na *Referência de APIs do Amazon EKS*. Você pode realizar qualquer uma das seguintes ações na configuração de rede do EKS Hybrid Nodes em um cluster: + [Adicione a configuração de rede remota para habilitar o EKS Hybrid Nodes em um cluster existente.](#hybrid-nodes-cluster-enable-existing) + [Adicione, altere ou remova as redes de nós remotos ou as redes de pods remotos em um cluster existente.](#hybrid-nodes-cluster-update-config) + [Remova todos os intervalos de CIDR da rede de nós remotos para desabilitar o EKS Hybrid Nodes em um cluster existente.](#hybrid-nodes-cluster-disable) ## Pré-requisitos + Antes de habilitar o cluster do Amazon EKS para nós híbridos, certifique-se de que seu ambiente atenda aos requisitos descritos em [Configuração de pré-requisitos para nós híbridos](hybrid-nodes-prereqs.md) e detalhados em [Preparar a rede para nós híbridos](hybrid-nodes-networking.md) [Preparar o sistema operacional para nós híbridos](hybrid-nodes-os.md) e [Preparar as credenciais para nós híbridos](hybrid-nodes-creds.md). + O cluster dove usar a família de endereços IPv4. + O cluster dove usar a `API` ou `API_AND_CONFIG_MAP` para o modo de autenticação do cluster. O processo para modificar o modo de autenticação do cluster está descrito em [Alterar o modo de autenticação para usar entradas de acesso](setting-up-access-entries.md). + Recomendamos usar o acesso de endpoint público ou privado para o endpoint do servidor da API do Kubernetes do Amazon EKS, mas não ambos. Se você escolher “Público e Privado”, o endpoint do servidor da API do Kubernetes do Amazon EKS sempre resolverá para os IPs públicos dos nós híbridos em execução fora da VPC, o que pode impedir que os nós híbridos se juntem ao cluster. O processo para modificar o acesso à rede ao seu cluster está descrito em [Endpoint do servidor de API do cluster](cluster-endpoint.md). + A versão mais recente da AWS Command Line Interface (AWS CLI) instalada e configurada no seu dispositivo. Para verificar sua versão atual, use `aws --version`. Os gerenciadores de pacotes, como yum, apt-get ou Homebrew para macOS, geralmente estão várias versões atrás da versão mais recente da AWS CLI. Para instalar a versão mais recente, consulte [Instalar ou atualizar a versão mais recente da AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) e [Como definir as configurações da AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) no Guia do usuário da AWS Command Line Interface. + Uma [entidade principal do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles#iam-term-principal) com permissão para chamar [UpdateClusterConfig](https://docs.aws.amazon.com/eks/latest/APIReference/API_UpdateClusterConfig.html) no cluster do Amazon EKS. + Atualize os complementos para as versões que são compatíveis com nós híbridos. Para as versões de complementos que são compatíveis com nós híbridos, consulte [Configuração de complementos para nós híbridos](hybrid-nodes-add-ons.md). + Se você estiver executando complementos que não sejam compatíveis com nós híbridos, certifique-se de que o complemento [DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/) ou [Deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) tenha a regra de afinidade a seguir para evitar a implantação em nós híbridos. Adicione a regra de afinidade a seguir caso não esteja presente. ``` affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: eks.amazonaws.com/compute-type operator: NotIn values: - hybrid ``` ## Considerações O objeto JSON `remoteNetworkConfig` tem o seguinte comportamento durante uma atualização: + Qualquer parte existente da configuração que você não especificar permanecerá inalterada. Se você não especificar nenhuma das `remoteNodeNetworks` ou `remotePodNetworks`, essa parte permanecerá a mesma. + Caso esteja modificando as listas de CIDRs das `remoteNodeNetworks` ou `remotePodNetworks`, você deverá especificar a lista completa de CIDRs que deseja em sua configuração final. Quando você especifica uma alteração na lista de CIDRs nas `remoteNodeNetworks` ou `remotePodNetworks`, o EKS substitui a lista original durante a atualização. + Os blocos CIDR de nós e pods on-premises devem atender aos seguintes requisitos: 1. Estar dentro de um dos intervalos IPv4 RFC-1918: 10.0.0.0/8, 172.16.0.0/12 ou 192.168.0.0/16, ou dentro do intervalo CGNAT definido pela RFC 6598: `100.64.0.0/10` 1. Não se sobrepor entre si, todos os CIDRs da VPC do cluster do Amazon EKS ou com o CIDR de IPv4 do serviço do Kubernetes. ## Habilitar nós híbridos em um cluster existente Você pode habilitar o EKS Hybrid Nodes em um cluster existente usando: + [AWS CloudFormation](#hybrid-nodes-cluster-enable-cfn) + [AWS CLI](#hybrid-nodes-cluster-enable-cli) + [Console de gerenciamento da AWS](#hybrid-nodes-cluster-enable-console) ### Habilitar o EKS Hybrid Nodes em um cluster existente: AWS CloudFormation 1. Para habilitar o EKS Hybrid Nodes em seu cluster, adicione a `RemoteNodeNetwork` e (opcional) a `RemotePodNetwork` ao seu modelo do CloudFormation, e atualize a pilha. Observe que a `RemoteNodeNetwork` é uma lista com no máximo um item `Cidrs`. e o `Cidrs` é uma lista de vários intervalos de CIDRs de IP. ``` RemoteNetworkConfig: RemoteNodeNetworks: - Cidrs: [RemoteNodeCIDR] RemotePodNetworks: - Cidrs: [RemotePodCIDR] ``` 1. Avance para [Preparar o acesso ao cluster para nós híbridos](hybrid-nodes-cluster-prep.md). ### Habilitar o EKS Hybrid Nodes em um cluster existente: AWS CLI 1. Execute o comando a seguir para habilitar a `RemoteNetworkConfig` para o EKS Hybrid Nodes para seu cluster do EKS. Antes de executar o comando, substitua as informações a seguir por suas próprias configurações. Para obter uma lista completa das configurações, consulte [UpdateClusterConfig](https://docs.aws.amazon.com/eks/latest/APIReference/API_UpdateClusterConfig.html) na *Referência de APIs do Amazon EKS*. 1. `CLUSTER_NAME`: nome do cluster do EKS a ser atualizado. 1. `AWS_REGION`: região da AWS em que o cluster do EKS está em execução. 1. `REMOTE_NODE_CIDRS`: o CIDR de nós on-premises para seus nós híbridos. 1. `REMOTE_POD_CIDRS` (opcional): o CIDR de pods on-premises para workloads executadas em nós híbridos. ``` aws eks update-cluster-config \ --name CLUSTER_NAME \ --region AWS_REGION \ --remote-network-config '{"remoteNodeNetworks":[{"cidrs":["REMOTE_NODE_CIDRS"]}],"remotePodNetworks":[{"cidrs":["REMOTE_POD_CIDRS"]}]}' ``` 1. Leva alguns minutos para atualizar o cluster. Você pode consultar o status do cluster com o comando a seguir. Substitua `CLUSTER_NAME` pelo nome do cluster que você está modificando e `AWS_REGION` pela região da AWS em que o cluster está sendo executado. Não prossiga para a próxima etapa até que a saída recebida esteja `ACTIVE`. ``` aws eks describe-cluster \ --name CLUSTER_NAME \ --region AWS_REGION \ --query "cluster.status" ``` 1. Avance para [Preparar o acesso ao cluster para nós híbridos](hybrid-nodes-cluster-prep.md). ### Habilitar o EKS Hybrid Nodes em um cluster existente: Console de gerenciamento da AWS 1. Abra o console do Amazon EKS em [Console do Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters). 1. Selecione o nome do cluster para exibir as informações dele. 1. Escolha a guia **Redes** e depois **Gerenciar**. 1. No menu suspenso, escolha **Redes remotas**. 1. **Escolha Configurar redes remotas para habilitar nós híbridos** e especifique seus CIDRs de nós e pods on-premises para nós híbridos. 1. Escolha **Save changes** (Salvar alterações) para terminar. Aguarde até que o status do cluster retorne para **Active**. 1. Avance para [Preparar o acesso ao cluster para nós híbridos](hybrid-nodes-cluster-prep.md). ## Atualizar a configuração de nós híbridos em um cluster existente É possível modificar `remoteNetworkConfig` em um cluster híbrido existente usando qualquer uma destas opções: + [AWS CloudFormation](#hybrid-nodes-cluster-update-cfn) + [AWS CLI](#hybrid-nodes-cluster-update-cli) + [Console de gerenciamento da AWS](#hybrid-nodes-cluster-update-console) ### Atualizar a configuração híbrida em um cluster existente: AWS CloudFormation 1. Atualize seu modelo do CloudFormation com os novos valores de CIDR da rede. ``` RemoteNetworkConfig: RemoteNodeNetworks: - Cidrs: [NEW_REMOTE_NODE_CIDRS] RemotePodNetworks: - Cidrs: [NEW_REMOTE_POD_CIDRS] ``` **nota** Ao atualizar as listas de CIDRs de `RemoteNodeNetworks` ou `RemotePodNetworks`, inclua todos os CIDRs (novos e existentes). O EKS substitui toda a lista durante as atualizações. A omissão desses campos da solicitação de atualização mantém as configurações existentes. 1. Atualize sua pilha do CloudFormation com o modelo modificado e aguarde a conclusão da atualização da pilha. ### Atualizar a configuração híbrida em um cluster existente: AWS CLI 1. Para modificar os CIDRs da rede remota, execute o comando a seguir. Substitua os valores por suas próprias configurações: ``` aws eks update-cluster-config --name CLUSTER_NAME --region AWS_REGION --remote-network-config '{"remoteNodeNetworks":[{"cidrs":["NEW_REMOTE_NODE_CIDRS"]}],"remotePodNetworks":[{"cidrs":["NEW_REMOTE_POD_CIDRS"]}]}' ``` **nota** Ao atualizar as listas de CIDRs de `remoteNodeNetworks` ou `remotePodNetworks`, inclua todos os CIDRs (novos e existentes). O EKS substitui toda a lista durante as atualizações. A omissão desses campos da solicitação de atualização mantém as configurações existentes. 1. Aguarde até que o status do cluster retorne para ACTIVE antes de continuar. ### Atualizar a configuração híbrida em um cluster existente: Console de gerenciamento da AWS 1. Abra o console do Amazon EKS em [Console do Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters). 1. Selecione o nome do cluster para exibir as informações dele. 1. Escolha a guia **Redes** e depois **Gerenciar**. 1. No menu suspenso, escolha **Redes remotas**. 1. Atualize os CIDRs em `Remote node networks` e `Remote pod networks - Optional`, conforme necessário. 1. Escolha **Salvar alterações** e aguarde até que o status do cluster retorne para **Active**. ## Desabilitar nós híbridos em um cluster existente Você pode desabilitar o EKS Hybrid Nodes em um cluster existente usando: + [AWS CloudFormation](#hybrid-nodes-cluster-disable-cfn) + [AWS CLI](#hybrid-nodes-cluster-disable-cli) + [Console de gerenciamento da AWS](#hybrid-nodes-cluster-disable-console) ### Desabilitar o EKS Hybrid Nodes em um cluster existente: AWS CloudFormation 1. Para desabilitar o EKS Hybrid Nodes em seu cluster, defina `RemoteNodeNetworks` e `RemotePodNetworks` para esvaziar matrizes em seu modelo do CloudFormation e atualize a pilha. ``` RemoteNetworkConfig: RemoteNodeNetworks: [] RemotePodNetworks: [] ``` ### Desabilitar o EKS Hybrid Nodes em um cluster existente: AWS CLI 1. Execute o comando a seguir para remover a `RemoteNetworkConfig` do cluster do EKS. Antes de executar o comando, substitua as informações a seguir por suas próprias configurações. Para obter uma lista completa das configurações, consulte [UpdateClusterConfig](https://docs.aws.amazon.com/eks/latest/APIReference/API_UpdateClusterConfig.html) na *Referência de APIs do Amazon EKS*. 1. `CLUSTER_NAME`: nome do cluster do EKS a ser atualizado. 1. `AWS_REGION`: região da AWS em que o cluster do EKS está em execução. ``` aws eks update-cluster-config \ --name CLUSTER_NAME \ --region AWS_REGION \ --remote-network-config '{"remoteNodeNetworks":[],"remotePodNetworks":[]}' ``` 1. Leva alguns minutos para atualizar o cluster. Você pode consultar o status do cluster com o comando a seguir. Substitua `CLUSTER_NAME` pelo nome do cluster que você está modificando e `AWS_REGION` pela região da AWS em que o cluster está sendo executado. Não prossiga para a próxima etapa até que a saída recebida esteja `ACTIVE`. ``` aws eks describe-cluster \ --name CLUSTER_NAME \ --region AWS_REGION \ --query "cluster.status" ``` ### Desabilitar o EKS Hybrid Nodes em um cluster existente: Console de gerenciamento da AWS 1. Abra o console do Amazon EKS em [Console do Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters). 1. Selecione o nome do cluster para exibir as informações dele. 1. Escolha a guia **Redes** e depois **Gerenciar**. 1. No menu suspenso, escolha **Redes remotas**. 1. Escolha **Configurar redes remotas para habilitar nós híbridos** e remova todos os CIDRs em `Remote node networks` e `Remote pod networks - Optional`. 1. Escolha **Save changes** (Salvar alterações) para terminar. Aguarde até que o status do cluster retorne para **Active**. # Preparar o acesso ao cluster para nós híbridos Preparar acesso ao cluster Antes de conectar nós híbridos ao cluster do Amazon EKS, você deve habilitar o perfil do IAM de nós híbridos com permissões do Kubernetes para ingressar no cluster. Para obter informações sobre como criar um perfil do IAM de nós híbridos, consulte [Preparar as credenciais para nós híbridos](hybrid-nodes-creds.md). O Amazon EKS é compatível com duas maneiras de associar as entidades principais do IAM ao controle de acesso por perfil (RBAC) do Kubernetes, entradas de acesso do Amazon EKS e o ConfigMap `aws-auth`. Para obter mais informações sobre o gerenciamento de acesso do Amazon EKS, consulte [Conceder aos usuários e perfis do IAM acesso às APIs do Kubernetes](grant-k8s-access.md). Use os procedimentos abaixo para associar o perfil do IAM de nós híbridos às permissões do Kubernetes. Para usar as entradas de acesso do Amazon EKS, o cluster deve ter sido criado com os modos de autenticação da `API` ou `API_AND_CONFIG_MAP`. Para usar o ConfigMap `aws-auth`, o cluster deve ter sido criado com o modo de autenticação `API_AND_CONFIG_MAP`. O modo de autenticação somente `CONFIG_MAP` não é compatível com clusters do Amazon EKS habilitados para nós híbridos. ## Usar entradas de acesso do Amazon EKS para o perfil do IAM de nós híbridos Há um tipo de entrada de acesso do Amazon EKS para nós híbridos denominado HYBRID\$1LINUX que pode ser usado com um perfil do IAM. Com esse tipo de entrada de acesso, o nome de usuário é automaticamente definido como system:node:\$1\$1SessionName\$1\$1. Para obter mais informações sobre como criar entradas de acesso, consulte [Criar entradas de acesso](creating-access-entries.md). ### AWS CLI 1. Você deve ter a versão mais recente da AWS CLI instalada e configurada no dispositivo. Para verificar sua versão atual, use `aws --version`. Os gerenciadores de pacotes, como yum, apt-get ou Homebrew para macOS, geralmente estão várias versões atrás da versão mais recente da AWS CLI. Para instalar a versão mais recente, consulte Instalar e Configuração rápida com aws configure no Guia do usuário da AWS Command Line Interface. 1. Crie a entrada de acesso com o comando a seguir. Substitua CLUSTER\$1NAME pelo nome do cluster e HYBRID\$1NODES\$1ROLE\$1ARN pelo ARN do perfil que você criou nas etapas para [Preparar as credenciais para nós híbridos](hybrid-nodes-creds.md). ``` aws eks create-access-entry --cluster-name CLUSTER_NAME \ --principal-arn HYBRID_NODES_ROLE_ARN \ --type HYBRID_LINUX ``` ### Console de gerenciamento da AWS 1. Abra o console do Amazon EKS em [Console do Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters). 1. Escolha o nome do cluster habilitado para nós híbridos. 1. Escolha a guia **Acesso**. 1. Selecione **Criar entrada de acesso**. 1. Em **Entidade principal do IAM**, selecione o perfil do IAM de nós híbridos que você criou nas etapas para [Preparar as credenciais para nós híbridos](hybrid-nodes-creds.md). 1. Para **Tipo**, selecione **Hybrid Linux**. 1. (Opcional) Para **Tags**, atribua rótulos à entrada de acesso. Por exemplo, para facilitar a localização de todos os recursos com a mesma tag. 1. Selecione **Ignorar para analisar e criar**. Você não pode adicionar políticas à entrada de acesso do Hybrid Linux nem alterar o escopo de acesso. 1. Revise a configuração da entrada de acesso. Se algo parecer errado, escolha **Anterior** para voltar às etapas anteriores e corrigir o erro. Se a configuração estiver correta, escolha **Criar**. ## Usar o ConfigMap aws-auth para o perfil do IAM de nós híbridos Nas etapas a seguir, você criará ou atualizará o ConfigMap `aws-auth` com o ARN do perfil do IAM de nós híbridos que você criou nas etapas para [Preparar as credenciais para nós híbridos](hybrid-nodes-creds.md). 1. Verifique se você tem um ConfigMap `aws-auth` existente para o cluster. Observe que, se você estiver usando um arquivo `kubeconfig` específico, use o sinalizador `--kubeconfig`. ``` kubectl describe configmap -n kube-system aws-auth ``` 1. Se você receber um ConfigMap `aws-auth`, atualize-o conforme necessário. 1. Abra o ConfigMap para edição. ``` kubectl edit -n kube-system configmap/aws-auth ``` 1. Adicione uma nova `mapRoles` entrada conforme necessário. Substitua `HYBRID_NODES_ROLE_ARN` pelo ARN do perfil do IAM de nós híbridos. Observe que `{{SessionName}}` é o formato de modelo correto para salvar no ConfigMap. Não o substitua por outros valores. ``` data: mapRoles: | - groups: - system:bootstrappers - system:nodes rolearn: HYBRID_NODES_ROLE_ARN username: system:node:{{SessionName}} ``` 1. Salve o arquivo e saia do seu editor de texto. 1. Se não houver um ConfigMap `aws-auth` existente para o cluster, crie-o com o comando a seguir. Substitua `HYBRID_NODES_ROLE_ARN` pelo ARN do perfil do IAM de nós híbridos. Observe que `{{SessionName}}` é o formato de modelo correto para salvar no ConfigMap. Não o substitua por outros valores. ``` kubectl apply -f=/dev/stdin <<-EOF apiVersion: v1 kind: ConfigMap metadata: name: aws-auth namespace: kube-system data: mapRoles: | - groups: - system:bootstrappers - system:nodes rolearn: HYBRID_NODES_ROLE_ARN username: system:node:{{SessionName}} EOF ``` # Execução de workloads on-premises em nós híbridos Executar nós híbridos Em um cluster do EKS com nós híbridos habilitados, você pode executar aplicações on-premises e de borda em sua própria infraestrutura com os mesmos clusters, recursos e ferramentas do Amazon EKS que você usa na Nuvem AWS. As seções a seguir contêm instruções passo a passo para usar nós híbridos. **Topics** + [Conectar nós híbridos](hybrid-nodes-join.md) + [Conectar nós híbridos com o Bottlerocket](hybrid-nodes-bottlerocket.md) + [Atualizar os nós híbridos](hybrid-nodes-upgrade.md) + [Patches em nós híbridos](hybrid-nodes-security.md) + [Excluir nós híbridos](hybrid-nodes-remove.md) # Conectar nós híbridos Conectar nós híbridos **nota** As etapas a seguir se aplicam aos nós híbridos que executam sistemas operacionais compatíveis, exceto o Bottlerocket. Para obter as etapas para conectar um nó híbrido que executa o Bottlerocket, consulte [Conectar nós híbridos com o Bottlerocket](hybrid-nodes-bottlerocket.md). Este tópico descreve como conectar nós híbridos a um cluster do Amazon EKS. Depois que os nós híbridos se unirem ao cluster, eles aparecerão com o status Não pronto no console do Amazon EKS e em ferramentas compatíveis com o Kubernetes, como o kubectl. Depois de concluir as etapas desta página, prossiga para [Configurar a CNI para nós híbridos](hybrid-nodes-cni.md) para preparar os nós híbridos para executar aplicações. ## Pré-requisitos Antes de conectar nós híbridos ao cluster do Amazon EKS, certifique-se de ter concluído as etapas de pré-requisitos. + Você tem conectividade de rede do ambiente on-premises para a região da AWS que hospeda o cluster do Amazon EKS. Consulte [Preparar a rede para nós híbridos](hybrid-nodes-networking.md) para obter mais informações. + Você tem um sistema operacional compatível para nós híbridos instalado nos hosts on-premises. Consulte [Preparar o sistema operacional para nós híbridos](hybrid-nodes-os.md) para obter mais informações. + Você criou o perfil do IAM de nós híbridos e configurou o provedor de credenciais on-premises (ativações híbridas do AWS Systems Manager ou o AWS IAM Roles Anywhere). Consulte [Preparar as credenciais para nós híbridos](hybrid-nodes-creds.md) para obter mais informações. + Você criou o cluster do Amazon EKS habilitado para nós híbridos. Consulte [Criar um cluster do Amazon EKS com nós híbridos](hybrid-nodes-cluster-create.md) para obter mais informações. + Você associou o perfil do IAM de nós híbridos às permissões de controle de acesso por perfil (RBAC) do Kubernetes. Consulte [Preparar o acesso ao cluster para nós híbridos](hybrid-nodes-cluster-prep.md) para obter mais informações. ## Etapa 1: instalar a CLI de nós híbridos (`nodeadm`) em cada host on-premises Caso esteja incluindo a CLI (`nodeadm`) do Amazon EKS Hybrid Nodes nas imagens pré-criadas do sistema operacional, você pode pular esta etapa. Para obter mais informações sobre a versão de nós híbridos de `nodeadm`, consulte [Referência do `nodeadm` para nós híbridos](hybrid-nodes-nodeadm.md). A versão de nós híbridos do `nodeadm` está hospedada no Amazon S3 com o Amazon CloudFront na frente. Para instalar `nodeadm` em cada host on-premises, você pode executar o comando a seguir nos hosts on-premises. **Para hosts x86\$164:** ``` curl -OL 'https://hybrid-assets.eks.amazonaws.com/releases/latest/bin/linux/amd64/nodeadm' ``` **Para hosts ARM** ``` curl -OL 'https://hybrid-assets.eks.amazonaws.com/releases/latest/bin/linux/arm64/nodeadm' ``` Adicione uma permissão de arquivo executável ao binário baixado em cada host. ``` chmod +x nodeadm ``` ## Etapa 2: instalar as dependências dos nós híbridos com `nodeadm` Caso esteja instalando as dependências de nós híbridos em imagens pré-criadas do sistema operacional, você pode pular esta etapa. O comando `nodeadm install` pode ser usado para instalar todas as dependências necessárias para nós híbridos. As dependências dos nós híbridos incluem containerd, kubelet, kubectl e componentes do AWS SSM ou AWS IAM Roles Anywhere. Consulte [Referência do `nodeadm` para nós híbridos](hybrid-nodes-nodeadm.md) para obter mais informações sobre os componentes e os locais dos arquivos instalados por `nodeadm install`. Consulte [Preparar a rede para nós híbridos](hybrid-nodes-networking.md) para conferir os nós híbridos e obter mais informações sobre os domínios que devem ser permitidos no firewall on-premises para o processo de `nodeadm install`. Execute o comando abaixo para instalar as dependências dos nós híbridos no host on-premises. O comando abaixo deve ser executado com um usuário que tenha acesso sudo/root no host. **Importante** A CLI de nós híbridos (`nodeadm`) deve ser executada com um usuário que tenha acesso sudo/root no host. + Substitua `K8S_VERSION` pela versão secundária do Kubernetes do cluster do Amazon EKS, por exemplo, `1.31`. Consulte as [versões compatíveis com o Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html) para obter uma lista das versões do Kubernetes compatíveis. + Substitua `CREDS_PROVIDER` pelo provedor de credenciais on-premises que você está usando. Os valores válidos são `ssm` para o AWS SSM e `iam-ra` para o AWS IAM Roles Anywhere. ``` nodeadm install K8S_VERSION --credential-provider CREDS_PROVIDER ``` ## Etapa 3: conectar nós híbridos ao cluster Antes de conectar os nós híbridos ao cluster, certifique-se de ter permitido o acesso necessário no firewall on-premises e no grupo de segurança do cluster para a comunicação do ambiente de gerenciamento do Amazon EKS de/para nós híbridos. A maioria dos problemas nesta etapa está relacionada à configuração do firewall, à configuração do grupo de segurança ou à configuração do perfil do IAM de nós híbridos. **Importante** A CLI de nós híbridos (`nodeadm`) deve ser executada com um usuário que tenha acesso sudo/root no host. 1. Crie um arquivo `nodeConfig.yaml` em cada host com os valores da implantação. Para obter uma descrição completa das configurações disponíveis, consulte [Referência do `nodeadm` para nós híbridos](hybrid-nodes-nodeadm.md). Se o perfil do IAM de nós híbridos não tiver permissão para a ação `eks:DescribeCluster`, você deverá passar o endpoint da API Kubernetes, o pacote de CA do cluster e o CIDR IPv4 do serviço do Kubernetes na seção de clusters do `nodeConfig.yaml`. 1. Use o exemplo de `nodeConfig.yaml` abaixo se estiver usando ativações híbridas do AWS SSM para o provedor de credenciais on-premises. 1. Substitua o `CLUSTER_NAME` pelo nome do cluster. 1. Substitua `AWS_REGION` pela região da AWS que está hospedando o cluster. Por exemplo, .`us-west-2` 1. Substitua `ACTIVATION_CODE` pelo código de ativação que você recebeu ao criar a ativação híbrida do AWS SSM. Consulte [Preparar as credenciais para nós híbridos](hybrid-nodes-creds.md) para obter mais informações. 1. Substitua `ACTIVATION_ID` pelo ID de ativação que você recebeu ao criar a ativação híbrida do AWS SSM. Você pode recuperar essas informações no console do AWS Systems Manager ou com o comando `aws ssm describe-activations` da AWS CLI. ``` apiVersion: node.eks.aws/v1alpha1 kind: NodeConfig spec: cluster: name: CLUSTER_NAME region: AWS_REGION hybrid: ssm: activationCode: ACTIVATION_CODE activationId: ACTIVATION_ID ``` 1. Use o exemplo de `nodeConfig.yaml` abaixo se estiver usando o AWS IAM Roles Anywhere para o provedor de credenciais on-premises. 1. Substitua o `CLUSTER_NAME` pelo nome do cluster. 1. Substitua `AWS_REGION` pela região da AWS que está hospedando o cluster. Por exemplo, .`us-west-2` 1. Substitua `NODE_NAME` pelo nome do nó. O nome do nó deve corresponder ao CN do certificado no host caso tenha configurado a política de confiança do perfil do IAM de nós híbridos com a condição de recurso `"sts:RoleSessionName": "${aws:PrincipalTag/x509Subject/CN}"`. O `nodeName` que você usar não deve ter mais de 64 caracteres. 1. Substitua `TRUST_ANCHOR_ARN` pelo ARN da âncora de confiança que você configurou nas etapas de Preparar credenciais para nós híbridos. 1. Substitua `PROFILE_ARN` pelo ARN da âncora de confiança que você configurou nas etapas de [Preparar as credenciais para nós híbridos](hybrid-nodes-creds.md). 1. Substitua `ROLE_ARN` pelo ARN do perfil do IAM de nós híbridos. 1. Substitua `CERTIFICATE_PATH` pelo caminho no disco para o certificado do nó. Caso não seja especificado, o padrão será `/etc/iam/pki/server.pem`. 1. Substitua `KEY_PATH` pelo caminho no disco para a chave privada do certificado. Caso não seja especificado, o padrão será `/etc/iam/pki/server.key`. ``` apiVersion: node.eks.aws/v1alpha1 kind: NodeConfig spec: cluster: name: CLUSTER_NAME region: AWS_REGION hybrid: iamRolesAnywhere: nodeName: NODE_NAME trustAnchorArn: TRUST_ANCHOR_ARN profileArn: PROFILE_ARN roleArn: ROLE_ARN certificatePath: CERTIFICATE_PATH privateKeyPath: KEY_PATH ``` 1. Execute o comando `nodeadm init` com o `nodeConfig.yaml` para conectar os nós híbridos ao cluster do Amazon EKS. ``` nodeadm init -c file://nodeConfig.yaml ``` Se o comando acima for concluído com sucesso, o nó híbrido terá se unido ao cluster do Amazon EKS. Você pode verificar isso no console do Amazon EKS navegando até a guia Computação do cluster ([certifique-se de que a entidade principal do IAM tenha permissões para visualizar](view-kubernetes-resources.md#view-kubernetes-resources-permissions)) ou com `kubectl get nodes`. **Importante** Seus nós terão o status `Not Ready`, o que é esperado e se deve à falta de uma CNI em execução nos nós híbridos. Se os nós não tiverem se unido ao cluster, consulte [Solução de problemas de nós híbridos](hybrid-nodes-troubleshooting.md). ## Etapa 4: configurar uma CNI para nós híbridos Para preparar os nós híbridos para executar aplicações, continue com as etapas em [Configurar a CNI para nós híbridos](hybrid-nodes-cni.md). # Conectar nós híbridos com o Bottlerocket Conectar nós híbridos com o Bottlerocket Este tópico descreve como conectar nós híbridos que executam o Bottlerocket a um cluster do Amazon EKS. O [Bottlerocket](https://aws.amazon.com/bottlerocket/) é uma distribuição de código aberto do Linux patrocinada e apoiada pela AWS. O Bottlerocket foi desenvolvido especificamente para hospedar workloads de contêineres. Com o Bottlerocket, você pode melhorar a disponibilidade de implantações em contêineres e reduzir os custos operacionais automatizando as atualizações em sua infraestrutura de contêineres. O Bottlerocket inclui somente o software essencial para executar contêineres, o que melhora o uso de recursos, reduz as ameaças à segurança e diminui a sobrecarga de gerenciamento. Somente as variantes VMware do Bottlerocket versão v1.37.0 e superior são compatíveis com os nós híbridos do EKS. As variantes de VMware do Bottlerocket estão disponíveis para as versões v1.28 e superiores do Kubernetes. As imagens do sistema operacional para essas variantes incluem o kubelet, containerd, aws-iam-authenticator e outros pré-requisitos de software para nós híbridos do EKS. É possível configurar esses componentes usando um arquivo de [configurações](https://github.com/bottlerocket-os/bottlerocket#settings) do Bottlerocket que inclui dados do usuário codificados em base64 para os contêineres de bootstrap e administração do Bottlerocket. Configurar essas opções permite que o Bottlerocket use seu provedor de credenciais de nós híbridos para autenticar nós híbridos em seu cluster. Depois que os nós híbridos se unirem ao cluster, eles aparecerão com o status `Not Ready` no console do Amazon EKS e em ferramentas compatíveis com o Kubernetes, como o `kubectl`. Depois de concluir as etapas desta página, prossiga para [Configurar a CNI para nós híbridos](hybrid-nodes-cni.md) para preparar os nós híbridos para executar aplicações. ## Pré-requisitos Antes de conectar nós híbridos ao cluster do Amazon EKS, certifique-se de ter concluído as etapas de pré-requisitos. + Você tem conectividade de rede do ambiente on-premises para a região da AWS que hospeda o cluster do Amazon EKS. Consulte [Preparar a rede para nós híbridos](hybrid-nodes-networking.md) para obter mais informações. + Você criou o perfil do IAM de nós híbridos e configurou o provedor de credenciais on-premises (ativações híbridas do AWS Systems Manager ou o AWS IAM Roles Anywhere). Consulte [Preparar as credenciais para nós híbridos](hybrid-nodes-creds.md) para obter mais informações. + Você criou o cluster do Amazon EKS habilitado para nós híbridos. Consulte [Criar um cluster do Amazon EKS com nós híbridos](hybrid-nodes-cluster-create.md) para obter mais informações. + Você associou o perfil do IAM de nós híbridos às permissões de controle de acesso por perfil (RBAC) do Kubernetes. Consulte [Preparar o acesso ao cluster para nós híbridos](hybrid-nodes-cluster-prep.md) para obter mais informações. ## Etapa 1: criar o arquivo TOML de configurações do Bottlerocket Para configurar o Bottlerocket para nós híbridos, você precisa criar um arquivo `settings.toml` com a configuração necessária. O conteúdo do arquivo TOML será diferente com base no provedor de credenciais utilizado (SSM ou IAM Roles Anywhere). Esse arquivo será passado como dados do usuário ao provisionar a instância do Bottlerocket. **nota** Os arquivos no formato TOML fornecidos abaixo representam somente as configurações mínimas necessárias para inicializar uma máquina com sistema operacional Bottlerocket na VMWare como um nó em um cluster do EKS. O Bottlerocket oferece uma ampla variedade de configurações para atender a diversos casos de uso. Portanto, para explorar outras opções de configuração além da inicialização de nós híbridos, consulte a [documentação do Bottlerocket](https://bottlerocket.dev/en). Nessa documentação, você encontrará a lista completa de todas as configurações documentadas da versão do Bottlerocket que você está usando (por exemplo, [estas](https://bottlerocket.dev/en/os/1.51.x/api/settings-index) são as configurações disponíveis para o Bottlerocket 1.51.x). ### SSM Se você estiver usando o AWS Systems Manager como seu provedor de credenciais, crie um arquivo `settings.toml` com o seguinte conteúdo: ``` [settings.kubernetes] cluster-name = "" api-server = "" cluster-certificate = "" hostname-override = "" provider-id = "eks-hybrid://///" authentication-mode = "aws" cloud-provider = "" server-tls-bootstrap = true [settings.network] hostname = "" [settings.aws] region = "" [settings.kubernetes.credential-providers.ecr-credential-provider] enabled = true cache-duration = "12h" image-patterns = [ "*.dkr.ecr.*.amazonaws.com", "*.dkr.ecr.*.amazonaws.com.rproxy.govskope.us.cn", "*.dkr.ecr.*.amazonaws.eu", "*.dkr.ecr-fips.*.amazonaws.com", "*.dkr.ecr-fips.*.amazonaws.eu", "public.ecr.aws" ] [settings.kubernetes.node-labels] "eks.amazonaws.com/compute-type" = "hybrid" "eks.amazonaws.com/hybrid-credential-provider" = "ssm" [settings.host-containers.admin] enabled = true user-data = "" [settings.bootstrap-containers.eks-hybrid-setup] mode = "always" user-data = "" [settings.host-containers.control] enabled = true ``` Substitua os espaços reservados pelos seguintes valores: + ``: o nome do cluster do Amazon EKS. + ``: o endpoint do servidor de API do seu cluster. + ``: o pacote de CA codificado em base64 do seu cluster. + ``: a região da AWS que hospeda seu cluster, por exemplo, "us-east-1". + ``: o nome do host da instância do Bottlerocket que também será configurado como o nome do nó. Esse pode ser qualquer valor exclusivo escolhido por você, mas deve seguir as convenções de nomenclatura de [objetos do Kubernetes.](https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names) Além disso, o nome do host utilizado não pode ter mais de 64 caracteres. OBSERVAÇÃO: quando o provedor SSM for usado, esse nome de host e nome de nó serão substituídos pelo ID da instância gerenciada (por exemplo, ID `mi-*`) depois que a instância for registrada no SSM. + ``: o conteúdo codificado em base64 da configuração do contêiner administrativo do Bottlerocket. A ativação do contêiner administrativo permite que você se conecte à sua instância do Bottlerocket com SSH para exploração e depuração do sistema. Embora essa não seja uma configuração obrigatória, recomendamos ativá-la para facilitar a solução de problemas. Consulte a [documentação do contêiner administrativo do Bottlerocket](https://github.com/bottlerocket-os/bottlerocket-admin-container#authenticating-with-the-admin-container) para obter mais informações sobre a autenticação com o contêiner administrativo. O contêiner administrativo recebe a entrada do usuário e da chave SSH no formato JSON, por exemplo, ``` { "user": "", "ssh": { "authorized-keys": [ "" ] } } ``` + ``: o conteúdo codificado em base64 da configuração do contêiner de bootstrap do Bottlerocket. Consulte a [documentação do contêiner de bootstrap do Bottlerocket](https://github.com/bottlerocket-os/bottlerocket-bootstrap-container) para obter mais informações sobre sua configuração. O contêiner de bootstrap é responsável por registrar a instância como uma instância gerenciada do AWS SSM e adicioná-la como um nó Kubernetes em seu cluster do Amazon EKS. Os dados do usuário passados para o contêiner de bootstrap assumem a forma de uma invocação de comando que aceita como entrada o código de ativação híbrida do SSM e o ID que você criou anteriormente: ``` eks-hybrid-ssm-setup --activation-id= --activation-code= --region= ``` ### IAM Roles Anywhere Se você estiver usando o AWS IAM Roles Anywhere como seu provedor de credenciais, crie um arquivo `settings.toml` com o seguinte conteúdo: ``` [settings.kubernetes] cluster-name = "" api-server = "" cluster-certificate = "" hostname-override = "" provider-id = "eks-hybrid://///" authentication-mode = "aws" cloud-provider = "" server-tls-bootstrap = true [settings.network] hostname = "" [settings.aws] region = "" config = "" [settings.kubernetes.credential-providers.ecr-credential-provider] enabled = true cache-duration = "12h" image-patterns = [ "*.dkr.ecr.*.amazonaws.com", "*.dkr.ecr.*.amazonaws.com.rproxy.govskope.us.cn", "*.dkr.ecr.*.amazonaws.eu", "*.dkr.ecr-fips.*.amazonaws.com", "*.dkr.ecr-fips.*.amazonaws.eu", "public.ecr.aws" ] [settings.kubernetes.node-labels] "eks.amazonaws.com/compute-type" = "hybrid" "eks.amazonaws.com/hybrid-credential-provider" = "iam-ra" [settings.host-containers.admin] enabled = true user-data = "" [settings.bootstrap-containers.eks-hybrid-setup] mode = "always" user-data = "" ``` Substitua os espaços reservados pelos seguintes valores: + ``: o nome do cluster do Amazon EKS. + ``: o endpoint do servidor de API do seu cluster. + ``: o pacote de CA codificado em base64 do seu cluster. + ``: a região da AWS que hospeda seu cluster, por exemplo, "us-east-1" + ``: o nome do host da instância do Bottlerocket que também será configurado como o nome do nó. Esse pode ser qualquer valor exclusivo escolhido por você, mas deve seguir as convenções de nomenclatura de [objetos do Kubernetes.](https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names) Além disso, o nome do host utilizado não pode ter mais de 64 caracteres. OBSERVAÇÃO: quando um provedor IAM-RA é usado, o nome do nó deve corresponder ao CN do certificado no host caso tenha configurado a política de confiança do perfil do IAM do Hybrid Nodes com a condição de recurso `"sts:RoleSessionName": "${aws:PrincipalTag/x509Subject/CN}"`. + ``: o conteúdo codificado em base64 do seu arquivo de configuração da AWS. O conteúdo do arquivo deve ser o seguinte: ``` [default] credential_process = aws_signing_helper credential-process --certificate /root/.aws/node.crt --private-key /root/.aws/node.key --profile-arn --role-arn --trust-anchor-arn --role-session-name ``` + ``: o conteúdo codificado em base64 da configuração do contêiner administrativo do Bottlerocket. A ativação do contêiner administrativo permite que você se conecte à sua instância do Bottlerocket com SSH para exploração e depuração do sistema. Embora essa não seja uma configuração obrigatória, recomendamos ativá-la para facilitar a solução de problemas. Consulte a [documentação do contêiner administrativo do Bottlerocket](https://github.com/bottlerocket-os/bottlerocket-admin-container#authenticating-with-the-admin-container) para obter mais informações sobre a autenticação com o contêiner administrativo. O contêiner administrativo recebe a entrada do usuário e da chave SSH no formato JSON, por exemplo, ``` { "user": "", "ssh": { "authorized-keys": [ "" ] } } ``` + ``: o conteúdo codificado em base64 da configuração do contêiner de bootstrap do Bottlerocket. Consulte a [documentação do contêiner de bootstrap do Bottlerocket](https://github.com/bottlerocket-os/bottlerocket-bootstrap-container) para obter mais informações sobre sua configuração. O contêiner de bootstrap é responsável por criar os arquivos de certificado de host e chave privada do certificado do IAM Roles Anywhere na instância. Eles serão consumidos pelo `aws_signing_helper` para obter as credenciais temporárias necessárias para autenticação com seu cluster do Amazon EKS. Os dados do usuário passados para o contêiner de bootstrap assumem a forma de uma invocação de comando que aceita como entrada o conteúdo do arquivo de certificado e chave privada que você criou anteriormente: ``` eks-hybrid-iam-ra-setup --certificate= --key= ``` ## Etapa 2: provisionar a VM vSphere do Bottlerocket com dados do usuário Depois de construir o arquivo TOML, passe-o como dados do usuário durante a criação da VM vSphere. Lembre-se de que os dados do usuário devem ser configurados antes que a VM seja ligada pela primeira vez. Dessa forma, você precisará fornecê-los ao criar a instância ou, se desejar criar a VM com antecedência, a VM deverá estar no estado poweredOff até que você configure os dados do usuário para ela. Por exemplo, se estiver usando a CLI do `govc`: ### Criar uma VM pela primeira vez ``` govc vm.create \ -on=true \ -c=2 \ -m=4096 \ -net.adapter= \ -net= \ -e guestinfo.userdata.encoding="base64" \ -e guestinfo.userdata="$(base64 -w0 settings.toml)" \ -template= \ ``` ### Atualizar dados do usuário para uma VM existente ``` govc vm.create \ -on=false \ -c=2 \ -m=4096 \ -net.adapter= \ -net= \ -template= \ govc vm.change -vm \ -e guestinfo.userdata="$(base64 -w0 settings.toml)" \ -e guestinfo.userdata.encoding="base64" govc vm.power -on ``` Nas seções acima, a opção `-e guestinfo.userdata.encoding="base64"` especifica que os dados do usuário são codificados em base64. A opção `-e guestinfo.userdata` passa o conteúdo codificado em base64 do arquivo `settings.toml` como dados do usuário para a instância do Bottlerocket. Substitua os espaços reservados por seus valores específicos, como o modelo OVA do Bottlerocket e detalhes da rede. ## Etapa 3: verificar a conexão do nó híbrido Depois que a instância do Bottlerocket for iniciada, ela tentará se juntar ao seu cluster do Amazon EKS. Você pode verificar a conexão no console do Amazon EKS navegando até a guia Computação do seu cluster ou executando o seguinte comando: ``` kubectl get nodes ``` **Importante** Seus nós terão o status `Not Ready`, o que é esperado e se deve à falta de uma CNI em execução nos nós híbridos. Se os nós não tiverem se unido ao cluster, consulte [Solução de problemas de nós híbridos](hybrid-nodes-troubleshooting.md). ## Etapa 4: configurar uma CNI para nós híbridos Para preparar os nós híbridos para executar aplicações, continue com as etapas em [Configurar a CNI para nós híbridos](hybrid-nodes-cni.md). # Atualizar os nós híbridos do cluster Atualizar os nós híbridos A orientação para atualizar nós híbridos é semelhante aos nós autogerenciados do Amazon EKS que são executados no Amazon EC2. Recomendamos que você crie nós híbridos na versão de destino do Kubernetes, migre gradualmente as aplicações existentes para os nós híbridos na nova versão do Kubernetes e remova os nós híbridos na versão antiga do Kubernetes do cluster. Certifique-se de revisar as [Práticas recomendadas do Amazon EKS](https://docs.aws.amazon.com/eks/latest/best-practices/cluster-upgrades.html) para obter atualizações antes de iniciar uma atualização. O Amazon EKS Hybrid Nodes tem o mesmo [suporte de versão do Kubernetes](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html) para clusters do Amazon EKS com nós na nuvem, incluindo suporte padrão e estendido. O Amazon EKS Hybrid Nodes segue a mesma [política de diferença de versão](https://kubernetes.io/releases/version-skew-policy/#supported-version-skew) para nós que o Kubernetes upstream. O Amazon EKS Hybrid Nodes não pode estar em uma versão mais recente do que o ambiente de gerenciamento do Amazon EKS, e os nós híbridos podem estar até três versões secundárias do Kubernetes mais antigas do que a versão secundária do ambiente de gerenciamento do Amazon EKS. Se você não tiver capacidade disponível para criar nós híbridos na versão de destino do Kubernetes para uma estratégia de atualização de migração por substituição, você também poderá usar a CLI (`nodeadm`) do Amazon EKS Hybrid Nodes para atualizar a versão do Kubernetes dos nós híbridos no local. **Importante** Se você estiver atualizando os nós híbridos localmente com `nodeadm`, haverá um tempo de inatividade do nó durante o processo em que a versão mais antiga dos componentes do Kubernetes é desligada e os novos componentes da versão do Kubernetes são instalados e iniciados. ## Pré-requisitos Antes de atualizar, certifique-se de ter atendido aos pré-requisitos a seguir. + A versão de destino do Kubernetes para a atualização dos nós híbridos deve ser igual ou inferior à versão do ambiente de gerenciamento do Amazon EKS. + Se você estiver seguindo uma estratégia de atualização de migração por substituição, os novos nós híbridos que você está instalando na versão de destino do Kubernetes deverão atender aos requisitos de [Configuração de pré-requisitos para nós híbridos](hybrid-nodes-prereqs.md). Isso inclui ter endereços IP no CIDR da rede remota de nós que você passou durante a criação do cluster do Amazon EKS. + Tanto para a migração por substituição quanto para as atualizações locais, os nós híbridos devem ter acesso aos [domínios necessários](hybrid-nodes-networking.md#hybrid-nodes-networking-on-prem) para extrair as novas versões das dependências dos nós híbridos. + Você deve ter o kubectl instalado na instância ou máquina local que você está usando para interagir com o endpoint da API do Kubernetes do Amazon EKS. + A versão da CNI deve ser compatível com a versão do Kubernetes para a qual você está atualizando. Caso contrário, atualize a versão da CNI antes de atualizar os nós híbridos. Consulte [Configurar a CNI para nós híbridos](hybrid-nodes-cni.md) para obter mais informações. ## Atualizações de migração por substituição (azul-verde) As *atualizações de migração por substituição* referem-se ao processo de criar nós híbridos em novos hosts com a versão de destino do Kubernetes, migrar tranquilamente as aplicações existentes para os novos nós híbridos na versão de destino do Kubernetes e remover os nós híbridos da versão antiga do Kubernetes do cluster. Essa estratégia também é chamada de migração azul-verde. 1. Conecte os novos hosts como nós híbridos seguindo as etapas de [Conectar nós híbridos](hybrid-nodes-join.md). Ao executar o comando `nodeadm install`, use a versão de destino do Kubernetes. 1. Habilite a comunicação entre os novos nós híbridos na versão de destino do Kubernetes e os nós híbridos na versão antiga do Kubernetes. Essa configuração permite que os pods se comuniquem entre si enquanto você está migrando a workload para os nós híbridos na versão de destino do Kubernetes. 1. Confirme se os nós híbridos na versão de destino do Kubernetes se uniram com êxito ao cluster e se têm o status Pronto. 1. Use o comando a seguir para marcar cada um dos nós que deseja remover como não programável. Isso serve para que novos pods não sejam programados ou reprogramados nos nós que você está substituindo. Para obter mais informações, consulte [isolar kubectl](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_cordon/) na documentação do Kubernetes. Substitua `NODE_NAME` pelo nome dos nós híbridos na versão antiga do Kubernetes. ``` kubectl cordon NODE_NAME ``` Você pode identificar e isolar todos os nós de uma determinada versão do Kubernetes (neste caso, `1.28`) com o trecho de código a seguir. ``` K8S_VERSION=1.28 for node in $(kubectl get nodes -o json | jq --arg K8S_VERSION "$K8S_VERSION" -r '.items[] | select(.status.nodeInfo.kubeletVersion | match("\($K8S_VERSION)")).metadata.name') do echo "Cordoning $node" kubectl cordon $node done ``` 1. Se a implantação atual estiver executando menos de duas réplicas de CoreDNS nos nós híbridos, aumente a escala horizontalmente da implantação para pelo menos duas réplicas. Recomendamos executar pelo menos duas réplicas do CoreDNS em nós híbridos para resiliência durante as operações normais. ``` kubectl scale deployments/coredns --replicas=2 -n kube-system ``` 1. Drene cada um dos nós híbridos na versão antiga do Kubernetes que você deseja remover do cluster com o comando a seguir. Para obter mais informações sobre como drenar nós, consulte [Safely Drain a Node](https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/) na documentação do Kubernetes. Substitua `NODE_NAME` pelo nome dos nós híbridos na versão antiga do Kubernetes. ``` kubectl drain NODE_NAME --ignore-daemonsets --delete-emptydir-data ``` Você pode identificar e drenar todos os nós de determinada versão do Kubernetes (neste caso, `1.28`) com o trecho de código a seguir. ``` K8S_VERSION=1.28 for node in $(kubectl get nodes -o json | jq --arg K8S_VERSION "$K8S_VERSION" -r '.items[] | select(.status.nodeInfo.kubeletVersion | match("\($K8S_VERSION)")).metadata.name') do echo "Draining $node" kubectl drain $node --ignore-daemonsets --delete-emptydir-data done ``` 1. Você pode usar `nodeadm` para interromper e remover os artefatos dos nós híbridos do host. Você deve executar `nodeadm` com um usuário que tenha privilégios root/sudo. Por padrão, `nodeadm uninstall` não prosseguirá se houver pods restantes no nó. Para obter mais informações, consulte [Referência do `nodeadm` para nós híbridos](hybrid-nodes-nodeadm.md). ``` nodeadm uninstall ``` 1. Com os artefatos dos nós híbridos interrompidos e desinstalados, remova o recurso do nó do cluster. ``` kubectl delete node node-name ``` Você pode identificar e excluir todos os nós de uma determinada versão do Kubernetes (neste caso, `1.28`) com o trecho de código a seguir. ``` K8S_VERSION=1.28 for node in $(kubectl get nodes -o json | jq --arg K8S_VERSION "$K8S_VERSION" -r '.items[] | select(.status.nodeInfo.kubeletVersion | match("\($K8S_VERSION)")).metadata.name') do echo "Deleting $node" kubectl delete node $node done ``` 1. Dependendo da sua escolha de CNI, poderá haver artefatos restantes nos nós híbridos após a execução das etapas acima. Consulte [Configurar a CNI para nós híbridos](hybrid-nodes-cni.md) para obter mais informações. ## Atualizações no local O processo de atualização no local refere-se ao uso de `nodeadm upgrade` para atualizar a versão do Kubernetes para nós híbridos sem usar novos hosts físicos ou virtuais e uma estratégia de migração por substituição. O processo de `nodeadm upgrade` desliga os componentes antigos existentes do Kubernetes em execução no nó híbrido, desinstala os componentes antigos do Kubernetes existentes, instala os novos componentes do Kubernetes de destino e inicia os novos componentes do Kubernetes de destino. É altamente recomendável atualizar um nó por vez para minimizar o impacto nas aplicações em execução nos nós híbridos. A duração desse processo depende da largura de banda e da latência da rede. 1. Use o comando a seguir para marcar o nó que você está atualizando como não programável. Isso serve para que novos pods não sejam programados ou reprogramados nos nós que você está atualizando. Para obter mais informações, consulte [isolar kubectl](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_cordon/) na documentação do Kubernetes. Substitua `NODE_NAME` pelo nome do nó híbrido que você está atualizando ``` kubectl cordon NODE_NAME ``` 1. Drene o nó que você está atualizando com o comando a seguir. Para obter mais informações sobre como drenar nós, consulte [Safely Drain a Node](https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/) na documentação do Kubernetes. Substitua `NODE_NAME` pelo nome do nó híbrido que você está atualizando. ``` kubectl drain NODE_NAME --ignore-daemonsets --delete-emptydir-data ``` 1. Execute `nodeadm upgrade` no nó híbrido que você está atualizando. Você deve executar `nodeadm` com um usuário que tenha privilégios root/sudo. O nome do nó é preservado durante a atualização para os provedores de credenciais do AWS SSM e AWS IAM Roles Anywhere. Você não pode alterar os provedores de credenciais durante o processo de atualização. Consulte [Referência do `nodeadm` para nós híbridos](hybrid-nodes-nodeadm.md) para obter os valores de configuração de `nodeConfig.yaml`. Substitua `K8S_VERSION` pela versão do Kubernetes de destino para a qual você está atualizando. ``` nodeadm upgrade K8S_VERSION -c file://nodeConfig.yaml ``` 1. Para permitir que os pods sejam agendados no nó após a atualização, digite o seguinte. Substitua `NODE_NAME` pelo nome do nó. ``` kubectl uncordon NODE_NAME ``` 1. Observe o status dos nós híbridos e aguarde até que os nós sejam desligados e reiniciados na nova versão do Kubernetes com o status Pronto. ``` kubectl get nodes -o wide -w ``` # Atualizações de segurança de patches para nós híbridos Patches em nós híbridos Este tópico descreve o procedimento para executar patches in-loco de atualizações de segurança para pacotes e dependências específicos em execução nos nós híbridos. Como prática recomendada, sugerimos que você atualize regularmente seus nós híbridos para receber CVEs e patches de segurança. Para ver as etapas de atualização da versão do Kubernetes, consulte [Atualizar os nós híbridos do cluster](hybrid-nodes-upgrade.md). Um exemplo de software que pode precisar de patches de segurança é `containerd`. ## `Containerd` `containerd` é o runtime padrão do contêiner Kubernetes e a dependência principal dos EKS Hybrid Nodes, usado para gerenciar o ciclo de vida do contêiner, incluindo a extração de imagens e o gerenciamento da execução do contêiner. Em um nó híbrido, você pode instalar o `containerd` por meio da [CLI do nodeadm](https://docs.aws.amazon.com/eks/latest/userguide/hybrid-nodes-nodeadm.html) ou manualmente. Dependendo do sistema operacional do seu nó, o `nodeadm` instalará o `containerd` por meio do pacote distribuído pelo sistema operacional ou do pacote Docker. Quando um CVE em `containerd` é publicado, você tem as opções a seguir de atualização para a versão corrigida do `containerd` em seus nós híbridos. ## Etapa 1: verificar se o patch foi publicado nos gerenciadores de pacotes Você pode verificar se o patch `containerd` CVE foi publicado em cada gerenciador de pacotes do sistema operacional respectivo consultando os boletins de segurança correspondentes: + [Amazon Linux 2023](https://alas.aws.amazon.com/alas2023.html) + [RHEL](https://access.redhat.com/security/security-updates/security-advisories) + [Ubuntu 20.04](https://ubuntu.com/security/notices?order=newest&release=focal) + [Ubuntu 22.04](https://ubuntu.com/security/notices?order=newest&release=jammy) + [Ubuntu 24.04](https://ubuntu.com/security/notices?order=newest&release=noble) Se você usa o repositório Docker como fonte do `containerd`, pode verificar os [anúncios de segurança do Docker](https://docs.docker.com/security/security-announcements/) para identificar a disponibilidade da versão corrigida no repositório Docker. ## Etapa 2: escolher o método para instalar o patch Existem três métodos para corrigir e instalar atualizações de segurança in-loco nos nós. O método que você pode usar depende de se o patch está ou não disponível no sistema operacional do gerenciador de pacotes: 1. Instale os patches com `nodeadm upgrade` que estão publicados nos gerenciadores de pacotes. Consulte a [Etapa 2 a](#hybrid-nodes-security-nodeadm). 1. Instale os patches diretamente com os gerenciadores de pacotes. Consulte a [Etapa 2 b](#hybrid-nodes-security-package). 1. Instale patches personalizados que não estão publicados nos gerenciadores de pacotes. Observe que há considerações especiais sobre patches personalizados para `containerd`, [Etapa 2 c](#hybrid-nodes-security-manual). ## Etapa 2 a: aplicar patches com `nodeadm upgrade` Depois de confirmar que o patch `containerd` da CVE foi publicado nos repositórios do sistema operacional ou do Docker (Apt ou RPM), você pode usar o comando `nodeadm upgrade` a fim de atualizar para a versão mais recente do `containerd`. Como não se trata de uma atualização da versão do Kubernetes, você deve passar sua versão atual do Kubernetes para o comando de upgrade do `nodeadm`. ``` nodeadm upgrade K8S_VERSION --config-source file:///root/nodeConfig.yaml ``` ## Etapa 2 b: aplicar patches com gerenciadores de pacotes do sistema operacional Alternativamente, você também pode atualizar por meio do respectivo gerenciador de pacotes e usá-lo para atualizar o pacote `containerd` como se segue. **Amazon Linux 2023** ``` sudo yum update -y sudo yum install -y containerd ``` **RHEL** ``` sudo yum install -y yum-utils sudo yum-config-manager --add-repo https://download.docker.com/linux/rhel/docker-ce.repo sudo yum update -y sudo yum install -y containerd ``` **Ubuntu** ``` sudo mkdir -p /etc/apt/keyrings sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc echo \ "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \ $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}") stable" | \ sudo tee /etc/apt/sources.list.d/docker.list > /dev/null sudo apt update -y sudo apt install -y --only-upgrade containerd.io ``` ## Etapa 2 c: patch `Containerd` da CVE não publicado nos gerenciadores de pacotes Se a versão corrigida de `containerd` estiver disponível apenas por outros meios e não no gerenciador de pacotes, por exemplo, nas versões do GitHub, você poderá instalar o `containerd` pelo site oficial do GitHub. 1. Se a máquina já fizer parte do cluster como um nó híbrido, será necessário executar o comando `nodeadm uninstall`. 1. Instale os arquivos binários oficiais do `containerd` . Você pode usar as [etapas oficiais de instalação](https://github.com/containerd/containerd/blob/main/docs/getting-started.md#option-1-from-the-official-binaries) no GitHub. 1. Execute o comando `nodeadm install` com o argumento `--containerd-source` definido como `none`, o que ignorará a instalação do `containerd` por meio do `nodeadm`. Você pode usar o valor de `none` na origem do `containerd` para qualquer sistema operacional que o nó estiver executando. ``` nodeadm install K8S_VERSION --credential-provider CREDS_PROVIDER --containerd-source none ``` # Remoção de nós híbridos Excluir nós híbridos Este tópico descreve como excluir nós híbridos do cluster do Amazon EKS. Você deve excluir os nós híbridos com as ferramentas de sua escolha compatíveis com o Kubernetes, como o [kubectl](https://kubernetes.io/docs/reference/kubectl/). As cobranças por nós híbridos param quando o objeto do nó é removido do cluster do Amazon EKS. Para obter mais informações sobre preços de nós híbridos, consulte [Preços do Amazon EKS](https://aws.amazon.com/eks/pricing/). **Importante** Remover os nós interrompe as workloads em execução no nó. Antes de excluir os nós híbridos, recomendamos primeiro drenar o nó para mover os pods para outro nó ativo. Para obter mais informações sobre como drenar nós, consulte [Safely Drain a Node](https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/) na documentação do Kubernetes. Execute as etapas do kubectl abaixo na instância ou máquina local que você usa para interagir com o endpoint da API do Kubernetes do cluster do Amazon EKS. Se você estiver usando um arquivo `kubeconfig` específico, use o sinalizador `--kubeconfig`. ## Etapa 1: listar os nós ``` kubectl get nodes ``` ## Etapa 2: drenar o nó Consulte [kubectl drain](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_drain/) na documentação do Kubernetes para obter mais informações sobre o comando `kubectl drain`. ``` kubectl drain --ignore-daemonsets ``` ## Etapa 3: interromper e desinstalar os artefatos dos nós híbridos Você pode usar a CLI (`nodeadm`) do Amazon EKS Hybrid Nodes para interromper e remover os artefatos dos nós híbridos do host. Você deve executar `nodeadm` com um usuário que tenha privilégios root/sudo. Por padrão, `nodeadm uninstall` não prosseguirá se houver pods restantes no nó. Se você estiver usando o AWS Systems Manager (SSM) como o provedor de credenciais, o comando `nodeadm uninstall` cancelará o registro do host como uma instância gerenciada do AWS SSM. Para obter mais informações, consulte [Referência do `nodeadm` para nós híbridos](hybrid-nodes-nodeadm.md). ``` nodeadm uninstall ``` ## Etapa 4: excluir o nó do cluster Com os artefatos dos nós híbridos interrompidos e desinstalados, remova o recurso do nó do cluster. ``` kubectl delete node ``` ## Etapa 5: verificar se há artefatos restantes Dependendo da sua escolha de CNI, poderá haver artefatos restantes nos nós híbridos após a execução das etapas acima. Consulte [Configurar a CNI para nós híbridos](hybrid-nodes-cni.md) para obter mais informações. # Configurar redes de aplicações, complementos e webhooks para nós híbridos Configurar Depois de criar um cluster EKS para nós híbridos, configure recursos adicionais para redes de aplicações (CNI, BGP, Ingress, balanceamento de carga, políticas de rede), complementos, webhooks e configurações de proxy. Para obter a lista completa dos complementos do EKS e da comunidade que são compatíveis com nós híbridos, consulte [Configuração de complementos para nós híbridos](hybrid-nodes-add-ons.md). **Insights de clusters do EKS** O EKS inclui verificações de insights para configurações incorretas na configuração dos seus nós híbridos que podem prejudicar a funcionalidade do cluster ou das workloads. Para obter mais informações sobre insights de clusters, consulte [Prepare-se para as atualizações da versão e a solução de problemas de configurações incorretas do Kubernetes com insights do cluster](cluster-insights.md). A seguir, são listados os recursos e complementos comuns que você pode usar com nós híbridos: + **Interface de rede de contêineres (CNI)**: a AWS oferece suporte para o [Cilium](https://docs.cilium.io/en/stable/index.html) como a CNI para nós híbridos. Para obter mais informações, consulte [Configurar a CNI para nós híbridos](hybrid-nodes-cni.md). Observe que a CNI da AWS VPC não pode ser usada com nós híbridos. + **CoreDNS e `kube-proxy`**: o CoreDNS e o `kube-proxy` são instalados automaticamente quando nós híbridos se unem ao cluster do Amazon EKS. Esses complementos podem ser gerenciados como complementos do EKS após a criação do cluster. + **Ingress e balanceamento de carga**: você pode usar o AWS Load Balancer Controller e o Application Load Balancer (ALB) ou Network Load Balancer (NLB) com o tipo de destino `ip` para workloads em execução em nós híbridos. A AWS oferece suporte para os atributos integrados de balanceamento de carga do Ingress, Gateway e Kubernetes Service do Cilium para workloads executadas em nós híbridos. Para obter mais informações, consulte [Configurar o Ingress do Kubernetes para nós híbridos](hybrid-nodes-ingress.md) e [Configurar serviços do tipo LoadBalancer para nós híbridos](hybrid-nodes-load-balancing.md). + **Métricas**: você pode usar os extratores sem atendente do Amazon Managed Service for Prometheus (AMP), o AWS Distro for Open Telemetry (ADOT) e o atendente de observabilidade do Amazon CloudWatch com nós híbridos. Para usar extratores sem atendente do AMP para métricas de pods em nós híbridos, os pods devem estar acessíveis na VPC que você usa para o cluster do EKS. + **Logs**: é possível habilitar o log do ambiente de gerenciamento do EKS para clusters habilitados para nós híbridos. Você pode usar o complemento do EKS para ADOT e o complemento do EKS do atendente de observabilidade do Amazon CloudWatch para o log de nós híbridos e pods. + **Identidades do pod e IRSA**: você pode usar Identidades de Pods do EKS e perfis do IAM para contas de serviço (IRSA) com aplicações executadas em nós híbridos para permitir acesso granular aos pods executados em nós híbridos com outros serviços da AWS. + **Webhooks**: se estiver executando webhooks, consulte [Configurar webhooks para nós híbridos](hybrid-nodes-webhooks.md) para considerações e etapas para, opcionalmente, executar webhooks em nós de nuvem, caso não consiga tornar suas redes de pod on-premises roteáveis. + **Proxy**: caso esteja usando um servidor proxy no ambiente on-premises para tráfego que sai do data center ou do ambiente de borda, é possível configurar os nós e o cluster para usar o servidor proxy. Para obter mais informações, consulte [Configurar proxy para nós híbridos](hybrid-nodes-proxy.md). **Topics** + [ # Configurar a CNI para nós híbridos ](hybrid-nodes-cni.md) + [ # Configuração de complementos para nós híbridos ](hybrid-nodes-add-ons.md) + [ # Configurar webhooks para nós híbridos ](hybrid-nodes-webhooks.md) + [ # Configurar proxy para nós híbridos ](hybrid-nodes-proxy.md) + [ # Configurar o BGP do Cilium para nós híbridos ](hybrid-nodes-cilium-bgp.md) + [ # Configurar o Ingress do Kubernetes para nós híbridos ](hybrid-nodes-ingress.md) + [ # Configurar serviços do tipo LoadBalancer para nós híbridos ](hybrid-nodes-load-balancing.md) + [ # Configurar políticas de rede do Kubernetes para nós híbridos ](hybrid-nodes-network-policies.md) # Configurar a CNI para nós híbridos Configurar CNI O Cilium é interface de rede de contêineres (CNI) compatível com a AWS para o Amazon EKS Hybrid Nodes. Você deve instalar uma CNI para que os nós híbridos fiquem prontos para atender às workloads. Os nós híbridos aparecem com o status `Not Ready` até que uma CNI esteja em execução. Você pode gerenciar essa CNI com ferramentas de sua escolha, como o Helm. As instruções nesta página abrangem o gerenciamento do ciclo de vida do Cilium (instalação, atualização, exclusão). Consulte [Visão geral do Ingress do Cilium e do Gateway do Cilium](hybrid-nodes-ingress.md#hybrid-nodes-ingress-cilium), [Tipo de serviço LoadBalancer](hybrid-nodes-ingress.md#hybrid-nodes-ingress-cilium-loadbalancer), e [Configurar políticas de rede do Kubernetes para nós híbridos](hybrid-nodes-network-policies.md) para saber como configurar o Cilium para Ingress, balanceamento de carga e políticas de rede. O Cilium não é compatível com a AWS quando executados em nós na Nuvem AWS. A CNI da Amazon VPC não é compatível com nós híbridos e está configurada com antiafinidade para o rótulo `eks.amazonaws.com/compute-type: hybrid`. A documentação anterior do Calico nesta página foi movida para o [Repositório de exemplos híbridos do EKS](https://github.com/aws-samples/eks-hybrid-examples). ## Compatibilidade da versão As versões `v1.17.x` e `v1.18.x` do Cilium são compatíveis com o EKS Hybrid Nodes para todas as versões do Kubernetes com suporte por parte do Amazon EKS. **nota** **Requisito de kernel do Cilium v1.18.3**: devido ao requisito de kernel (kernel do Linux igual ou superior à versão 5.10), o Cilium v1.18.3 não é compatível com: + Ubuntu 20.04 + Red Hat Enterprise Linux (RHEL) 8 Para obter os requisitos do sistema, consulte [Requisitos do sistema Cilium](https://docs.cilium.io/en/stable/operations/system_requirements/). Consulte o [suporte a versões do Kubernetes](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html) para obter uma lista das versões do Kubernetes compatíveis com o Amazon EKS. O EKS Hybrid Nodes tem o mesmo suporte a versão do Kubernetes que os clusters do Amazon EKS com nós na nuvem. ## Recursos com suporte A AWS mantém compilações do Cilium para o EKS Hybrid Nodes baseadas no [projeto Cilium](https://github.com/cilium/cilium) de código aberto. Para receber suporte da AWS para o Cilium, você deve usar as compilações do Cilium fornecidas pela AWS e as versões compatíveis com o Cilium. A AWS oferece suporte técnico para a configuração padrão dos recursos do Cilium para uso com o EKS Hybrid Nodes. Se você planeja usar o recurso fora do escopo do suporte da AWS, recomendamos que obtenha suporte comercial para o Cilium ou tenha a experiência interna para solucionar problemas e contribuir com correções para o projeto do Cilium. | Atributo do Cilium | Com suporte da AWS | | --- | --- | | Conformidade da rede do Kubernetes | Sim | | Conectividade do cluster principal | Sim | | Família IP | IPv4 | | Gerenciamento de ciclo de vida | Helm | | Modo de rede | Encapsulamento VXLAN | | Gerenciamento de endereços IP (IPAM) | Escopo do cluster de IPAM do Cilium | | Política de rede | Política de rede do Kubernetes | | Protocolo de Gateway da Borda (BGP) | Ambiente de gerenciamento BGP do Cilium | | Ingress do Kubernetes | Ingress do Cilium, Gateway do Cilium | | Alocação de IP do Service LoadBalancer | Balanceador de Carga de IPAM do Cilium | | Anúncio de Endereço IP do Service LoadBalancer | Ambiente de gerenciamento BGP do Cilium | | substituição do kube-proxy | Sim | ## Considerações sobre o Cilium + **Repositório Helm**: a AWS hospeda o chart do Helm do Cilium no Amazon Elastic Container Registry Public (Amazon ECR Public) no [Amazon EKS Cilium/Cilium](https://gallery.ecr.aws/eks/cilium/cilium). As versões disponíveis são: + Cilium v1.17.9: `oci://public.ecr.aws/eks/cilium/cilium:1.17.9-0` + Cilium v1.18.3: `oci://public.ecr.aws/eks/cilium/cilium:1.18.3-0` Os comandos neste tópico usam esse repositório. Observe que certos comandos `helm repo` não são válidos para repositórios do Helm no Amazon ECR Public, então você não pode se referir a esse repositório a partir de um nome de repositório local do Helm. Em vez disso, use o URI completo na maioria dos comandos. + Por padrão, o Cilium é configurado para ser executado no modo sobreposto e túnel com VXLAN como [método de encapsulamento](https://docs.cilium.io/en/stable/network/concepts/routing/#encapsulation). Esse modo tem o menor número de requisitos para a rede física subjacente. + Por padrão, o Cilium [mascara](https://docs.cilium.io/en/stable/network/concepts/masquerading/) o endereço IP de origem de todo o tráfego de pods que sai do cluster para o endereço IP do nó. Se você desabilitar o mascaramento, os CIDRs do pod devem ser roteáveis na sua rede on-premises. + Se você estiver executando webhooks em nós híbridos, os CIDRs do pod deverão ser roteáveis em sua rede on-premises. Se os CIDRs de pod não forem roteáveis na rede on-premises, é recomendável executar webhooks em nós de nuvem no mesmo cluster. Consulte [Configurar webhooks para nós híbridos](hybrid-nodes-webhooks.md) e [Preparar a rede para nós híbridos](hybrid-nodes-networking.md) para obter mais informações. + A AWS recomenda o uso da funcionalidade BGP integrada do Cilium para tornar os CIDRs do pod roteáveis na sua rede on-premises. Para obter mais informações sobre como configurar o BGP do Cilium com nós híbridos, consulte [Configurar o BGP do Cilium para nós híbridos](hybrid-nodes-cilium-bgp.md). + O Gerenciamento de endereços IP (IPAM) padrão no Cilium é chamado de [Escopo do cluster](https://docs.cilium.io/en/stable/network/concepts/ipam/cluster-pool/), em que o operador do Cilium aloca endereços IP para cada nó com base nos CIDRs de pod configurados pelo usuário. ## Instalar o Cilium em nós híbridos ### Procedimento 1. Crie um novo arquivo YAML denominado `cilium-values.yaml`. O exemplo a seguir configura o Cilium para ser executado somente em nós híbridos, definindo a afinidade para o rótulo `eks.amazonaws.com/compute-type: hybrid` para o atendente e operador do Cilium. + Configure `clusterPoolIpv4PodCIDRList` com os mesmos CIDRs de pods que configurou as *redes remotas de pods do seu cluster do EKS*. Por exemplo, `10.100.0.0/24`. O operador do Cilium aloca fatias de endereço IP por meio do espaço de IP configurado `clusterPoolIpv4PodCIDRList`. O CIDR do seu pod não deve se sobrepor ao CIDR do nó on-premises, ao CIDR da VPC ou ao CIDR do serviço do Kubernetes. + Configure `clusterPoolIpv4MaskSize` com base nos pods necessários por nó. Por exemplo, `25` para um tamanho de segmento /25 de 128 pods por nó. + Não altere `clusterPoolIpv4PodCIDRList` ou `clusterPoolIpv4MaskSize` depois de implantar o Cilium em seu cluster, consulte [Expandir o pool de clusters](https://docs.cilium.io/en/stable/network/concepts/ipam/cluster-pool/#expanding-the-cluster-pool) para obter mais informações. + Se você estiver executando o Cilium no modo de substituição do kube-proxy, defina `kubeProxyReplacement: "true"` em seus valores de Helm e certifique-se de não ter uma implantação existente do kube-proxy em execução nos mesmos nós que o Cilium. + O exemplo abaixo desabilita o proxy Envoy Layer 7 (L7) que o Cilium usa para políticas de rede L7 e Ingress. Para obter mais informações, consulte [Configurar políticas de rede do Kubernetes para nós híbridos](hybrid-nodes-network-policies.md) e [Visão geral do Ingress do Cilium e do Gateway do Cilium](hybrid-nodes-ingress.md#hybrid-nodes-ingress-cilium). + O exemplo abaixo configura `loadBalancer.serviceTopology`: `true` para que a Distribuição de tráfego de serviços funcione corretamente se você a configurar para seus serviços. Para obter mais informações, consulte [Configurar a Distribuição de Tráfego de Serviços](hybrid-nodes-webhooks.md#hybrid-nodes-mixed-service-traffic-distribution). + Para obter uma lista completa dos valores do Helm para o Cilium, consulte a [referência do Helm](https://docs.cilium.io/en/stable/helm-reference/) na documentação do Cilium. ``` affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: eks.amazonaws.com/compute-type operator: In values: - hybrid ipam: mode: cluster-pool operator: clusterPoolIPv4MaskSize: 25 clusterPoolIPv4PodCIDRList: - POD_CIDR loadBalancer: serviceTopology: true operator: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: eks.amazonaws.com/compute-type operator: In values: - hybrid unmanagedPodWatcher: restart: false loadBalancer: serviceTopology: true envoy: enabled: false kubeProxyReplacement: "false" ``` 1. Instale o Cilium no cluster. + Substitua `CILIUM_VERSION` por uma versão do Cilium (por exemplo, `1.17.9-0` ou `1.18.3-0`). É recomendável usar a versão de patch mais recente para a versão secundária do Cilium. + Certifique-se de que seus nós atendam aos requisitos de kernel da versão escolhida. O Cilium v1.18.3 necessita do kernel do Linux igual ou superior à versão 5.10. + Caso esteja usando um arquivo kubeconfig específico, use o sinalizador `--kubeconfig` com o comando de instalação do Helm. ``` helm install cilium oci://public.ecr.aws/eks/cilium/cilium \ --version CILIUM_VERSION \ --namespace kube-system \ --values cilium-values.yaml ``` 1. Confirme que a instalação do Cilium teve êxito com os comandos a seguir. Você deve ver a implantação `cilium-operator` e o `cilium-agent` em execução em cada um dos seus nós híbridos. Além disso, os nós híbridos agora devem ter o status `Ready`. Para obter informações sobre como configurar o BGP do Cilium para anunciar seus CIDRs de pod em sua rede on-premises, acesse [Configurar o BGP do Cilium para nós híbridos](hybrid-nodes-cilium-bgp.md). ``` kubectl get pods -n kube-system ``` ``` NAME READY STATUS RESTARTS AGE cilium-jjjn8 1/1 Running 0 11m cilium-operator-d4f4d7fcb-sc5xn 1/1 Running 0 11m ``` ``` kubectl get nodes ``` ``` NAME STATUS ROLES AGE VERSION mi-04a2cf999b7112233 Ready 19m v1.31.0-eks-a737599 ``` ## Atualizar o Cilium em nós híbridos Antes de atualizar a implantação do Cilium, analise cuidadosamente a [documentação de atualização do Cilium](https://docs.cilium.io/en/v1.17/operations/upgrade/) e as notas de atualização para entender as mudanças na versão de destino do Cilium. 1. Certifique-se de ter instalado a CLI do `helm` no ambiente de linha de comandos. Consulte a [documentação do Helm](https://helm.sh/docs/intro/quickstart/) para obter instruções da instalação. 1. Execute a verificação de pré-lançamento da atualização do Cilium. Substitua `CILIUM_VERSION` pela sua versão de destino do Cilium. Recomendamos executar a versão de patch mais recente para a versão secundária do Cilium. Você pode encontrar a versão de patch mais recente para uma determinada versão secundária do Cilium na [seção Stable Releases](https://github.com/cilium/cilium#stable-releases) da documentação do Cilium. ``` helm install cilium-preflight oci://public.ecr.aws/eks/cilium/cilium --version CILIUM_VERSION \ --namespace=kube-system \ --set preflight.enabled=true \ --set agent=false \ --set operator.enabled=false ``` 1. Depois de aplicar o `cilium-preflight.yaml`, certifique-se de que o número de pods `READY` seja o mesmo número de pods do Cilium em execução. ``` kubectl get ds -n kube-system | sed -n '1p;/cilium/p' ``` ``` NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE cilium 2 2 2 2 2 1h20m cilium-pre-flight-check 2 2 2 2 2 7m15s ``` 1. Quando o número de pods READY for igual, certifique-se de que a implantação de pré-lançamento do Cilium também esteja marcada como READY 1/1. Caso mostre READY 0/1, consulte a seção [Validação de CNP](https://docs.cilium.io/en/v1.17/operations/upgrade/#cnp-validation) e resolva problemas com a implantação antes de continuar com a atualização. ``` kubectl get deployment -n kube-system cilium-pre-flight-check -w ``` ``` NAME READY UP-TO-DATE AVAILABLE AGE cilium-pre-flight-check 1/1 1 0 12s ``` 1. Excluir o pré-lançamento ``` helm uninstall cilium-preflight --namespace kube-system ``` 1. Antes de executar o comando `helm upgrade`, preserve os valores da implantação em um `existing-cilium-values.yaml` ou use as opções da linha de comando `--set` para as configurações quando estiver executando o comando de upgrade. A operação de atualização substitui o ConfigMap do Cilium, portanto, é fundamental que os valores de configuração sejam passados durante a atualização. ``` helm get values cilium --namespace kube-system -o yaml > existing-cilium-values.yaml ``` 1. Durante as operações normais do cluster, todos os componentes do Cilium devem executar a mesma versão. As etapas a seguir descrevem como atualizar todos os componentes de uma versão estável para uma versão estável posterior. Ao atualizar de uma versão secundária para outra versão secundária, é recomendável atualizar primeiro para a versão de patch mais recente da versão secundária existente do Cilium. Para minimizar a interrupção, a opção `upgradeCompatibility` deve ser definida para a versão inicial do Cilium que foi instalada no cluster. ``` helm upgrade cilium oci://public.ecr.aws/eks/cilium/cilium --version CILIUM_VERSION \ --namespace kube-system \ --set upgradeCompatibility=1.X \ -f existing-cilium-values.yaml ``` 1. (Opcional) Se você precisar reverter a atualização devido a problemas, execute os comandos a seguir. ``` helm history cilium --namespace kube-system helm rollback cilium [REVISION] --namespace kube-system ``` ## Excluir o Cilium dos nós híbridos 1. Execute o comando a seguir para desinstalar todos os componentes do Cilium do cluster. Observe que a desinstalação da CNI pode afetar a integridade dos nós e pods e não deve ser realizada em clusters de produção. ``` helm uninstall cilium --namespace kube-system ``` As interfaces e rotas configuradas pelo Cilium não são removidas por padrão quando a CNI é removida do cluster. Consulte o [problema do GitHub](https://github.com/cilium/cilium/issues/34289) para obter mais informações. 1. Para limpar os arquivos e recursos de configuração em disco, caso esteja usando os diretórios de configuração padrão, você poderá remover os arquivos conforme mostrado pelo [script `cni-uninstall.sh`](https://github.com/cilium/cilium/blob/main/plugins/cilium-cni/cni-uninstall.sh) no repositório do Cilium no GitHub. 1. Para remover as definições de recursos personalizados (CRDs) do Cilium do cluster, você pode executar os comandos a seguir. ``` kubectl get crds -oname | grep "cilium" | xargs kubectl delete ``` # Configuração de complementos para nós híbridos Configurar complementos Esta página descreve as considerações para a execução de complementos da AWS e complementos da comunidade no Amazon EKS Hybrid Nodes. Para saber mais sobre os complementos do Amazon EKS e os processos de criação, atualização e remoção de complementos do cluster, consulte [Complementos do Amazon EKS](eks-add-ons.md). Salvo indicação em contrário nesta página, os processos para criar, atualizar e remover complementos do Amazon EKS são os mesmos para clusters do Amazon EKS com nós híbridos e para clusters do Amazon EKS com nós em execução na Nuvem AWS. Somente os complementos incluídos nesta página foram validados quanto à compatibilidade com o Amazon EKS Hybrid Nodes. Os complementos da AWS a seguir são compatíveis com o Amazon EKS Hybrid Nodes. | complemento da AWS | Versões de complementos compatíveis | | --- | --- | | kube-proxy | v1.25.14-eksbuild.2 e superior | | CoreDNS | v1.9.3-eksbuild.7 e superior | | AWS Distro para OpenTelemetry (ADOT) | v0.102.1-eksbuild.2 e superior | | Agente de observabilidade do CloudWatch | v2.2.1-eksbuild.1 e superior | | Atendente de Identidade de Pods do EKS | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/eks/latest/userguide/hybrid-nodes-add-ons.html) | | Agente de monitoramento de nós | v1.2.0-eksbuild.1 e superior | | Controlador de snapshots da CSI | v8.1.0-eksbuild.1 e superior | | Conector de CA Privado da AWS para Kubernetes | v1.6.0-eksbuild.1 e superior | | Driver CSI do Amazon FSx | v1.7.0-eksbuild.1 e superior | | Provedor de drivers CSI da AWS Secrets Store | v2.1.1-eksbuild.1 e superior | Os complementos da comunidade a seguir são compatíveis com o Amazon EKS Hybrid Nodes. Para saber mais sobre os complementos da comunidade, consulte [Complementos da comunidade](community-addons.md). | Complemento da comunidade | Versões de complementos compatíveis | | --- | --- | | Servidor de métricas do Kubernetes | v0.7.2-eksbuild.1 e superior | | cert-manager | v1.17.2-eksbuild.1 e superior | | Exportador de nós do Prometheus | v1.9.1-eksbuild.2 e superior | | kube-state-metrics | v2.15.0-eksbuild.4 e superior | | DNS externo | v0.19.0-eksbuild.1 e superior | Além dos complementos do Amazon EKS nas tabelas acima, o [Amazon Managed Service for Prometheus Collector](prometheus.md) e o [AWS Load Balancer Controller](aws-load-balancer-controller.md) para [entrada de aplicações](alb-ingress.md) (HTTP) e [balanceamento de carga](network-load-balancing.md) (TCP e UDP) são compatíveis com nós híbridos. Alguns complementos da AWS e complementos da comunidade não são compatíveis com o Amazon EKS Hybrid Nodes. As versões mais recentes desses complementos têm uma regra de antiafinidade para o rótulo padrão `eks.amazonaws.com/compute-type: hybrid` aplicado aos nós híbridos. Isso impede que eles sejam executados em nós híbridos quando implantados nos clusters. Caso tenha clusters com nós híbridos e nós em execução na Nuvem AWS, você poderá implantar esses complementos no cluster para nós executados na Nuvem AWS. A CNI da Amazon VPC não é compatível com nós híbridos, e o Cilium e o Calico são compatíveis como as interfaces de rede de contêineres (CNIs) do Amazon EKS Hybrid Nodes. Consulte [Configurar a CNI para nós híbridos](hybrid-nodes-cni.md) para obter mais informações. ## Complementos da AWS As próximas seções descrevem as diferenças entre a execução de complementos compatíveis da AWS em nós híbridos, em comparação com os outros tipos de computação do Amazon EKS. ## kube-proxy e CoreDNS Por padrão, o EKS instala o kube-proxy e o CoreDNS como complementos autogerenciados quando você cria um cluster do EKS com a API da AWS e AWS SDKs, inclusive da AWS CLI. Você pode substituir esses complementos pelos complementos do Amazon EKS após a criação do cluster. Consulte a documentação do EKS para obter detalhes sobre [Gerenciar o `kube-proxy` em clusters do Amazon EKS](managing-kube-proxy.md) e [Gerenciar o CoreDNS para DNS em clusters do Amazon EKS](managing-coredns.md). Se você estiver executando um cluster com nós híbridos e não híbridos na AWS Nuvem, a AWS recomenda ter pelo menos uma réplica do CoreDNS nos nós híbridos e pelo menos uma réplica do CoreDNS nos nós na Nuvem AWS. Consulte [Configurar réplicas do CoreDNS](hybrid-nodes-webhooks.md#hybrid-nodes-mixed-coredns) para saber sobre as etapas de configuração. ## Agente de observabilidade do CloudWatch O operador do Agente de observabilidade do CloudWatch usa [webhooks](https://kubernetes.io/docs/reference/access-authn-authz/webhook/). Caso você esteja executando o operador em nós híbridos, o CIDR do pod on-premises deverá ser roteável na rede on-premises e você deverá configurar o cluster do EKS com a rede remota de pods. Para obter mais informações, consulte [Configurar webhooks para nós híbridos](hybrid-nodes-webhooks.md). As métricas no nível do nó não estão disponíveis para nós híbridos porque o [CloudWatch Container Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContainerInsights.html) depende da disponibilidade do [Serviço de metadados de instância](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html) (IMDS) das métricas no nível do nó. Métricas no nível de cluster, workload, pod e contêiner estão disponíveis para nós híbridos. Depois de instalar o complemento seguindo as etapas descritas em [Instalar o atendente do CloudWatch com a observabilidade do Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/install-CloudWatch-Observability-EKS-addon.html), o manifesto do complemento deve ser atualizado antes que o atendente possa ser executado com êxito em nós híbridos. Edite o recurso `amazoncloudwatchagents` no cluster para adicionar a variável `RUN_WITH_IRSA` de ambiente, conforme mostrado abaixo. ``` kubectl edit amazoncloudwatchagents -n amazon-cloudwatch cloudwatch-agent ``` ``` apiVersion: v1 items: - apiVersion: cloudwatch.aws.amazon.com/v1alpha1 kind: AmazonCloudWatchAgent metadata: ... name: cloudwatch-agent namespace: amazon-cloudwatch ... spec: ... env: - name: RUN_WITH_IRSA # <-- Add this value: "True" # <-- Add this - name: K8S_NODE_NAME valueFrom: fieldRef: fieldPath: spec.nodeName ... ``` ## Coletor gerenciado do Amazon Managed Prometheus para nós híbridos Um coletor gerenciado do Amazon Managed Service for Prometheus (AMP) consiste em um extrator que descobre e coleta métricas dos recursos em um cluster do Amazon EKS. O AMP gerencia o extrator para você, eliminando a necessidade de gerenciar instâncias, atendentes ou extratores por conta própria. Você pode usar coletores gerenciados pelo AMP sem nenhuma configuração adicional específica para nós híbridos. No entanto, os endpoints de métricas das aplicações nos nós híbridos devem ser acessíveis na VPC, incluindo rotas da VPC para CIDRs de rede remota de pods e as portas abertas no firewall on-premises. Além disso, o cluster deve ter [acesso ao endpoint privado do cluster](cluster-endpoint.md). Siga as etapas em [Usar um coletor gerenciado pela AWS](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-collector-how-to.html) no Guia do usuário do Amazon Managed Service for Prometheus. ## AWS Distro para OpenTelemetry (ADOT) Você pode usar o complemento do AWS Distro for OpenTelemetry (ADOT) para coletar métricas, logs e dados de rastreamento das aplicações executadas em nós híbridos. O ADOT usa [webhooks](https://kubernetes.io/docs/reference/access-authn-authz/webhook/) de admissão para alterar e validar as solicitações do Collector Custom Resource. Caso esteja executando o operador ADOT em nós híbridos, o CIDR de pods on-premises deverá ser roteável na rede on-premises e você deverá configurar o cluster do EKS com a rede remota de pods. Para obter mais informações, consulte [Configurar webhooks para nós híbridos](hybrid-nodes-webhooks.md). Siga as etapas em [Getting Started with AWS Distro for OpenTelemetry using EKS Add-Ons](https://aws-otel.github.io/docs/getting-started/adot-eks-add-on) na documentação do *AWS Distro para OpenTelemetry*. ## AWS Load Balancer Controller Você pode usar o [AWS Load Balancer Controller](aws-load-balancer-controller.md) e o Application Load Balancer (ALB) ou Network Load Balancer (NLB) com o tipo de destino `ip` para workloads em nós híbridos. Os destinos de IP usados com o ALB ou o NLB devem ser roteáveis pela AWS. O AWS Load Balancer Controller também usa[webhooks](https://kubernetes.io/docs/reference/access-authn-authz/webhook/). Caso você execute o operador do AWS Load Balancer Controller em nós híbridos, o CIDR de pods on-premises deverá ser roteável na rede on-premises e você deverá configurar o cluster do EKS com a rede remota de pods. Para obter mais informações, consulte [Configurar webhooks para nós híbridos](hybrid-nodes-webhooks.md). Para instalar o AWS Load Balancer Controller, siga as etapas em [Application Load Balancer da AWS](hybrid-nodes-ingress.md#hybrid-nodes-ingress-alb) ou [AWS Network Load Balancer](hybrid-nodes-load-balancing.md#hybrid-nodes-service-lb-nlb). Para entrar com o ALB, você deve especificar as anotações abaixo. Consulte [Roteamento de aplicações e tráfego HTTP com Application Load Balancers](alb-ingress.md) para obter mais informações. ``` alb.ingress.kubernetes.io/target-type: ip ``` Para o balanceamento de carga com NLB, você deve especificar as anotações abaixo. Consulte [Roteamento de tráfego TCP e UDP com Network Load Balancers](network-load-balancing.md) para obter mais informações. ``` service.beta.kubernetes.io/aws-load-balancer-type: "external" service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: "ip" ``` ## Atendente de Identidade de Pods do EKS **nota** Para implantar com êxito o complemento do atendente da Identidade de Pods do EKS em nós híbridos que executam o Bottlerocket, certifique-se de que a versão do Bottlerocket seja pelo menos a v1.39.0. O atendente da Identidade de Pods não é compatível com versões anteriores do Bottlerocket em ambientes de nós híbridos. O DaemonSet do atendente original da Identidade de Pods do Amazon EKS depende da disponibilidade do IMDS do EC2 no nó para obter as credenciais da AWS necessárias. Como o IMDS não está disponível em nós híbridos, a partir da versão 1.3.3-eksbuild.1, o complemento do atendente da Identidade de Pods implanta opcionalmente um DaemonSet que monta as credenciais necessárias. Os nós híbridos que executam o Bottlerocket exigem um método diferente para montar as credenciais e, a partir da versão 1.3.7-eksbuild.2, o complemento do atendente da Identidade de Pods implanta opcionalmente um DaemonSet voltado especificamente para nós híbridos do Bottlerocket. As seções a seguir descrevem o processo para habilitar os DaemonSets opcionais. ### Ubuntu/RHEL/AL2023 1. Para usar o atendente da Identidade de Pods em nós híbridos do Ubuntu/RHEL/AL2023, defina `enableCredentialsFile: true` na seção híbrida da configuração de `nodeadm`, conforme mostrado abaixo: ``` apiVersion: node.eks.aws/v1alpha1 kind: NodeConfig spec: hybrid: enableCredentialsFile: true # <-- Add this ``` Isso vai configurar `nodeadm` para criar um arquivo de credenciais a ser configurado no nó abaixo de `/eks-hybrid/.aws/credentials`, que será usado pelos pods `eks-pod-identity-agent`. Esse arquivo de credenciais conterá credenciais temporárias da AWS que serão atualizadas periodicamente. 1. Depois de atualizar a configuração de `nodeadm` em *cada* nó, execute o comando `nodeadm init` a seguir com o `nodeConfig.yaml` para unir os nós híbridos ao cluster do Amazon EKS. Se os nós já se uniram ao cluster anteriormente, execute o comando `nodeadm init` novamente. ``` nodeadm init -c file://nodeConfig.yaml ``` 1. Instale o `eks-pod-identity-agent` com o suporte para nós híbridos habilitado usando a AWS CLI ou o Console de gerenciamento da AWS. 1. AWS CLI: na máquina que você está usando para administrar o cluster, execute o comando a seguir para instalar `eks-pod-identity-agent` com o suporte para nós híbridos habilitado. Substitua o `my-cluster` pelo nome do cluster. ``` aws eks create-addon \ --cluster-name my-cluster \ --addon-name eks-pod-identity-agent \ --configuration-values '{"daemonsets":{"hybrid":{"create": true}}}' ``` 1. Console de gerenciamento da AWS: se você estiver instalando o complemento do atendente da Identidade de Pods no Console da AWS, adicione o seguinte à configuração opcional para implantar o DaemonSet que tem como destino os nós híbridos. ``` {"daemonsets":{"hybrid":{"create": true}}} ``` ### Bottlerocket 1. Para usar o atendente da Identidade de Pods nos nós híbridos do Bottlerocket, adicione o sinalizador `--enable-credentials-file=true` ao comando usado para os dados do usuário do contêiner de bootstrap do Bottlerocket, conforme descrito em [Conectar nós híbridos com o Bottlerocket](hybrid-nodes-bottlerocket.md). 1. Se você estiver usando o provedor de credenciais do SSM, seu comando deverá ser semelhante a este: ``` eks-hybrid-ssm-setup --activation-id= --activation-code= --region= --enable-credentials-file=true ``` 1. Se você estiver usando o provedor de credenciais do IAM Roles Anywhere, seu comando deverá ser semelhante a este: ``` eks-hybrid-iam-ra-setup --certificate= --key= --enable-credentials-file=true ``` Isso vai configurar o script de bootstrap para criar um arquivo de credenciais no nó em `/var/eks-hybrid/.aws/credentials`, que será usado pelos pods do `eks-pod-identity-agent`. Esse arquivo de credenciais conterá credenciais temporárias da AWS que serão atualizadas periodicamente. 1. Instale o `eks-pod-identity-agent` com o suporte para nós híbridos do Bottlerocket habilitado usando a AWS CLI ou o Console de gerenciamento da AWS. 1. AWS CLI: na máquina que você está usando para administrar o cluster, execute o comando a seguir para instalar o `eks-pod-identity-agent` com o suporte para nós híbridos do Bottlerocket habilitado. Substitua o `my-cluster` pelo nome do cluster. ``` aws eks create-addon \ --cluster-name my-cluster \ --addon-name eks-pod-identity-agent \ --configuration-values '{"daemonsets":{"hybrid-bottlerocket":{"create": true}}}' ``` 1. Console de gerenciamento da AWS: se você estiver instalando o complemento do atendente da Identidade de Pods no Console da AWS, adicione o seguinte à configuração opcional para implantar o DaemonSet que tem como destino os nós híbridos do Bottlerocket. ``` {"daemonsets":{"hybrid-bottlerocket":{"create": true}}} ``` ## Controlador de snapshots da CSI A partir da versão `v8.1.0-eksbuild.2`, o [complemento do controlador de snapshots da CSI](csi-snapshot-controller.md) aplica uma regra flexível de antiafinidade para nós híbridos, preferindo que o controlador `deployment` seja executado no EC2 na mesma região da AWS do ambiente de gerenciamento do Amazon EKS. Colocar a `deployment` na mesma região da AWS do ambiente de gerenciamento do Amazon EKS melhora a latência. ## Complementos da comunidade As próximas seções descrevem as diferenças entre a execução de complementos compatíveis da comunidade em nós híbridos, em comparação com os outros tipos de computação do Amazon EKS. ## Servidor de métricas do Kubernetes O ambiente de gerenciamento precisa alcançar o IP do pod do Metrics Server (ou IP do nó se o HostNetwork estiver habilitado). Portanto, a menos que execute o Metrics Server no modo hostNetwork, você deverá configurar uma rede de pod remota ao criar o cluster do Amazon EKS e deverá tornar os endereços IP do pod roteáveis. A implementação do Protocolo de Gateway da Borda (BGP) com o CNI é uma forma comum de tornar os endereços IP do pod roteáveis. ## cert-manager O `cert-manager` usa [webhooks](https://kubernetes.io/docs/reference/access-authn-authz/webhook/). Caso execute o `cert-manager` em nós híbridos, o CIDR de pods on-premises deverá ser roteável na rede on-premises e você deverá configurar o cluster do EKS com a rede remota de pods. Para obter mais informações, consulte [Configurar webhooks para nós híbridos](hybrid-nodes-webhooks.md). # Configurar webhooks para nós híbridos Configurar webhooks Esta página detalha os aspectos da execução de webhooks com nós híbridos. Os webhooks são usados em aplicações Kubernetes e projetos de código aberto, como o AWS Load Balancer Controller e o CloudWatch Observability Agent, para executar recursos de mutação e validação no runtime. **Redes de pods roteáveis** Se for possível tornar o CIDR de pods on-premises roteável em sua rede on-premises, você poderá executar webhooks em nós híbridos. Você pode usar várias técnicas para tornar seu pod CIDR on-premises roteável na rede on-premises, incluindo o Protocolo de Gateway da Borda (BGP), rotas estáticas ou outras soluções de roteamento personalizadas. O BGP é a solução recomendada, pois é mais escalável e fácil de gerenciar do que soluções alternativas, que demandam uma configuração de rota personalizada ou manual. A AWS dá suporte aos recursos do BGP do Cilium e do Calico para anunciar CIDRs do pod. Consulte [Configurar a CNI para nós híbridos](hybrid-nodes-cni.md) e [CIDRs de pods remotos roteáveis](hybrid-nodes-concepts-kubernetes.md#hybrid-nodes-concepts-k8s-pod-cidrs) para obter mais informações. **Redes de pods não roteáveis** Se você *não puder* tornar seu CIDR de pods on-premises roteável na rede on-premises e precisar executar webhooks, recomendamos executar todos os webhooks em nós da nuvem no mesmo cluster do EKS que os nós híbridos. ## Considerações sobre clusters de modo misto Os *clusters de modo misto* são definidos como clusters do EKS que têm nós híbridos e nós em execução na Nuvem AWS. Ao executar um cluster de modo misto, considere as seguintes recomendações: + Execute a VPC CNI em nós na Nuvem AWS e o Cilium ou o Calico em nós híbridos. O Cilium e o Calico não são compatíveis com a AWS quando executados em nós na Nuvem AWS. + Configurar os webhooks para execução em nós na Nuvem AWS. Confira [Configurar webhooks para complementos](#hybrid-nodes-webhooks-add-ons) para saber como configurar os webhooks da AWS e os complementos da comunidade. + Se as aplicações precisarem de pods executados em nós na Nuvem AWS para se comunicar diretamente com os pods executados em nós híbridos (“comunicação leste-oeste”), e você estiver usando a CNI da VPC nos nós na Nuvem AWS e o Cilium ou o Calico em nós híbridos, então o CIDR de pods on-premises deverá ser roteável na rede on-premises. + Execute pelo menos uma réplica do CoreDNS em nós na Nuvem AWS e uma réplica do CoreDNS em nós híbridos. + Configure a Distribuição de Tráfego de Serviços para manter o tráfego de serviços local na zona de origem. Para obter mais informações sobre Distribuição de Tráfego de Serviços, consulte [Configurar a Distribuição de Tráfego de Serviços](#hybrid-nodes-mixed-service-traffic-distribution). + Se você estiver usando o AWS Application Load Balancers (ALB) ou o Network Load Balancers (NLB) para tráfego de workloads executado em nós híbridos, os destinos de IP usados com o ALB ou o NLB deverão ser roteáveis da AWS. + O complemento Metrics Server requer conectividade do ambiente de gerenciamento do EKS com o endereço IP do pod do Metrics Server. Se você estiver executando o complemento Metrics Server em nós híbridos, o CIDR do pod on-premises deverá ser roteável em sua rede on-premises. + Para coletar métricas de nós híbridos usando coletores gerenciados do Amazon Managed Service for Prometheus (AMP), o CIDR do pod on-premises deverá ser roteável na rede local. Outra opção é usar o coletor gerenciado do AMP para recursos e métricas do ambiente de gerenciamento do EKS executados na Nuvem AWS, e o complemento do AWS Distro para OpenTelemetry (ADOT) para coletar métricas de nós híbridos. ## Configurar clusters de modo misto Para visualizar os webhooks mutantes e validados em execução no cluster, você pode ver o tipo de recurso **Extensões** no painel **Recursos** do console do EKS do cluster ou usar os comandos a seguir. O EKS também informa as métricas do webhook no painel de observabilidade do cluster. Consulte [Monitore seu cluster com o painel de observabilidade](observability-dashboard.md) para obter mais informações. ``` kubectl get mutatingwebhookconfigurations ``` ``` kubectl get validatingwebhookconfigurations ``` ### Configurar a Distribuição de Tráfego de Serviços Ao executar clusters de modo misto, recomendamos que você use a [https://kubernetes.io/docs/reference/networking/virtual-ips/#traffic-distribution](https://kubernetes.io/docs/reference/networking/virtual-ips/#traffic-distribution) para manter o tráfego de serviços local na zona de onde ele é originado. A Distribuição de Tráfego de Serviços (disponível para as versões 1.31 e posteriores do Kubernetes no EKS) é a solução recomendada em relação ao [Roteamento com Reconhecimento de Topologia](https://kubernetes.io/docs/concepts/services-networking/topology-aware-routing/) porque é a mais previsível. Na Distribuição de Tráfego de Serviços, os endpoints íntegros na zona receberão todo o tráfego dela. No Roteamento com Reconhecimento de Topologia, cada serviço deve atender a várias condições na zona para aplicar o roteamento personalizado. Do contrário, ele vai rotear o tráfego uniformemente para todos os endpoints. Se você estiver usando o Cilium como seu CNI, você deve executar o CNI com o `enable-service-topology` definido como `true` para habilitar a Distribuição de tráfego de serviço. Você pode passar essa configuração com o sinalizador de instalação do Helm `--set loadBalancer.serviceTopology=true` ou atualizar uma instalação existente com o comando `cilium config set enable-service-topology true` da CLI do Cilium. O agente do Cilium em execução em cada nó deve ser reiniciado após a atualização da configuração de uma instalação existente. Um exemplo de como configurar a Distribuição de Tráfego de Serviços para o serviço CoreDNS é mostrado na seção a seguir, e recomendamos que você habilite o mesmo para todos os serviços no cluster para evitar tráfego não intencional entre ambientes. ### Configurar réplicas do CoreDNS Se você estiver executando um cluster em modo misto com nós híbridos e nós na Nuvem AWS, é recomendável ter pelo menos uma réplica do CoreDNS nos nós híbridos e pelo menos uma réplica do CoreDNS nos nós na Nuvem AWS. Para evitar problemas de latência e rede em uma configuração de cluster em modo misto, é possível configurar o serviço CoreDNS para preferir a réplica do CoreDNS mais próxima com [Distribuição de tráfego de serviço](https://kubernetes.io/docs/reference/networking/virtual-ips/#traffic-distribution). A *Distribuição de tráfego de serviço* (disponível para as versões 1.31 e posteriores do Kubernetes no EKS) é a solução recomendada em relação ao [Roteamento com reconhecimento de topologia](https://kubernetes.io/docs/concepts/services-networking/topology-aware-routing/) porque é a mais previsível. Na Distribuição de tráfego de serviço, os endpoints saudáveis na zona receberão todo o tráfego dessa zona. No roteamento com reconhecimento de topologia, cada serviço deve atender a várias condições nessa zona para aplicar o roteamento personalizado, caso contrário, ele roteia o tráfego uniformemente para todos os endpoints. As etapas a seguir configuram a Distribuição de tráfego de serviço. Se você estiver usando o Cilium como seu CNI, você deve executar o CNI com o `enable-service-topology` definido como `true` para habilitar a Distribuição de tráfego de serviço. Você pode passar essa configuração com o sinalizador de instalação do Helm `--set loadBalancer.serviceTopology=true` ou atualizar uma instalação existente com o comando `cilium config set enable-service-topology true` da CLI do Cilium. O agente do Cilium em execução em cada nó deve ser reiniciado após a atualização da configuração de uma instalação existente. 1. Adicione um rótulo de zona de topologia para cada um dos seus nós híbridos, por exemplo, `topology.kubernetes.io/zone: onprem`. Ou você pode definir o rótulo na fase `nodeadm init` especificando o rótulo na configuração de `nodeadm`, consulte [Configuração de nó para personalizar o kubelet (opcional)](hybrid-nodes-nodeadm.md#hybrid-nodes-nodeadm-kubelet). Observe que os nós executados na Nuvem AWS recebem automaticamente um rótulo de zona de topologia aplicado a eles, correspondente à zona de disponibilidade (AZ) do nó. ``` kubectl label node hybrid-node-name topology.kubernetes.io/zone=zone ``` 1. Adicione `podAntiAffinity` à implantação do CoreDNS com a chave da zona de topologia. Ou você pode configurar a implantação do CoreDNS durante a instalação com os complementos do EKS. ``` kubectl edit deployment coredns -n kube-system ``` ``` spec: template: spec: affinity: ... podAntiAffinity: preferredDuringSchedulingIgnoredDuringExecution: - podAffinityTerm: labelSelector: matchExpressions: - key: k8s-app operator: In values: - kube-dns topologyKey: kubernetes.io/hostname weight: 100 - podAffinityTerm: labelSelector: matchExpressions: - key: k8s-app operator: In values: - kube-dns topologyKey: topology.kubernetes.io/zone weight: 50 ... ``` 1. Adicione a configuração `trafficDistribution: PreferClose` à configuração do serviço `kube-dns` para habilitar a Distribuição de Tráfego de Serviços. ``` kubectl patch svc kube-dns -n kube-system --type=merge -p '{ "spec": { "trafficDistribution": "PreferClose" } }' ``` 1. É possível confirmar se a Distribuição de tráfego de serviço está habilitada visualizando as fatias de endpoint do serviço `kube-dns`. Suas fatias de endpoint devem mostrar o `hints` para seus rótulos de zona de topologia, o que confirma que a Distribuição de tráfego de serviço está habilitada. Se você não consegue ver o `hints` para cada endereço de endpoint, então a Distribuição de tráfego de serviço não está habilitada. ``` kubectl get endpointslice -A | grep "kube-dns" ``` ``` kubectl get endpointslice [.replaceable]`kube-dns-` -n kube-system -o yaml ``` ``` addressType: IPv4 apiVersion: discovery.k8s.io/v1 endpoints: - addresses: - hints: forZones: - name: onprem nodeName: zone: onprem - addresses: - hints: forZones: - name: us-west-2a nodeName: zone: us-west-2a ``` ### Configurar webhooks para complementos Os complementos a seguir usam webhooks e são compatíveis para uso com nós híbridos. + AWS Load Balancer Controller + Agente de observabilidade do CloudWatch + AWS Distro para OpenTelemetry (ADOT) + `cert-manager` Consulte as seções a seguir para configurar os webhooks usados por esses complementos para executar em nós na Nuvem AWS. #### AWS Load Balancer Controller Para usar o AWS Load Balancer Controller em uma configuração de cluster em modo misto, é necessário executar o controlador em nós na Nuvem AWS. Para fazer isso, adicione as opções a seguir à sua configuração de valores do Helm ou especifique os valores usando a configuração de add-on do EKS. ``` affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: eks.amazonaws.com/compute-type operator: NotIn values: - hybrid ``` #### Agente de observabilidade do CloudWatch O complemento do Agente de observabilidade do CloudWatch tem um operador do Kubernetes que usa webhooks. Para executar o operador em nós na Nuvem AWS em uma configuração de cluster de modo misto, edite a configuração do operador do Agente de observabilidade do CloudWatch. Não é possível configurar a afinidade do operador durante a instalação com os complementos do Helm e EKS (consulte o [problema nº 2431 do mapa de contêineres](https://github.com/aws/containers-roadmap/issues/2431)). ``` kubectl edit -n amazon-cloudwatch deployment amazon-cloudwatch-observability-controller-manager ``` ``` spec: ... template: ... spec: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: eks.amazonaws.com/compute-type operator: NotIn values: - hybrid ``` #### AWS Distro para OpenTelemetry (ADOT) O complemento AWS Distro for OpenTelemetry (ADOT) tem um operador do Kubernetes que usa webhooks. Para executar o operador em nós na Nuvem AWS em uma configuração de cluster de modo misto, adicione as informações abaixo à sua configuração de valores do Helm ou especifique os valores usando a configuração do complemento do EKS. ``` affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: eks.amazonaws.com/compute-type operator: NotIn values: - hybrid ``` Se o CIDR do pod não for roteável na rede on-premises, o coletor do ADOT deverá ser executado em nós híbridos para extrair as métricas de seus nós híbridos e das workloads executadas neles. Para fazer isso, edite a Definição de recurso personalizado (CRD). ``` kubectl -n opentelemetry-operator-system edit opentelemetrycollectors.opentelemetry.io adot-col-prom-metrics ``` ``` spec: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: eks.amazonaws.com/compute-type operator: In values: - hybrid ``` Você pode configurar o coletor ADOT para extrair métricas apenas dos nós híbridos e dos recursos executados nos nós híbridos adicionando o seguinte `relabel_configs` a cada `scrape_configs` na configuração CRD do coletor ADOT. ``` relabel_configs: - action: keep regex: hybrid source_labels: - __meta_kubernetes_node_label_eks_amazonaws_com_compute_type ``` O complemento ADOT tem como pré-requisito a instalação do `cert-manager` para os certificados TLS usados pelo webhook do operador ADOT. O `cert-manager` também executa webhooks e você pode configurá-lo para executar em nós na Nuvem AWS com a configuração de valores do Helm a seguir. ``` affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: eks.amazonaws.com/compute-type operator: NotIn values: - hybrid webhook: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: eks.amazonaws.com/compute-type operator: NotIn values: - hybrid cainjector: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: eks.amazonaws.com/compute-type operator: NotIn values: - hybrid startupapicheck: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: eks.amazonaws.com/compute-type operator: NotIn values: - hybrid ``` #### `cert-manager` O complemento `cert-manager` também executa webhooks, e você pode configurá-lo para execução em nós na Nuvem AWS com a configuração de valores do Helm a seguir. ``` affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: eks.amazonaws.com/compute-type operator: NotIn values: - hybrid webhook: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: eks.amazonaws.com/compute-type operator: NotIn values: - hybrid cainjector: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: eks.amazonaws.com/compute-type operator: NotIn values: - hybrid startupapicheck: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: eks.amazonaws.com/compute-type operator: NotIn values: - hybrid ``` # Configurar proxy para nós híbridos Configurar proxy Caso esteja usando um servidor proxy no ambiente on-premises para tráfego que sai do data center ou do ambiente de borda, você precisa configurar em separado os nós e o cluster para usar o servidor proxy. Cluster No cluster, você precisa configurar `kube-proxy` para usar o servidor proxy. Você deve configurar `kube-proxy` após criar o cluster do Amazon EKS. Nós Nos nós, você deve configurar o sistema operacional, `containerd`, `kubelet` e o agente Amazon SSM para usar o servidor proxy. Você pode fazer essas alterações durante o processo de criação para as imagens do sistema operacional ou antes de executar `nodeadm init` em cada nó híbrido. ## Configuração no nível do nó Você deve aplicar as configurações a seguir nas imagens do sistema operacional ou antes de executar `nodeadm init` em cada nó híbrido. ### Configuração do proxy `containerd` `containerd` é o runtime padrão de gerenciamento de contêineres para o Kubernetes. Caso esteja usando um proxy para acesso à internet, você deverá configurar o `containerd` para que ele possa extrair as imagens de contêiner exigidas pelo Kubernetes e pelo Amazon EKS. Crie um arquivo em cada nó híbrido denominado `http-proxy.conf` no diretório `/etc/systemd/system/containerd.service.d` com os conteúdos a seguir. Substitua `proxy-domain` e `port` pelos valores do seu ambiente. ``` [Service] Environment="HTTP_PROXY=http://proxy-domain:port" Environment="HTTPS_PROXY=http://proxy-domain:port" Environment="NO_PROXY=localhost" ``` #### Configuração do `containerd` dos dados do usuário O diretório `containerd.service.d` precisará ser criado para esse arquivo. Você precisará recarregar o systemd para obter o arquivo de configuração sem reinicializar. No AL2023, o serviço provavelmente já estará em execução quando seu script for executado, então você também precisará reiniciá-lo. ``` mkdir -p /etc/systemd/system/containerd.service.d echo '[Service]' > /etc/systemd/system/containerd.service.d/http-proxy.conf echo 'Environment="HTTP_PROXY=http://proxy-domain:port"' >> /etc/systemd/system/containerd.service.d/http-proxy.conf echo 'Environment="HTTPS_PROXY=http://proxy-domain:port"' >> /etc/systemd/system/containerd.service.d/http-proxy.conf echo 'Environment="NO_PROXY=localhost"' >> /etc/systemd/system/containerd.service.d/http-proxy.conf systemctl daemon-reload systemctl restart containerd ``` ### Configuração do proxy `kubelet` `kubelet` é o agente de nó do Kubernetes que é executado em cada nó do Kubernetes e é responsável por gerenciar os nós e pods em execução nele. Caso esteja usando um proxy no ambiente on-premises, você deverá configurar o `kubelet` para que ele possa se comunicar com os endpoints públicos ou privados do cluster do Amazon EKS. Crie um arquivo em cada nó híbrido denominado `http-proxy.conf` no diretório `/etc/systemd/system/kubelet.service.d/` com o conteúdo a seguir. Substitua `proxy-domain` e `port` pelos valores do seu ambiente. ``` [Service] Environment="HTTP_PROXY=http://proxy-domain:port" Environment="HTTPS_PROXY=http://proxy-domain:port" Environment="NO_PROXY=localhost" ``` #### Configuração do `kubelet` dos dados do usuário O diretório `kubelet.service.d` deve ser criado para esse arquivo. Você precisará recarregar o systemd para obter o arquivo de configuração sem reinicializar. No AL2023, o serviço provavelmente já estará em execução quando seu script for executado, então você também precisará reiniciá-lo. ``` mkdir -p /etc/systemd/system/kubelet.service.d echo '[Service]' > /etc/systemd/system/kubelet.service.d/http-proxy.conf echo 'Environment="HTTP_PROXY=http://proxy-domain:port"' >> /etc/systemd/system/kubelet.service.d/http-proxy.conf echo 'Environment="HTTPS_PROXY=http://proxy-domain:port"' >> /etc/systemd/system/kubelet.service.d/http-proxy.conf echo 'Environment="NO_PROXY=localhost"' >> /etc/systemd/system/kubelet.service.d/http-proxy.conf systemctl daemon-reload systemctl restart kubelet ``` ### Configuração do proxy `ssm` O `ssm` é um dos provedores de credenciais que podem ser usados para inicializar um nó híbrido. O `ssm` é responsável pela autenticação na AWS e pela geração de credenciais temporárias que são usadas pelo `kubelet`. Caso esteja usando um proxy no ambiente on-premises e usando o `ssm` como provedor de credenciais no nó, você deverá configurar o `ssm` para que ele possa se comunicar com os endpoints do serviço do Amazon SSM. Crie um arquivo em cada nó híbrido chamado `http-proxy.conf` no caminho abaixo, dependendo do sistema operacional + Ubuntu - `/etc/systemd/system/snap.amazon-ssm-agent.amazon-ssm-agent.service.d/http-proxy.conf` + Amazon Linux 2023 e Red Hat Enterprise Linux: `/etc/systemd/system/amazon-ssm-agent.service.d/http-proxy.conf` Preencha o arquivo com o seguinte conteúdo. Substitua `proxy-domain` e `port` pelos valores do seu ambiente. ``` [Service] Environment="HTTP_PROXY=http://proxy-domain:port" Environment="HTTPS_PROXY=http://proxy-domain:port" Environment="NO_PROXY=localhost" ``` #### Configuração do `ssm` dos dados do usuário O serviço `ssm` systemd deve ser criado para esse arquivo. O caminho do diretório dependerá do sistema operacional usado no nó. + Ubuntu - `/etc/systemd/system/snap.amazon-ssm-agent.amazon-ssm-agent.service.d` + Amazon Linux 2023 e Red Hat Enterprise Linux: `/etc/systemd/system/amazon-ssm-agent.service.d` Substitua o nome do serviço systemd no comando restart abaixo, dependendo do sistema operacional usado no nó + Ubuntu - `snap.amazon-ssm-agent.amazon-ssm-agent` + Amazon Linux 2023 e Red Hat Enterprise Linux: `amazon-ssm-agent` ``` mkdir -p systemd-service-file-directory echo '[Service]' > [.replaceable]#systemd-service-file-directory/http-proxy.conf echo 'Environment="HTTP_PROXY=http://[.replaceable]#proxy-domain:port"' >> systemd-service-file-directory/http-proxy.conf echo 'Environment="HTTPS_PROXY=http://[.replaceable]#proxy-domain:port"' >> [.replaceable]#systemd-service-file-directory/http-proxy.conf echo 'Environment="NO_PROXY=localhost"' >> [.replaceable]#systemd-service-file-directory/http-proxy.conf systemctl daemon-reload systemctl restart [.replaceable]#systemd-service-name ``` ### Configuração de proxy do sistema operacional Caso esteja usando um proxy para acesso à internet, você deve configurar o sistema operacional para poder extrair as dependências dos nós híbridos do gerenciador de pacotes do sistema operacional. **Ubuntu** 1. Configure `snap` para usar o proxy com os seguintes comandos: ``` sudo snap set system proxy.https=http://proxy-domain:port sudo snap set system proxy.http=http://proxy-domain:port ``` 1. Para habilitar o proxy para `apt`, crie um arquivo denominado `apt.conf` no diretório `/etc/apt/`. Substitua proxy-domain e a porta pelos valores do seu ambiente. ``` Acquire::http::Proxy "http://proxy-domain:port"; Acquire::https::Proxy "http://proxy-domain:port"; ``` **Amazon Linux 2023** 1. Configure `dnf` para usar o proxy. Crie um arquivo `/etc/dnf/dnf.conf` com os valores de proxy-domain e port para seu ambiente. ``` proxy=http://proxy-domain:port ``` **Red Hat Enterprise Linux** 1. Configure `yum` para usar o proxy. Crie um arquivo `/etc/yum.conf` com os valores de proxy-domain e port para seu ambiente. ``` proxy=http://proxy-domain:port ``` ### Configuração de proxies do IAM Roles Anywhere O serviço de provedor de credenciais do IAM Roles Anywhere é responsável por atualizar as credenciais ao usar o IAM Roles Anywhere com o sinalizador `enableCredentialsFile` (consulte [Atendente de Identidade de Pods do EKS](hybrid-nodes-add-ons.md#hybrid-nodes-add-ons-pod-id)). Caso esteja usando um proxy no ambiente on-premises, você deverá configurar o serviço para que ele possa se comunicar com os endpoints do IAM Roles Anywhere. No diretório `/etc/systemd/system/aws_signing_helper_update.service.d/`, crie um arquivo denominado `http-proxy.conf` com o conteúdo a seguir. Substitua `proxy-domain` e `port` pelos valores do seu ambiente. ``` [Service] Environment="HTTP_PROXY=http://proxy-domain:port" Environment="HTTPS_PROXY=http://proxy-domain:port" Environment="NO_PROXY=localhost" ``` ## Configuração de todo o cluster As configurações nesta seção devem ser aplicadas depois de você criar o cluster do Amazon EKS e antes de executar `nodeadm init` em cada nó híbrido. ### Configuração do proxy kube-proxy O Amazon EKS instala automaticamente o `kube-proxy` em cada nó híbrido como um DaemonSet quando os nós híbridos se unem ao cluster. O `kube-proxy` permite o roteamento entre serviços que são apoiados por pods nos clusters do Amazon EKS. Para configurar cada host, o `kube-proxy` requer resolução de DNS para o endpoint de cluster do Amazon EKS. 1. Editar o DaemonSet do `kube-proxy` com o comando a seguir ``` kubectl -n kube-system edit ds kube-proxy ``` Isso abrirá a definição do DaemonSet do `kube-proxy` no editor configurado. 1. Adicione variáveis de ambiente para `HTTP_PROXY` e `HTTPS_PROXY`. Observe que a variável de ambiente `NODE_NAME` já deve existir na configuração. Substitua `proxy-domain` e `port` pelos valores do seu ambiente. ``` containers: - command: - kube-proxy - --v=2 - --config=/var/lib/kube-proxy-config/config - --hostname-override=$(NODE_NAME) env: - name: HTTP_PROXY value: http://proxy-domain:port - name: HTTPS_PROXY value: http://proxy-domain:port - name: NODE_NAME valueFrom: fieldRef: apiVersion: v1 fieldPath: spec.nodeName ``` # Configurar o BGP do Cilium para nós híbridos Configurar o BGP Este tópico descreve como configurar o Protocolo de Gateway da Borda (BGP) do Cilium para o Amazon EKS Hybrid Nodes. A funcionalidade BGP do Cilium é chamada de [Ambiente de gerenciamento BGP do Cilium](https://docs.cilium.io/en/stable/network/bgp-control-plane/bgp-control-plane/) e pode ser usada para anunciar endereços de pod e serviços em sua rede on-premises. Para obter métodos alternativos de tornar os CIDRs de pods roteáveis na rede on-premises, consulte [CIDRs de pods remotos roteáveis](hybrid-nodes-concepts-kubernetes.md#hybrid-nodes-concepts-k8s-pod-cidrs). ## Configurar o BGP do Cilium ### Pré-requisitos + Cilium instalado seguindo as instruções em [Configurar a CNI para nós híbridos](hybrid-nodes-cni.md). ### Procedimento 1. Para usar o BGP com o Cilium para anunciar endereços de pods ou serviços na sua rede on-premises, você deve ter o Cilium instalado com `bgpControlPlane.enabled: true`. Caso esteja habilitando o BGP para uma implantação existente do Cilium, você deverá reiniciar o operador do Cilium para aplicar a configuração do BGP caso ele não tenha sido habilitado anteriormente. Você pode definir `operator.rollOutPods` como `true` nos seus valores do Helm para reiniciar o operador do Cilium como parte do processo de instalação e atualização do Helm. ``` helm upgrade cilium oci://public.ecr.aws/eks/cilium/cilium \ --namespace kube-system \ --reuse-values \ --set operator.rollOutPods=true \ --set bgpControlPlane.enabled=true ``` 1. Confirme se o operador e os atendentes do Cilium foram reiniciados e estão funcionando. ``` kubectl -n kube-system get pods --selector=app.kubernetes.io/part-of=cilium ``` ``` NAME READY STATUS RESTARTS AGE cilium-grwlc 1/1 Running 0 4m12s cilium-operator-68f7766967-5nnbl 1/1 Running 0 4m20s cilium-operator-68f7766967-7spfz 1/1 Running 0 4m20s cilium-pnxcv 1/1 Running 0 6m29s cilium-r7qkj 1/1 Running 0 4m12s cilium-wxhfn 1/1 Running 0 4m1s cilium-z7hlb 1/1 Running 0 6m30s ``` 1. Crie um arquivo chamado `cilium-bgp-cluster.yaml` com uma definição `CiliumBGPClusterConfig`. Talvez seja necessário obter as informações a seguir do seu administrador de rede. + Configure o `localASN` com o ASN dos nós que executam o Cilium. + Configure o `peerASN` com o ASN do roteador on-premises. + Configure o `peerAddress` com o IP do roteador on-premises com o qual cada nó que executa o Cilium fará emparelhamento. ``` apiVersion: cilium.io/v2alpha1 kind: CiliumBGPClusterConfig metadata: name: cilium-bgp spec: nodeSelector: matchExpressions: - key: eks.amazonaws.com/compute-type operator: In values: - hybrid bgpInstances: - name: "rack0" localASN: NODES_ASN peers: - name: "onprem-router" peerASN: ONPREM_ROUTER_ASN peerAddress: ONPREM_ROUTER_IP peerConfigRef: name: "cilium-peer" ``` 1. Aplique a configuração do cluster do BGP do Cilium ao seu cluster. ``` kubectl apply -f cilium-bgp-cluster.yaml ``` 1. Crie um arquivo `cilium-bgp-peer.yaml` com o nome do recurso `CiliumBGPPeerConfig` que define a configuração de pares do BGP. Vários pares podem compartilhar a mesma configuração e fornecer referência ao recurso comum de `CiliumBGPPeerConfig`. Consulte a [configuração de pares do BGP](https://docs.cilium.io/en/latest/network/bgp-control-plane/bgp-control-plane-v2/#bgp-peer-configuration) na documentação do Cilium para obter uma lista completa das opções de configuração. Os valores das seguintes configurações de pares do Cilium devem corresponder aos do roteador on-premises com o qual você está fazendo o emparelhamento. + Configure `holdTimeSeconds`, que determina quanto tempo um par do BGP espera por uma mensagem de manutenção ou atualização antes de declarar a sessão inativa. O padrão é de 90 segundos. + Configure `keepAliveTimeSeconds`, que determina se um par do BGP ainda está acessível e se a sessão do BGP está ativa. O padrão é 30 segundos. + Configure `restartTimeSeconds`, que determina o tempo em que se espera que o ambiente de gerenciamento do BGP do Cilium restabeleça a sessão do BGP após uma reinicialização. O padrão é 120 segundos. ``` apiVersion: cilium.io/v2alpha1 kind: CiliumBGPPeerConfig metadata: name: cilium-peer spec: timers: holdTimeSeconds: 90 keepAliveTimeSeconds: 30 gracefulRestart: enabled: true restartTimeSeconds: 120 families: - afi: ipv4 safi: unicast advertisements: matchLabels: advertise: "bgp" ``` 1. Aplique a configuração de pares do BGP do Cilium ao seu cluster. ``` kubectl apply -f cilium-bgp-peer.yaml ``` 1. Crie um arquivo `cilium-bgp-advertisement-pods.yaml` com o nome de um recurso `CiliumBGPAdvertisement` para anunciar os CIDRs do pod em sua rede on-premises. + O recurso `CiliumBGPAdvertisement` é usado para definir tipos e atributos de anúncios associados a eles. O exemplo abaixo configura o Cilium para anunciar somente CIDRs de pod. Veja os exemplos em [Tipo de serviço LoadBalancer](hybrid-nodes-ingress.md#hybrid-nodes-ingress-cilium-loadbalancer) e [Balanceamento de carga no cluster do Cilium](hybrid-nodes-load-balancing.md#hybrid-nodes-service-lb-cilium) para obter mais informações sobre como configurar o Cilium para anunciar endereços de serviços. + Cada nó híbrido que executa o atendente do Cilium emparelha com o roteador upstream habilitado para BGP. Cada nó anuncia a faixa de pod CIDR que possui quando `advertisementType` do Cilium está configurada como `PodCIDR` no exemplo abaixo. Consulte a [configuração de anúncios do BGP](https://docs.cilium.io/en/stable/network/bgp-control-plane/bgp-control-plane-v2/#bgp-advertisements) na documentação do Cilium para obter mais informações. ``` apiVersion: cilium.io/v2alpha1 kind: CiliumBGPAdvertisement metadata: name: bgp-advertisement-pods labels: advertise: bgp spec: advertisements: - advertisementType: "PodCIDR" ``` 1. Aplique a configuração de anúncios do BGP do Cilium ao seu cluster. ``` kubectl apply -f cilium-bgp-advertisement-pods.yaml ``` 1. Você pode confirmar que o emparelhamento do BGP funcionou com a [CLI do Cilium](https://docs.cilium.io/en/stable/gettingstarted/k8s-install-default/#install-the-cilium-cli) usando o comando `cilium bgp peers`. Você deve ver os valores corretos na saída do ambiente e no estado da sessão como `established`. Consulte o [Guia de solução de problemas e operações](https://docs.cilium.io/en/latest/network/bgp-control-plane/bgp-control-plane/#troubleshooting-and-operation-guide) na documentação do Cilium para obter mais informações sobre a solução de problemas. Nos exemplos abaixo, há cinco nós híbridos executando o atendente do Cilium e cada nó está anunciando o intervalo de CIDR do Pod que possui. ``` cilium bgp peers ``` ``` Node Local AS Peer AS Peer Address Session State Uptime Family Received Advertised mi-026d6a261e355fba7 NODES_ASN ONPREM_ROUTER_ASN ONPREM_ROUTER_IP established 1h18m58s ipv4/unicast 1 2 mi-082f73826a163626e NODES_ASN ONPREM_ROUTER_ASN ONPREM_ROUTER_IP established 1h19m12s ipv4/unicast 1 2 mi-09183e8a3d755abf6 NODES_ASN ONPREM_ROUTER_ASN ONPREM_ROUTER_IP established 1h18m47s ipv4/unicast 1 2 mi-0d78d815980ed202d NODES_ASN ONPREM_ROUTER_ASN ONPREM_ROUTER_IP established 1h19m12s ipv4/unicast 1 2 mi-0daa253999fe92daa NODES_ASN ONPREM_ROUTER_ASN ONPREM_ROUTER_IP established 1h18m58s ipv4/unicast 1 2 ``` ``` cilium bgp routes ``` ``` Node VRouter Prefix NextHop Age Attrs mi-026d6a261e355fba7 NODES_ASN 10.86.2.0/26 0.0.0.0 1h16m46s [{Origin: i} {Nexthop: 0.0.0.0}] mi-082f73826a163626e NODES_ASN 10.86.2.192/26 0.0.0.0 1h16m46s [{Origin: i} {Nexthop: 0.0.0.0}] mi-09183e8a3d755abf6 NODES_ASN 10.86.2.64/26 0.0.0.0 1h16m46s [{Origin: i} {Nexthop: 0.0.0.0}] mi-0d78d815980ed202d NODES_ASN 10.86.2.128/26 0.0.0.0 1h16m46s [{Origin: i} {Nexthop: 0.0.0.0}] mi-0daa253999fe92daa NODES_ASN 10.86.3.0/26 0.0.0.0 1h16m46s [{Origin: i} {Nexthop: 0.0.0.0}] ``` # Configurar o Ingress do Kubernetes para nós híbridos Configurar o Ingress Este tópico descreve como configurar o Ingress do Kubernetes para workloads em execução no Amazon EKS Hybrid Nodes. O [Ingress do Kubernetes](https://kubernetes.io/docs/concepts/services-networking/ingress/) expõe rotas HTTP e HTTPS de fora do cluster para os serviços dentro do cluster. Para usar os recursos do Ingress, é necessário um controlador do Ingress do Kubernetes para configurar a infraestrutura de rede e os componentes que atendem ao tráfego da rede. A AWS oferece suporte para o AWS Application Load Balancer (ALB) e Cilium para Ingress do Kubernetes para workloads em execução no EKS Hybrid Nodes. A decisão de usar o ALB ou o Cilium para o Ingress é baseada na origem do tráfego da aplicação. Se o tráfego da aplicação for originário de uma região da AWS, a AWS recomenda usar o AWS ALB e o AWS Load Balancer Controller. Se o tráfego da aplicação for originado do ambiente on-premises ou da borda, a AWS recomenda usar os recursos de entrada integrados do Cilium, que podem ser usados com ou sem a infraestrutura de balanceador de carga em seu ambiente. ![\[Ingress do EKS Hybrid Nodes\]](http://docs.aws.amazon.com/pt_br/eks/latest/userguide/images/hybrid-nodes-ingress.png) ## Application Load Balancer da AWS Você pode usar o [AWS Load Balancer Controller](aws-load-balancer-controller.md) e o Application Load Balancer (ALB) com o tipo de destino `ip` para workloads executadas em nós híbridos. Ao usar o tipo de destino `ip`, o ALB encaminha o tráfego diretamente para os pods, ignorando o caminho de rede da camada de serviço. Para que o ALB alcance os destinos IP do pod on-premises em nós híbridos, o CIDR do pod on-premises deverá ser roteável em sua rede on-premises. Além disso, o AWS Load Balancer Controller usa webhooks e requer comunicação direta do ambiente de gerenciamento EKS. Para obter mais informações, consulte [Configurar webhooks para nós híbridos](hybrid-nodes-webhooks.md). ### Considerações + Consulte [Roteamento de aplicações e tráfego HTTP com Application Load Balancers](alb-ingress.md) e [Instale o AWS Load Balancer Controller com o Helm](lbc-helm.md) para obter mais informações sobre o AWS Application Load Balancer e o AWS Load Balancer Controller. + Consulte [Práticas recomendadas para balanceamento de carga](https://docs.aws.amazon.com/eks/latest/best-practices/load-balacing.html) para obter informações sobre como escolher entre o AWS Application Load Balancer e o AWS Network Load Balancer. + Consulte [Anotações do Ingress do AWS Load Balancer Controller](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/ingress/annotations/) para ver a lista de anotações que podem ser configuradas para recursos do Ingress com o AWS Application Load Balancer. ### Pré-requisitos + Cilium instalado seguindo as instruções em [Configurar a CNI para nós híbridos](hybrid-nodes-cni.md). + O ambiente de gerenciamento BGP do Cilium é habilitado seguindo as instruções em [Configurar o BGP do Cilium para nós híbridos](hybrid-nodes-cilium-bgp.md). Se você não quiser usar o BGP, deverá usar um método alternativo para tornar os CIDRs do pod on-premises roteáveis em sua rede on-premises. Se você não tornar seus CIDRs de pod on-premises roteáveis, o ALB não poderá registrar ou contatar seus destinos IP de pod. + O Helm instalado em seu ambiente de linha de comando. Consulte as [Instruções de configuração do Helm](helm.md) para obter mais informações. + O eksctl instalado em seu ambiente de linha de comando. Consulte as [instruções de instalação do eksctl](install-kubectl.md#eksctl-install-update) para obter mais informações. ### Procedimento 1. Baixe uma política do IAM para o AWS Load Balancer Controller que permita que ele faça chamadas para APIs da AWS em seu nome. ``` curl -O https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/refs/heads/main/docs/install/iam_policy.json ``` 1. Crie uma política do IAM usando a política obtida por download na etapa anterior. ``` aws iam create-policy \ --policy-name AWSLoadBalancerControllerIAMPolicy \ --policy-document file://iam_policy.json ``` 1. Substitua os valores do nome do cluster (`CLUSTER_NAME`), região da AWS (`AWS_REGION`) e ID da conta da AWS (`AWS_ACCOUNT_ID`) pelas suas configurações e execute o comando a seguir. ``` eksctl create iamserviceaccount \ --cluster=CLUSTER_NAME \ --namespace=kube-system \ --name=aws-load-balancer-controller \ --attach-policy-arn=arn:aws:iam::AWS_ACCOUNT_ID:policy/AWSLoadBalancerControllerIAMPolicy \ --override-existing-serviceaccounts \ --region AWS_REGION \ --approve ``` 1. Adicione o repositório de chart do Helm do eks-charts e atualize o repositório Helm local para garantir que você tenha os gráficos mais recentes. ``` helm repo add eks https://aws.github.io/eks-charts ``` ``` helm repo update eks ``` 1. Instale o AWS Load Balancer Controller. Substitua os valores do nome do cluster (`CLUSTER_NAME`), região da AWS (`AWS_REGION`), ID da VPC (`VPC_ID`) e versão do chart do Helm do AWS Load Balancer Controller (`AWS_LBC_HELM_VERSION`) pelas suas configurações e execute o comando a seguir. Se você estiver executando um cluster em modo misto com nós híbridos e nós na Nuvem AWS, você pode executar o AWS Load Balancer Controller nos nós da nuvem seguindo as instruções em [AWS Load Balancer Controller](hybrid-nodes-webhooks.md#hybrid-nodes-mixed-lbc). + Você pode encontrar a versão mais recente do chart do Helm executando `helm search repo eks/aws-load-balancer-controller --versions`. ``` helm install aws-load-balancer-controller eks/aws-load-balancer-controller \ -n kube-system \ --version AWS_LBC_HELM_VERSION \ --set clusterName=CLUSTER_NAME \ --set region=AWS_REGION \ --set vpcId=VPC_ID \ --set serviceAccount.create=false \ --set serviceAccount.name=aws-load-balancer-controller ``` 1. Verifique se o AWS Load Balancer Controller foi instalado com êxito. ``` kubectl get -n kube-system deployment aws-load-balancer-controller ``` ``` NAME READY UP-TO-DATE AVAILABLE AGE aws-load-balancer-controller 2/2 2 2 84s ``` 1. Crie uma aplicação de exemplo. O exemplo abaixo usa a aplicação de microsserviços de amostra [Istio Bookinfo](https://istio.io/latest/docs/examples/bookinfo/). ``` kubectl apply -f https://raw.githubusercontent.com/istio/istio/refs/heads/master/samples/bookinfo/platform/kube/bookinfo.yaml ``` 1. Crie um arquivo denominado `my-ingress-alb.yaml` com os conteúdos a seguir. ``` apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: my-ingress namespace: default annotations: alb.ingress.kubernetes.io/load-balancer-name: "my-ingress-alb" alb.ingress.kubernetes.io/target-type: "ip" alb.ingress.kubernetes.io/scheme: "internet-facing" alb.ingress.kubernetes.io/healthcheck-path: "/details/1" spec: ingressClassName: alb rules: - http: paths: - backend: service: name: details port: number: 9080 path: /details pathType: Prefix ``` 1. Aplique a configuração do Ingress ao seu cluster. ``` kubectl apply -f my-ingress-alb.yaml ``` 1. O provisionamento do ALB para o recurso do Ingress pode demorar alguns minutos. Depois que o ALB for provisionado, seu recurso do Ingress terá um endereço atribuído a ele que corresponde ao nome DNS da implantação do ALB. O endereço terá o formato `-..elb.amazonaws.com`. ``` kubectl get ingress my-ingress ``` ``` NAME CLASS HOSTS ADDRESS PORTS AGE my-ingress alb * my-ingress-alb-..elb.amazonaws.com 80 23m ``` 1. Acesse o serviço usando o endereço do ALB. ``` curl -s http//my-ingress-alb-..elb.amazonaws.com:80/details/1 | jq ``` ``` { "id": 1, "author": "William Shakespeare", "year": 1595, "type": "paperback", "pages": 200, "publisher": "PublisherA", "language": "English", "ISBN-10": "1234567890", "ISBN-13": "123-1234567890" "details": "This is the details page" } ``` ## Visão geral do Ingress do Cilium e do Gateway do Cilium Os recursos de entrada do Cilium são incorporados à arquitetura do Cilium e podem ser gerenciados com a API do Ingress do Kubernetes ou a API do Gateway. Se você não tem recursos do Ingress existentes, a AWS recomenda começar com a API do Gateway, pois é uma forma mais expressiva e flexível de definir e gerenciar os recursos de rede do Kubernetes. A [API do Gateway do Kubernetes](https://gateway-api.sigs.k8s.io/) visa padronizar como os recursos de rede para Ingress, balanceamento de carga e malha de serviços são definidos e gerenciados nos clusters do Kubernetes. Quando você habilita atributos do Ingress ou do Gateway do Cilium, o operador do Cilium reconcilia os objetos do Ingress ou Gateway no cluster e os proxies Envoy em cada nó processam o tráfego de rede da Camada 7 (L7). O Cilium não provisiona diretamente a infraestrutura Ingress ou Gateway, como balanceadores de carga. Se você planeja usar o Ingress do Cilium/Gateway com um balanceador de carga, deve usar as ferramentas do balanceador de carga, geralmente um controlador Ingress ou Gateway, para implantar e gerenciar a infraestrutura do balanceador de carga. Para tráfego de Ingress ou Gateway, o Cilium lida com o tráfego da rede principal e a aplicação da política L3/L4, e os proxies Envoy integrados processam o tráfego de rede de L7. Com o Ingress do Cilium/Gateway, o Envoy é responsável por aplicar regras, políticas e manipulação de solicitações de roteamento L7, gerenciamento avançado de tráfego, como divisão e espelhamento de tráfego, e terminação e originação de TLS. Os proxies Envoy do Cilium são implantados como um DaemonSet (`cilium-envoy`) separado por padrão, o que permite que o Envoy e o atendente do Cilium sejam atualizados, escalados e gerenciados separadamente. Para obter mais informações sobre como o Ingress do Cilium e o Gateway do Cilium funcionam, consulte as páginas [Ingress do Cilium](https://docs.cilium.io/en/stable/network/servicemesh/ingress/) e [Gateway do Cilium](https://docs.cilium.io/en/stable/network/servicemesh/gateway-api/gateway-api/) na documentação do Cilium. ## Comparação entre Ingress e Gateway do Cilium A tabela abaixo resume os recursos do Ingress do Cilium e do Gateway do Cilium a partir da **versão 1.17.x do Cilium**. | Recurso | Ingress | Gateway | | --- | --- | --- | | Tipo de serviço LoadBalancer | Sim | Sim | | Tipo de serviço NodePort | Sim | Não1 | | Rede do host | Sim | Sim | | Balanceador de carga compartilhado | Sim | Sim | | Balanceador de carga dedicado | Sim | Número2 | | Políticas de rede | Sim | Sim | | Protocolos | Camada 7 (HTTP(S), gRPC) | Camada 7 (HTTP(S), gRPC)3 | | Passagem do TLS | Sim | Sim | | Gerenciamento de tráfego | Roteamento de caminhos e hosts | Roteamento de caminho e host, redirecionamento e reescrita de URL, divisão de tráfego, modificação de cabeçalho | 1 O suporte do Gateway do Cilium para serviços NodePort está planejado para a versão 1.18.x do Cilium ([\$127273](https://github.com/cilium/cilium/pull/27273)) 2 Suporte do Gateway do Cilium para balanceadores de carga dedicados ([\$125567](https://github.com/cilium/cilium/issues/25567)) 3 Suporte do Gateway do Cilium para TCP/UDP ([\$121929](https://github.com/cilium/cilium/issues/21929)) ## Instale o Gateway do Cilium ### Considerações + O Cilium deve ser configurado com `nodePort.enabled` definido como `true`, conforme mostrado nos exemplos abaixo. Se você estiver usando o atributo de substituição de kube-proxy do Cilium, não precisará definir `nodePort.enabled` como `true`. + O Cilium deve ser configurado com `envoy.enabled` definido como `true`, conforme mostrado nos exemplos abaixo. + O Gateway do Cilium pode ser implantado no balanceador de carga (padrão) ou no modo de rede host. + Ao usar o Gateway do Cilium no modo balanceador de carga, a anotação `service.beta.kubernetes.io/aws-load-balancer-type: "external"` deve ser definida no recurso do Gateway para evitar que o provedor de, nuvem AWS herdado crie um Classic Load Balancer para o serviço do tipo LoadBalancer que o Cilium cria para o recurso do Gateway. + Ao usar o Gateway do Cilium no modo de rede do host, o serviço do tipo LoadBalancer é desabilitado. O modo de rede do host é útil para ambientes que não têm infraestrutura de balanceador de carga, consulte [Rede do host](#hybrid-nodes-ingress-cilium-host-network) para obter mais informações. ### Pré-requisitos 1. O Helm foi instalado em seu ambiente de linha de comando. Consulte as [Instruções de configuração do Helm](helm.md). 1. Cilium instalado seguindo as instruções em [Configurar a CNI para nós híbridos](hybrid-nodes-cni.md). ### Procedimento 1. Instale as definições de recursos personalizados (CRDs) da API do Gateway do Kubernetes. ``` kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/gateway-api/v1.2.1/config/crd/standard/gateway.networking.k8s.io_gatewayclasses.yaml kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/gateway-api/v1.2.1/config/crd/standard/gateway.networking.k8s.io_gateways.yaml kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/gateway-api/v1.2.1/config/crd/standard/gateway.networking.k8s.io_httproutes.yaml kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/gateway-api/v1.2.1/config/crd/standard/gateway.networking.k8s.io_referencegrants.yaml kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/gateway-api/v1.2.1/config/crd/standard/gateway.networking.k8s.io_grpcroutes.yaml ``` 1. Crie um arquivo chamado `cilium-gateway-values.yaml` com o conteúdo a seguir. O exemplo abaixo configura o Gateway do Cilium para usar o modo padrão do balanceador de carga e usar um DaemonSet `cilium-envoy` separado para proxies Envoy configurados para serem executados somente em nós híbridos. ``` gatewayAPI: enabled: true # uncomment to use host network mode # hostNetwork: # enabled: true nodePort: enabled: true envoy: enabled: true affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: eks.amazonaws.com/compute-type operator: In values: - hybrid ``` 1. Aplique o arquivo de valores do Helm ao seu cluster. ``` helm upgrade cilium oci://public.ecr.aws/eks/cilium/cilium \ --namespace kube-system \ --reuse-values \ --set operator.rollOutPods=true \ --values cilium-gateway-values.yaml ``` 1. Confirme se o operador, o atendente e os pods do Envoy do Cilium estão funcionando. ``` kubectl -n kube-system get pods --selector=app.kubernetes.io/part-of=cilium ``` ``` NAME READY STATUS RESTARTS AGE cilium-envoy-5pgnd 1/1 Running 0 6m31s cilium-envoy-6fhg4 1/1 Running 0 6m30s cilium-envoy-jskrk 1/1 Running 0 6m30s cilium-envoy-k2xtb 1/1 Running 0 6m31s cilium-envoy-w5s9j 1/1 Running 0 6m31s cilium-grwlc 1/1 Running 0 4m12s cilium-operator-68f7766967-5nnbl 1/1 Running 0 4m20s cilium-operator-68f7766967-7spfz 1/1 Running 0 4m20s cilium-pnxcv 1/1 Running 0 6m29s cilium-r7qkj 1/1 Running 0 4m12s cilium-wxhfn 1/1 Running 0 4m1s cilium-z7hlb 1/1 Running 0 6m30s ``` ## Configurar o Gateway do Cilium O Gateway do Cilium é habilitado em objetos do Gateway definindo `gatewayClassName` como `cilium`. O serviço que o Cilium cria para recursos do Gateway pode ser configurado com campos no objeto Gateway. As anotações comuns usadas pelos controladores do Gateway para configurar a infraestrutura do balanceador de carga podem ser configuradas com o campo `infrastructure` do objeto do Gateway. Ao usar o IPAM de LoadBalancer do Cilium (veja o exemplo em [Tipo de serviço LoadBalancer](#hybrid-nodes-ingress-cilium-loadbalancer)), o endereço IP a ser usado para o serviço do tipo LoadBalancer pode ser configurado no campo `addresses` do objeto do Gateway. Para obter mais informações sobre a configuração do Gateway, consulte a [especificação da API do Gateway do Kubernetes.](https://gateway-api.sigs.k8s.io/reference/spec/#gateway) ``` apiVersion: gateway.networking.k8s.io/v1 kind: Gateway metadata: name: my-gateway spec: gatewayClassName: cilium infrastructure: annotations: service.beta.kubernetes.io/... service.kuberentes.io/... addresses: - type: IPAddress value: listeners: ... ``` O Cilium e a especificação do Kubernetes Gateway oferecem suporte aos recursos GatewayClass, Gateway, HTTPRoute, GRPCRoute e ReferenceGrant. + Consulte as especificações [HTTPRoute](https://gateway-api.sigs.k8s.io/api-types/httproute/HTTPRoute) e [GRPCRoute](https://gateway-api.sigs.k8s.io/api-types/grpcroute/GRPCRoute) para ver a lista de campos disponíveis. + Veja os exemplos na seção [Implantar o Gateway do Cilium](#hybrid-nodes-ingress-cilium-gateway-deploy) abaixo e os exemplos na [documentação do Cilium](https://docs.cilium.io/en/stable/network/servicemesh/gateway-api/gateway-api/#examples) para saber como usar e configurar esses recursos. ## Implantar o Gateway do Cilium 1. Crie uma aplicação de exemplo. O exemplo abaixo usa a aplicação de microsserviços de amostra [Istio Bookinfo](https://istio.io/latest/docs/examples/bookinfo/). ``` kubectl apply -f https://raw.githubusercontent.com/istio/istio/refs/heads/master/samples/bookinfo/platform/kube/bookinfo.yaml ``` 1. Verifique se a aplicação está sendo executada com êxito. ``` kubectl get pods ``` ``` NAME READY STATUS RESTARTS AGE details-v1-766844796b-9965p 1/1 Running 0 81s productpage-v1-54bb874995-jmc8j 1/1 Running 0 80s ratings-v1-5dc79b6bcd-smzxz 1/1 Running 0 80s reviews-v1-598b896c9d-vj7gb 1/1 Running 0 80s reviews-v2-556d6457d-xbt8v 1/1 Running 0 80s reviews-v3-564544b4d6-cpmvq 1/1 Running 0 80s ``` 1. Crie um arquivo denominado `my-gateway.yaml` com os conteúdos a seguir. O exemplo abaixo usa a anotação `service.beta.kubernetes.io/aws-load-balancer-type: "external"` para impedir que o provedor de nuvem AWS herdado crie um Classic Load Balancer para o serviço do tipo LoadBalancer que o Cilium cria para o recurso do Gateway. ``` --- apiVersion: gateway.networking.k8s.io/v1 kind: Gateway metadata: name: my-gateway spec: gatewayClassName: cilium infrastructure: annotations: service.beta.kubernetes.io/aws-load-balancer-type: "external" listeners: - protocol: HTTP port: 80 name: web-gw allowedRoutes: namespaces: from: Same --- apiVersion: gateway.networking.k8s.io/v1 kind: HTTPRoute metadata: name: http-app-1 spec: parentRefs: - name: my-gateway namespace: default rules: - matches: - path: type: PathPrefix value: /details backendRefs: - name: details port: 9080 ``` 1. Aplique o recurso do Gateway ao seu cluster. ``` kubectl apply -f my-gateway.yaml ``` 1. Confirme se o recurso do Gateway e o serviço correspondente foram criados. Nesse estágio, espera-se que o campo `ADDRESS` do recurso do Gateway não seja preenchido com um endereço IP ou nome de host e que o serviço do tipo LoadBalancer para o recurso do Gateway também não tenha um endereço IP ou nome de host atribuído. ``` kubectl get gateway my-gateway ``` ``` NAME CLASS ADDRESS PROGRAMMED AGE my-gateway cilium True 10s ``` ``` kubectl get svc cilium-gateway-my-gateway ``` ``` NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE cilium-gateway-my-gateway LoadBalancer 172.16.227.247 80:30912/TCP 24s ``` 1. Continue para [Tipo de serviço LoadBalancer](#hybrid-nodes-ingress-cilium-loadbalancer) para configurar o recurso do Gateway para usar um endereço IP alocado pelo IPAM do balanceador de carga do Cilium, e [Tipo de serviço NodePort](#hybrid-nodes-ingress-cilium-nodeport) ou [Rede do host](#hybrid-nodes-ingress-cilium-host-network) para configurar o recurso do Gateway para usar endereços de rede NodePort ou host. ## Instale o Ingress do Cilium ### Considerações + O Cilium deve ser configurado com `nodePort.enabled` definido como `true`, conforme mostrado nos exemplos abaixo. Se você estiver usando o atributo de substituição de kube-proxy do Cilium, não precisará definir `nodePort.enabled` como `true`. + O Cilium deve ser configurado com `envoy.enabled` definido como `true`, conforme mostrado nos exemplos abaixo. + Com `ingressController.loadbalancerMode` definido como `dedicated`, o Cilium cria serviços dedicados para cada recurso do Ingress. Com `ingressController.loadbalancerMode` definido como `shared`, o Cilium cria um serviço compartilhado do tipo LoadBalancer para todos os recursos do Ingress no cluster. Ao usar o modo `shared` do balanceador de carga, as configurações do serviço compartilhado, como `labels`, `annotations`, `type` e `loadBalancerIP`, são definidas na seção `ingressController.service` dos valores do Helm. Consulte a [referência de valores Helm do Cilium](https://github.com/cilium/cilium/blob/v1.17.6/install/kubernetes/cilium/values.yaml#L887) para obter mais informações. + Com `ingressController.default` definido como `true`, o Cilium é configurado como o controlador de padrão do Ingress para o cluster e criará entradas do Ingress mesmo quando `ingressClassName` não estiver especificado nos recursos do Ingress. + O Ingress do Cilium pode ser implantado no balanceador de carga (padrão), na porta do nó ou no modo de rede host. Quando o Cilium é instalado no modo de rede host, os modos de serviço do tipo LoadBalancer e de serviço do tipo NodePort são desabilitados. Consulte [Rede do host](#hybrid-nodes-ingress-cilium-host-network) para obter mais informações. + Sempre defina `ingressController.service.annotations` como `service.beta.kubernetes.io/aws-load-balancer-type: "external"` nos valores do Helm para evitar que o provedor de nuvem AWS herdado crie um Classic Load Balancer para o serviço padrão `cilium-ingress` criado pelo [chart do Helm do Cilium](https://github.com/cilium/cilium/blob/main/install/kubernetes/cilium/templates/cilium-ingress-service.yaml). ### Pré-requisitos 1. O Helm foi instalado em seu ambiente de linha de comando. Consulte as [Instruções de configuração do Helm](helm.md). 1. Cilium instalado seguindo as instruções em [Configurar a CNI para nós híbridos](hybrid-nodes-cni.md). ### Procedimento 1. Crie um arquivo chamado `cilium-ingress-values.yaml` com o conteúdo a seguir. O exemplo abaixo configura o Ingress do Cilium para usar o modo `dedicated` do balanceador de carga padrão e usar um DaemonSet separado `cilium-envoy` para Envoy, proxies configurados para serem executados somente em nós híbridos. ``` ingressController: enabled: true loadbalancerMode: dedicated service: annotations: service.beta.kubernetes.io/aws-load-balancer-type: "external" nodePort: enabled: true envoy: enabled: true affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: eks.amazonaws.com/compute-type operator: In values: - hybrid ``` 1. Aplique o arquivo de valores do Helm ao seu cluster. ``` helm upgrade cilium oci://public.ecr.aws/eks/cilium/cilium \ --namespace kube-system \ --reuse-values \ --set operator.rollOutPods=true \ --values cilium-ingress-values.yaml ``` 1. Confirme se o operador, o atendente e os pods do Envoy do Cilium estão funcionando. ``` kubectl -n kube-system get pods --selector=app.kubernetes.io/part-of=cilium ``` ``` NAME READY STATUS RESTARTS AGE cilium-envoy-5pgnd 1/1 Running 0 6m31s cilium-envoy-6fhg4 1/1 Running 0 6m30s cilium-envoy-jskrk 1/1 Running 0 6m30s cilium-envoy-k2xtb 1/1 Running 0 6m31s cilium-envoy-w5s9j 1/1 Running 0 6m31s cilium-grwlc 1/1 Running 0 4m12s cilium-operator-68f7766967-5nnbl 1/1 Running 0 4m20s cilium-operator-68f7766967-7spfz 1/1 Running 0 4m20s cilium-pnxcv 1/1 Running 0 6m29s cilium-r7qkj 1/1 Running 0 4m12s cilium-wxhfn 1/1 Running 0 4m1s cilium-z7hlb 1/1 Running 0 6m30s ``` ## Configurar o Ingress do Cilium O Ingress do Cilium é habilitado em objetos do Ingress definindo `ingressClassName` como `cilium`. Os serviços que o Cilium cria para os recursos do Ingress podem ser configurados com anotações nos objetos do Ingress ao usar o modo `dedicated` do de balanceador de carga, assim como na configuração do Cilium ou Helm ao usar o modo `shared` do balanceador de carga. Essas anotações são comumente usadas pelos controladores do Ingress para configurar a infraestrutura do balanceador de carga ou outros atributos do serviço, como tipo de serviço, modo do balanceador de carga, portas e passagem TLS. As anotações principais são descritas abaixo. Para obter uma lista completa das anotações compatíveis, consulte as [Anotações do Ingress do Cilium](https://docs.cilium.io/en/stable/network/servicemesh/ingress/#supported-ingress-annotations) na documentação do Cilium. | Anotação | Descrição | | --- | --- | | `ingress.cilium.io/loadbalancer-mode` | `dedicated`: serviço dedicado do tipo LoadBalancer para cada recurso do Ingress (padrão). `shared`: serviço único do tipo LoadBalancer para todos os recursos do Ingress. | | `ingress.cilium.io/service-type` | `LoadBalancer`: o serviço será do tipo LoadBalancer (padrão) `NodePort`: o serviço será do tipo NodePort. | | `service.beta.kubernetes.io/aws-load-balancer-type` | `"external"`: evite que um provedor de nuvem da AWS antigo provisione o Classic Load Balancer para serviços do tipo LoadBalancer. | | `lbipam.cilium.io/ips` | Lista de endereços IP a serem alocados do Cilium LoadBalancer IPAM | O Cilium e a especificação Ingress do Kubernetes oferecem suporte a regras de correspondência exatas, prefixas e específicas de implementação para caminhos de entrada. O Cilium oferece suporte para regex como sua regra de correspondência específica para a implementação. Para obter mais informações, consulte [Tipos e precedência de caminhos de entrada](https://docs.cilium.io/en/stable/network/servicemesh/ingress/#ingress-path-types-and-precedence) e [Exemplos de tipos de caminhos](https://docs.cilium.io/en/stable/network/servicemesh/path-types/) na documentação do Cilium e os exemplos na seção [Implementar o Ingress do Cilium](#hybrid-nodes-ingress-cilium-ingress-deploy) desta página. Um exemplo de objeto do Ingress do Cilium é mostrado abaixo. ``` apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: my-ingress annotations: service.beta.kuberentes.io/... service.kuberentes.io/... spec: ingressClassName: cilium rules: ... ``` ## Implementar o Ingress do Cilium 1. Crie uma aplicação de exemplo. O exemplo abaixo usa a aplicação de microsserviços de amostra [Istio Bookinfo](https://istio.io/latest/docs/examples/bookinfo/). ``` kubectl apply -f https://raw.githubusercontent.com/istio/istio/refs/heads/master/samples/bookinfo/platform/kube/bookinfo.yaml ``` 1. Verifique se a aplicação está sendo executada com êxito. ``` kubectl get pods ``` ``` NAME READY STATUS RESTARTS AGE details-v1-766844796b-9965p 1/1 Running 0 81s productpage-v1-54bb874995-jmc8j 1/1 Running 0 80s ratings-v1-5dc79b6bcd-smzxz 1/1 Running 0 80s reviews-v1-598b896c9d-vj7gb 1/1 Running 0 80s reviews-v2-556d6457d-xbt8v 1/1 Running 0 80s reviews-v3-564544b4d6-cpmvq 1/1 Running 0 80s ``` 1. Crie um arquivo denominado `my-ingress.yaml` com os conteúdos a seguir. O exemplo abaixo usa a anotação `service.beta.kubernetes.io/aws-load-balancer-type: "external"` para impedir que o provedor de nuvem AWS herdado crie um Classic Load Balancer para o serviço do tipo LoadBalancer que o Cilium cria para o recurso do Ingress. ``` apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: my-ingress namespace: default annotations: service.beta.kubernetes.io/aws-load-balancer-type: "external" spec: ingressClassName: cilium rules: - http: paths: - backend: service: name: details port: number: 9080 path: /details pathType: Prefix ``` 1. Aplique o recurso do Ingress ao seu cluster. ``` kubectl apply -f my-ingress.yaml ``` 1. Confirme se o recurso de entrada e o serviço correspondente foram criados. Nesse estágio, espera-se que o campo `ADDRESS` do recurso do Ingress não seja preenchido com um endereço IP ou nome de host e que o serviço compartilhado ou dedicado do tipo LoadBalancer para o recurso do Ingress também não tenha um endereço IP ou nome de host atribuído. ``` kubectl get ingress my-ingress ``` ``` NAME CLASS HOSTS ADDRESS PORTS AGE my-ingress cilium * 80 8s ``` Para o modo `shared` do balanceador de carga ``` kubectl -n kube-system get svc cilium-ingress ``` ``` NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE cilium-ingress LoadBalancer 172.16.217.48 80:32359/TCP,443:31090/TCP 10m ``` Para o modo `dedicated` do balanceador de carga ``` kubectl -n default get svc cilium-ingress-my-ingress ``` ``` NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE cilium-ingress-my-ingress LoadBalancer 172.16.193.15 80:32088/TCP,443:30332/TCP 25s ``` 1. Continue para [Tipo de serviço LoadBalancer](#hybrid-nodes-ingress-cilium-loadbalancer) para configurar o recurso do Ingress para usar um endereço IP alocado pelo IPAM do balanceador de carga do Cilium, e [Tipo de serviço NodePort](#hybrid-nodes-ingress-cilium-nodeport) ou [Rede do host](#hybrid-nodes-ingress-cilium-host-network) para configurar o recurso do Ingress para usar endereços de rede NodePort ou host. ## Tipo de serviço LoadBalancer ### Infraestrutura de balanceador de carga existente Por padrão, tanto para o Ingress do Cilium quanto para o Gateway do Cilium, o Cilium cria serviços do Kubernetes do tipo LoadBalancer para os recursos do Ingress ou Gateway. Os atributos do(s) serviço(s) que o Cilium cria podem ser configurados por meio dos recursos do Ingress e do Gateway. Quando você cria recursos de Ingress ou Gateway, o endereço IP ou os nomes de host expostos externamente para o Ingress ou o Gateway são alocados da infraestrutura do balanceador de carga, que normalmente é provisionada por um controlador de Ingress ou Gateway. Muitos controladores Ingress e Gateway usam anotações para detectar e configurar a infraestrutura do balanceador de carga. As anotações desses controladores Ingress e Gateway são configuradas nos recursos do Ingress ou do Gateway, conforme mostrado nos exemplos anteriores acima. Consulte a documentação do controlador do Ingress ou do Gateway para ver as anotações compatíveis e consulte a [documentação do Ingress do Kubernetes](https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/) e a [documentação do Gateway do Kubernetes](https://gateway-api.sigs.k8s.io/implementations/) para ver uma lista dos controladores populares. **Importante** O Ingress e o Gateway do Cilium não podem ser usados com o AWS Load Balancer Controller e o AWS Network Load Balancers (NLBs) com o EKS Hybrid Nodes. A tentativa de usá-los juntos resulta em destinos não registrados, pois o NLB tenta se conectar diretamente aos IPs do pod que apoiam o serviço do tipo LoadBalancer quando o tipo `target-type` do NLB está definido como `ip` (requisito para usar o NLB com workloads em execução no EKS Hybrid Nodes). ### Não há Infraestrutura de balanceador de carga Se você não tiver uma infraestrutura de balanceador de carga e o controlador do Ingress ou Gateway correspondente em seu ambiente, os recursos do Ingress ou Gateway e os serviços correspondentes do tipo LoadBalancer podem ser configurados para usar endereços IP alocados pelo [gerenciamento de endereços IP do balanceador de carga](https://docs.cilium.io/en/stable/network/lb-ipam/) (LB IPAM) do Cilium. O IPAM de LB do Cilium pode ser configurado com intervalos de endereços IP conhecidos de seu ambiente on-premises e pode usar o suporte integrado ao Protocolo de Gateway da Borda (BGP) do Cilium ou anúncios L2 para anunciar os endereços IP do LoadBalancer em sua rede on-premises. O exemplo abaixo mostra como configurar o LB IPAM do Cilium com um endereço IP para usar em seus recursos do Ingress ou Gateway e como configurar o ambiente de gerenciamento BGP do Cilium para anunciar o endereço IP do LoadBalancer na rede on-premises. O atributo LB IPAM do Cilium está habilitado por padrão, mas não será habilitado até a criação de um recurso `CiliumLoadBalancerIPPool`. #### Pré-requisitos + Ingress do Cilium ou Gateway instalado seguindo as instruções em [Instale o Ingress do Cilium](#hybrid-nodes-ingress-cilium-ingress-install) ou [Instale o Gateway do Cilium](#hybrid-nodes-ingress-cilium-gateway-install). + Recursos do Ingress ou Gateway do Cilium com a aplicação de amostra implantada seguindo as instruções em [Implementar o Ingress do Cilium](#hybrid-nodes-ingress-cilium-ingress-deploy) ou [Implantar o Gateway do Cilium](#hybrid-nodes-ingress-cilium-gateway-deploy). + O ambiente de gerenciamento BGP do Cilium é habilitado seguindo as instruções em [Configurar o BGP do Cilium para nós híbridos](hybrid-nodes-cilium-bgp.md). Se você não quiser usar o BGP, poderá ignorar esse pré-requisito, mas não poderá acessar seu recurso de entrada ou gateway até que o endereço IP do LoadBalancer alocado pelo IPAM do Cilium LB seja roteável em sua rede on-premises. #### Procedimento 1. Opcionalmente, corrija o recurso do Ingress ou Gateway para solicitar um endereço IP específico para usar no serviço do tipo LoadBalancer. Se você não solicitar um endereço IP específico, o Cilium alocará um endereço IP do intervalo de endereços IP configurado no recurso `CiliumLoadBalancerIPPool` na etapa subsequente. Nos comandos abaixo, substitua `LB_IP_ADDRESS` pelo endereço IP para solicitar o serviço do tipo LoadBalancer. **Gateway** ``` kubectl patch gateway -n default my-gateway --type=merge -p '{ "spec": { "addresses": [{"type": "IPAddress", "value": "LB_IP_ADDRESS"}] } }' ``` **Ingress** ``` kubectl patch ingress my-ingress --type=merge -p '{ "metadata": {"annotations": {"lbipam.cilium.io/ips": "LB_IP_ADDRESS"}} }' ``` 1. Crie um arquivo chamado `cilium-lbip-pool-ingress.yaml` com um recurso `CiliumLoadBalancerIPPool` para configurar o intervalo de endereços IP do balanceador de carga para seus recursos do Ingress ou Gateway. + Se você estiver usando o Ingress do Cilium, o Cilium aplica automaticamente o rótulo `cilium.io/ingress: "true"` aos serviços que cria para os recursos do Ingress. Você pode usar esse rótulo no campo `serviceSelector` da definição do recurso `CiliumLoadBalancerIPPool` para selecionar os serviços elegíveis para o LB IPAM. + Se você estiver usando o Gateway do Cilium, poderá usar o rótulo `gateway.networking.k8s.io/gateway-name` nos campos `serviceSelector` da definição do recurso `CiliumLoadBalancerIPPool` para selecionar os recursos do Gateway elegíveis para o LB IPAM. + Substitua `LB_IP_CIDR` pelo intervalo de endereços IP a ser usado para os endereços IP do balanceador de carga. Para selecionar um único endereço IP, use um `/32` CIDR. Para obter mais informações, consulte [Gerenciamento de endereços IP do LoadBalancer](https://docs.cilium.io/en/stable/network/lb-ipam/) na documentação do Cilium. ``` apiVersion: cilium.io/v2alpha1 kind: CiliumLoadBalancerIPPool metadata: name: bookinfo-pool spec: blocks: - cidr: "LB_IP_CIDR" serviceSelector: # if using Cilium Gateway matchExpressions: - { key: gateway.networking.k8s.io/gateway-name, operator: In, values: [ my-gateway ] } # if using Cilium Ingress matchLabels: cilium.io/ingress: "true" ``` 1. Aplique o recurso `CiliumLoadBalancerIPPool` ao seu cluster. ``` kubectl apply -f cilium-lbip-pool-ingress.yaml ``` 1. Confirme se um endereço IP foi alocado por meio do LB IPAM do Colium para o recurso do Ingress ou Gateway. **Gateway** ``` kubectl get gateway my-gateway ``` ``` NAME CLASS ADDRESS PROGRAMMED AGE my-gateway cilium LB_IP_ADDRESS True 6m41s ``` **Ingress** ``` kubectl get ingress my-ingress ``` ``` NAME CLASS HOSTS ADDRESS PORTS AGE my-ingress cilium * LB_IP_ADDRESS 80 10m ``` 1. Crie um arquivo nomeado como `cilium-bgp-advertisement-ingress.yaml` com um recurso `CiliumBGPAdvertisement` para anunciar o endereço IP do LoadBalancer para os recursos do Ingress ou Gateway. Se você não estiver usando o Cilium BGP, poderá ignorar esta etapa. O endereço IP do LoadBalancer usado para seu recurso do Ingress ou Gateway deve ser roteável em sua rede on-premises para que você possa consultar o serviço na próxima etapa. ``` apiVersion: cilium.io/v2alpha1 kind: CiliumBGPAdvertisement metadata: name: bgp-advertisement-lb-ip labels: advertise: bgp spec: advertisements: - advertisementType: "Service" service: addresses: - LoadBalancerIP selector: # if using Cilium Gateway matchExpressions: - { key: gateway.networking.k8s.io/gateway-name, operator: In, values: [ my-gateway ] } # if using Cilium Ingress matchLabels: cilium.io/ingress: "true" ``` 1. Aplique o recurso `CiliumBGPAdvertisement` ao seu cluster. ``` kubectl apply -f cilium-bgp-advertisement-ingress.yaml ``` 1. Acesse o serviço usando o endereço IP alocado pelo Cilium LB IPAM. ``` curl -s http://LB_IP_ADDRESS:80/details/1 | jq ``` ``` { "id": 1, "author": "William Shakespeare", "year": 1595, "type": "paperback", "pages": 200, "publisher": "PublisherA", "language": "English", "ISBN-10": "1234567890", "ISBN-13": "123-1234567890" } ``` ## Tipo de serviço NodePort Se você não tiver infraestrutura de balanceador de carga e controlador de entrada correspondente em seu ambiente, ou se estiver autogerenciando sua infraestrutura de balanceador de carga ou usando balanceamento de carga baseado em DNS, você pode configurar o Ingress do Cilium para criar serviços do tipo NodePort para os recursos do Ingress. Ao usar o NodePort com o Ingress do Cilium, o serviço do tipo NodePort é exposto em uma porta em cada nó no intervalo de portas 30000-32767. Nesse modo, quando o tráfego chega a qualquer nó no cluster no NodePort, ele é encaminhado para um pod que faz o backup do serviço, que pode estar no mesmo nó ou em um nó diferente. **nota** O suporte do Gateway do Cilium para serviços NodePort está planejado para a versão 1.18.x ([\$127273](https://github.com/cilium/cilium/pull/27273)) ### Pré-requisitos + O Ingress do Cilium foi instalado seguindo as instruções em [Instale o Ingress do Cilium](#hybrid-nodes-ingress-cilium-ingress-install). + Recursos do Ingress do Cilium com aplicação de amostra implantada seguindo as instruções em [Implementar o Ingress do Cilium](#hybrid-nodes-ingress-cilium-ingress-deploy). ### Procedimento 1. Corrija o recurso do Ingress existente `my-ingress` para alterá-lo do tipo de serviço LoadBalancer para NodePort. ``` kubectl patch ingress my-ingress --type=merge -p '{ "metadata": {"annotations": {"ingress.cilium.io/service-type": "NodePort"}} }' ``` Se você não criou o recurso do Ingress, poderá fazê-lo aplicando a seguinte definição do Ingress ao seu cluster. Observe que a definição do Ingress abaixo usa a aplicação de amostra Istio Bookinfo descrita em [Implementar o Ingress do Cilium](#hybrid-nodes-ingress-cilium-ingress-deploy). ``` apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: my-ingress namespace: default annotations: service.beta.kubernetes.io/aws-load-balancer-type: "external" "ingress.cilium.io/service-type": "NodePort" spec: ingressClassName: cilium rules: - http: paths: - backend: service: name: details port: number: 9080 path: /details pathType: Prefix ``` 1. Confirme se o serviço do recurso do Ingress foi atualizado para usar o tipo de serviço NodePort. Observe a porta do protocolo HTTP na saída. No exemplo abaixo, essa porta HTTP é `32353`, que será usada em uma etapa subsequente para fazer uma consulta sobre o serviço. A vantagem de usar o Ingress do Cilium com serviço do tipo NodePort é que você pode aplicar roteamento baseado em caminho e host, bem como políticas de rede para o tráfego de entrada, o que você não pode fazer para um serviço padrão do tipo NodePort sem o Ingress. ``` kubectl -n default get svc cilium-ingress-my-ingress ``` ``` NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE cilium-ingress-my-ingress NodePort 172.16.47.153 80:32353/TCP,443:30253/TCP 27m ``` 1. Obtenha os endereços IP dos nós do seu cluster. ``` kubectl get nodes -o wide ``` ``` NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME mi-026d6a261e355fba7 Ready 23h v1.32.3-eks-473151a 10.80.146.150 Ubuntu 22.04.5 LTS 5.15.0-142-generic containerd://1.7.27 mi-082f73826a163626e Ready 23h v1.32.3-eks-473151a 10.80.146.32 Ubuntu 22.04.4 LTS 5.15.0-142-generic containerd://1.7.27 mi-09183e8a3d755abf6 Ready 23h v1.32.3-eks-473151a 10.80.146.33 Ubuntu 22.04.4 LTS 5.15.0-142-generic containerd://1.7.27 mi-0d78d815980ed202d Ready 23h v1.32.3-eks-473151a 10.80.146.97 Ubuntu 22.04.4 LTS 5.15.0-142-generic containerd://1.7.27 mi-0daa253999fe92daa Ready 23h v1.32.3-eks-473151a 10.80.146.100 Ubuntu 22.04.4 LTS 5.15.0-142-generic containerd://1.7.27 ``` 1. Acesse o serviço do tipo NodePort usando os endereços IP dos seus nós e o NodePort capturado acima. No exemplo abaixo, o endereço IP do nó usado é `10.80.146.32` e o NodePort é `32353`. Substitua-os pelos valores para o seu ambiente. ``` curl -s http://10.80.146.32:32353/details/1 | jq ``` ``` { "id": 1, "author": "William Shakespeare", "year": 1595, "type": "paperback", "pages": 200, "publisher": "PublisherA", "language": "English", "ISBN-10": "1234567890", "ISBN-13": "123-1234567890" } ``` ## Rede do host Semelhante ao serviço do tipo NodePort, se você não tiver uma infraestrutura de balanceador de carga e um controlador de entrada ou gateway, ou se estiver gerenciando automaticamente seu balanceamento de carga com um balanceador de carga externo, poderá configurar o Ingress do Cilium e o Gateway do Cilium para expor os recursos do Ingress e do Gateway diretamente na rede do host. Quando o modo de rede do host está habilitado para um recurso de entrada ou gateway, o serviço dos modos LoadBalancer e NodePort é automaticamente desabilitado. O modo de rede do host é mutuamente exclusivo com esses modos alternativos para cada recurso de entrada ou gateway. Comparado ao serviço do tipo NodePort, o modo de rede host oferece flexibilidade adicional para a variedade de portas que podem ser usadas (não está restrito ao intervalo 30000-32767 NodePort) e você pode configurar um subconjunto de nós em que os proxies Envoy são executados na rede do host. ### Pré-requisitos + Ingress do Cilium ou Gateway instalado seguindo as instruções em [Instale o Ingress do Cilium](#hybrid-nodes-ingress-cilium-ingress-install) ou [Instale o Gateway do Cilium](#hybrid-nodes-ingress-cilium-gateway-install). ### Procedimento #### Gateway 1. Crie um arquivo chamado `cilium-gateway-host-network.yaml` com o conteúdo a seguir. ``` gatewayAPI: enabled: true hostNetwork: enabled: true # uncomment to restrict nodes where Envoy proxies run on the host network # nodes: # matchLabels: # role: gateway ``` 1. Aplique a configuração do Gateway do Cilium de rede do host ao seu cluster. ``` helm upgrade cilium oci://public.ecr.aws/eks/cilium/cilium \ --namespace kube-system \ --reuse-values \ --set operator.rollOutPods=true \ -f cilium-gateway-host-network.yaml ``` Se você não criou o recurso do Gateway, pode criá-lo aplicando a seguinte definição de Gateway ao seu cluster. A definição de Gateway abaixo usa a aplicação de amostra Istio Bookinfo descrita em [Implantar o Gateway do Cilium](#hybrid-nodes-ingress-cilium-gateway-deploy). No exemplo abaixo, o recurso do Gateway está configurado para usar a porta `8111` do receptor HTTP, que é a porta compartilhada do receptor para os proxies Envoy em execução na rede do host. Se você estiver usando uma porta privilegiada (inferior a 1023) para o recurso do Gateway, consulte a [documentação do Cilium](https://docs.cilium.io/en/stable/network/servicemesh/gateway-api/gateway-api/#bind-to-privileged-port) para obter instruções. ``` --- apiVersion: gateway.networking.k8s.io/v1 kind: Gateway metadata: name: my-gateway spec: gatewayClassName: cilium listeners: - protocol: HTTP port: 8111 name: web-gw allowedRoutes: namespaces: from: Same --- apiVersion: gateway.networking.k8s.io/v1 kind: HTTPRoute metadata: name: http-app-1 spec: parentRefs: - name: my-gateway namespace: default rules: - matches: - path: type: PathPrefix value: /details backendRefs: - name: details port: 9080 ``` Você pode observar a configuração aplicada do Cilium Envoy com o comando a seguir. ``` kubectl get cec cilium-gateway-my-gateway -o yaml ``` Você pode obter a porta do receptor Envoy para o serviço `cilium-gateway-my-gateway` com o comando a seguir. Neste exemplo, a porta compartilhada do receptor é `8111`. ``` kubectl get cec cilium-gateway-my-gateway -o jsonpath={.spec.services[0].ports[0]} ``` 1. Obtenha os endereços IP dos nós do seu cluster. ``` kubectl get nodes -o wide ``` ``` NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME mi-026d6a261e355fba7 Ready 23h v1.32.3-eks-473151a 10.80.146.150 Ubuntu 22.04.5 LTS 5.15.0-142-generic containerd://1.7.27 mi-082f73826a163626e Ready 23h v1.32.3-eks-473151a 10.80.146.32 Ubuntu 22.04.4 LTS 5.15.0-142-generic containerd://1.7.27 mi-09183e8a3d755abf6 Ready 23h v1.32.3-eks-473151a 10.80.146.33 Ubuntu 22.04.4 LTS 5.15.0-142-generic containerd://1.7.27 mi-0d78d815980ed202d Ready 23h v1.32.3-eks-473151a 10.80.146.97 Ubuntu 22.04.4 LTS 5.15.0-142-generic containerd://1.7.27 mi-0daa253999fe92daa Ready 23h v1.32.3-eks-473151a 10.80.146.100 Ubuntu 22.04.4 LTS 5.15.0-142-generic containerd://1.7.27 ``` 1. Acesse o serviço usando os endereços IP dos seus nós e a porta do receptor do recurso `cilium-gateway-my-gateway`. No exemplo abaixo, o endereço IP do nó usado é `10.80.146.32` e a porta do receptor é `8111`. Substitua-os pelos valores para o seu ambiente. ``` curl -s http://10.80.146.32:8111/details/1 | jq ``` ``` { "id": 1, "author": "William Shakespeare", "year": 1595, "type": "paperback", "pages": 200, "publisher": "PublisherA", "language": "English", "ISBN-10": "1234567890", "ISBN-13": "123-1234567890" } ``` #### Ingress Devido a um problema de upstream do Cilium ([\$134028](https://github.com/cilium/cilium/issues/34028)), o Ingress do Cilium no modo de rede do host requer o uso de `loadbalancerMode: shared`, o que cria um único serviço do tipo ClusterIP para todos os recursos do Ingress no cluster. Se você estiver usando uma porta privilegiada (inferior a 1023) para o recurso do Ingress, consulte a [documentação do Cilium](https://docs.cilium.io/en/stable/network/servicemesh/ingress/#bind-to-privileged-port) para obter instruções. 1. Crie um arquivo chamado `cilium-ingress-host-network.yaml` com o conteúdo a seguir. ``` ingressController: enabled: true loadbalancerMode: shared # This is a workaround for the upstream Cilium issue service: externalTrafficPolicy: null type: ClusterIP hostNetwork: enabled: true # ensure the port does not conflict with other services on the node sharedListenerPort: 8111 # uncomment to restrict nodes where Envoy proxies run on the host network # nodes: # matchLabels: # role: ingress ``` 1. Aplique a configuração do Ingress do Cilium em modo de rede do host ao seu cluster. ``` helm upgrade cilium oci://public.ecr.aws/eks/cilium/cilium \ --namespace kube-system \ --reuse-values \ --set operator.rollOutPods=true \ -f cilium-ingress-host-network.yaml ``` Se você não criou o recurso do Ingress, poderá fazê-lo aplicando a seguinte definição do Ingress ao seu cluster. A definição do Ingress abaixo usa a aplicação de amostra Istio Bookinfo descrita em [Implementar o Ingress do Cilium](#hybrid-nodes-ingress-cilium-ingress-deploy). ``` apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: my-ingress namespace: default spec: ingressClassName: cilium rules: - http: paths: - backend: service: name: details port: number: 9080 path: /details pathType: Prefix ``` Você pode observar a configuração aplicada do Cilium Envoy com o comando a seguir. ``` kubectl get cec -n kube-system cilium-ingress -o yaml ``` Você pode obter a porta do receptor Envoy para o serviço `cilium-ingress` com o comando a seguir. Neste exemplo, a porta compartilhada do receptor é `8111`. ``` kubectl get cec -n kube-system cilium-ingress -o jsonpath={.spec.services[0].ports[0]} ``` 1. Obtenha os endereços IP dos nós do seu cluster. ``` kubectl get nodes -o wide ``` ``` NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME mi-026d6a261e355fba7 Ready 23h v1.32.3-eks-473151a 10.80.146.150 Ubuntu 22.04.5 LTS 5.15.0-142-generic containerd://1.7.27 mi-082f73826a163626e Ready 23h v1.32.3-eks-473151a 10.80.146.32 Ubuntu 22.04.4 LTS 5.15.0-142-generic containerd://1.7.27 mi-09183e8a3d755abf6 Ready 23h v1.32.3-eks-473151a 10.80.146.33 Ubuntu 22.04.4 LTS 5.15.0-142-generic containerd://1.7.27 mi-0d78d815980ed202d Ready 23h v1.32.3-eks-473151a 10.80.146.97 Ubuntu 22.04.4 LTS 5.15.0-142-generic containerd://1.7.27 mi-0daa253999fe92daa Ready 23h v1.32.3-eks-473151a 10.80.146.100 Ubuntu 22.04.4 LTS 5.15.0-142-generic containerd://1.7.27 ``` 1. Acesse o serviço usando os endereços IP dos seus nós e a `sharedListenerPort` para o recurso `cilium-ingress`. No exemplo abaixo, o endereço IP do nó usado é `10.80.146.32` e a porta do receptor é `8111`. Substitua-os pelos valores para o seu ambiente. ``` curl -s http://10.80.146.32:8111/details/1 | jq ``` ``` { "id": 1, "author": "William Shakespeare", "year": 1595, "type": "paperback", "pages": 200, "publisher": "PublisherA", "language": "English", "ISBN-10": "1234567890", "ISBN-13": "123-1234567890" } ``` # Configurar serviços do tipo LoadBalancer para nós híbridos Configurar os serviços LoadBalancer Este tópico descreve como configurar o balanceamento de carga de camada 4 (L4) para aplicações executadas no Amazon EKS Hybrid Nodes. Os serviços Kubernetes do tipo LoadBalancer são usados para expor aplicações do Kubernetes externos ao cluster. Serviços do tipo LoadBalancer são comumente usados com a infraestrutura física do balanceador de carga na nuvem ou no ambiente on-premises para atender ao tráfego da workload. Essa infraestrutura de balanceador de carga geralmente é provisionada com um controlador específico do ambiente. A AWS oferece suporte para o AWS Network Load Balancer (NLB) e o Cilium para serviços do tipo LoadBalancer em execução no EKS Hybrid Nodes. A decisão de usar o NLB ou o Cilium é baseada na origem do tráfego da aplicação. Se o tráfego da aplicação for originário de uma região da AWS, a AWS recomenda usar o AWS NLB e o AWS Load Balancer Controller. Se o tráfego da aplicação for originado do ambiente on-premises ou de borda, a AWS recomenda usar os recursos de balanceamento de carga integrados do Cilium, que podem ser usados com ou sem a infraestrutura de balanceador de carga em seu ambiente. Para balanceamento de carga de tráfego de aplicações de camada 7 (L7), consulte [Configurar o Ingress do Kubernetes para nós híbridos](hybrid-nodes-ingress.md). Para obter informações gerais sobre balanceamento de carga com EKS, consulte [Melhores práticas para balanceamento de carga](https://docs.aws.amazon.com/eks/latest/best-practices/load-balancing.html). ## AWS Network Load Balancer Você pode usar o [AWS Load Balancer Controller](aws-load-balancer-controller.md) e o NLB com o tipo de destino `ip` para workloads executadas em nós híbridos. Ao usar o tipo de destino `ip`, o NLB encaminha o tráfego diretamente para os pods, ignorando o caminho de rede da camada de serviço. Para que o NLB alcance as metas de IP do pod em nós híbridos, os CIDRs de pods on-premises deverão ser roteáveis em sua rede on-premises roteáveis em sua rede on-premises roteáveis. Além disso, o AWS Load Balancer Controller usa webhooks e requer comunicação direta do ambiente de gerenciamento EKS. Para obter mais informações, consulte [Configurar webhooks para nós híbridos](hybrid-nodes-webhooks.md). + Consulte [Roteamento de tráfego TCP e UDP com Network Load Balancers](network-load-balancing.md) os requisitos de configuração de sub-rede, [Instale o AWS Load Balancer Controller com o Helm](lbc-helm.md) e as [melhores práticas para balanceamento de carga](https://docs.aws.amazon.com/eks/latest/best-practices/load-balancing.html) para obter informações adicionais sobre o AWS Network Load Balancer e o AWS Load Balancer Controller. + Consulte [Configurações de NLB do AWS Load Balancer Controller](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/service/nlb/) para ver as configurações que podem ser aplicadas a serviços do tipo `LoadBalancer` com o AWS Network Load Balancer. ### Pré-requisitos + Cilium instalado seguindo as instruções em [Configurar a CNI para nós híbridos](hybrid-nodes-cni.md). + O ambiente de gerenciamento BGP do Cilium é habilitado seguindo as instruções em [Configurar o BGP do Cilium para nós híbridos](hybrid-nodes-cilium-bgp.md). Se não quiser usar o BGP, você deverá usar um método alternativo para tornar seus CIDRs de pods on-premises roteáveis em sua rede on-premises. Consulte [CIDRs de pods remotos roteáveis](hybrid-nodes-concepts-kubernetes.md#hybrid-nodes-concepts-k8s-pod-cidrs) para obter mais informações. + O Helm foi instalado em seu ambiente de linha de comando. Consulte as [Instruções de configuração do Helm](helm.md). + O eksctl foi instalado em seu ambiente de linha de comando. Consulte as [Instruções de configuração do eksctl](install-kubectl.md#eksctl-install-update). ### Procedimento 1. Baixe uma política do IAM para o AWS Load Balancer Controller que permita que ele faça chamadas para APIs da AWS em seu nome. ``` curl -O https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/refs/heads/main/docs/install/iam_policy.json ``` 1. Crie uma política do IAM usando a política obtida por download na etapa anterior. ``` aws iam create-policy \ --policy-name AWSLoadBalancerControllerIAMPolicy \ --policy-document file://iam_policy.json ``` 1. Substitua os valores do nome do cluster (`CLUSTER_NAME`), região da AWS (`AWS_REGION`) e ID da conta da AWS (`AWS_ACCOUNT_ID`) pelas suas configurações e execute o comando a seguir. ``` eksctl create iamserviceaccount \ --cluster=CLUSTER_NAME \ --namespace=kube-system \ --name=aws-load-balancer-controller \ --attach-policy-arn=arn:aws:iam::AWS_ACCOUNT_ID:policy/AWSLoadBalancerControllerIAMPolicy \ --override-existing-serviceaccounts \ --region AWS_REGION \ --approve ``` 1. Adicione o repositório de chart do Helm eks-charts. A AWS mantém esse repositório no GitHub. ``` helm repo add eks https://aws.github.io/eks-charts ``` 1. Atualize o repositório local do Helm para confirmar que você tem os gráficos mais recentes. ``` helm repo update eks ``` 1. Instale o AWS Load Balancer Controller. Substitua os valores do nome do cluster (`CLUSTER_NAME`), região da AWS (`AWS_REGION`), ID da VPC (`VPC_ID`) e a versão do chart do Helm do AWS Load Balancer Controller (`AWS_LBC_HELM_VERSION`) pelas suas configurações. Você pode encontrar a versão mais recente do chart do Helm executando `helm search repo eks/aws-load-balancer-controller --versions`. Se você estiver executando um cluster em modo misto com nós híbridos e nós na Nuvem AWS, você pode executar o AWS Load Balancer Controller nos nós da nuvem seguindo as instruções em [AWS Load Balancer Controller](hybrid-nodes-webhooks.md#hybrid-nodes-mixed-lbc). ``` helm install aws-load-balancer-controller eks/aws-load-balancer-controller \ -n kube-system \ --version AWS_LBC_HELM_VERSION \ --set clusterName=CLUSTER_NAME \ --set region=AWS_REGION \ --set vpcId=VPC_ID \ --set serviceAccount.create=false \ --set serviceAccount.name=aws-load-balancer-controller ``` 1. Verifique se o AWS Load Balancer Controller foi instalado com êxito. ``` kubectl get -n kube-system deployment aws-load-balancer-controller ``` ``` NAME READY UP-TO-DATE AVAILABLE AGE aws-load-balancer-controller 2/2 2 2 84s ``` 1. Defina uma aplicação de amostra em um arquivo chamado `tcp-sample-app.yaml`. O exemplo abaixo usa uma implantação simples do NGINX com uma porta TCP. ``` apiVersion: apps/v1 kind: Deployment metadata: name: tcp-sample-app namespace: default spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: public.ecr.aws/nginx/nginx:1.23 ports: - name: tcp containerPort: 80 ``` 1. Aplique a implantação ao seu cluster. ``` kubectl apply -f tcp-sample-app.yaml ``` 1. Defina um serviço do tipo LoadBalancer para a implantação em um arquivo chamado `tcp-sample-service.yaml`. ``` apiVersion: v1 kind: Service metadata: name: tcp-sample-service namespace: default annotations: service.beta.kubernetes.io/aws-load-balancer-type: external service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: ip service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing spec: ports: - port: 80 targetPort: 80 protocol: TCP type: LoadBalancer selector: app: nginx ``` 1. Aplicar a configuração do serviço ao seu cluster. ``` kubectl apply -f tcp-sample-service.yaml ``` 1. O provisionamento do NLB para o serviço pode levar alguns minutos. Depois que o NLB for provisionado, o serviço terá um endereço atribuído a ele que corresponde ao nome DNS da implantação do NLB. ``` kubectl get svc tcp-sample-service ``` ``` NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE tcp-sample-service LoadBalancer 172.16.115.212 k8s-default-tcpsampl-xxxxxxxxxx-xxxxxxxxxxxxxxxx.elb..amazonaws.com 80:30396/TCP 8s ``` 1. Acesse o serviço usando o endereço do NLB. ``` curl k8s-default-tcpsampl-xxxxxxxxxx-xxxxxxxxxxxxxxxx.elb..amazonaws.com ``` Um exemplo de saída está abaixo. ``` Welcome to nginx! [...] ``` 1. Limpe os recursos que você criou. ``` kubectl delete -f tcp-sample-service.yaml kubectl delete -f tcp-sample-app.yaml ``` ## Balanceamento de carga no cluster do Cilium O Cilium pode ser usado como um balanceador de carga no cluster para workloads em execução no EKS Hybrid Nodes, o que pode ser útil para ambientes que não têm infraestrutura de balanceador de carga. Os recursos de balanceamento de carga do Cilium são baseados em uma combinação de atributos do Cilium, incluindo a substituição do kube-proxy, o Gerenciador de endereços IP (IPAM) do balanceador de carga e o ambiente de gerenciamento BGP. As responsabilidades desses atributos estão detalhadas abaixo: + **Substituição do Cilium kube-proxy**: manipula o tráfego do serviço de roteamento para pods de backend. + **IPAM do Cilium Load Balancer**: gerencia endereços IP que podem ser atribuídos a serviços do tipo `LoadBalancer`. + **Ambiente de gerenciamento do Cilium BGP**: anuncia endereços IP alocados para IPAM do balanceador de carga para a rede on-premises. Se você não estiver usando o substituto kube-proxy do Cilium, ainda poderá usar o IPAM do balanceador de carga do Cilium e o ambiente de gerenciamento do BGP para alocar e atribuir endereços IP para serviços do tipo LoadBalancer. Se você não estiver usando o substituto kube-proxy do Cilium, o balanceamento de carga dos serviços para pods de backend é feito pelas regras kube-proxy e iptables por padrão no EKS. ### Pré-requisitos + O Cilium foi instalado seguindo as instruções [Configurar a CNI para nós híbridos](hybrid-nodes-cni.md) com ou sem a substituição do kube-proxy ativada. A substituição do kube-proxy do Cilium requer a execução de um sistema operacional com um kernel Linux pelo menos tão recente quanto v4.19.57, v5.1.16 ou v5.2.0. Todas as versões recentes dos sistemas operacionais compatíveis para uso com nós híbridos atendem a esses critérios, com exceção do Red Hat Enterprise Linux (RHEL) 8.x. + O ambiente de gerenciamento BGP do Cilium é habilitado seguindo as instruções em [Configurar o BGP do Cilium para nós híbridos](hybrid-nodes-cilium-bgp.md). Se não quiser usar o BGP, você deverá usar um método alternativo para tornar seus CIDRs de pods on-premises roteáveis em sua rede on-premises. Consulte [CIDRs de pods remotos roteáveis](hybrid-nodes-concepts-kubernetes.md#hybrid-nodes-concepts-k8s-pod-cidrs) para obter mais informações. + O Helm foi instalado em seu ambiente de linha de comando. Consulte as [Instruções de configuração do Helm](helm.md). ### Procedimento 1. Crie um arquivo chamado `cilium-lbip-pool-loadbalancer.yaml` com um recurso `CiliumLoadBalancerIPPool` para configurar o intervalo de endereços IP do balanceador de carga para seus serviços do tipo LoadBalancer. + Substitua `LB_IP_CIDR` pelo intervalo de endereços IP a ser usado para os endereços IP do balanceador de carga. Para selecionar um único endereço IP, use um `/32` CIDR. Para obter mais informações, consulte [Gerenciamento de endereços IP do LoadBalancer](https://docs.cilium.io/en/stable/network/lb-ipam/) na documentação do Cilium. + O campo `serviceSelector` está configurado para corresponder ao nome do serviço que você criará em uma etapa subsequente. Com essa configuração, os IPs desse pool serão alocados somente aos serviços com o nome `tcp-sample-service`. ``` apiVersion: cilium.io/v2alpha1 kind: CiliumLoadBalancerIPPool metadata: name: tcp-service-pool spec: blocks: - cidr: "LB_IP_CIDR" serviceSelector: matchLabels: io.kubernetes.service.name: tcp-sample-service ``` 1. Aplique o recurso `CiliumLoadBalancerIPPool` ao seu cluster. ``` kubectl apply -f cilium-lbip-pool-loadbalancer.yaml ``` 1. Confirme se há pelo menos um endereço IP disponível no pool. ``` kubectl get ciliumloadbalancerippools.cilium.io ``` ``` NAME DISABLED CONFLICTING IPS AVAILABLE AGE tcp-service-pool false False 1 24m ``` 1. Crie um arquivo `cilium-bgp-advertisement-loadbalancer.yaml` com o nome de um recurso `CiliumBGPAdvertisement` para anunciar o endereço IP do balanceador de carga para o serviço que você criará na próxima etapa. Se você não estiver usando o Cilium BGP, poderá ignorar esta etapa. O endereço IP do balanceador de carga usado para seu serviço deve ser roteável em sua rede on-premises para que você possa consultar o serviço na etapa final. + O campo `advertisementType` está definido como `Service` e `service.addresses` está definido como `LoadBalancerIP` para anunciar somente o `LoadBalancerIP` para serviços do tipo `LoadBalancer`. + O campo `selector` está configurado para corresponder ao nome do serviço que você criará em uma etapa subsequente. Com essa configuração, somente o `LoadBalancerIP` para os serviços com o nome `tcp-sample-service` serão anunciados. ``` apiVersion: cilium.io/v2alpha1 kind: CiliumBGPAdvertisement metadata: name: bgp-advertisement-tcp-service labels: advertise: bgp spec: advertisements: - advertisementType: "Service" service: addresses: - LoadBalancerIP selector: matchLabels: io.kubernetes.service.name: tcp-sample-service ``` 1. Aplique o recurso `CiliumBGPAdvertisement` ao seu cluster. Se você não estiver usando o Cilium BGP, poderá ignorar esta etapa. ``` kubectl apply -f cilium-bgp-advertisement-loadbalancer.yaml ``` 1. Defina uma aplicação de amostra em um arquivo chamado `tcp-sample-app.yaml`. O exemplo abaixo usa uma implantação simples do NGINX com uma porta TCP. ``` apiVersion: apps/v1 kind: Deployment metadata: name: tcp-sample-app namespace: default spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: public.ecr.aws/nginx/nginx:1.23 ports: - name: tcp containerPort: 80 ``` 1. Aplique a implantação ao seu cluster. ``` kubectl apply -f tcp-sample-app.yaml ``` 1. Defina um serviço do tipo LoadBalancer para a implantação em um arquivo chamado `tcp-sample-service.yaml`. + Você pode solicitar um endereço IP específico do pool IP do balanceador de carga com a anotação `lbipam.cilium.io/ips` no objeto do serviço. Você pode remover essa anotação se não quiser solicitar um endereço IP específico para o serviço. + O campo de especificação `loadBalancerClass` é obrigatório para evitar que o provedor de Nuvem AWS herdado crie um Classic Load Balancer para o serviço. No exemplo abaixo, isso está configurado `io.cilium/bgp-control-plane` para usar o ambiente de gerenciamento BGP do Cilium como a classe do balanceador de carga. Como alternativa, esse campo pode ser configurado para que `io.cilium/l2-announcer` use o [atributo L2 Announcements do Cilium](https://docs.cilium.io/en/latest/network/l2-announcements/) (atualmente em versão beta e não compatível com a AWS). ``` apiVersion: v1 kind: Service metadata: name: tcp-sample-service namespace: default annotations: lbipam.cilium.io/ips: "LB_IP_ADDRESS" spec: loadBalancerClass: io.cilium/bgp-control-plane ports: - port: 80 targetPort: 80 protocol: TCP type: LoadBalancer selector: app: nginx ``` 1. Aplique o serviço ao seu cluster. O serviço será criado com um endereço IP externo que você poderá usar para acessar a aplicação. ``` kubectl apply -f tcp-sample-service.yaml ``` 1. Verifique se o serviço foi criado com sucesso e tem um IP atribuído a ele a partir do `CiliumLoadBalancerIPPool` criado na etapa anterior. ``` kubectl get svc tcp-sample-service ``` ``` NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE tcp-sample-service LoadBalancer 172.16.117.76 LB_IP_ADDRESS 80:31129/TCP 14m ``` 1. Se você estiver usando o Cilium no modo de substituição do kube-proxy, você pode confirmar que o Cilium está lidando com o balanceamento de carga do serviço executando o comando a seguir. Na saída abaixo, os endereços `10.86.2.x` são os endereços IP dos pods de backend para o serviço. ``` kubectl -n kube-system exec ds/cilium -- cilium-dbg service list ``` ``` ID Frontend Service Type Backend ... 41 LB_IP_ADDRESS:80/TCP LoadBalancer 1 => 10.86.2.76:80/TCP (active) 2 => 10.86.2.130:80/TCP (active) 3 => 10.86.2.141:80/TCP (active) ``` 1. Confirme se o Cilium está anunciando o endereço IP para a rede on-premises via BGP. No exemplo abaixo, há cinco nós híbridos, cada um anunciando o `LB_IP_ADDRESS` para o serviço de `tcp-sample-service` na rede on-premises. ``` Node VRouter Prefix NextHop Age Attrs mi-026d6a261e355fba7 NODES_ASN LB_IP_ADDRESS/32 0.0.0.0 12m3s [{Origin: i} {Nexthop: 0.0.0.0}] mi-082f73826a163626e NODES_ASN LB_IP_ADDRESS/32 0.0.0.0 12m3s [{Origin: i} {Nexthop: 0.0.0.0}] mi-09183e8a3d755abf6 NODES_ASN LB_IP_ADDRESS/32 0.0.0.0 12m3s [{Origin: i} {Nexthop: 0.0.0.0}] mi-0d78d815980ed202d NODES_ASN LB_IP_ADDRESS/32 0.0.0.0 12m3s [{Origin: i} {Nexthop: 0.0.0.0}] mi-0daa253999fe92daa NODES_ASN LB_IP_ADDRESS/32 0.0.0.0 12m3s [{Origin: i} {Nexthop: 0.0.0.0}] ``` 1. Acesse o serviço usando o endereço IP do balanceador de carga atribuído. ``` curl LB_IP_ADDRESS ``` Um exemplo de saída está abaixo. ``` Welcome to nginx! [...] ``` 1. Limpe os recursos que você criou. ``` kubectl delete -f tcp-sample-service.yaml kubectl delete -f tcp-sample-app.yaml kubectl delete -f cilium-lb-ip-pool.yaml kubectl delete -f cilium-bgp-advertisement.yaml ``` # Configurar políticas de rede do Kubernetes para nós híbridos Configurar políticas de rede A AWS oferece suporte para políticas de rede do Kubernetes (camada 3/camada 4) para tráfego de entrada e saída de pod ao usar o Cilium como a CNI com o EKS Hybrid Nodes. Se você estiver executando clusters EKS com nós na Nuvem AWS, a AWS oferece suporte às [políticas de rede CNI da Amazon VPC para Kubernetes](cni-network-policy.md). Este tópico aborda como configurar as políticas de rede do Cilium e do Kubernetes com o EKS Hybrid Nodes. Para obter informações detalhadas sobre as políticas de rede do Kubernetes, consulte Políticas de rede do [Kubernetes na documentação do Kubernetes.](https://kubernetes.io/docs/concepts/services-networking/network-policies/) ## Configure as políticas de rede ### Considerações + A AWS oferece suporte para as políticas de rede upstream do Kubernetes e a especificação para entrada e saída de pods. No momento, a AWS não oferce suporte para `CiliumNetworkPolicy` ou `CiliumClusterwideNetworkPolicy`. + O valor `policyEnforcementMode` do Helm pode ser usado para controlar o comportamento padrão de aplicação da política do Cilium. O comportamento padrão permite todo o tráfego de entrada e saída. Quando um endpoint é selecionado por uma política de rede, ele passa para um estado de negação padrão, em que somente o tráfego explicitamente permitido é permitido. Consulte a documentação do Cilium para obter mais informações sobre o modo de [política padrão e os modos de [aplicação de políticas](https://docs.cilium.io/en/stable/security/policy/intro/#policy-enforcement-modes).](https://docs.cilium.io/en/stable/security/policy/intro/#policy-mode-default) + Caso esteja mudando `policyEnforcementMode` para uma instalação existente do Cilium, você deverá reiniciar o DaemonSet do atendente do Cilium para aplicar o novo modo de imposição de políticas. + Use `namespaceSelector` e `podSelector` para permitir ou negar tráfego de/para namespaces e pods com rótulos correspondentes. O `namespaceSelector` e `podSelector` podem ser usados com `matchLabels` ou `matchExpressions` para selecionar namespaces e pods com base em seus rótulos. + Use `ingress.ports` e `egress.ports` para permitir ou negar tráfego de/para portas e protocolos. + O campo `ipBlock` não pode ser usado para permitir ou negar seletivamente o tráfego de/para endereços IP do pod ([\$19209](https://github.com/cilium/cilium/issues/9209)). O uso de seletores `ipBlock` para IPs de nós é um atributo beta do Cilium e não é compatível com a AWS. + Consulte o [recurso NetworkPolicy](https://kubernetes.io/docs/concepts/services-networking/network-policies/#networkpolicy-resource) na documentação do Kubernetes para obter informações sobre os campos disponíveis para as políticas de rede do Kubernetes. ### Pré-requisitos + Cilium instalado seguindo as instruções em [Configurar a CNI para nós híbridos](hybrid-nodes-cni.md). + O Helm foi instalado em seu ambiente de linha de comando. Consulte as [Instruções de configuração do Helm](helm.md). ### Procedimento O procedimento a seguir configura políticas de rede para uma aplicação de microsserviços de exemplo, de forma que os componentes só possam se comunicar com outros componentes necessários para o funcionamento da aplicação. O procedimento usa a aplicação de microsserviços de amostra [Istio Bookinfo](https://istio.io/latest/docs/examples/bookinfo/). A aplicação Bookinfo consiste em quatro microsserviços separados com os seguintes relacionamentos: + **productpage**. O microsserviço productpage chama os microsserviços de detalhes e resenhas para preencher a página. + **detalhes**. O microsserviço de detalhes contém informações sobre o livro. + **análises**. O microsserviço de resenhas contém resenhas de livros. Também chama o microsserviço de classificações. + **classificações**. O microsserviço de classificações contém informações de classificação de livros que acompanham uma resenha de livro. 1. Crie as aplicações de exemplo. ``` kubectl apply -f https://raw.githubusercontent.com/istio/istio/refs/heads/master/samples/bookinfo/platform/kube/bookinfo.yaml ``` 1. Confirme se a aplicação estiver sendo executado com êxito e anote o endereço IP do pod do microsserviço productpage. Você usará esse endereço IP do pod para fazer uma consulta sobre cada microsserviço nas etapas subsequentes. ``` kubectl get pods -o wide ``` ``` NAME READY STATUS RESTARTS AGE IP NODE details-v1-766844796b-9wff2 1/1 Running 0 7s 10.86.3.7 mi-0daa253999fe92daa productpage-v1-54bb874995-lwfgg 1/1 Running 0 7s 10.86.2.193 mi-082f73826a163626e ratings-v1-5dc79b6bcd-59njm 1/1 Running 0 7s 10.86.2.232 mi-082f73826a163626e reviews-v1-598b896c9d-p2289 1/1 Running 0 7s 10.86.2.47 mi-026d6a261e355fba7 reviews-v2-556d6457d-djktc 1/1 Running 0 7s 10.86.3.58 mi-0daa253999fe92daa reviews-v3-564544b4d6-g8hh4 1/1 Running 0 7s 10.86.2.69 mi-09183e8a3d755abf6 ``` 1. Crie um pod que será usado para testar as políticas de rede. Observe que o pod é criado no namespace `default` com o rótulo `access: true`. ``` kubectl run curl-pod --image=curlimages/curl -i --tty --labels=access=true --namespace=default --overrides='{"spec": { "nodeSelector": {"eks.amazonaws.com/compute-type": "hybrid"}}}' -- /bin/sh ``` 1. Teste o acesso ao microsserviço productpage. No exemplo abaixo, usamos o endereço IP do pod productpage (`10.86.2.193`) para consultar o microsserviço. Substitua isso pelo endereço IP do pod de productpage em seu ambiente. ``` curl -s http://10.86.2.193:9080/productpage | grep -o ".*" ``` ``` Simple Bookstore App ``` 1. Você pode sair do pod test curl digitando `exit` e reconectar-se ao pod executando o seguinte comando. ``` kubectl attach curl-pod -c curl-pod -i -t ``` 1. Para demonstrar os efeitos das políticas de rede nas etapas a seguir, primeiro criamos uma política de rede que nega todo o tráfego dos microsserviços da BookInfo. Crie um arquivo chamado `network-policy-deny-bookinfo.yaml` que defina a política de negação de rede. ``` apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: deny-bookinfo namespace: default spec: podSelector: matchExpressions: - key: app operator: In values: ["productpage", "details", "reviews", "ratings"] policyTypes: - Ingress - Egress ``` 1. Aplique a política de negação de rede ao seu cluster. ``` kubectl apply -f network-policy-default-deny-bookinfo.yaml ``` 1. Teste o acesso à aplicação BookInfo. No exemplo abaixo, usamos o endereço IP do pod productpage (`10.86.2.193`) para consultar o microsserviço. Substitua isso pelo endereço IP do pod de productpage em seu ambiente. ``` curl http://10.86.2.193:9080/productpage --max-time 10 ``` ``` curl: (28) Connection timed out after 10001 milliseconds ``` 1. Crie um arquivo chamado `network-policy-productpage.yaml` que defina a política de rede de productpage. A política estabelece as seguintes regras: + permite o tráfego de entrada de pods com o rótulo `access: true` (o pod curl criado na etapa anterior) + permite o tráfego TCP de saída na porta `9080` para os microsserviços de detalhes, avaliações e classificações + permite o tráfego TCP/UDP de saída na porta `53` para o CoreDNS, que é executado no namespace `kube-system` ``` apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: productpage-policy namespace: default spec: podSelector: matchLabels: app: productpage policyTypes: - Ingress - Egress ingress: - from: - podSelector: matchLabels: access: "true" egress: - to: - podSelector: matchExpressions: - key: app operator: In values: ["details", "reviews", "ratings"] ports: - port: 9080 protocol: TCP - to: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: kube-system podSelector: matchLabels: k8s-app: kube-dns ports: - port: 53 protocol: UDP - port: 53 protocol: TCP ``` 1. Aplique a política de rede do productpage ao seu cluster. ``` kubectl apply -f network-policy-productpage.yaml ``` 1. Conecte-se ao pod curl e teste o acesso à aplicação Bookinfo. O acesso ao microsserviço productpage agora é permitido, mas os outros microsserviços ainda estão negados porque ainda estão sujeitos à política de rede de negação. Nos exemplos abaixo, usamos o endereço IP do pod de productpage (`10.86.2.193`) para consultar o microsserviço. Substitua isso pelo endereço IP do pod de productpage em seu ambiente. ``` kubectl attach curl-pod -c curl-pod -i -t ``` ``` curl -s http://10.86.2.193:9080/productpage | grep -o ".*" Simple Bookstore App ``` ``` curl -s http://10.86.2.193:9080/api/v1/products/1 {"error": "Sorry, product details are currently unavailable for this book."} ``` ``` curl -s http://10.86.2.193:9080/api/v1/products/1/reviews {"error": "Sorry, product reviews are currently unavailable for this book."} ``` ``` curl -s http://10.86.2.193:9080/api/v1/products/1/ratings {"error": "Sorry, product ratings are currently unavailable for this book."} ``` 1. Crie um arquivo chamado `network-policy-details.yaml` que defina os detalhes da política de rede. A política permite somente o tráfego de entrada do microsserviço productpage. ``` apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: details-policy namespace: default spec: podSelector: matchLabels: app: details policyTypes: - Ingress ingress: - from: - podSelector: matchLabels: app: productpage ``` 1. Crie um arquivo chamado `network-policy-reviews.yaml` que defina a política de rede de avaliações. A política permite somente o tráfego de entrada do microsserviço productpage e somente o tráfego de saída para o microsserviço de classificações e o CoreDNS. ``` apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: reviews-policy namespace: default spec: podSelector: matchLabels: app: reviews policyTypes: - Ingress - Egress ingress: - from: - podSelector: matchLabels: app: productpage egress: - to: - podSelector: matchLabels: app: ratings - to: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: kube-system podSelector: matchLabels: k8s-app: kube-dns ports: - port: 53 protocol: UDP - port: 53 protocol: TCP ``` 1. Crie um arquivo chamado `network-policy-ratings.yaml` que defina a política de rede de classificações. A política permite somente o tráfego de entrada dos microsserviços productpage e avaliações. ``` apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: ratings-policy namespace: default spec: podSelector: matchLabels: app: ratings policyTypes: - Ingress ingress: - from: - podSelector: matchExpressions: - key: app operator: In values: ["productpage", "reviews"] ``` 1. Aplique as políticas de rede de detalhes, avaliações e classificações ao seu cluster. ``` kubectl apply -f network-policy-details.yaml kubectl apply -f network-policy-reviews.yaml kubectl apply -f network-policy-ratings.yaml ``` 1. Conecte-se ao pod curl e teste o acesso à aplicação Bookinfo. Nos exemplos abaixo, usamos o endereço IP do pod de productpage (`10.86.2.193`) para consultar o microsserviço. Substitua isso pelo endereço IP do pod de productpage em seu ambiente. ``` kubectl attach curl-pod -c curl-pod -i -t ``` Teste o microsserviço de detalhes. ``` curl -s http://10.86.2.193:9080/api/v1/products/1 ``` ``` {"id": 1, "author": "William Shakespeare", "year": 1595, "type": "paperback", "pages": 200, "publisher": "PublisherA", "language": "English", "ISBN-10": "1234567890", "ISBN-13": "123-1234567890"} ``` Teste o microsserviço de avaliações. ``` curl -s http://10.86.2.193:9080/api/v1/products/1/reviews ``` ``` {"id": "1", "podname": "reviews-v1-598b896c9d-p2289", "clustername": "null", "reviews": [{"reviewer": "Reviewer1", "text": "An extremely entertaining play by Shakespeare. The slapstick humour is refreshing!"}, {"reviewer": "Reviewer2", "text": "Absolutely fun and entertaining. The play lacks thematic depth when compared to other plays by Shakespeare."}]} ``` Teste o microsserviço de classificações. ``` curl -s http://10.86.2.193:9080/api/v1/products/1/ratings ``` ``` {"id": 1, "ratings": {"Reviewer1": 5, "Reviewer2": 4}} ``` 1. Limpe os recursos que você criou nesse processo. ``` kubectl delete -f network-policy-deny-bookinfo.yaml kubectl delete -f network-policy-productpage.yaml kubectl delete -f network-policy-details.yaml kubectl delete -f network-policy-reviews.yaml kubectl delete -f network-policy-ratings.yaml kubectl delete -f https://raw.githubusercontent.com/istio/istio/refs/heads/master/samples/bookinfo/platform/kube/bookinfo.yaml kubectl delete pod curl-pod ``` # Conceitos de nós híbridos Como funciona Com o *Amazon EKS Hybrid Nodes*, você une máquinas físicas ou virtuais em execução em ambientes on-premises ou de borda aos clusters do Amazon EKS executados na Nuvem AWS. Essa abordagem traz muitos benefícios, mas também introduz novos conceitos e arquiteturas de rede para aqueles que estão familiarizados com a execução de clusters do Kubernetes em um único ambiente de rede. As seções a seguir se aprofundam nos conceitos do Kubernetes e de rede para o EKS Hybrid Nodes e detalham como o tráfego flui pela arquitetura híbrida. Essas seções exigem que você esteja familiarizado com o conhecimento básico de rede do Kubernetes, como os conceitos de pods, nós, serviços, ambiente de gerenciamento do Kubernetes, kubelet e kube-proxy. Recomendamos a leitura dessas páginas em ordem, começando com [Conceitos de rede para nós híbridos](hybrid-nodes-concepts-networking.md), depois [Conceitos do Kubernetes para nós híbridos](hybrid-nodes-concepts-kubernetes.md) e, finalmente, [Fluxos de tráfego de rede para nós híbridos](hybrid-nodes-concepts-traffic-flows.md). **Topics** + [ # Conceitos de rede para nós híbridos ](hybrid-nodes-concepts-networking.md) + [ # Conceitos do Kubernetes para nós híbridos ](hybrid-nodes-concepts-kubernetes.md) + [ # Fluxos de tráfego de rede para nós híbridos ](hybrid-nodes-concepts-traffic-flows.md) # Conceitos de rede para nós híbridos Conceitos de rede Esta seção detalha os principais conceitos de rede e as restrições que você deve considerar ao projetar sua topologia de rede para o EKS Hybrid Nodes. ## Conceitos de rede para o EKS Hybrid Nodes ![\[Diagrama de rede de nós híbridos de alto nível\]](http://docs.aws.amazon.com/pt_br/eks/latest/userguide/images/hybrid-nodes-highlevel-network.png) **VPC como o hub de rede** Todo o tráfego que cruza os limites da nuvem passa pela sua VPC. Isso inclui o tráfego entre o ambiente de gerenciamento do EKS ou os pods em execução na AWS e os nós híbridos ou os pods em execução neles. Você pode considerar a VPC do cluster como o hub de rede entre os nós híbridos e o restante do cluster. Essa arquitetura oferece controle total do tráfego e de seu roteamento, mas também faz com que você seja responsável por configurar corretamente rotas, grupos de segurança e firewalls para a VPC. **Ambiente de gerenciamento do EKS para a VPC** O ambiente de gerenciamento do EKS anexa **interfaces de rede elástica (ENIs)** à VPC. Essas ENIs processam o tráfego de e para o servidor de API do EKS. Você controla o posicionamento das ENIs do ambiente de gerenciamento do EKS ao configurar o cluster, pois o EKS anexa ENIs às sub-redes que você passa durante a criação do cluster. O EKS associa grupos de segurança às ENIs que o EKS anexa às sub-redes. Esses grupos de segurança permitem o tráfego de e para o ambiente de gerenciamento do EKS por meio das ENIs. Isso é importante para o EKS Hybrid Nodes porque você deve permitir o tráfego dos nós híbridos e dos pods executados nele para as ENIs do ambiente de gerenciamento do EKS. **Redes de nós remotos** As redes de nós remotos, especificamente os CIDRs de nós remotos, são os intervalos de IPs atribuídos às máquinas que você usa como nós híbridos. Quando você provisiona nós híbridos, eles residem em seu data center on-premises ou local da borda, que é um domínio de rede diferente do ambiente de gerenciamento do EKS e da VPC. Cada nó híbrido tem um endereço IP, ou endereços, de um CIDR de nó remoto que é distinto das sub-redes na VPC. Você configura o cluster do EKS com esses CIDRs de nós remotos para que o EKS saiba rotear todo o tráfego destinado aos IPs dos nós híbridos por meio da VPC do cluster, como solicitações para a API do kubelet. As conexões com a API do `kubelet` são usadas nos comandos `kubectl attach`, `kubectl cp`, `kubectl exec`, `kubectl logs` e `kubectl port-forward`. **Redes de pods remotos** As redes de pods remotos são os intervalos de IPs atribuídos aos pods em execução nos nós híbridos. Geralmente, você configura a CNI com esses intervalos, e a funcionalidade de gerenciamento de endereços IP (IPAM) da CNI se encarrega de atribuir uma fatia desses intervalos a cada nó híbrido. Quando você cria um pod, a CNI atribui um IP ao pod da fatia alocada para o nó em que o pod foi programado. Você configura o cluster do EKS com esses CIDRs de pods remotos para que o ambiente de gerenciamento do EKS saiba rotear todo o tráfego destinado aos pods em execução nos nós híbridos por meio da VPC do cluster, como a comunicação com webhooks. ![\[Redes de pods remotos\]](http://docs.aws.amazon.com/pt_br/eks/latest/userguide/images/hybrid-nodes-remote-pod-cidrs.png) **On-premises para a VPC** A rede on-premises que você usa para nós híbridos deve ser roteada para a VPC que você usa para o cluster do EKS. Há várias [opções de conectividade de rede para a Amazon VPC](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/network-to-amazon-vpc-connectivity-options.html) disponíveis para conectar a rede on-premises a uma VPC. Você também pode usar sua própria solução de VPN. É importante que você configure o roteamento corretamente no lado da Nuvem AWS na VPC e na rede on-premises para que ambas as redes roteiem o tráfego certo por meio da conexão das duas redes. Na VPC, todo o tráfego que vai para o nó remoto e para as redes de pods remotos deve ser roteado pela conexão com a rede on-premises (denominada “gateway”). Se algumas das sub-redes tiverem tabelas de rotas diferentes, você deverá configurar cada tabela de rotas com as rotas dos nós híbridos e os pods em execução neles. Isso vale para as sub-redes às quais as ENIs do ambiente de gerenciamento do EKS estão anexadas e para as sub-redes que contêm nós ou pods do EC2 que precisam se comunicar com nós híbridos. Na rede on-premises, você deve configurar a rede para permitir tráfego de e para a VPC do cluster do EKS e os outros serviços da AWS necessários para nós híbridos. O tráfego do cluster do EKS atravessa o gateway em ambas as direções. ## Restrições de rede **Rede totalmente roteada** A principal restrição é que o ambiente de gerenciamento do EKS e todos os nós, da nuvem ou híbridos, precisam formar uma rede **totalmente roteada**. Isso significa que todos os nós devem ser capazes de acessar uns aos outros na camada três, por endereço IP. O ambiente de gerenciamento do EKS e os nós da nuvem já podem ser acessados uns nos outros porque estão em uma rede simples (a VPC). Os nós híbridos, no entanto, estão em outro domínio de rede. É por isso que você precisa configurar um roteamento adicional na VPC e na rede on-premises para rotear o tráfego entre os nós híbridos e o restante do cluster. Se os nós híbridos puderem ser acessados entre si e pela VPC, os nós híbridos poderão estar em uma única rede simples ou em várias redes segmentadas. **CIDRs de pods remotos roteáveis** Para que o ambiente de gerenciamento do EKS se comunique com os pods executados em nós híbridos (por exemplo, webhooks ou o servidor de métricas), ou para que os pods executados em nós da nuvem se comuniquem com pods executados nos nós híbridos (comunicação leste-oeste de workload), o CIDR de pod remoto deve ser roteável da VPC. Isso significa que a VPC deve ser capaz de rotear o tráfego para os CIDRs de pods por meio do gateway para sua rede on-premises, e que a rede on-premises deve ser capaz de rotear o tráfego de um pod para o nó correto. É importante observar a distinção entre os requisitos de roteamento de pods na VPC e on-premises. A VPC só precisa saber que qualquer tráfego que vá para um pod remoto deve passar pelo gateway. Caso tenha apenas um CIDR de pod remoto, você precisará de apenas uma rota. Esse requisito é válido para todos os saltos na rede on-premises até o roteador local na mesma sub-rede dos nós híbridos. Esse é o único roteador que precisa estar ciente da fatia do CIDR do pod atribuída a cada nó, garantindo que o tráfego de um determinado pod seja entregue ao nó em que o pod foi programado. Você pode optar por propagar essas rotas para os CIDRs de pods on-premises do seu roteador local para as tabelas de rotas da VPC, mas isso não é necessário. Se seus CIDRs de pods on-premises mudarem com frequência e suas tabelas de rotas da VPC precisarem ser atualizadas para refletir os CIDRs de pods em mudança, recomendamos que você propague os CIDRs de pods on-premises para as tabelas de rotas de VPC, mas isso é incomum. Observe que a restrição para tornar seus CIDRs de pods on-premises roteáveis é opcional. Caso você não precise executar webhooks nos nós híbridos ou fazer com que os pods em nós da nuvem se comuniquem com os pods nos nós híbridos, não será necessário configurar o roteamento para os CIDRs de pods na rede on-premises. *Por que os CIDRs de pods on-premises precisam ser roteáveis com nós híbridos?* Ao usar o EKS com a CNI da VPC para os nós da nuvem, a CNI da VPC atribui IPs diretamente da VPC aos pods. Isso significa que não há necessidade de nenhum roteamento especial, pois tanto os pods da nuvem quanto o ambiente de gerenciamento do EKS podem acessar diretamente os IPs dos pods. Ao serem executados on-premises (e com outras CNIs na nuvem), os pods normalmente são executados em uma rede de sobreposição isolada, e a CNI se encarrega de fornecer tráfego entre os pods. Isso geralmente é feito por meio do encapsulamento: a CNI converte o tráfego pod-to-pod em tráfego node-to-node, cuidando do encapsulamento e do desencapsulamento em ambas as extremidades. Dessa forma, não há necessidade de configuração extra nos nós e nos roteadores. A rede com nós híbridos é exclusiva porque apresenta uma combinação de ambas as topologias: o ambiente de gerenciamento do EKS e os nós da nuvem (com a CNI da VPC) esperam uma rede simples incluindo nós e pods, enquanto os pods executados em nós híbridos estão em uma rede de sobreposição usando VXLAN para encapsulamento (por padrão, no Cilium). Os pods executados em nós híbridos podem acessar o ambiente de gerenciamento do EKS e os pods executados em nós da nuvem, supondo que a rede on-premises possa ser roteada para a VPC. No entanto, sem o roteamento dos CIDRs de pods na rede on-premises, qualquer tráfego que retorne para um IP de pod on-premises será, por fim, descartado se a rede não souber como acessar a rede de sobreposição e como rotear para os nós corretos. # Conceitos do Kubernetes para nós híbridos Conceitos do Kubernetes Esta página detalha os principais conceitos do Kubernetes que fundamentam a arquitetura do sistema do EKS Hybrid Nodes. ## Ambiente de gerenciamento do EKS na VPC Os IPs das ENIs do ambiente de gerenciamento do EKS são armazenados no objeto de `Endpoints` do `kubernetes` no namespace `default`. Quando o EKS cria novas ENIs ou remove as mais antigas, o EKS atualiza esse objeto para que a lista de IPs esteja sempre atualizada. Você pode usar esses endpoints por meio do serviço do `kubernetes`, e também no namespace `default`. Esse serviço, do tipo `ClusterIP`, sempre tem atribuído o primeiro IP do CIDR de serviço do cluster. Por exemplo, para o CIDR do serviço `172.16.0.0/16`, o IP do serviço será `172.16.0.1`. Geralmente, é assim que os pods (independentemente de serem executados na nuvem ou em nós híbridos) acessam o servidor de API do Kubernetes para EKS. Os pods usam o IP do serviço como o IP de destino, que é convertido para os IPs reais de uma das ENIs do ambiente de gerenciamento do EKS. A principal exceção é o `kube-proxy`, pois ele configura a conversão. ## Endpoint do servidor de API do EKS O IP do serviço do `kubernetes` não é a única maneira de acessar o servidor de API do EKS. O EKS também criará um nome DNS do Route 53 quando você criar o cluster. Este é o campo do `endpoint` do seu cluster do EKS ao chamar a ação da API `DescribeCluster` do EKS. ``` { "cluster": { "endpoint": "https://xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.gr7.us-west-2.eks.amazonaws.com", "name": "my-cluster", "status": "ACTIVE" } } ``` Em um acesso ao endpoint público ou em um cluster de acesso ao endpoint público e privado, seus nós híbridos resolverão esse nome DNS para um IP público por padrão, roteável pela internet. Em um cluster de acesso de endpoint privado, o nome DNS é resolvido para os IPs privados das ENIs do ambiente de gerenciamento do EKS. É assim que o `kubelet` e o `kube-proxy` acessam o servidor de API do Kubernetes. Se você quiser que todo o tráfego do cluster do Kubernetes flua pela VPC, você precisa configurar o cluster no modo de acesso privado ou modificar o servidor DNS on-premises para resolver o endpoint do cluster do EKS para os IPs privados das ENIs do ambiente de gerenciamento do EKS. ## Endpoint do `kubelet` O `kubelet` expõe vários endpoints REST, permitindo que outras partes do sistema interajam e coletem informações de cada nó. Na maioria dos clusters, a maior parte do tráfego para o servidor do `kubelet` vem do ambiente de gerenciamento, mas determinados agentes de monitoramento também podem interagir com ele. Por meio dessa interface, o `kubelet` processa várias solicitações: busca de logs (`kubectl logs`), execução de comandos dentro de contêineres (`kubectl exec`) e tráfego de encaminhamento de portas (`kubectl port-forward`). Cada uma dessas solicitações interage com o runtime do contêiner subjacente por meio do `kubelet`, parecendo perfeita para administradores e desenvolvedores de clusters. O consumidor mais comum dessa API é o servidor de API do Kubernetes. Quando você usa qualquer um dos comandos do `kubectl` mencionados anteriormente, o `kubectl` faz uma solicitação de API ao servidor de API, que então chama a API do `kubelet` do nó em que o pod está sendo executado. Este é o principal motivo pelo qual o IP do nó precisa estar acessível no ambiente de gerenciamento do EKS e por que, mesmo que seus pods estejam em execução, você não conseguirá acessar seus logs ou `exec` se a rota do nó estiver configurada incorretamente. **IPs de nós** Quando o ambiente de gerenciamento do EKS se comunica com um nó, ele usa um dos endereços informados no status do objeto do `Node` (`status.addresses`). Com os nós de nuvem do EKS, é comum que o kubelet informe o IP privado da instância do EC2 como um `InternalIP` durante o registro do nó. Esse IP é então validado pelo Cloud Controller Manager (CCM), certificando-se de que ele pertença à instância do EC2. Além disso, o CCM normalmente adiciona os IPs públicos (como `ExternalIP`) e os nomes DNS (`InternalDNS` e `ExternalDNS`) da instância ao status do nó. No entanto, não há um CCM para nós híbridos. Quando você registra um nó híbrido com a CLI do EKS Hybrid Nodes (`nodeadm`), ele configura o kubelet para informar o IP da máquina diretamente no status do nó, sem o CCM. ``` apiVersion: v1 kind: Node metadata: name: my-node-1 spec: providerID: eks-hybrid:///us-west-2/my-cluster/my-node-1 status: addresses: - address: 10.1.1.236 type: InternalIP - address: my-node-1 type: Hostname ``` Caso a máquina tenha vários IPs, o kubelet selecionará um deles seguindo sua própria lógica. Você pode controlar o IP selecionado com o sinalizador `--node-ip`, que pode ser passado no config `nodeadm` em `spec.kubelet.flags`. Somente o IP informado no objeto do `Node` precisa de uma rota da VPC. As máquinas podem ter outros IPs que não podem ser acessados pela nuvem. ## `kube-proxy` O `kube-proxy` é responsável por implementar a abstração do serviço na camada de rede de cada nó. Ele atua como um proxy de rede e um balanceador de carga para o tráfego destinado aos serviços do Kubernetes. Ao observar continuamente o servidor de API do Kubernetes em busca de alterações relacionadas a serviços e endpoints, o `kube-proxy` atualiza dinamicamente as regras de rede do host subjacente para garantir que o tráfego seja direcionado adequadamente. No modo `iptables`, o `kube-proxy` programa várias cadeias de `netfilter` para processar o tráfego do serviço. As regras formam a seguinte hierarquia: 1. **Cadeia KUBE-SERVICES**: o ponto de entrada para todo o tráfego de serviços. Ele tem regras que correspondem a cada porta e `ClusterIP` do serviço. 1. **Cadeias KUBE-SVC-XXX**: cadeias específicas de serviços que têm regras de balanceamento de carga para cada serviço. 1. **Cadeias KUBE-SEP-XXX**: cadeias específicas de endpoints que têm as regras reais de `DNAT`. Vamos examinar o que acontece com um serviço de `test-server` no namespace `default`: \$1 ClusterIP do serviço: `172.16.31.14` \$1 Porta de serviço: `80` \$1 Pods de backup: `10.2.0.110`, `10.2.1.39` e `10.2.2.254` Quando inspecionamos as regras de `iptables` (usando `iptables-save –0— grep -A10 KUBE-SERVICES`): 1. Na cadeia **KUBE-SERVICES**, encontramos uma regra correspondente ao serviço: ``` -A KUBE-SERVICES -d 172.16.31.14/32 -p tcp -m comment --comment "default/test-server cluster IP" -m tcp --dport 80 -j KUBE-SVC-XYZABC123456 ``` + Essa regra corresponde aos pacotes destinados a 172.16.31.14:80 + O comentário indica para que serve essa regra: `default/test-server cluster IP` + Pacotes correspondentes vão para a cadeia `KUBE-SVC-XYZABC123456` 1. A cadeia **KUBE-SVC-XYZABC123456** tem regras de balanceamento de carga baseadas em probabilidade: ``` -A KUBE-SVC-XYZABC123456 -m statistic --mode random --probability 0.33333333349 -j KUBE-SEP-POD1XYZABC -A KUBE-SVC-XYZABC123456 -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-POD2XYZABC -A KUBE-SVC-XYZABC123456 -j KUBE-SEP-POD3XYZABC ``` + Primeira regra: 33,3% de chance de ir para `KUBE-SEP-POD1XYZABC` + Segunda regra: 50% de chance de o tráfego restante (33,3% do total) ir para `KUBE-SEP-POD2XYZABC` + Última regra: todo o tráfego restante (33,3% do total) vai para `KUBE-SEP-POD3XYZABC` 1. As cadeias **KUBE-SEP-XXX** individuais executam o DNAT (NAT de destino): ``` -A KUBE-SEP-POD1XYZABC -p tcp -m tcp -j DNAT --to-destination 10.2.0.110:80 -A KUBE-SEP-POD2XYZABC -p tcp -m tcp -j DNAT --to-destination 10.2.1.39:80 -A KUBE-SEP-POD3XYZABC -p tcp -m tcp -j DNAT --to-destination 10.2.2.254:80 ``` + Essas regras de DNAT regravam o IP e a porta de destino para direcionar o tráfego para pods específicos. + Cada regra processa cerca de 33,3% do tráfego, fornecendo um balanceamento de carga uniforme entre `10.2.0.110`, `10.2.1.39` e `10.2.2.254`. Essa estrutura de cadeia de vários níveis permite que o `kube-proxy` implemente com eficiência o balanceamento e o redirecionamento da carga de serviço por meio da manipulação de pacotes no nível do kernel, sem exigir um processo de proxy no caminho dos dados. ### Impacto nas operações do Kubernetes Uma falha no `kube-proxy` em um nó impede que esse nó roteie o tráfego do serviço adequadamente, causando tempos limite ou falhas nas conexões dos pods que dependem dos serviços do cluster. Isso pode ser especialmente disruptivo quando um nó é registrado pela primeira vez. A CNI precisa se comunicar com o servidor de API do Kubernetes para obter informações, como o CIDR do pod do nó, antes de poder configurar qualquer rede de pods. Para fazer isso, ela usa o IP do serviço do `kubernetes`. No entanto, se o `kube-proxy` não pôde iniciar ou não conseguiu definir as regras corretas de `iptables`, as solicitações que irão para o IP do serviço do `kubernetes` não serão convertidas para os IPs reais das ENIs do ambiente de gerenciamento do EKS. Como consequência, a CNI entrará em um loop de falha e nenhum dos pods será executado corretamente. Sabemos que os pods usam o IP do serviço do `kubernetes` para se comunicar com o servidor de API do Kubernetes, mas o `kube-proxy` precisa primeiro definir as regras de `iptables` para que isso funcione. Como o `kube-proxy` se comunica com o servidor de API? O `kube-proxy` deve ser configurado para usar os IPs reais do servidor de API do Kubernetes ou um nome DNS que os determine. No caso do EKS, ele configura o `kube-proxy` padrão para apontar para o nome DNS do Route 53 que o EKS cria quando você cria o cluster. Você pode ver esse valor no ConfigMap do `kube-proxy` no namespace do `kube-system`. O conteúdo desse ConfigMap é um `kubeconfig` que é injetado no pod do `kube-proxy`, portanto, localize o campo `clusters–0—.cluster.server`. Esse valor corresponderá ao campo do `endpoint` do cluster do EKS (ao chamar a API `DescribeCluster` do EKS). ``` apiVersion: v1 data: kubeconfig: |- kind: Config apiVersion: v1 clusters: - cluster: certificate-authority: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt server: https://xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.gr7.us-west-2.eks.amazonaws.com name: default contexts: - context: cluster: default namespace: default user: default name: default current-context: default users: - name: default user: tokenFile: /var/run/secrets/kubernetes.io/serviceaccount/token kind: ConfigMap metadata: name: kube-proxy namespace: kube-system ``` ## CIDRs de pods remotos roteáveis A página [Conceitos de rede para nós híbridos](hybrid-nodes-concepts-networking.md) detalha os requisitos para executar webhooks em nós híbridos ou para que os pods executados em nós de nuvem se comuniquem com os pods executados em nós híbridos. O principal requisito é que o roteador on-premises precisa saber qual nó é responsável por um determinado IP de pod. Há várias maneiras de fazer isso, incluindo o Protocolo de Gateway da Borda (BGP), rotas estáticas e o proxy Address Resolution Protocol (ARP). Essas formas são abordadas nas próximas seções. **Protocolo de Gateway da Borda (BGP)** Se a CNI for compatível (como Cilium e Calico), você poderá usar o modo BGP da CNI para propagar rotas para os CIDRs de pods por nó dos nós para o roteador local. Ao usar o modo BGP da CNI, a CNI atua como um roteador virtual, então o roteador local acha que o CIDR do pod pertence a outra sub-rede e seu nó é o gateway para essa sub-rede. ![\[Roteamento BGP para nós híbridos\]](http://docs.aws.amazon.com/pt_br/eks/latest/userguide/images/hybrid-nodes-bgp.png) **Rotas estáticas** Como alternativa, é possível configurar rotas estáticas no roteador local. Esta é a maneira mais simples de rotear o CIDR do pod on-premises para a VPC, mas também é a mais propensa a erros e difícil de manter. Você precisa garantir que as rotas estejam sempre atualizadas com os nós existentes e seus CIDRs de pods atribuídos. Se o número de nós for pequeno e a infraestrutura for estática, esta é uma opção viável e elimina a necessidade de suporte do BGP em seu roteador. Se você optar por isso, recomendamos configurar a CNI com a parcela do CIDR do pod que você deseja atribuir a cada nó, em vez de deixar que o IPAM decida. ![\[Roteamento estático para nós híbridos\]](http://docs.aws.amazon.com/pt_br/eks/latest/userguide/images/hybrid-nodes-static-routes.png) **Proxy Address Resolution Protocol (ARP)** O proxy ARP é outra abordagem para tornar os IPs de pods on-premises roteáveis, particularmente útil quando os nós híbridos estão na mesma rede de camada 2 do roteador local. Com o proxy ARP habilitado, um nó responde às solicitações de ARP dos IPs de pods que ele hospeda, mesmo que esses IPs pertençam a outra sub-rede. Quando um dispositivo em sua rede local tenta acessar um IP de pod, ele primeiro envia uma solicitação ao ARP perguntando: “quem tem este IP?”. O nó híbrido que hospeda esse pod responderá com seu próprio endereço MAC, dizendo: “eu posso processar o tráfego desse IP”. Isso cria um caminho direto entre os dispositivos na rede local e os pods sem precisar da configuração do roteador. Para que isso funcione, a CNI deve ser compatível com a funcionalidade do proxy ARP. O Cilium tem suporte integrado para o proxy ARP que você pode habilitar por meio da configuração. A principal consideração é que o CIDR do pod não deve se sobrepor a nenhuma outra rede em seu ambiente, pois isso pode causar conflitos de roteamento. Essa abordagem traz diversas vantagens: \$1 Não é necessário configurar o roteador com BGP ou manter rotas estáticas \$1 Funciona bem em ambientes em que você não tem controle sobre a configuração do roteador ![\[Proxy ARP para nós híbridos\]](http://docs.aws.amazon.com/pt_br/eks/latest/userguide/images/hybrid-nodes-arp-proxy.png) ## Encapsulamento pod-to-pod Em ambientes on-premises, as CNIs normalmente usam protocolos de encapsulamento para criar redes de sobreposição que possam operar na rede física sem a necessidade de reconfigurá-la. Esta seção explica como esse encapsulamento funciona. Observe que alguns dos detalhes podem variar dependendo da CNI que você está usando. O encapsulamento compacta os pacotes de rede do pod original dentro de outro pacote de rede que pode ser roteado pela rede física subjacente. Isso permite que os pods se comuniquem entre os nós que executam a mesma CNI sem exigir que a rede física saiba como rotear esses CIDRs de pod. O protocolo de encapsulamento mais comum usado com o Kubernetes é o Virtual Extensible LAN (VXLAN), embora outros (como o `Geneve`) também estejam disponíveis, dependendo da sua CNI. ### Encapsulamento VXLAN O VXLAN encapsula os quadros do Layer 2 Ethernet em pacotes do UDP. Quando um pod envia tráfego para outro pod em um nó diferente, a CNI faz o seguinte: 1. A CNI intercepta pacotes do pod A 1. A CNI compacta o pacote original em um cabeçalho VXLAN 1. Esse pacote compactado é então enviado pela pilha de rede regular do nó para o nó de destino 1. A CNI no nó de destino descompacta o pacote e o entrega ao pod B Verifique o que acontece com a estrutura do pacote durante o encapsulamento VXLAN: Pacote original de pod-to-pod: ``` +-----------------+---------------+-------------+-----------------+ | Ethernet Header | IP Header | TCP/UDP | Payload | | Src: Pod A MAC | Src: Pod A IP | Src Port | | | Dst: Pod B MAC | Dst: Pod B IP | Dst Port | | +-----------------+---------------+-------------+-----------------+ ``` Após o encapsulamento VXLAN: ``` +-----------------+-------------+--------------+------------+---------------------------+ | Outer Ethernet | Outer IP | Outer UDP | VXLAN | Original Pod-to-Pod | | Src: Node A MAC | Src: Node A | Src: Random | VNI: xx | Packet (unchanged | | Dst: Node B MAC | Dst: Node B | Dst: 4789 | | from above) | +-----------------+-------------+--------------+------------+---------------------------+ ``` O VXLAN Network Identifier (VNI) distingue entre diferentes redes de sobreposição. ### Cenários de comunicação do pod **Pods no mesmo nó híbrido** Quando pods no mesmo nó híbrido se comunicam, normalmente nenhum encapsulamento é necessário. A CNI configura rotas locais que direcionam o tráfego entre os pods por meio das interfaces virtuais internas do nó: ``` Pod A -> veth0 -> node's bridge/routing table -> veth1 -> Pod B ``` O pacote nunca sai do nó e não requer encapsulamento. **Pods em diferentes nós híbridos** A comunicação entre pods em diferentes nós híbridos requer encapsulamento: ``` Pod A -> CNI -> [VXLAN encapsulation] -> Node A network -> router or gateway -> Node B network -> [VXLAN decapsulation] -> CNI -> Pod B ``` Isso permite que o tráfego do pod atravesse a infraestrutura física da rede sem exigir que a rede física saiba o roteamento IP do pod. # Fluxos de tráfego de rede para nós híbridos Fluxos de tráfego 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. # Referência do `nodeadm` para nós híbridos Nós híbridos nodeadm A CLI (`nodeadm`) do Amazon EKS Hybrid Nodes simplifica a instalação, a configuração, o registro e a desinstalação dos componentes dos nós híbridos. Você pode incluir o `nodeadm` nas imagens do sistema operacional para automatizar o bootstrap de nós híbridos. Consulte [Preparar o sistema operacional para nós híbridos](hybrid-nodes-os.md) para obter mais informações. A versão do `nodeadm` para nós híbridos difere da versão do `nodeadm` usada para inicializar instâncias do Amazon EC2 como nós nos clusters do Amazon EKS. Siga a documentação e as referências para a versão apropriada do `nodeadm`. Esta página da documentação é para a versão do `nodeadm` para nós híbridos. O código-fonte do `nodeadm` para nós híbridos é publicado no repositório https://github.com/aws/eks-hybrid do GitHub. **Importante** Você deve executar `nodeadm` com um usuário que tenha privilégios root/sudo. ## Baixar `nodeadm` A versão de nós híbridos do `nodeadm` está hospedada no Amazon S3 com o Amazon CloudFront na frente. Para instalar `nodeadm` em cada host on-premises, você pode executar o comando a seguir nos hosts on-premises. **Para hosts x** ``` curl -OL 'https://hybrid-assets.eks.amazonaws.com/releases/latest/bin/linux/amd64/nodeadm' ``` **Para hosts ARM** ``` curl -OL 'https://hybrid-assets.eks.amazonaws.com/releases/latest/bin/linux/arm64/nodeadm' ``` Adicione uma permissão de arquivo executável ao binário baixado em cada host. ``` chmod +x nodeadm ``` ## `nodeadm install` O comando `nodeadm install` é usado para instalar os artefatos e dependências necessários para executar e unir nós híbridos a um cluster do Amazon EKS. O comando `nodeadm install` pode ser executado individualmente em cada nó híbrido ou durante os pipelines de criação de imagens para pré-instalar as dependências dos nós híbridos nas imagens do sistema operacional. **Usage** ``` nodeadm install [KUBERNETES_VERSION] [flags] ``` **Argumentos posicionais** (Obrigatório) `KUBERNETES_VERSION` A versão major.minor do Kubernetes do EKS a ser instalada, por exemplo, `1.32` **Sinalizadores** | Nome | Obrigatório | Descrição | | --- | --- | --- | | `-p`, `--credential-provider` | TRUE | Provedor de credenciais a ser instalado. Os valores compatíveis são `iam-ra` e `ssm`. Consulte [Preparar as credenciais para nós híbridos](hybrid-nodes-creds.md) para obter mais informações. | | `-s`, `--containerd-source` | FALSE | Fonte para `containerd`. O `nodeadm` é compatível com a instalação de `containerd` do distro do sistema operacional, os pacotes do Docker e a omissão da instalação de `containerd`. **Valores** `distro`: este é o valor padrão. O `nodeadm` instalará o pacote `containerd` mais recente distribuído pelo sistema operacional do nó que seja compatível com a versão do Kubernetes do EKS. O `distro` não é um valor compatível com sistemas operacionais do Red Hat Enterprise Linux (RHEL). `docker`: o `nodeadm` instalará o pacote `containerd` mais recente desenvolvido e distribuído pelo Docker que seja compatível com a versão do Kubernetes do EKS. O `docker` não é um valor compatível com o Amazon Linux 2023. `none`: o `nodeadm` não vai instalar o pacote `containerd`. Você deve instalar `containerd` manualmente antes de executar `nodeadm init`. | | `-r`, `--region` | FALSE | Especifica a região da AWS para baixar artefatos, como o Agente SSM. O padrão é `us-west-2`. | | `-t`, `--timeout` | FALSE | Duração máxima do comando de instalação. A entrada segue o formato de duração. Por exemplo, . `1h23m`. O tempo limite de download padrão para o comando de instalação é definido como 20 minutos. | | `-h`, `--help` | FALSE | Exibe a mensagem de ajuda com os parâmetros de sinalização, subcomando e valor posicional disponíveis. | **Exemplos** Instale a versão `1.32` do Kubernetes com o AWS Systems Manager (SSM) como o provedor de credenciais ``` nodeadm install 1.32 --credential-provider ssm ``` Instale a versão `1.32` do Kubernetes com o AWS Systems Manager (SSM) como o provedor de credenciais, e o Docker como a fonte do containerd, com um tempo limite de download de 20 minutos. ``` nodeadm install 1.32 --credential-provider ssm --containerd-source docker --timeout 20m ``` Instale a versão `1.32` do Kubernetes com o AWS IAM Roles Anywhere como o provedor de credenciais ``` nodeadm install 1.32 --credential-provider iam-ra ``` ## `nodeadm config check` O comando `nodeadm config check` verifica se há erros na configuração do nó fornecido. Esse comando pode ser usado para verificar e validar a exatidão de um arquivo de configuração de nó híbrido. **Usage** ``` nodeadm config check [flags] ``` **Sinalizadores** | Nome | Obrigatório | Descrição | | --- | --- | --- | | `-c`, `--config-source` | TRUE | Fonte da configuração do nodeadm. Para nós híbridos, a entrada deve seguir um URI com esquema de arquivo. | | `-h`, `--help` | FALSE | Exibe a mensagem de ajuda com os parâmetros de sinalização, subcomando e valor posicional disponíveis. | **Exemplos** ``` nodeadm config check -c file://nodeConfig.yaml ``` ## `nodeadm init` O comando `nodeadm init` inicia e conecta o nó híbrido com o cluster configurado do Amazon EKS. Consulte [Configuração de nó para ativações híbridas do SSM](#hybrid-nodes-node-config-ssm) ou [Configuração de nó para o IAM Roles Anywhere](#hybrid-nodes-node-config-iamra) para obter detalhes sobre como configurar o arquivo `nodeConfig.yaml`. **Usage** ``` nodeadm init [flags] ``` **Sinalizadores** | Nome | Obrigatório | Descrição | | --- | --- | --- | | `-c`, `--config-source` | TRUE | Fonte de configuração do `nodeadm`. Para nós híbridos, a entrada deve seguir um URI com esquema de arquivo. | | `-s`, `--skip` | FALSE | Fases de `init` a serem ignoradas. Não é recomendável pular nenhuma das fases, a menos que isso ajude a corrigir um problema. **Valores** `install-validation` vai ignorar a verificação se o comando de instalação anterior tiver sido executado com êxito. A `cni-validation` vai ignorar a verificação se as portas VXLAN da CNI do Cilium ou do Calico estiverem abertas, caso o firewall esteja habilitado no nó `node-ip-validation` ignorará a verificação se o IP do nó estiver dentro de um CIDR nas redes de nós remotos | | `-h`, `--help` | FALSE | Exibe a mensagem de ajuda com os parâmetros de sinalização, subcomando e valor posicional disponíveis. | **Exemplos** ``` nodeadm init -c file://nodeConfig.yaml ``` ## `nodeadm upgrade` O comando `nodeadm upgrade` atualiza todos os artefatos instalados para a versão mais recente e inicializa o nó para configurar os artefatos atualizados e unir o cluster do EKS na AWS. O upgrade é um comando de interrupção para as workloads em execução no nó. Mova as workloads para outro nó antes de executar o comando upgrade. **Usage** ``` nodeadm upgrade [KUBERNETES_VERSION] [flags] ``` **Argumentos posicionais** (Obrigatório) `KUBERNETES_VERSION` A versão major.minor do Kubernetes do EKS a ser instalada, por exemplo, `1.32` **Sinalizadores** | Nome | Obrigatório | Descrição | | --- | --- | --- | | `-c`, `--config-source` | TRUE | Fonte de configuração do `nodeadm`. Para nós híbridos, a entrada deve seguir um URI com esquema de arquivo. | | `-t`, `--timeout` | FALSE | Tempo limite para download de artefatos. A entrada segue o formato de duração. Por exemplo, 1h23m. O tempo limite de download padrão para o comando de atualização é definido para dez minutos. | | `-s`, `--skip` | FALSE | Fases da atualização a serem ignoradas. Não é recomendável pular nenhuma fase, a menos que isso ajude a corrigir um problema. **Valores** `pod-validation` ignora a verificação se todos os pods não estão em execução no nó, exceto conjuntos de daemons e pods estáticos. `node-validation` ignora a verificação se o nó foi isolado. `init-validation` ignora a verificação se o nó foi inicializado com sucesso antes de executar a atualização. O valor `containerd-major-version-upgrade` impede atualizações da versão principal do containerd durante a atualização do nó. | | `-h`, `--help` | FALSE | Exibe a mensagem de ajuda com os parâmetros de sinalização, subcomando e valor posicional disponíveis. | **Exemplos** ``` nodeadm upgrade 1.32 -c file://nodeConfig.yaml ``` ``` nodeadm upgrade 1.32 -c file://nodeConfig.yaml --timeout 20m ``` ## `nodeadm uninstall` O comando `nodeadm uninstall` interrompe e remove os artefatos do `nodeadm` instalados durante a `nodeadm install`, incluindo o kubelet e o containerd. Observe que o comando uninstall não drena nem exclui os nós híbridos do cluster. Você deve executar as operações de drenagem e exclusão separadamente. Consulte [Remoção de nós híbridos](hybrid-nodes-remove.md) para obter mais informações. Por padrão, `nodeadm uninstall` não prosseguirá se houver pods restantes no nó. Da mesma forma, `nodeadm uninstall` não remove dependências da CNI ou dependências de outros complementos do Kubernetes que você executa no cluster. Para remover totalmente a instalação da CNI do host, consulte as instruções em [Configurar a CNI para nós híbridos](hybrid-nodes-cni.md). Se você estiver usando ativações híbridas do AWS SSM como o provedor de credenciais on-premises, o comando `nodeadm uninstall` vai cancelar o registro dos hosts como instâncias gerenciadas pelo AWS SSM. **Usage** ``` nodeadm uninstall [flags] ``` **Sinalizadores** | Nome | Obrigatório | Descrição | | --- | --- | --- | | `-s`, `--skip` | FALSE | Fases de desinstalação a serem ignoradas. Não é recomendável pular nenhuma das fases, a menos que isso ajude a corrigir um problema. **Valores** `pod-validation` ignora a verificação se todos os pods não estão em execução no nó, exceto conjuntos de daemons e pods estáticos. `node-validation` ignora a verificação se o nó foi isolado. A `init-validation` vai ignorar a verificação se o nó tiver sido inicializado com êxito antes de executar a desinstalação. | | `-h`, `--help` | FALSE | Exibe a mensagem de ajuda com os parâmetros de sinalização, subcomando e valor posicional disponíveis. | | `-f`, `--force` | FALSE | Força a exclusão de diretórios adicionais que possam conter arquivos restantes dos componentes do Kubernetes e da CNI. **AVISO** Isso excluirá todo o conteúdo nos diretórios padrão do Kubernetes e da CNI (`/var/lib/cni`, `/etc/cni/net.d`, etc). Não use esse sinalizador se você armazenar seus próprios dados nesses locais. A partir do nodeadm `v1.0.9`, o comando `./nodeadm uninstall --skip node-validation,pod-validation --force` não exclui mais o diretório `/var/lib/kubelet`. Isso ocorre porque ele pode conter volumes de pod e diretórios de subcaminhos de volume que às vezes incluem o sistema de arquivos do nó montado. **Dicas de manuseio seguro** - A exclusão de caminhos montados pode levar à exclusão acidental do sistema de arquivos real do nó montado. Antes de excluir manualmente o diretório `/var/lib/kubelet`, inspecione cuidadosamente todas as montagens ativas e desmonte os volumes com segurança para evitar perda de dados. | **Exemplos** ``` nodeadm uninstall ``` ``` nodeadm uninstall --skip node-validation,pod-validation ``` ## `nodeadm debug` O comando `nodeadm debug` pode ser usado para solucionar problemas de nós híbridos não íntegros ou mal configurados. Ele valida se os requisitos a seguir estão em vigor. + O nó tem acesso de rede às APIs da AWS necessárias para obter credenciais. + O nó é capaz de obter credenciais da AWS para o perfil do IAM configurado de nós híbridos. + O nó tem acesso de rede ao endpoint da API do Kubernetes do EKS e à validade do certificado do endpoint da API do Kubernetes do EKS. + O nó é capaz de se autenticar com o cluster do EKS, sua identidade no cluster é válida e o nó tem acesso ao cluster do EKS por meio da VPC configurada para o cluster do EKS. Se forem encontrados erros, a saída do comando vai sugerir etapas de solução de problemas. Certas etapas de validação mostram processos secundários. Se estes falharem, a saída será mostrada em uma seção stderr abaixo do erro de validação. **Usage** ``` nodeadm debug [flags] ``` **Sinalizadores** | Nome | Obrigatório | Descrição | | --- | --- | --- | | `-c`, `--config-source` | TRUE | Fonte de configuração do `nodeadm`. Para nós híbridos, a entrada deve seguir um URI com esquema de arquivo. | | `--no-color` | FALSE | Desativa a saída de cores. Útil para automação. | | `-h`, `--help` | FALSE | Exibe a mensagem de ajuda com os parâmetros de sinalização, subcomando e valor posicional disponíveis. | **Exemplos** ``` nodeadm debug -c file://nodeConfig.yaml ``` ## Locais dos arquivos do nodeadm ### Instalação do nodeadm Durante a execução da `nodeadm install`, os arquivos e as localizações de arquivos a seguir são configurados. | Artifact | Caminho | | --- | --- | | CLI do IAM Roles Anywhere | /usr/local/bin/aws\$1signing\$1helper | | Binário do Kubelet | /usr/bin/kubelet | | Binário do Kubectl | usr/local/bin/kubectl | | Provedor de credenciais do ECR | /etc/eks/image-credential-provider/ecr-credential-provider | | AWS IAM Authenticator | /usr/local/bin/aws-iam-authenticator | | CLI de configuração do SSM | /opt/ssm/ssm-setup-cli | | SSM Agent | No Ubuntu: /snap/amazon-ssm-agent/current/amazon-ssm-agent No RHEL e AL2023: /usr/bin/amazon-ssm-agent | | Containerd | No Ubuntu e AL2023: /usr/bin/containerd No RHEL: /bin/containerd | | Iptables | No Ubuntu e AL2023: /usr/sbin/iptables No RHEL: /sbin/iptables | | Plug-ins da CNI | /opt/cni/bin | | rastreador de artefatos instalado | /opt/nodeadm/tracker | ### Inicialização do nodeadm Durante a execução da `nodeadm init`, os arquivos e as localizações de arquivos a seguir são configurados. | Nome | Caminho | | --- | --- | | kubeconfig do Kubelet | /var/lib/kubelet/kubeconfig | | Configuração do Kubelet | /etc/kubernetes/kubelet/config.json | | Unidade systemd do Kubelet | /etc/systemd/system/kubelet.service | | Configuração do provedor de credenciais de imagem | /etc/eks/image-credential-provider/config.json | | Arquivo env do Kubelet | /etc/eks/kubelet/environment | | Certificados do Kubelet | /etc/kubernetes/pki/ca.crt | | Configuração do containerd | /etc/containerd/config.toml | | Configuração dos módulos do containerd do kernel | /etc/modules-load.d/contianerd.conf | | AWSArquivo de configuração da | /etc/aws/hybrid/config | | Arquivo de credenciais da AWS (se habilitar arquivo de credenciais) | /eks-hybrid/.aws/credentials | | Unidade do sistema auxiliar de assinatura da AWS | /etc/systemd/system/aws\$1signing\$1helper\$1update.service | | Arquivo de configuração Sysctl | /etc/sysctl.d/99-nodeadm.conf | | Ca-certificates | /etc/ssl/certs/ca-certificates.crt | | Arquivo de chaves GPG | /etc/apt/keyrings/docker.asc | | Arquivo de origem do repositório do Docker | /etc/apt/sources.list.d/docker.list | ## Configuração de nó para ativações híbridas do SSM Veja a seguir um exemplo de `nodeConfig.yaml` ao usar ativações híbridas do AWS SSM para credenciais de nós híbridos. ``` apiVersion: node.eks.aws/v1alpha1 kind: NodeConfig spec: cluster: name: # Name of the EKS cluster region: # AWS Region where the EKS cluster resides hybrid: ssm: activationCode: # SSM hybrid activation code activationId: # SSM hybrid activation id ``` ## Configuração de nó para o IAM Roles Anywhere Veja a seguir um exemplo de `nodeConfig.yaml` do AWS IAM Roles Anywhere para credenciais de nós híbridos. Ao usar o AWS IAM Roles Anywhere como seu provedor de credenciais on-premises, o `nodeName` que você usa na configuração do `nodeadm` deve estar alinhado com as permissões que você definiu como escopo para o perfil do IAM de nós híbridos. Por exemplo, se as permissões para o perfil do IAM de nós híbridos só permitirem que o AWS IAM Roles Anywhere assuma o perfil quando o nome da sessão do perfil for igual ao CN do certificado do host, o `nodeName` na configuração do `nodeadm` deverá ser o mesmo que o CN dos certificados. O `nodeName` que você usa não pode exceder 64 caracteres. Para obter mais informações, consulte [Preparar as credenciais para nós híbridos](hybrid-nodes-creds.md). ``` apiVersion: node.eks.aws/v1alpha1 kind: NodeConfig spec: cluster: name: # Name of the EKS cluster region: # AWS Region where the EKS cluster resides hybrid: iamRolesAnywhere: nodeName: # Name of the node trustAnchorArn: # ARN of the IAM Roles Anywhere trust anchor profileArn: # ARN of the IAM Roles Anywhere profile roleArn: # ARN of the Hybrid Nodes IAM role certificatePath: # Path to the certificate file to authenticate with the IAM Roles Anywhere trust anchor privateKeyPath: # Path to the private key file for the certificate ``` ## Configuração de nó para personalizar o kubelet (opcional) Você pode passar a configuração e os sinalizadores do kubelet na configuração do `nodeadm`. Veja o exemplo abaixo para saber como adicionar um rótulo de nó `abc.amazonaws.com/test-label` e como configurar para definir `shutdownGracePeriod` como 30 segundos. ``` apiVersion: node.eks.aws/v1alpha1 kind: NodeConfig spec: cluster: name: # Name of the EKS cluster region: # AWS Region where the EKS cluster resides kubelet: config: # Map of kubelet config and values shutdownGracePeriod: 30s flags: # List of kubelet flags - --node-labels=abc.company.com/test-label=true hybrid: ssm: activationCode: # SSM hybrid activation code activationId: # SSM hybrid activation id ``` ## Configuração de nó para personalizar o containerd (opcional) Você pode passar uma configuração personalizada do containerd na configuração do `nodeadm`. A configuração do containerd para `nodeadm` aceita TOML em linha. Veja o exemplo abaixo para saber como configurar o containerd para desabilitar a exclusão de camadas de imagens descompactadas no armazenamento de conteúdo do containerd. ``` apiVersion: node.eks.aws/v1alpha1 kind: NodeConfig spec: cluster: name: # Name of the EKS cluster region: # AWS Region where the EKS cluster resides containerd: config: | # Inline TOML containerd additional configuration [plugins."io.containerd.grpc.v1.cri".containerd] discard_unpacked_layers = false hybrid: ssm: activationCode: # SSM hybrid activation code activationId: # SSM hybrid activation id ``` **nota** As versões 1.x e 2.x do containerd contam com formatos de configuração distintos. O containerd 1.x usa a versão 2 da configuração, enquanto o containerd 2.x usa a versão 3. Embora o containerd 2.x seja compatível com versões anteriores da configuração 2, a versão 3 é recomendada para obtenção da performance ideal. Confira a versão do containerd com `containerd --version` ou analise os logs de instalação do `nodeadm`. Para obter mais detalhes sobre o versionamento da configuração, consulte https://containerd.io/releases/. Você também pode usar a configuração do containerd para habilitar a compatibilidade com o SELinux. Com o SELinux habilitado no containerd, certifique-se de que os pods programados no nó tenham o securityContext e o seLinuxOptions adequados habilitados. Você pode encontrar mais informações sobre como configurar um contexto de segurança na [documentação do Kubernetes](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/). **nota** O Red Hat Enterprise Linux (RHEL) 8 e o RHEL 9 têm o SELinux habilitado por padrão e configurado como estrito no host. Por padrão, o Amazon Linux 2023 tem o SELinux habilitado e configurado para o modo permissivo. Quando o SELinux está configurado para o modo permissivo no host, ativá-lo no containerd não bloqueará as solicitações, mas as registrará em log de acordo com a configuração do SELinux no host. ``` apiVersion: node.eks.aws/v1alpha1 kind: NodeConfig spec: cluster: name: # Name of the EKS cluster region: # AWS Region where the EKS cluster resides containerd: config: | # Inline TOML containerd additional configuration [plugins."io.containerd.grpc.v1.cri"] enable_selinux = true hybrid: ssm: activationCode: # SSM hybrid activation code activationId: # SSM hybrid activation id ``` # Solução de problemas de nós híbridos Solução de problemas Este tópico aborda alguns erros comuns que você poderia encontrar ao usar o Amazon EKS Hybrid Nodes e como resolvê-los. Para obter outras informações sobre solução de problemas, consulte [Solucionar problemas com clusters e nós do Amazon EKS](troubleshooting.md) e [Conteúdo do Centro de Conhecimento para o Amazon EKS](https://repost.aws/tags/knowledge-center/TA4IvCeWI1TE66q4jEj4Z9zg/amazon-elastic-kubernetes-service) no *AWS re:Post*. Caso não consiga resolver o problema, entre em contato com o AWS Support. **Solução de problemas de nós com `nodeadm debug`** Você pode executar o comando `nodeadm debug` dos nós híbridos para validar se os requisitos de rede e credenciais foram atendidos. Para obter mais informações sobre o comando `nodeadm debug`, consulte [Referência do `nodeadm` para nós híbridos](hybrid-nodes-nodeadm.md). **Detectar problemas com os nós híbridos com insights de clusters** Os insights de clusters do Amazon EKS incluem *verificações de insights* que detectam problemas comuns com a configuração do EKS Hybrid Nodes no cluster. Você pode ver os resultados de todas as verificações de insights no Console de gerenciamento da AWS, na AWS CLI e nos SDKs da AWS. Para obter mais informações sobre insights de clusters, consulte [Prepare-se para as atualizações da versão e a solução de problemas de configurações incorretas do Kubernetes com insights do cluster](cluster-insights.md). ## Instalar a solução de problemas de nós híbridos Os tópicos de solução de problemas a seguir estão relacionados à instalação das dependências dos nós híbridos nos hosts com o comando `nodeadm install`. ** `nodeadm` Falha no comando `must run as root` ** O comando `nodeadm install` deve ser executado com um usuário que tenha privilégios de usuário-raiz ou `sudo` no host. Caso execute `nodeadm install` com um usuário que não tenha privilégios de usuário-raiz ou `sudo`, você verá o erro a seguir na saída de `nodeadm`. ``` "msg":"Command failed","error":"must run as root" ``` **Não é possível conectar às dependências** O comando `nodeadm install` instala as dependências necessárias para os nós híbridos. As dependências dos nós híbridos incluem `containerd`, `kubelet`, `kubectl` e componentes do AWS SSM ou do AWS IAM Roles Anywhere. Você deve ter acesso do local em que está executando `nodeadm install` para baixar essas dependências. Para obter mais informações sobre a lista de locais que você deve poder acessar, consulte [Preparar a rede para nós híbridos](hybrid-nodes-networking.md). Caso não tenha acesso, você verá erros semelhantes ao apresentado a seguir na saída de `nodeadm install`. ``` "msg":"Command failed","error":"failed reading file from url: ...: max retries achieved for http request" ``` **Falha ao atualizar o gerenciador de pacotes** O comando `nodeadm install` executa `apt update` ou `yum update` ou `dnf update` antes de instalar as dependências dos nós híbridos. Se essa etapa não tiver êxito, erros semelhantes aos abaixo poderão ocorrer. Para corrigir, é possível executar `apt update` ou `yum update` ou `dnf update` antes de executar `nodeadm install`. Também é possível tentar executar `nodeadm install` novamente. ``` failed to run update using package manager ``` **Tempo limite ou prazo de contexto excedido** Ao executar `nodeadm install`, se você observar problemas em várias etapas do processo de instalação com erros que indicam que houve um tempo limite ou que o prazo do contexto foi excedido, você pode ter uma conexão lenta que está impedindo a instalação das dependências dos nós híbridos antes que os tempos limite sejam atingidos. Para contornar esses problemas, você pode tentar usar o sinalizador `--timeout` em `nodeadm` para estender a duração dos tempos limite para baixar as dependências. ``` nodeadm install K8S_VERSION --credential-provider CREDS_PROVIDER --timeout 20m0s ``` ## Solução de problemas de conexão de nós híbridos Os tópicos de solução de problemas nesta seção estão relacionados ao processo de conexão de nós híbridos a clusters do EKS com o comando `nodeadm init`. **Erros de operação ou esquema não compatível** Ao executar `nodeadm init`, se você encontrar erros relacionados a `operation error` ou `unsupported scheme`, verifique o `nodeConfig.yaml` para garantir que esteja formatado corretamente e tenha sido passado para `nodeadm`. Para obter mais informações sobre o formato e as opções para `nodeConfig.yaml`, consulte [Referência do `nodeadm` para nós híbridos](hybrid-nodes-nodeadm.md). ``` "msg":"Command failed","error":"operation error ec2imds: GetRegion, request canceled, context deadline exceeded" ``` **Perfil do IAM de nós híbridos sem permissões para a ação `eks:DescribeCluster`** Durante a execução do `nodeadm init`, o `nodeadm` tenta obter informações sobre seu cluster do EKS ao chamar a ação `DescribeCluster` do EKS. Se o perfil do IAM do Hybrid Nodes não tiver permissão para realizar a ação `eks:DescribeCluster`, será necessário informar o endpoint da API do Kubernetes, o pacote da CA do cluster e o intervalo CIDR IPv4 do serviço na configuração do nó que você transmite ao `nodeadm` ao executar `nodeadm init`. Para obter mais informações sobre as permissões necessárias para o perfil do IAM de nós híbridos, consulte [Preparar as credenciais para nós híbridos](hybrid-nodes-creds.md). ``` "msg":"Command failed","error":"operation error EKS: DescribeCluster, https response error StatusCode: 403 ... AccessDeniedException" ``` **Perfil do IAM de nós híbridos sem permissões para a ação `eks:ListAccessEntries`** Durante a execução do `nodeadm init`, o `nodeadm` tenta validar se o seu cluster do EKS contém uma entrada de acesso do tipo `HYBRID_LINUX` associada ao perfil do IAM do Hybrid Nodes ao chamar a ação `ListAccessEntries` do EKS. Se o perfil do IAM do Hybrid Nodes não tiver permissão para realizar a ação `eks:ListAccessEntries`, será necessário informar o sinalizador `--skip cluster-access-validation` ao executar o comando `nodeadm init`. Para obter mais informações sobre as permissões necessárias para o perfil do IAM de nós híbridos, consulte [Preparar as credenciais para nós híbridos](hybrid-nodes-creds.md). ``` "msg":"Command failed","error":"operation error EKS: ListAccessEntries, https response error StatusCode: 403 ... AccessDeniedException" ``` **O IP do nó não está no CIDR da rede do nó remoto** Ao executar `nodeadm init`, você poderá encontrar um erro se o endereço IP do nó não estiver dentro dos CIDRs da rede do nó remoto especificado. O erro será semelhante ao seguinte exemplo: ``` node IP 10.18.0.1 is not in any of the remote network CIDR blocks [10.0.0.0/16 192.168.0.0/16] ``` Este exemplo mostra um nó com IP 10.18.0.1 tentando ingressar em um cluster com os CIDRs de rede remota 10.0.0.0/16 e 192.168.0.0/16. O erro ocorre porque 10.18.0.1 não faz parte de nenhum dos intervalos. Confirme se você configurou corretamente o seu `RemoteNodeNetworks` para incluir todos os endereços IP de nós. Para obter mais informações sobre a configuração da rede, consulte [Preparar a rede para nós híbridos](hybrid-nodes-networking.md). + Execute o comando a seguir na região em que seu cluster está localizado para verificar suas configurações de `RemoteNodeNetwork`. Verifique se os blocos CIDR listados na saída incluem o intervalo de IP do seu nó e são iguais aos blocos CIDR listados na mensagem de erro. Se eles não corresponderem, confirme se o nome do cluster e a região em seu cluster do `nodeConfig.yaml` correspondem ao cluster pretendido. ``` aws eks describe-cluster --name CLUSTER_NAME --region REGION_NAME --query cluster.remoteNetworkConfig.remoteNodeNetworks ``` + Verifique se você está trabalhando com o nó pretendido: + Confirme se você está no nó correto verificando se o nome do host e o endereço IP correspondem aos que você pretende registrar no cluster. + Confirme se esse nó está na rede on-premises correta (aquela cujo intervalo de CIDR foi registrado como `RemoteNodeNetwork` durante a configuração do cluster). Se o IP do seu nó ainda não for o esperado, verifique o seguinte: + Se você estiver usando o IAM Roles Anywhere, o `kubelet` realizará uma pesquisa de DNS em `nodeName` do IAM Roles Anywhere e usará um IP associado ao nome do nó, se disponível. Se você mantiver entradas de DNS para seus nós, confirme se essas entradas apontam para IPs pertencentes aos CIDRs da rede dos nós remotos. + Se seu nó tiver várias interfaces de rede, `kubelet` poderá selecionar uma interface com um endereço IP fora dos CIDRs de rede do nó remoto como padrão. Para usar uma interface diferente, especifique seu endereço IP usando o sinalizador `--node-ip` do `kubelet` em seu `nodeConfig.yaml`. Para obter mais informações, consulte [Referência do `nodeadm` para nós híbridos](hybrid-nodes-nodeadm.md). É possível visualizar as interfaces de rede do seu nó e seus endereços IP executando o seguinte comando no nó: ``` ip addr show ``` **Os nós híbridos não estão aparecendo no cluster do EKS** Se você executou `nodeadm init` e ele foi concluído, mas os nós híbridos não aparecem no cluster, pode haver problemas com a conexão de rede entre os nós híbridos e o ambiente de gerenciamento do EKS, você pode não ter as permissões de grupo de segurança necessárias configuradas ou você pode não ter o mapeamento necessário do perfil do IAM de nós híbridos para o controle de acesso por perfil (RBAC) do Kubernetes. Você pode iniciar o processo de depuração verificando o status do `kubelet` e os logs do `kubelet` com os comandos a seguir. Execute os comandos a seguir nos nós híbridos que não conseguiram se unir ao cluster. ``` systemctl status kubelet ``` ``` journalctl -u kubelet -f ``` **Não é possível se comunicar com o cluster** Se o nó híbrido não conseguiu se comunicar com o ambiente de gerenciamento do cluster, talvez você veja logs semelhantes aos abaixo. ``` "Failed to ensure lease exists, will retry" err="Get ..." ``` ``` "Unable to register node with API server" err="Post ..." ``` ``` Failed to contact API server when waiting for CSINode publishing ... dial tcp : i/o timeout ``` Se você vir essas mensagens, verifique as informações abaixo para garantir que atenda aos requisitos de nós híbridos detalhados em [Preparar a rede para nós híbridos](hybrid-nodes-networking.md). + Confirme se a VPC passada para o cluster do EKS tem rotas para o gateway de trânsito (TGW) ou o gateway privado virtual (VGW) para seu nó on-premises e, opcionalmente, CIDRs de pods. + Confirme se você tem um grupo de segurança adicional para o cluster do EKS com regras de entrada para os CIDRs de nós on-premises e, opcionalmente, para CIDRs de pods. + Confirme se o roteador on-premises está configurado para permitir o tráfego de e para o ambiente de gerenciamento do EKS. **Não autorizado** Se o nó híbrido conseguiu se comunicar com o ambiente de gerenciamento do EKS, mas não conseguiu se registrar, você poderá ver logs semelhantes aos a seguir. Observe que a principal diferença nas mensagens de logs abaixo é o erro `Unauthorized`. Isso indica que o nó não conseguiu realizar suas tarefas porque não tem as permissões necessárias. ``` "Failed to ensure lease exists, will retry" err="Unauthorized" ``` ``` "Unable to register node with API server" err="Unauthorized" ``` ``` Failed to contact API server when waiting for CSINode publishing: Unauthorized ``` Se você vir essas mensagens, verifique as informações a seguir para garantir que atenda aos requisitos de nós híbridos detalhados em [Preparar as credenciais para nós híbridos](hybrid-nodes-creds.md) e [Preparar o acesso ao cluster para nós híbridos](hybrid-nodes-cluster-prep.md). + Confirme se a identidade dos nós híbridos corresponde ao perfil do IAM de nós híbridos esperado. Isso pode ser feito executando `sudo aws sts get-caller-identity` nos nós híbridos. + Confirme se o perfil do IAM de nós híbridos tem as permissões necessárias. + Confirme se em seu cluster você tem uma entrada de acesso ao EKS para o perfil do IAM de nós híbridos, ou confirme se o ConfigMap `aws-auth` tem uma entrada para o perfil do IAM de nós híbridos. Se você estiver usando entradas de acesso ao EKS, confirme se a entrada de acesso do perfil do IAM de nós híbridos tem o tipo de acesso `HYBRID_LINUX`. Se você estiver usando o ConfigMap `aws-auth`, confirme se a entrada para o perfil do IAM de nós híbridos atende aos requisitos e à formatação detalhados em [Preparar o acesso ao cluster para nós híbridos](hybrid-nodes-cluster-prep.md). ### Nós híbridos registrados no cluster do EKS, mas mostram o status `Not Ready` Se os nós híbridos tiverem sido registrados com êxito no cluster do EKS, mas mostrarem o status `Not Ready`, a primeira coisa a verificar é o status da interface de rede de contêineres (CNI). Se você não instalou uma CNI, é esperado que os nós híbridos tenham o status `Not Ready`. Depois que uma CNI é instalada e executada com êxito, os nós são atualizados para o status `Ready`. Se você tentou instalar uma CNI, mas ela não está sendo executada com êxito, consulte [Solução de problemas da CNI em nós híbridos](#hybrid-nodes-troubleshooting-cni) nesta página. **As solicitações de assinatura de certificado (CSRs) estão pendentes** Depois de conectar os nós híbridos ao cluster do EKS, se você perceber que há CSRs pendentes para os nós híbridos, isso significa que eles não estão atendendo aos requisitos de aprovação automática. As CSRs para nós híbridos serão aprovadas e emitidas automaticamente se tiverem sido criadas por um nó com o rótulo `eks.amazonaws.com/compute-type: hybrid` e tiverem os seguintes nomes alternativos de assunto (SANs): pelo menos um SAN DNS igual ao nome do nó e os SANs IP pertencerem aos CIDRs da rede remota de nós. **O usuário híbrido já existe** Caso tenha alterado a configuração do `nodeadm` e registrado novamente o nó com a nova configuração, você poderá ver um erro informando que o usuário híbrido já existe, mas que seu conteúdo foi alterado. Em vez de executar `nodeadm init` entre as alterações de configuração, execute `nodeadm uninstall` seguido de um `nodeadm install` e `nodeadm init`. Isso garante uma limpeza adequada com as alterações na configuração. ``` "msg":"Command failed","error":"hybrid profile already exists at /etc/aws/hybrid/config but its contents do not align with the expected configuration" ``` **O nó híbrido falhou ao resolver a API privada** Após executar `nodeadm init`, se você observar um erro nos logs do `kubelet` que mostra falhas ao contatar o servidor da API do Kubernetes do EKS porque há `no such host`, talvez seja necessário alterar sua entrada de DNS para o endpoint da API do Kubernetes do EKS na rede on-premises ou no nível do host. Consulte [Forwarding inbound DNS queries to your VPC](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-forwarding-inbound-queries.html) na *documentação do AWS Route 53*. ``` Failed to contact API server when waiting for CSINode publishing: Get ... no such host ``` **Não é possível visualizar nós híbridos no console do EKS** Se você registrou os nós híbridos, mas não consegue visualizá-los no console do EKS, verifique as permissões da entidade principal do IAM que você está usando para visualizar o console. A entidade principal do IAM que você está usando deve ter permissões mínimas específicas do IAM e do Kubernetes para visualizar os recursos no console. Para obter mais informações, consulte [Visualize os recursos do Kubernetes na seção Console de gerenciamento da AWS](view-kubernetes-resources.md). ## Solução de problemas de execução de nós híbridos Se os nós híbridos registrados no cluster do EKS tinham o status `Ready` e depois passaram para o status `Not Ready`, há uma ampla gama de problemas que podem ter contribuído para o status de não íntegro, como a falta de recursos suficientes para CPU, memória ou espaço em disco disponível, ou o nó está desconectado do ambiente de gerenciamento do EKS. Você pode usar as etapas abaixo para solucionar problemas nos nós e, se não conseguir resolver o problema, entre em contato com o AWS Support. Execute `nodeadm debug` nos nós híbridos para validar se os requisitos de rede e credenciais foram atendidos. Para obter mais informações sobre o comando `nodeadm debug`, consulte [Referência do `nodeadm` para nós híbridos](hybrid-nodes-nodeadm.md). **Obter status do nó** ``` kubectl get nodes -o wide ``` **Verificar condições e eventos do nó** ``` kubectl describe node NODE_NAME ``` **Obter status do pod** ``` kubectl get pods -A -o wide ``` **Verificar condições e eventos do pod** ``` kubectl describe pod POD_NAME ``` **Verificar logs do pod** ``` kubectl logs POD_NAME ``` **Verificar os logs do `kubectl`** ``` systemctl status kubelet ``` ``` journalctl -u kubelet -f ``` **Falha nas sondas de liveness do pod ou os webhooks não estão funcionando** Se as aplicações, os complementos ou os webhooks executados nos nós híbridos não estiverem iniciando corretamente, você poderá observar problemas de rede que bloqueiam a comunicação com os pods. Para que o ambiente de gerenciamento do EKS faça contato com os webhooks em execução nos nós híbridos, você deve configurar o cluster do EKS com uma rede remota de pods e ter rotas para o CIDR de pods on-premises na tabela de roteamento da VPC com o destino como o gateway de trânsito (TGW), o gateway privado virtual (VPW) ou outro gateway que você esteja usando para conectar a VPC à rede on-premises. Para obter mais informações sobre os requisitos de rede para nós híbridos, consulte [Preparar a rede para nós híbridos](hybrid-nodes-networking.md). Além disso, você deve permitir esse tráfego no firewall on-premises e garantir que o roteador possa rotear adequadamente para os pods. Consulte [Configurar webhooks para nós híbridos](hybrid-nodes-webhooks.md) para obter mais informações sobre os requisitos para executar webhooks em nós híbridos. Uma mensagem comum de log de pod para esse cenário é mostrada abaixo, em que ip-address é o IP do cluster para o serviço do Kubernetes. ``` dial tcp :443: connect: no route to host ``` **Comandos `kubectl logs` ou `kubectl exec` não estão funcionando (comandos da API do `kubelet`)** Se os comandos `kubectl attach`, `kubectl cp`, `kubectl exec`, `kubectl logs` e `kubectl port-forward` atingirem o tempo limite, enquanto outros comandos `kubectl` funcionam com êxito, o problema provavelmente está relacionado à configuração da rede remota. Esses comandos se conectam por meio do cluster ao endpoint `kubelet` no nó. Para obter mais informações, consulte [Endpoint do `kubelet`](hybrid-nodes-concepts-kubernetes.md#hybrid-nodes-concepts-k8s-kubelet-api). Verifique se seus IPs de nó e IPs de pod se enquadram na rede de nós remotos e nos CIDRs da rede de pods remotos configurados para seu cluster. Use os comandos abaixo para examinar as atribuições de IP. ``` kubectl get nodes -o wide ``` ``` kubectl get pods -A -o wide ``` Compare esses IPs com seus CIDRs de rede remota configurados para garantir o roteamento adequado. Para requisitos de configuração de rede, consulte [Preparar a rede para nós híbridos](hybrid-nodes-networking.md). ## Solução de problemas da CNI em nós híbridos Se, a princípio, você encontrar problemas ao iniciar o Cilium ou o Calico com nós híbridos, geralmente é devido a problemas de rede entre os nós híbridos ou os pods da CNI executados em nós híbridos e o ambiente de gerenciamento do EKS. Certifique-se de que seu ambiente atenda aos requisitos em Preparar a rede para nós híbridos. É útil dividir o problema em partes. Configuração do cluster do EKS As configurações de RemoteNodeNetwork e RemotePodNetwork estão corretas? Configuração de VPC Há rotas para RemoteNodeNetwork e RemotePodNetwork na tabela de roteamento da VPC com o destino do gateway de trânsito ou do gateway privado virtual? Configuração do security group Existem regras de entrada e saída para RemoteNodeNetwork e RemotePodNetwork? Rede on-premises Existem rotas e acesso de e para o ambiente de gerenciamento do EKS e de e para os nós híbridos e os pods executados em nós híbridos? Configuração da CNI Se estiver usando uma rede de sobreposição, a configuração do grupo de IPs para a CNI corresponderá à RemotePodNetwork configurada para o cluster do EKS se estiver usando webhooks? **O nó híbrido tem o status `Ready` sem uma CNI instalada** Se os nós híbridos estiverem mostrando o status `Ready`, mas você não instalou uma CNI no cluster, é possível que haja artefatos de CNI antigos nos nós híbridos. Por padrão, quando você desinstala o Cilium e o Calico com ferramentas como o Helm, os recursos em disco não são removidos das máquinas físicas ou virtuais. Além disso, as definições de recursos personalizados (CRDs) dessas CNIs ainda podem estar presentes no cluster de uma instalação antiga. Para obter mais informações, consulte as seções Excluir Cilium e Excluir Calico de [Configurar a CNI para nós híbridos](hybrid-nodes-cni.md). **Solução de problemas do Cilium** Caso esteja tendo problemas ao executar o Cilium em nós híbridos, consulte [as etapas de solução de problemas](https://docs.cilium.io/en/stable/operations/troubleshooting/) na documentação do Cilium. As seções abaixo abordam problemas que podem ser exclusivos da implantação do Cilium em nós híbridos. **O Cilium não está iniciando** Se os agentes do Cilium que são executados em cada nó híbrido não estiverem iniciando, verifique os logs dos pods do agente do Cilium em busca de erros. O agente do Cilium requer conectividade com o endpoint da API do Kubernetes do EKS para iniciar. A inicialização do agente do Cilium falhará se essa conectividade não estiver configurada corretamente. Nesse caso, você verá mensagens de log semelhantes às abaixo nos logs do pod do agente do Cilium. ``` msg="Unable to contact k8s api-server" level=fatal msg="failed to start: Get \"https://:443/api/v1/namespaces/kube-system\": dial tcp :443: i/o timeout" ``` O agente do Cilium é executado na rede do host. O cluster do EKS deve ser configurado com `RemoteNodeNetwork` para a conectividade do Cilium. Confirme se você tem um grupo de segurança adicional para o cluster do EKS com uma regra de entrada para `RemoteNodeNetwork`, se você tem rotas na VPC para `RemoteNodeNetwork` e se a rede on-premises está configurada corretamente para permitir a conectividade com o ambiente de gerenciamento do EKS. Se o operador do Cilium estiver em execução, e alguns dos agentes do Cilium estiverem em execução, mas não todos, confirme se você tem IPs de pods disponíveis para alocar para todos os nós do cluster. Você configura o tamanho dos CIDRs de pods alocáveis ao usar o IPAM do grupo de clusters com `clusterPoolIPv4PodCIDRList` na configuração do Cilium. O tamanho do CIDR por nó é configurado com a definição de `clusterPoolIPv4MaskSize` na configuração do Cilium. Consulte [Expanding the cluster pool](https://docs.cilium.io/en/stable/network/concepts/ipam/cluster-pool/#expanding-the-cluster-pool) na documentação do Cilium para obter mais informações. **O BGP do Cilium não está funcionando** Se você estiver usando o ambiente de gerenciamento do BGP do Cilium para anunciar os endereços de pod ou serviço na rede on-premises, você poderá usar os comandos a seguir da CLI do Cilium para verificar se o BGP está anunciando as rotas para os recursos. Para obter as etapas de instalação da CLI do Cilium, consulte [Install the Cilium CLI](https://docs.cilium.io/en/stable/gettingstarted/k8s-install-default/#install-the-cilium-cli) na documentação do Cilium. Caso o BGP esteja funcionando corretamente, você deverá ver os nós híbridos com o estado da sessão `established` na saída. Talvez seja necessário trabalhar com a equipe de rede para identificar os valores corretos para o AS local, AS do par e Endereço do par do ambiente. ``` cilium bgp peers ``` ``` cilium bgp routes ``` Se você estiver usando o BGP do Cilium para anunciar os IPs dos serviços com o tipo `LoadBalancer`, você deverá ter o mesmo rótulo tanto em `CiliumLoadBalancerIPPool` quanto no serviço, que deve ser usado no seletor de `CiliumBGPAdvertisement`. Um exemplo é mostrado abaixo. Observe que, se você estiver usando o BGP do Cilium para anunciar os IPs dos serviços com o tipo LoadBalancer, as rotas do BGP poderão ser interrompidas durante a reinicialização do agente do Cilium. Para obter mais informações, consulte [Failure Scenarios](https://docs.cilium.io/en/latest/network/bgp-control-plane/bgp-control-plane-operation/#failure-scenarios) na documentação do Cilium. **Serviço** ``` kind: Service apiVersion: v1 metadata: name: guestbook labels: app: guestbook spec: ports: - port: 3000 targetPort: http-server selector: app: guestbook type: LoadBalancer ``` **CiliumLoadBalancerIPPool** ``` apiVersion: cilium.io/v2alpha1 kind: CiliumLoadBalancerIPPool metadata: name: guestbook-pool labels: app: guestbook spec: blocks: - cidr: serviceSelector: matchExpressions: - { key: app, operator: In, values: [ guestbook ] } ``` **CiliumBGPAdvertisement** ``` apiVersion: cilium.io/v2alpha1 kind: CiliumBGPAdvertisement metadata: name: bgp-advertisements-guestbook labels: advertise: bgp spec: advertisements: - advertisementType: "Service" service: addresses: - ExternalIP - LoadBalancerIP selector: matchExpressions: - { key: app, operator: In, values: [ guestbook ] } ``` **Solução de problemas do Calico** Se você estiver tendo problemas ao executar o Calico em nós híbridos, consulte [as etapas de solução de problemas](https://docs.tigera.io/calico/latest/operations/troubleshoot/) na documentação do Calico. As seções abaixo abordam problemas que podem ser exclusivos da implantação do Calico em nós híbridos. A tabela abaixo resume os componentes do Calico e se eles são executados na rede de nós ou de pods por padrão. Se você configurou o Calico para usar NAT para tráfego de saída de pods, a rede on-premises deve estar configurada para rotear o tráfego para o CIDR de nós on-premises, e as tabelas de roteamento da VPC devem ser configuradas com uma rota para o CIDR de nós on-premises com o gateway de trânsito (TGW) ou o gateway privado virtual (VGW) como destino. Se você não estiver configurando o Calico para usar NAT para tráfego de saída de pods, a rede on-premises deverá estar configurada para rotear o tráfego para o CIDR de pods on-premises, e as tabelas de roteamento da VPC devem ser configuradas com uma rota para o CIDR de pods on-premises com o gateway de trânsito (TGW) ou o gateway privado virtual (VGW) como destino. | Componente | Rede | | --- | --- | | Servidor da API do Calico | Nó | | Calico Controllers for Kubernetes | Pod | | Agente de nós do Calico | Nó | | Calico `typha` | Nó | | Driver de nós da CSI do Calico | Pod | | Operador do Calico | Nó | **Recursos do Calico são programados ou executados em nós isolados** Os recursos do Calico que não são executados como um DaemonSet têm tolerâncias flexíveis por padrão que permitem que sejam programados em nós isolados que não estão prontos para programar ou executar pods. Você pode restringir as tolerâncias para os recursos do Calico que não são DaemonSet alterando a instalação do operador para incluir o abaixo. ``` installation: ... controlPlaneTolerations: - effect: NoExecute key: node.kubernetes.io/unreachable operator: Exists tolerationSeconds: 300 - effect: NoExecute key: node.kubernetes.io/not-ready operator: Exists tolerationSeconds: 300 calicoKubeControllersDeployment: spec: template: spec: tolerations: - effect: NoExecute key: node.kubernetes.io/unreachable operator: Exists tolerationSeconds: 300 - effect: NoExecute key: node.kubernetes.io/not-ready operator: Exists tolerationSeconds: 300 typhaDeployment: spec: template: spec: tolerations: - effect: NoExecute key: node.kubernetes.io/unreachable operator: Exists tolerationSeconds: 300 - effect: NoExecute key: node.kubernetes.io/not-ready operator: Exists tolerationSeconds: 300 ``` ## Solução de problemas de credenciais Para ativações híbridas do AWS SSM e AWS IAM Roles Anywhere, você pode validar se as credenciais do perfil do IAM de nós híbridos estão configuradas corretamente nos nós híbridos ao executar o comando a seguir nos nós híbridos. Confirme se o nome do nó e o nome do perfil do IAM de nós híbridos são os esperados. ``` sudo aws sts get-caller-identity ``` ``` { "UserId": "ABCDEFGHIJKLM12345678910:", "Account": "", "Arn": "arn:aws:sts:::assumed-role/" } ``` ** AWS Solução de problemas do Systems Manager (SSM** Se você estiver usando ativações híbridas do AWS SSM para as credenciais de nós híbridos, esteja ciente dos diretórios e artefatos do SSM a seguir que são instalados nos nós híbridos pelo `nodeadm`. Para obter mais informações sobre o SSM Agente, consulte [Trabalhar com o SSM Agent](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent.html) no *Guia do usuário do AWS Systems Manager*. | Descrição | Local | | --- | --- | | SSM agent | Ubuntu: `/snap/amazon-ssm-agent/current/amazon-ssm-agent` RHEL e AL2023: `/usr/bin/amazon-ssm-agent` | | Registros de atendentes do SSM | `/var/log/amazon/ssm` | | Credenciais AWS | `/root/.aws/credentials` | | CLI de configuração do SSM | `/opt/ssm/ssm-setup-cli` | **Reiniciar o SSM Agent** Alguns problemas podem ser resolvidos ao reiniciar o SSM Agent. Você pode usar os comandos abaixo para reiniciá-lo. **AL2023 e outros sistemas operacionais** ``` systemctl restart amazon-ssm-agent ``` **Ubuntu** ``` systemctl restart snap.amazon-ssm-agent.amazon-ssm-agent ``` **Verificar a conectividade com os endpoints do SSM** Confirme se você pode se conectar aos endpoints do SSM nos nós híbridos. Para obter uma lista de endpoints do SSM, consulte [AWS Systems Manager endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/ssm.html). Substitua `us-west-2` no comando abaixo pela região da AWS para sua ativação híbrida do AWS SSM. ``` ping ssm.us-west-2.amazonaws.com ``` **Visualizar o status da conexão das instâncias registradas do SSM** Você pode verificar o status da conexão das instâncias registradas com ativações híbridas do SSM com o comando da AWS CLI a seguir. Substitua o ID da máquina pelo ID da máquina da sua instância. ``` aws ssm get-connection-status --target mi-012345678abcdefgh ``` **Incompatibilidade da soma de verificação da CLI de configuração do SSM** Caso encontre um problema com a incompatibilidade da soma de verificação `ssm-setup-cli` ao executar `nodeadm install`, você deve confirmar que não há instalações mais antigas do SSM existentes no host. Se houver instalações mais antigas do SSM no host, remova-as e execute novamente `nodeadm install` para resolver o problema. ``` Failed to perform agent-installation/on-prem registration: error while verifying installed ssm-setup-cli checksum: checksum mismatch with latest ssm-setup-cli. ``` **do SSM `InvalidActivation` ** Se você vir um erro ao registrar a instância com o AWS SSM, confirme se `region`, `activationCode` e `activationId` em `nodeConfig.yaml` estão corretos. A região da AWS para o cluster do EKS deve corresponder à região da ativação híbrida do SSM. Se esses valores estiverem configurados incorretamente, você verá um erro semelhante ao abaixo. ``` ERROR Registration failed due to error registering the instance with AWS SSM. InvalidActivation ``` **`ExpiredTokenException` do SSM: o token de segurança incluído na solicitação está expirado** Se o SSM Agent não conseguir atualizar as credenciais, você poderá observar um `ExpiredTokenException`. Nesse cenário, se você conseguir se conectar aos endpoints do SSM nos nós híbridos, talvez seja necessário reiniciar o SSM Agent para forçar uma atualização da credencial. ``` "msg":"Command failed","error":"operation error SSM: DescribeInstanceInformation, https response error StatusCode: 400, RequestID: eee03a9e-f7cc-470a-9647-73d47e4cf0be, api error ExpiredTokenException: The security token included in the request is expired" ``` **Erro do SSM ao executar o comando de registro de máquina** Se você observar um erro ao registrar a máquina com o SSM, talvez seja necessário executar `nodeadm install` novamente para garantir que todas as dependências do SSM estejam instaladas corretamente. ``` "error":"running register machine command: , error: fork/exec /opt/aws/ssm-setup-cli: no such file or directory" ``` **do SSM `ActivationExpired` ** Durante a execução de `nodeadm init`, se você vir um erro ao registrar a instância com o SSM devido a uma ativação expirada, você precisará criar uma ativação híbrida do SSM, atualizar `nodeConfig.yaml` com `activationCode` e `activationId` da nova ativação híbrida do SSM e executar `nodeadm init` novamente. ``` "msg":"Command failed","error":"SSM activation expired. Please use a valid activation" ``` ``` ERROR Registration failed due to error registering the instance with AWS SSM. ActivationExpired ``` **O SSM falhou ao atualizar as credenciais em cache** Se você perceber uma falha na atualização das credenciais em cache, o arquivo `/root/.aws/credentials` pode ter sido excluído do host. Primeiro, verifique a ativação híbrida do SSM e certifique-se de que ela esteja ativa e que os nós híbridos estejam configurados corretamente para usar a ativação. Verifique os logs do SSM Agent em `/var/log/amazon/ssm` e execute novamente o comando `nodeadm init` depois de resolver o problema no lado do SSM. ``` "Command failed","error":"operation error SSM: DescribeInstanceInformation, get identity: get credentials: failed to refresh cached credentials" ``` **Limpar o SSM** Para remover o SSM Agent do host, você pode executar os comandos a seguir. ``` dnf remove -y amazon-ssm-agent sudo apt remove --purge amazon-ssm-agent snap remove amazon-ssm-agent rm -rf /var/lib/amazon/ssm/Vault/Store/RegistrationKey ``` ** AWS Solução de problemas do IAM Roles Anywhere** Se você estiver usando o AWS IAM Roles Anywhere para as credenciais dos nós híbridos, esteja ciente dos diretórios e artefatos a seguir que são instalados nos nós híbridos pelo `nodeadm`. Para obter mais informações sobre a solução de problemas do IAM Roles Anywhere, consulte [Troubleshooting AWS IAM Roles Anywhere identity and access](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/security_iam_troubleshoot.html) no *Guia do usuário do AWS IAM Roles Anywhere*. | Descrição | Local | | --- | --- | | CLI do IAM Roles Anywhere | `/usr/local/bin/aws_signing_helper` | | Local e nome padrão do certificado | `/etc/iam/pki/server.pem` | | Local e nome padrão da chave | `/etc/iam/pki/server.key` | **O IAM Roles Anywhere falhou ao atualizar as credenciais em cache** Se você observar uma falha na atualização das credenciais em cache, revise o conteúdo de `/etc/aws/hybrid/config` e confirme se o IAM Roles Anywhere foi configurado corretamente na sua configuração do `nodeadm`. Confirme se `/etc/iam/pki` existe. Cada nó deve ter um certificado e uma chave exclusivos. Por padrão, ao usar o IAM Roles Anywhere como provedor de credenciais, o `nodeadm` usa `/etc/iam/pki/server.pem` para o local e o nome do certificado e `/etc/iam/pki/server.key` para a chave privada. Talvez seja necessário criar os diretórios antes de colocar os certificados e as chaves nos diretórios com `sudo mkdir -p /etc/iam/pki`. Você pode verificar o conteúdo do certificado com o comando abaixo. ``` openssl x509 -text -noout -in server.pem ``` ``` open /etc/iam/pki/server.pem: no such file or directory could not parse PEM data Command failed {"error": "... get identity: get credentials: failed to refresh cached credentials, process provider error: error in credential_process: exit status 1"} ``` **IAM Roles Anywhere não autorizado a executar `sts:AssumeRole` ** Nos logs do `kubelet`, se você vir um problema de acesso negado para a operação `sts:AssumeRole` ao usar o IAM Roles Anywhere, verifique a política de confiança do perfil do IAM de nós híbridos para confirmar se a entidade principal do serviço do IAM Roles Anywhere tem permissão para assumir o perfil do IAM de nós híbridos. Além disso, confirme se o ARN da âncora de confiança está configurado corretamente na política de confiança do perfil do IAM de nós híbridos, e se este foi adicionado ao seu usuário do IAM Roles Anywhere. ``` could not get token: AccessDenied: User: ... is not authorized to perform: sts:AssumeRole on resource: ... ``` **IAM Roles Anywhere não autorizado a definir `roleSessionName` ** Nos logs do `kubelet`, se você vir um problema de acesso negado para definir `roleSessionName`, confirme que você definiu `acceptRoleSessionName` como true para seu usuário do IAM Roles Anywhere. ``` AccessDeniedException: Not authorized to set roleSessionName ``` ## Solução de problemas do sistema operacional ### RHEL **Falhas no registro do gerenciador de direitos ou assinaturas** Se você estiver executando `nodeadm install` e encontrar uma falha na instalação das dependências dos nós híbridos devido a problemas de registro de direitos, certifique-se de ter definido corretamente a senha e o nome de usuário do Red Hat no host. ``` This system is not registered with an entitlement server ``` ### Ubuntu **GLIBC não encontrado** Se estiver usando o Ubuntu como o sistema operacional e o IAM Roles Anywhere como o provedor de credenciais com nós híbridos e verificar um problema com o GLIBC não encontrado, você poderá instalar essa dependência manualmente para resolver o problema. ``` GLIBC_2.32 not found (required by /usr/local/bin/aws_signing_helper) ``` Execute os seguintes comandos para instalar a dependência: ``` ldd --version sudo apt update && apt install libc6 sudo apt install glibc-source ``` ### Bottlerocket Se o contêiner de administração do Bottlerocket estiver habilitado, você poderá acessá-lo via SSH para depuração avançada e solução de problemas com privilégios elevados. As seções a seguir contêm comandos que precisam ser executados no contexto do host do Bottlerocket. Quando estiver no contêiner de administração, você poderá executar `sheltie` para abrir um shell com privilégios totais de usuário-raiz no host do Bottlerocket. ``` sheltie ``` Você também pode executar os comandos nas seções a seguir a partir do shell do contêiner de administração prefixando cada comando com `sudo chroot /.bottlerocket/rootfs`. ``` sudo chroot /.bottlerocket/rootfs ``` **Usar o logdog para coletar logs** O Bottlerocket fornece o utilitário `logdog` para coletar logs e informações do sistema de forma eficiente para fins de solução de problemas. ``` logdog ``` O utilitário `logdog` reúne logs de vários locais em um host do Bottlerocket e os combina em um arquivo tarball. Por padrão, o arquivo tarball será criado em `/var/log/support/bottlerocket-logs.tar.gz` e pode ser acessado via contêineres do host em `/.bottlerocket/support/bottlerocket-logs.tar.gz`. **Acessar logs do sistema com journalctl** Você pode verificar o status dos vários serviços do sistema, como `kubelet`, `containerd`, etc., e visualizar seus logs com os comandos a seguir. A flag `-f` acompanhará os logs em tempo real. Para verificar o status do serviço `kubelet` e recuperar logs do `kubelet`, execute: ``` systemctl status kubelet journalctl -u kubelet -f ``` Para verificar o status do serviço `containerd` e recuperar os logs da instância orquestrada do `containerd`, execute: ``` systemctl status containerd journalctl -u containerd -f ``` Para verificar o status do serviço `host-containerd` e recuperar os logs da instância host do `containerd`, execute: ``` systemctl status host-containerd journalctl -u host-containerd -f ``` Para recuperar os logs dos contêineres de bootstrap e contêineres de host, execute: ``` journalctl _COMM=host-ctr -f ```