**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à. # Risoluzione dei problemi delle politiche di rete Kubernetes per Amazon EKS Questa è la guida alla risoluzione dei problemi per la funzionalità di policy di rete di CNI di Amazon VPC. Questa guida illustra: + informazioni su installazione, autorizzazioni di CRD e RBAC [Nuovo CRD `policyendpoints` e autorizzazioni](#network-policies-troubleshooting-permissions) + log da esaminare durante la diagnosi dei problemi relativi alle politiche di rete [Log delle policy di rete](#network-policies-troubleshooting-flowlogs) + esecuzione della raccolta di strumenti SDK eBPF per la risoluzione dei problemi + Problemi noti e risoluzioni [Problemi noti e risoluzioni](#network-policies-troubleshooting-known-issues) **Nota** Tieni presente che le politiche di rete vengono applicate solo ai pod creati da *Implementazioni* di Kubernetes. Per ulteriori limitazioni delle politiche di rete nel CNI di VPC, consultare [Considerazioni](cni-network-policy.md#cni-network-policy-considerations). È possibile risolvere i problemi e analizzare le connessioni di rete che utilizzano le policy di rete leggendo i [log della policy di rete](#network-policies-troubleshooting-flowlogs) ed eseguendo gli strumenti da [eBPF SDK](#network-policies-ebpf-sdk). ## Nuovo CRD `policyendpoints` e autorizzazioni + CRD: `policyendpoints.networking.k8s.aws` + API di Kubernetes: `apiservice` ha chiamato `v1.networking.k8s.io` + Risorsa di Kubernetes: `Kind: NetworkPolicy` + RBAC: `ClusterRole` ha chiamato `aws-node` (CNI di VPC), `ClusterRole` ha chiamato `eks:network-policy-controller` (controller delle politiche di rete nel piano di controllo del cluster EKS) Per la politica di rete, CNI di VPC crea un nuovo `CustomResourceDefinition` (CRD) chiamato `policyendpoints.networking.k8s.aws`. Il CNI VPC deve disporre delle autorizzazioni per creare il CRD e creare CustomResources (CR) di questo e dell'altro CRD installato dal VPC CNI (). `eniconfigs.crd.k8s.amazonaws.com` [Entrambi sono disponibili nel file su. CRDs `crds.yaml`](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/charts/aws-vpc-cni/crds/customresourcedefinition.yaml) GitHub In particolare, CNI di VPC deve disporre delle autorizzazioni verbali “ottieni”, “elenco” e “guarda” per `policyendpoints`. La *politica di rete* di Kubernetes fa parte dei `apiservice` chiamato `v1.networking.k8s.io` e ciò è `apiversion: networking.k8s.io/v1` nei file YAML della politica. `DaemonSet` di CNI di VPC deve disporre delle autorizzazioni per utilizzare questa parte dell’API Kubernetes. Le autorizzazioni di CNI di VPC sono disponibili in un `ClusterRole` chiamato `aws-node`. Si noti che gli oggetti `ClusterRole` non sono raggruppati in namespace. Di seguito, è illustrato il `aws-node` di un cluster: ``` kubectl get clusterrole aws-node -o yaml ``` ``` apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: labels: app.kubernetes.io/instance: aws-vpc-cni app.kubernetes.io/managed-by: Helm app.kubernetes.io/name: aws-node app.kubernetes.io/version: v1.19.4 helm.sh/chart: aws-vpc-cni-1.19.4 k8s-app: aws-node name: aws-node rules: - apiGroups: - crd.k8s.amazonaws.com resources: - eniconfigs verbs: - list - watch - get - apiGroups: - "" resources: - namespaces verbs: - list - watch - get - apiGroups: - "" resources: - pods verbs: - list - watch - get - apiGroups: - "" resources: - nodes verbs: - list - watch - get - apiGroups: - "" - events.k8s.io resources: - events verbs: - create - patch - list - apiGroups: - networking.k8s.aws resources: - policyendpoints verbs: - get - list - watch - apiGroups: - networking.k8s.aws resources: - policyendpoints/status verbs: - get - apiGroups: - vpcresources.k8s.aws resources: - cninodes verbs: - get - list - watch - patch ``` Inoltre, un nuovo controller è avviato nel piano di controllo di ciascun cluster EKS. Il controller utilizza le autorizzazioni del `ClusterRole` chiamato `eks:network-policy-controller`. Di seguito, è illustrato il `eks:network-policy-controller` di un cluster: ``` kubectl get clusterrole eks:network-policy-controller -o yaml ``` ``` apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: labels: app.kubernetes.io/name: amazon-network-policy-controller-k8s name: eks:network-policy-controller rules: - apiGroups: - "" resources: - namespaces verbs: - get - list - watch - apiGroups: - "" resources: - pods verbs: - get - list - watch - apiGroups: - "" resources: - services verbs: - get - list - watch - apiGroups: - networking.k8s.aws resources: - policyendpoints verbs: - create - delete - get - list - patch - update - watch - apiGroups: - networking.k8s.aws resources: - policyendpoints/finalizers verbs: - update - apiGroups: - networking.k8s.aws resources: - policyendpoints/status verbs: - get - patch - update - apiGroups: - networking.k8s.io resources: - networkpolicies verbs: - get - list - patch - update - watch ``` ## Log delle policy di rete Ciascuna decisione da parte di CNI di VPC relativamente al fatto che le connessioni sono consentite o negate da una policy di rete è registrata da *log di flusso*. I log delle policy di rete su ogni nodo includono i log di flusso per ogni pod che dispone di una policy di rete. I log delle policy di rete sono archiviati in `/var/log/aws-routed-eni/network-policy-agent.log`. Di seguito è riportato un esempio del file `network-policy-agent.log`: ``` {"level":"info","timestamp":"2023-05-30T16:05:32.573Z","logger":"ebpf-client","msg":"Flow Info: ","Src IP":"192.168.87.155","Src Port":38971,"Dest IP":"64.6.160","Dest Port":53,"Proto":"UDP","Verdict":"ACCEPT"} ``` I log della policy di rete sono disabilitati per impostazione predefinita. Per abilitare i log della policy di rete, segui i passaggi riportati di seguito: **Nota** I log delle policy di rete richiedono 1 vCPU aggiuntiva per il container `aws-network-policy-agent` nel manifesto `aws-node` `DaemonSet` di CNI di VPC. ### Componenti aggiuntivi di Amazon EKS ** Console di gestione AWS ** 1. Aprire la [Console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters). 1. Nel riquadro di navigazione a sinistra, seleziona **Cluster**, quindi seleziona il nome del cluster per cui desideri configurare il componente aggiuntivo CNI di Amazon VPC. 1. Selezionare la scheda **Componenti aggiuntivi**. 1. Selezionare la casella nella parte superiore destra della casella del componente aggiuntivo e scegli **Modifica**. 1. Nella pagina **Configura {{Amazon VPC CNI}}**: 1. Seleziona una `v1.14.0-eksbuild.3` o versione successiva nell'elenco a discesa **Versione**. 1. Scegli **Impostazioni di configurazione facoltative**. 1. Inserisci la chiave JSON di primo livello `"nodeAgent":` e il valore, che è un oggetto con una chiave`"enablePolicyEventLogs":` e un valore di `"true"` nei **Valori di configurazione**. Il testo risultante deve essere un oggetto JSON valido. L'esempio seguente mostra i criteri di rete e i registri dei criteri di rete sono abilitati e i registri dei criteri di rete vengono inviati a CloudWatch Logs: ``` { "enableNetworkPolicy": "true", "nodeAgent": { "enablePolicyEventLogs": "true" } } ``` Lo screenshot seguente mostra un esempio di tale scenario. ![mostrando il componente aggiuntivo VPC CNI con policy di rete e CloudWatch log nella configurazione opzionale.](http://docs.aws.amazon.com/it_it/eks/latest/userguide/images/console-cni-config-network-policy-logs.png) AWS CLI 1. Esegui il seguente comando AWS CLI. Sostituisci `my-cluster` con il nome del cluster e l'ARN del ruolo IAM con il ruolo che stai utilizzando. ``` aws eks update-addon --cluster-name my-cluster --addon-name vpc-cni --addon-version v1.14.0-eksbuild.3 \ --service-account-role-arn arn:aws: iam::123456789012:role/AmazonEKSVPCCNIRole \ --resolve-conflicts PRESERVE --configuration-values '{"nodeAgent": {"enablePolicyEventLogs": "true"}}' ``` ### Componenti aggiuntivi autogestiti Helm Se il plugin CNI di Amazon VPC per Kubernetes è stato installato attraverso`helm`, è possibile aggiornare la configurazione per scrivere i log della policy di rete. 1. Esegui il comando seguente per abilitare la policy di rete. ``` helm upgrade --set nodeAgent.enablePolicyEventLogs=true aws-vpc-cni --namespace kube-system eks/aws-vpc-cni ``` kubectl Se il plugin CNI di Amazon VPC per Kubernetes è stato installato attraverso`kubectl`, è possibile aggiornare la configurazione per scrivere i log della policy di rete. 1. Apri la `DaemonSet` del `aws-node` nell’editor. ``` kubectl edit daemonset -n kube-system aws-node ``` 1. Sostituisci il valore `false` con `true` nell’argomento del comando `--enable-policy-event-logs=false` in `args:` nel container `aws-network-policy-agent` nel manifesto `aws-node` `DaemonSet` di CNI di VPC. ``` - args: - --enable-policy-event-logs=true ``` ### Invia i log delle policy di rete ad Amazon CloudWatch Logs Puoi monitorare i log delle politiche di rete utilizzando servizi come Amazon CloudWatch Logs. Puoi utilizzare i seguenti metodi per inviare i log delle politiche di rete a Logs. CloudWatch Per i cluster EKS, i log delle policy si troveranno in `/aws/eks/{{cluster-name}}/cluster/`, mentre per i cluster K8S autogestiti i log verranno collocati in `/aws/k8s-cluster/cluster/`. #### Invio dei log della policy di rete con il plugin CNI di Amazon VPC per Kubernetes Se si abilitano le policy di rete, ai pod viene aggiunto un secondo container `aws-node` per un *agente del nodo*. Questo agente del nodo può inviare i registri delle politiche di rete a Logs. CloudWatch **Nota** Solo i log delle policy di rete vengono inviati dall'agente del nodo. Gli altri log creati dalla CNI di VPC non sono inclusi. ##### Prerequisiti + Aggiungi le seguenti autorizzazioni come strofa o policy separata al ruolo IAM che stai utilizzando per la CNI di VPC. ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": [ "logs:DescribeLogGroups", "logs:CreateLogGroup", "logs:CreateLogStream", "logs:PutLogEvents" ], "Resource": "*" } ] } ``` ##### Componenti aggiuntivi di Amazon EKS ** Console di gestione AWS ** 1. Aprire la [Console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters). 1. Nel riquadro di navigazione a sinistra, seleziona **Cluster**, quindi seleziona il nome del cluster per cui desideri configurare il componente aggiuntivo CNI di Amazon VPC. 1. Selezionare la scheda **Componenti aggiuntivi**. 1. Selezionare la casella nella parte superiore destra della casella del componente aggiuntivo e scegli **Modifica**. 1. Nella pagina **Configura {{Amazon VPC CNI}}**: 1. Seleziona una `v1.14.0-eksbuild.3` o versione successiva nell'elenco a discesa **Versione**. 1. Scegli **Impostazioni di configurazione facoltative**. 1. Inserisci la chiave JSON di primo livello `"nodeAgent":` e il valore, che è un oggetto con una chiave`"enableCloudWatchLogs":` e un valore di `"true"` nei **Valori di configurazione**. Il testo risultante deve essere un oggetto JSON valido. L'esempio seguente mostra i criteri di rete e i registri dei criteri di rete sono abilitati e i log vengono inviati a Logs: CloudWatch ``` { "enableNetworkPolicy": "true", "nodeAgent": { "enablePolicyEventLogs": "true", "enableCloudWatchLogs": "true", } } ``` Lo screenshot seguente mostra un esempio di tale scenario. ![mostrando il componente aggiuntivo VPC CNI con policy di rete e CloudWatch log nella configurazione opzionale.](http://docs.aws.amazon.com/it_it/eks/latest/userguide/images/console-cni-config-network-policy-logs-cwl.png) ** AWS CLI** 1. Esegui il seguente comando AWS CLI. Sostituisci `my-cluster` con il nome del cluster e l'ARN del ruolo IAM con il ruolo che stai utilizzando. ``` aws eks update-addon --cluster-name my-cluster --addon-name vpc-cni --addon-version v1.14.0-eksbuild.3 \ --service-account-role-arn arn:aws: iam::123456789012:role/AmazonEKSVPCCNIRole \ --resolve-conflicts PRESERVE --configuration-values '{"nodeAgent": {"enablePolicyEventLogs": "true", "enableCloudWatchLogs": "true"}}' ``` ##### Componenti aggiuntivi autogestiti **Timone** Se hai installato il plug-in Amazon VPC CNI per Kubernetes tramite`helm`, puoi aggiornare la configurazione per inviare i log delle politiche di rete a Logs. CloudWatch 1. Esegui il comando seguente per abilitare i log delle politiche di rete e inviarli a Logs. CloudWatch ``` helm upgrade --set nodeAgent.enablePolicyEventLogs=true --set nodeAgent.enableCloudWatchLogs=true aws-vpc-cni --namespace kube-system eks/aws-vpc-cni ``` **kubectl** 1. Apri la `DaemonSet` del `aws-node` nell’editor. ``` kubectl edit daemonset -n kube-system aws-node ``` 1. Sostituisci `false` con `true` in due argomenti del comando `--enable-policy-event-logs=false` e `--enable-cloudwatch-logs=false` nel `args:` nel container `aws-network-policy-agent` nel manifesto `aws-node` `DaemonSet` di CNI di VPC. ``` - args: - --enable-policy-event-logs=true - --enable-cloudwatch-logs=true ``` #### Invio dei log delle policy di rete con Fluent Bit `DaemonSet` Se stai utilizzando Fluent Bit in `DaemonSet` per inviare i log dai nodi, è possibile aggiungere una configurazione che includa i log delle policy di rete provenienti dalle policy di rete. È possibile utilizzare la configurazione di esempio seguente: ``` [INPUT] Name tail Tag eksnp.* Path /var/log/aws-routed-eni/network-policy-agent*.log Parser json DB /var/log/aws-routed-eni/flb_npagent.db Mem_Buf_Limit 5MB Skip_Long_Lines On Refresh_Interval 10 ``` ## SDK ebPF incluso Il plugin CNI di Amazon VPC per Kubernetes installa la raccolta di strumenti dell’SDK eBPF sui nodi. È possibile utilizzare gli strumenti dell’SDK eBPF per identificare i problemi relativi alle policy di rete. Ad esempio, il comando seguente elenca i programmi in esecuzione sul nodo. ``` sudo /opt/cni/bin/aws-eks-na-cli ebpf progs ``` Per eseguire questo comando, è possibile utilizzare qualsiasi metodo di connessione al nodo. ## Problemi noti e risoluzioni Le seguenti sezioni descrivono i problemi noti con la funzionalità di policy di rete CNI di Amazon VPC e le relative soluzioni. ### Registri delle politiche di rete generati nonostante l'impostazione sia impostata su false enable-policy-event-logs **Problema**: CNI di VPC EKS genera log delle politiche di rete anche quando l’impostazione `enable-policy-event-logs` è impostata su `false`. **Soluzione**: l’impostazione `enable-policy-event-logs` disabilita solo i log delle “decisioni” delle politiche, ma non disabilita tutta la registrazione degli agenti della policy di rete. Questo comportamento è documentato nel [aws-network-policy-agent README](https://github.com/aws/aws-network-policy-agent/) on. GitHub Per disabilitare completamente la registrazione, potrebbe essere necessario modificare altre configurazioni di registrazione. ### Problemi di pulizia della mappa della policy di rete **Problema**: la rete `policyendpoint` è ancora esistente e non è ripulita dopo l’eliminazione dei pod. **Soluzione**: questo problema è stato causato da un problema con il componente aggiuntivo di CNI di VPC versione 1.19.3-eksbuild.1. Per risolvere questo problema, esegui l’aggiornamento a una versione più recente del componente aggiuntivo CNI di VPC. ### Le politiche di rete non sono applicate **Problema**: la funzionalità della policy di rete è abilitata nel plugin CNI di Amazon VPC, ma le policy di rete non sono applicate correttamente. Se crei una policy di rete `kind: NetworkPolicy` e questa non influisce sul pod, verifica che l’oggetto policyendpoint sia stato creato nello stesso namespace del pod. Se non ci sono oggetti `policyendpoint` nei namespace, il controller della policy di rete (parte del cluster EKS) non è stato in grado di creare regole di policy di rete per l’agente delle policy di rete (parte del CNI di VPC) da applicare. **Soluzione**: la soluzione consiste nel correggere le autorizzazioni del CNI di VPC (`ClusterRole` : `aws-node`) e del controller delle policy di rete (`ClusterRole` : `eks:network-policy-controller`) e consentire queste azioni in qualsiasi strumento di applicazione delle policy come Kyverno. Assicurati che le policy di Kyverno non blocchino la creazione di oggetti `policyendpoint`. Vedi la sezione precedente per le autorizzazioni in cui sono necessarie le autorizzazioni in [Nuovo CRD `policyendpoints` e autorizzazioni](#network-policies-troubleshooting-permissions). ### I pod non tornano allo stato di negazione predefinito dopo l’eliminazione della policy in modalità rigida **Problema**: quando i criteri di rete sono abilitati in modalità rigida, i pod iniziano con una politica di negazione predefinita. Dopo l’applicazione delle politiche, il traffico è consentito verso gli endpoint specificati. Tuttavia, quando le policy sono eliminate, il pod non torna allo stato di negazione predefinito, invece passa allo stato di autorizzazione predefinito. **Soluzione**: questo problema è stato risolto in CNI di VPC versione 1.19.3, che includeva l’agente di policy di rete versione 1.2.0. Dopo la correzione, con la modalità rigida abilitata, una volta rimosse le policy, il pod tornerà allo stato di negazione predefinito come previsto. ### Latenza di avvio dei gruppi di sicurezza for pod **Problema**: quando si utilizza la funzionalità dei gruppi di sicurezza per pod in EKS, la latenza di avvio dei pod aumenta. **Soluzione**: la latenza è dovuta alla limitazione della velocità nel controller di risorse dovuta alla limitazione dell'API sull'`CreateNetworkInterface`API, che il controller di risorse VPC utilizza per creare un ramo per i pod. ENIs Verifica i limiti delle API del tuo account per questa operazione e, se necessario, valuta la possibilità di richiedere un aumento del limite. ### FailedScheduling a causa dell'insufficienza di vpc.amazonaws.com/pod-eni **Problema**: i pod non riescono a pianificarsi con l’errore: `FailedScheduling 2m53s (x28 over 137m) default-scheduler 0/5 nodes are available: 5 Insufficient vpc.amazonaws.com/pod-eni. preemption: 0/5 nodes are available: 5 No preemption victims found for incoming pod.` **Soluzione**: come nel problema precedente, l’assegnazione dei gruppi di sicurezza ai pod aumenta la latenza di pianificazione dei pod e può superare la soglia CNI necessaria per aggiungere ogni ENI, causando il mancato avvio dei pod. Questo è il comportamento previsto quando si utilizzano i gruppi di sicurezza per pod. Considera le implicazioni di pianificazione durante la progettazione dell’architettura del carico di lavoro. ### Problemi di connettività IPAM ed errori di segmentazione **Problema**: si verificano molteplici errori, tra cui problemi di connettività IPAM, richieste di limitazione ed errori di segmentazione: + `Checking for IPAM connectivity …​` + `Throttling request took 1.047064274s` + `Retrying waiting for IPAM-D` + `panic: runtime error: invalid memory address or nil pointer dereference` **Soluzione**: questo problema si verifica se si installa `systemd-udev` su AL2 023, poiché il file viene riscritto con una politica non conforme. Ciò può accadere quando si esegue l’aggiornamento a un `releasever` diverso che ha un pacchetto aggiornato o si aggiorna manualmente il pacchetto stesso. Evita l'installazione o l'aggiornamento `systemd-udev` sui nodi AL2 023. ### Errore di ricerca del dispositivo in base al nome non riuscito **Problema**: messaggio di errore: `{"level":"error","ts":"2025-02-05T20:27:18.669Z","caller":"ebpf/bpf_client.go:578","msg":"failed to find device by name eni9ea69618bf0: %!w(netlink.LinkNotFoundError={0xc000115310})"}` **Soluzione**: questo problema è stato identificato e risolto nelle versioni più recenti dell’agente di policy di rete CNI di Amazon VPC (v1.2.0). Per risolvere questo problema, effettua l’aggiornamento alla versione più recente di CNI di VPC. ### Vulnerabilità di CVE nell’immagine Multus CNI **Problema**: Enhanced EKS ImageScan CVE Report identifica le vulnerabilità nella versione dell'immagine Multus CNI v4.1.4-eksbuild.2\_thick. **Soluzione**: esegui l’aggiornamento alla nuova versione dell’immagine Multus CNI e alla nuova immagine del controller della policy di rete, che non presentano vulnerabilità. Lo scanner può essere aggiornato per risolvere le vulnerabilità rilevate nella versione precedente. ### Le informazioni sul flusso NEGANO i verdetti nei log **Problema**: i log delle politiche di rete mostrano i verdetti di NEGAZIONE: `{"level":"info","ts":"2024-11-25T13:34:24.808Z","logger":"ebpf-client","caller":"events/events.go:193","msg":"Flow Info: ","Src IP":"","Src Port":9096,"Dest IP":"","Dest Port":56830,"Proto":"TCP","Verdict":"DENY"}` **Soluzione**: questo problema è stato risolto nella nuova versione di controller della policy di rete. Effettua l’aggiornamento alla versione più recente della piattaforma EKS per risolvere i problemi di registrazione. ### Pod-to-pod problemi di comunicazione dopo la migrazione da Calico **Problema**: dopo l'aggiornamento di un cluster EKS alla versione 1.30 e il passaggio da Calico ad Amazon VPC CNI per le policy di rete pod-to-pod, la comunicazione fallisce quando vengono applicate le policy di rete. La comunicazione è ripristinata quando le policy di rete sono eliminate. **Soluzione**: l’agente di policy di rete nel CNI di VPC non può avere tante porte specificate quante ne ha Calico. Invece, utilizza gli intervalli di porte nelle policy di rete. Il numero massimo di combinazioni univoche di porte per ogni protocollo `ingress:` o `egress:` selettore in una politica di rete è 24. Utilizza gli intervalli di porte per ridurre il numero di porte uniche ed evitare questa limitazione. ### L’agente della policy di rete non supporta i pod autonomi **Problema**: le policy di rete applicate ai pod autonomi possono avere un comportamento incoerente. **Soluzione**: attualmente l’agente della policy di rete supporta solo i pod distribuiti come parte di un set di implementazione/replica. Se le policy di rete sono applicate ai pod autonomi, potrebbero esserci delle incongruenze nel comportamento. Questo è documentato nella parte superiore di questa pagina[Considerazioni](cni-network-policy.md#cni-network-policy-considerations), nel e nel [aws-network-policy-agent GitHub numero \#327 successivo](https://github.com/aws/aws-network-policy-agent/issues/327). GitHub Implementa i pod come parte di un’implementazione o di un set di replica per un comportamento coerente delle policy di rete.