**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. # Configuração de complementos para nós híbridos 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).