**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. # Configurar webhooks para nós híbridos 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 ```