**Contribuisci a migliorare questa pagina** Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà. Per contribuire a questa guida per l'utente, scegli il GitHub ** link ** Modifica questa pagina su che si trova nel riquadro destro di ogni pagina. Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà. # Configurazione di webhook per nodi ibridi Questa pagina descrive in dettaglio le considerazioni sull’esecuzione di webhook con nodi ibridi. I webhook vengono utilizzati nelle applicazioni Kubernetes e nei progetti open source, come Load AWS Balancer Controller e CloudWatch Observability Agent, per eseguire funzionalità di mutazione e convalida in fase di esecuzione. **Reti di pod instradabili** Se riesci a rendere il CIDR del tuo pod on-premises instradabile sulla tua rete on-premises, puoi eseguire webhook su nodi ibridi. Esistono diverse tecniche che puoi utilizzare per rendere il CIDR del pod on-premises instradabile sulla tua rete on-premises, tra cui Border Gateway Protocol (BGP), route statiche o altre soluzioni di instradamento personalizzate. BGP è la soluzione consigliata in quanto è più scalabile e più facile da gestire rispetto alle soluzioni alternative che richiedono una configurazione personalizzata o manuale dei percorsi. AWS supporta le funzionalità BGP di Cilium e Calico per la pubblicità dei pod CIDR, vedi e per ulteriori informazioni. [Configurazione della CNI per nodi ibridi](hybrid-nodes-cni.md) [CIDR dei pod remoti instradabili](hybrid-nodes-concepts-kubernetes.md#hybrid-nodes-concepts-k8s-pod-cidrs) **Reti di pod non instradabili** Se *non* riesci a rendere il CIDR del tuo pod on-premises instradabile sulla tua rete on-premises e devi eseguire i webhook, ti consigliamo di eseguire tutti i webhook sui nodi cloud nello stesso cluster EKS dei nodi ibridi. ## Considerazioni per i cluster in modalità mista *I cluster in modalità mista * sono definiti come cluster EKS con nodi ibridi e nodi in esecuzione nel cloud. AWS Quando esegui un cluster in modalità mista, considera i seguenti consigli: + Esegui il VPC CNI sui nodi in AWS Cloud e Cilium o Calico sui nodi ibridi. Cilium e Calico non sono supportati da AWS quando vengono eseguiti su nodi in Cloud. AWS + Configura i webhook per l'esecuzione sui nodi nel cloud. AWS Scopri come configurare [Configurazione dei webhook per i componenti aggiuntivi](#hybrid-nodes-webhooks-add-ons) i webhook e i componenti aggiuntivi della community. AWS + Se le tue applicazioni richiedono che i pod in esecuzione su nodi in AWS Cloud comunichino direttamente con i pod in esecuzione su nodi ibridi («comunicazione est-ovest») e utilizzi il VPC CNI sui nodi in AWS Cloud e Cilium o Calico sui nodi ibridi, allora il tuo pod CIDR locale deve essere instradabile sulla tua rete locale. + Esegui almeno una replica di CoreDNS sui nodi in AWS Cloud e almeno una replica di CoreDNS sui nodi ibridi. + Configura la distribuzione del traffico del servizio per mantenerlo locale rispetto alla zona da cui proviene. Per ulteriori informazioni sulla Distribuzione del traffico del servizio, consulta [Configurazione della distribuzione del traffico del servizio](#hybrid-nodes-mixed-service-traffic-distribution). + Se utilizzi AWS Application Load Balancer (ALB) o Network Load Balancer (NLB) per il traffico dei carichi di lavoro in esecuzione su nodi ibridi, allora i target IP utilizzati con ALB o NLB devono essere instradabili da. AWS + Il componente aggiuntivo Metrics Server richiede la connettività dal piano di controllo EKS all’indirizzo IP del pod Metrics Server. Se esegui il componente aggiuntivo Metrics Server su nodi ibridi, il CIDR del pod on-premises deve essere instradabile sulla rete on-premises. + Per raccogliere metriche per i nodi ibridi utilizzando il Servizio gestito da Amazon per Prometheus (AMP), il CIDR del pod on-premises deve essere instradabile sulla rete on-premises. In alternativa, puoi utilizzare il collettore gestito AMP per le metriche e le risorse del piano di controllo EKS in esecuzione nel AWS cloud e il componente aggiuntivo AWS Distro for OpenTelemetry (ADOT) per raccogliere le metriche per i nodi ibridi. ## Configurazione di cluster in modalità mista Per visualizzare i webhook in fase di mutazione e convalida in esecuzione sul cluster, puoi visualizzare il tipo di risorsa **Estensioni** nel pannello **Risorse** della console EKS per il cluster oppure utilizzare i seguenti comandi. EKS riporta anche le metriche dei webhook nella dashboard di osservabilità del cluster, consulta [Monitora il tuo cluster con la dashboard di osservabilità](observability-dashboard.md) per ulteriori informazioni. ``` kubectl get mutatingwebhookconfigurations ``` ``` kubectl get validatingwebhookconfigurations ``` ### Configurazione della distribuzione del traffico del servizio Quando esegui cluster in modalità mista, ti consigliamo di utilizzare la [*Distribuzione del traffico del servizio*](https://kubernetes.io/docs/reference/networking/virtual-ips/#traffic-distribution) per mantenere il traffico del servizio locale rispetto alla zona da cui proviene. La Distribuzione del traffico del servizio (disponibile per le versioni 1.31 e successive di Kubernetes in EKS) è la soluzione consigliata rispetto al [Topology Aware Routing](https://kubernetes.io/docs/concepts/services-networking/topology-aware-routing/) perché è più prevedibile. Con la Distribuzione del traffico del servizio, gli endpoint integri della zona riceveranno tutto il traffico di quella zona. Con il Topology Aware Routing, ciascun servizio deve soddisfare diverse condizioni in quella zona per applicare il routing personalizzato, altrimenti indirizza il traffico in modo uniforme verso tutti gli endpoint. Se utilizzi Cilium come CNI, devi eseguire la CNI con il set `enable-service-topology` su `true` per abilitare la distribuzione del traffico del servizio. Puoi trasferire questa configurazione con il flag di installazione Helm `--set loadBalancer.serviceTopology=true` oppure puoi aggiornare un’installazione esistente con il comando CLI `cilium config set enable-service-topology true` di Cilium. L’agente Cilium in esecuzione su ciascun nodo deve essere riavviato dopo aver aggiornato la configurazione per un’installazione esistente. Nella sezione seguente è riportato un esempio di come configurare la distribuzione del traffico del servizio per il servizio CoreDNS, ti consigliamo di abilitare la stessa opzione per tutti i servizi del cluster per evitare traffico indesiderato tra gli ambienti. ### Configurazione delle repliche CoreDNS Se stai eseguendo un cluster in modalità mista con nodi ibridi e nodi nel AWS Cloud, ti consigliamo di avere almeno una replica CoreDNS sui nodi ibridi e almeno una replica CoreDNS sui tuoi nodi nel Cloud. AWS Per evitare problemi di latenza e di rete in una configurazione di cluster in modalità mista, puoi configurare il servizio CoreDNS in modo da preferire la replica CoreDNS più vicina con la [Distribuzione del traffico del servizio](https://kubernetes.io/docs/reference/networking/virtual-ips/#traffic-distribution). La *Distribuzione del traffico del servizio* (disponibile per le versioni 1.31 e successive di Kubernetes in EKS) è la soluzione consigliata rispetto al [Topology Aware Routing](https://kubernetes.io/docs/concepts/services-networking/topology-aware-routing/) perché è più prevedibile. Nella Distribuzione del traffico del servizio, gli endpoint integri della zona riceveranno tutto il traffico di quella zona. Nel Topology Aware Routing, ciascun servizio deve soddisfare diverse condizioni in quella zona per applicare il routing personalizzato, altrimenti indirizza il traffico in modo uniforme verso tutti gli endpoint. I seguenti passaggi configurano la Distribuzione del traffico del servizio. Se utilizzi Cilium come CNI, devi eseguire la CNI con il set `enable-service-topology` su `true` per abilitare la Distribuzione del traffico del servizio. Puoi trasferire questa configurazione con il flag di installazione Helm `--set loadBalancer.serviceTopology=true` oppure puoi aggiornare un’installazione esistente con il comando CLI `cilium config set enable-service-topology true` di Cilium. L’agente Cilium in esecuzione su ciascun nodo deve essere riavviato dopo aver aggiornato la configurazione per un’installazione esistente. 1. Aggiungi un’etichetta di zona topologica per ciascuno dei tuoi nodi ibridi, ad esempio `topology.kubernetes.io/zone: onprem`. In alternativa, puoi impostare l’etichetta nella fase `nodeadm init`, specificando l’etichetta nella configurazione di `nodeadm`. Consultare [Configurazione del nodo per personalizzare kubelet (Facoltativo)](hybrid-nodes-nodeadm.md#hybrid-nodes-nodeadm-kubelet). Nota, ai nodi in esecuzione nel AWS Cloud viene applicata automaticamente un'etichetta di zona topologica che corrisponde alla zona di disponibilità (AZ) del nodo. ``` kubectl label node {{hybrid-node-name}} topology.kubernetes.io/zone={{zone}} ``` 1. Aggiungi `podAntiAffinity` all’implementazione di CoreDNS con la chiave della zona di topologia. In alternativa, puoi configurare l’implementazione di CoreDNS durante l’installazione con i componenti aggiuntivi 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. Aggiungi l’impostazione `trafficDistribution: PreferClose` alla configurazione del servizio `kube-dns` per abilitare la Distribuzione del traffico del servizio. ``` kubectl patch svc kube-dns -n kube-system --type=merge -p '{ "spec": { "trafficDistribution": "PreferClose" } }' ``` 1. Puoi confermare che la Distribuzione del traffico del servizio è abilitata visualizzando le slice degli endpoint per il servizio `kube-dns`. Le sezioni degli endpoint devono mostrare gli `hints` per le etichette delle zone topologiche, a conferma che la Distribuzione del traffico del servizio è abilitata. Se non vedi l’`hints` per ciascun indirizzo degli endpoint, la Distribuzione del traffico del servizio non è abilitato. ``` kubectl get endpointslice -A | grep "kube-dns" ``` ``` kubectl get endpointslice {{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 ``` ### Configurazione dei webhook per i componenti aggiuntivi I seguenti componenti aggiuntivi utilizzano i webhook e sono supportati per l’uso con nodi ibridi. + AWS Load Balancer Controller + CloudWatch Agente di osservabilità + AWS Distro per OpenTelemetry (ADOT) + `cert-manager` Consulta le sezioni seguenti per configurare i webhook utilizzati da questi componenti aggiuntivi per l'esecuzione sui nodi in Cloud. AWS #### AWS Controller del sistema di bilanciamento del carico Per utilizzare il AWS Load Balancer Controller in una configurazione di cluster in modalità mista, è necessario eseguire il controller sui nodi in Cloud. AWS A tale scopo, aggiungi quanto segue alla configurazione dei valori di Helm o specifica i valori utilizzando la configurazione aggiuntiva EKS. ``` affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: eks.amazonaws.com/compute-type operator: NotIn values: - hybrid ``` #### CloudWatch Observability Agent L'add-on CloudWatch Observability Agent ha un operatore Kubernetes che utilizza webhook. Per eseguire l'operatore sui nodi in AWS Cloud in una configurazione di cluster in modalità mista, modifica la configurazione dell'operatore Observability Agent. CloudWatch Non puoi configurare l’affinità dell’operatore durante l’installazione con i componenti aggiuntivi Helm ed EKS (consulta [problema containers-roadmap \#2431](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 per OpenTelemetry (ADOT) L'add-on AWS Distro for OpenTelemetry (ADOT) ha un operatore Kubernetes che utilizza webhook. Per eseguire l'operatore sui nodi in AWS Cloud in una configurazione del cluster in modalità mista, aggiungi quanto segue alla configurazione dei valori di Helm o specifica i valori utilizzando la configurazione del componente aggiuntivo EKS. ``` affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: eks.amazonaws.com/compute-type operator: NotIn values: - hybrid ``` Se il CIDR del pod non è instradabile sulla rete on-premises, il collettore ADOT deve essere eseguito su nodi ibridi per acquisire le metriche dai nodi ibridi e dai carichi di lavoro in esecuzione su di essi. A tale scopo, modifica la Definizione di risorse personalizzate (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 ``` Puoi configurare il collettore ADOT per acquisire solo le metriche dai nodi ibridi e dalle risorse in esecuzione sui nodi ibridi aggiungendo il seguente `relabel_configs` a ciascun `scrape_configs` nella configurazione CRD del collettore ADOT. ``` relabel_configs: - action: keep regex: hybrid source_labels: - __meta_kubernetes_node_label_eks_amazonaws_com_compute_type ``` L'add-on ADOT ha un requisito preliminare da installare `cert-manager` per i certificati TLS utilizzati dal webhook dell'operatore ADOT. `cert-manager`esegue anche webhook ed è possibile configurarlo per l'esecuzione su nodi in AWS Cloud con la seguente configurazione dei valori Helm. ``` 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` L'`cert-manager`add-on esegue i webhook ed è possibile configurarlo per l'esecuzione su nodi in AWS Cloud con la seguente configurazione dei valori Helm. ``` 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 ```