**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** 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 il Controller del bilanciatore del carico di AWS e l’agente osservabilità di CloudWatch, per eseguire funzionalità di mutazione e convalida in fase di runtime. **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. Il BGP è la soluzione consigliata in quanto è più scalabile e facile da gestire rispetto alle soluzioni alternative che richiedono una configurazione del percorso personalizzata o manuale. AWS supporta le funzionalità BGP di Cilium e Calico per la pubblicità dei CIDR dei pod, consulta [Configurazione della CNI per nodi ibridi](hybrid-nodes-cni.md) e [CIDR dei pod remoti instradabili](hybrid-nodes-concepts-kubernetes.md#hybrid-nodes-concepts-k8s-pod-cidrs) per ulteriori informazioni. **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 la CNI del VPC sui nodi nel cloud AWS e Cilium o Calico sui nodi ibridi. Cilium e Calico non sono supportati da AWS quando vengono eseguiti su nodi in nel cloud AWS. + Configura i webhook per l’esecuzione su nodi nel cloud AWS. Consulta [Configurazione dei webhook per i componenti aggiuntivi](#hybrid-nodes-webhooks-add-ons) su come configurare i webhook per e i componenti aggiuntivi di AWS e della community. + Se le tue applicazioni richiedono pod in esecuzione su nodi nel cloud AWS per comunicare direttamente con pod in esecuzione su nodi ibridi (“comunicazione est-ovest”) e utilizzi la CNI del VPC sui nodi nel cloud AWS e Cilium o Calico sui nodi ibridi, il CIDR del tuo pod on-premises deve essere instradabile sulla tua rete on-premises. + Esegui almeno una replica di CoreDNS sui nodi nel cloud AWS 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 Application Load Balancer (ALB) o Network Load Balancer (NLB) di AWS per il traffico del carico di lavoro in esecuzione su nodi ibridi, è necessario che sia possibile instradare le destinazioni IP utilizzate con ALB o NLB 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 cloud AWS e il componente aggiuntivo Distro for OpenTelemetry (ADOT) di AWS per raccogliere 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 [https://kubernetes.io/docs/reference/networking/virtual-ips/#traffic-distribution](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 cloud AWS, ti consigliamo di avere almeno una replica CoreDNS sui nodi ibridi e almeno una 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). Attenzione, ai nodi in esecuzione nel cloud AWS 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 [.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 ``` ### Configurazione dei webhook per i componenti aggiuntivi I seguenti componenti aggiuntivi utilizzano i webhook e sono supportati per l’uso con nodi ibridi. + Controller del bilanciatore del carico AWS + Agente osservabilità di CloudWatch + Distro for OpenTelemetry (ADOT) di AWS + `cert-manager` Consulta le seguenti sezioni per configurare i webhook utilizzati da questi componenti aggiuntivi per l’esecuzione su nodi nel cloud AWS. #### Controller del bilanciatore del carico AWS Per utilizzare il Controller del bilanciatore del carico di AWS in una configurazione di cluster in modalità mista, devi eseguire il controller sui nodi nel 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 ``` #### Agente osservabilità di CloudWatch Il componente aggiuntivo Agente osservabilità di CloudWatch dispone di un operatore Kubernetes che utilizza webhook. Per eseguire l’operatore sui nodi nel cloud AWS in una configurazione di cluster in modalità mista, modifica la configurazione dell’operatore Agente osservabilità di 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 ``` #### Distro for OpenTelemetry (ADOT) di AWS Il componente aggiuntivo Distro for OpenTelemetry (ADOT) di AWS dispone di un operatore Kubernetes che utilizza i webhook. Per eseguire l’operatore sui nodi nel cloud AWS in una configurazione di cluster in modalità mista, 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 ``` 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 ``` Il componente aggiuntivo ADOT presenta un requisito preliminare per installare `cert-manager` per i certificati TLS utilizzati dal webhook dell’operatore ADOT. `cert-manager` esegue anche webhook e puoi configurarlo per l’esecuzione su nodi nel cloud AWS 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` Il componente aggiuntivo `cert-manager` esegue i webhook e puoi configurarlo per l’esecuzione su nodi nel cloud AWS 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 ```