Aiutaci 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 Amazon VPC CNI.

Questa guida tratta:

È possibile risolvere i problemi e analizzare le connessioni di rete che utilizzano i criteri di rete leggendo i registri dei criteri di rete ed eseguendo gli strumenti di eBPF SDK.

Nuovo CRD e autorizzazioni policyendpoints

Per la politica di rete, il VPC CNI 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 GitHub In particolare, il CNI VPC deve disporre delle autorizzazioni verbali «get», «list» e «watch» per. policyendpoints

La politica di rete Kubernetes fa parte dei file YAML apiservice chiamati e si trova nei file v1.networking.k8s.io YAML della politica. apiversion: networking.k8s.io/v1 Il CNI VPC DaemonSet deve disporre delle autorizzazioni per utilizzare questa parte dell'API Kubernetes.

Le autorizzazioni VPC CNI sono disponibili in una chiamata. ClusterRole aws-node Nota che ClusterRole gli oggetti non sono raggruppati in namespace. Di seguito viene illustrato il profilo di un clusteraws-node:

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 viene eseguito nel piano di controllo di ogni cluster EKS. Il controller utilizza le autorizzazioni del ClusterRole chiamatoeks:network-policy-controller. Di seguito viene illustrato il profilo 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

Ogni decisione del CNI VPC se le connessioni sono consentite o negate da una politica di rete viene registrata nei 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 registri delle politiche di rete sono disabilitati per impostazione predefinita. Per abilitare i registri delle politiche di rete, procedi nel seguente modo:

Componenti aggiuntivi di Amazon EKS

Lo screenshot seguente mostra un esempio di tale scenario.

Componenti aggiuntivi autogestiti

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 registri delle politiche si troveranno sotto /aws/eks/cluster-name/cluster/ e per i cluster K8S autogestiti, i log verranno posizionati sotto. /aws/k8s-cluster/cluster/

Invia i log delle policy di rete con il plug-in Amazon VPC CNI 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 log delle politiche di rete a Logs. CloudWatch

Prerequisiti

Componenti aggiuntivi di Amazon EKS

Componenti aggiuntivi autogestiti

Invia i registri delle politiche di rete con un Fluent Bit DaemonSet

Se utilizzi Fluent Bit in DaemonSet a per inviare i log dai tuoi nodi, puoi aggiungere una configurazione per includere i registri delle politiche di rete provenienti dalle politiche 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 plug-in Amazon VPC CNI per Kubernetes installa la raccolta di strumenti eBPF SDK sui nodi. È possibile utilizzare gli strumenti SDK di eBPF per identificare i problemi relativi alle politiche 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 e soluzioni noti

Le seguenti sezioni descrivono i problemi noti con la funzionalità di policy di rete CNI di Amazon VPC e le relative soluzioni.

I log delle policy di rete sono stati generati nonostante enable-policy-event-logs l'impostazione sia impostata su false

Problema: EKS VPC CNI genera registri delle politiche di rete anche quando l'enable-policy-event-logsimpostazione è impostata su. false

Soluzione: l'enable-policy-event-logsimpostazione disabilita solo i registri delle «decisioni» delle politiche, ma non disabilita tutta la registrazione degli agenti di Network Policy. Questo comportamento è documentato nel README on. aws-network-policy-agent GitHub Per disabilitare completamente la registrazione, potrebbe essere necessario modificare altre configurazioni di registrazione.

Problemi di pulizia della mappa delle politiche di rete

Problema: la rete policyendpoint è ancora esistente e non viene ripulita dopo l'eliminazione dei pod.

Soluzione: questo problema è stato causato da un problema con il componente aggiuntivo VPC CNI versione 1.19.3-eksbuild.1. Esegui l'aggiornamento a una versione più recente del componente aggiuntivo VPC CNI per risolvere questo problema.

Le politiche di rete non vengono applicate

Problema: la funzionalità delle policy di rete è abilitata nel plug-in Amazon VPC CNI, ma le policy di rete non vengono 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 policyendpoint oggetti nei namespace, il controller delle 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 VPC) da applicare.

Soluzione: la soluzione consiste nel fissare le autorizzazioni del VPC CNI ClusterRole (aws-node:) e del controller delle politiche di rete ClusterRole (eks:network-policy-controller:) e consentire queste azioni in qualsiasi strumento di applicazione delle policy come Kyverno. Assicurati che le politiche di Kyverno non blocchino la creazione di oggetti. policyendpoint Vedi la sezione precedente per le autorizzazioni in cui sono necessarie le autorizzazioni. Nuovo CRD e autorizzazioni policyendpoints

I pod non tornano allo stato di negazione predefinito dopo l'eliminazione della policy in modalità rigorosa

Problema: quando i criteri di rete sono abilitati in modalità rigorosa, 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 vengono eliminate, il pod non torna allo stato di negazione predefinito e passa invece allo stato di autorizzazione predefinito.

Soluzione: questo problema è stato risolto nella versione 1.19.3 di VPC CNI, che includeva la versione 1.2.0 di Network Policy Agent. Dopo la correzione, con la modalità rigorosa abilitata, una volta rimosse le policy, il pod tornerà allo stato di negazione predefinito come previsto.

Latenza di avvio di Security Groups for Pods

Problema: quando si utilizza la funzionalità Security Groups for Pods 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'CreateNetworkInterfaceAPI, 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 programmarsi 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 utilizza Security Groups for Pods. Considerate le implicazioni di pianificazione durante la progettazione dell'architettura del carico di lavoro.

Problemi di connettività IPAM e errori di segmentazione

Problema: si verificano diversi errori, tra cui problemi di connettività IPAM, richieste di limitazione ed errori di segmentazione:

Soluzione: questo problema si verifica se si installa systemd-udev su AL2 023, poiché il file viene riscritto con una politica non conforme. Questo può verificarsi quando si esegue l'aggiornamento a un altro releasever pacchetto con un pacchetto aggiornato o si aggiorna manualmente il pacchetto stesso. Evita l'installazione o l'aggiornamento systemd-udev su AL2 023 nodi.

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 ultime versioni dell'agente di policy di rete Amazon VPC CNI (v1.2.0). Effettua l'aggiornamento alla versione più recente di VPC CNI per risolvere questo problema.

Vulnerabilità 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: eseguire l'aggiornamento alla nuova versione dell'immagine Multus CNI e alla nuova immagine Network Policy Controller, che non presentano vulnerabilità. Lo scanner può essere aggiornato per risolvere le vulnerabilità rilevate nella versione precedente.

Flow Info: nega i verdetti nei log

Problema: i registri delle politiche di rete mostrano i verdetti DENY: {"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 Network Policy Controller. 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 viene ripristinata quando le politiche di rete vengono eliminate.

Soluzione: l'agente di policy di rete nel CNI VPC non può avere tante porte specificate quante ne ha Calico. Utilizza invece gli intervalli di porte nelle politiche 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.

Network Policy Agent non supporta i pod autonomi

Problema: i criteri di rete applicati ai pod autonomi possono avere un comportamento incoerente.

Soluzione: l'agente Network Policy attualmente supporta solo i pod distribuiti come parte di un set di distribuzione/replica. Se le policy di rete vengono applicate ai pod autonomi, potrebbero esserci delle incongruenze nel comportamento. Questo è documentato nella parte superiore di questa pagina, nelConsiderazioni, e nel numero #327 successivo. aws-network-policy-agent GitHub GitHub Implementa i pod come parte di una distribuzione o di un set di repliche per un comportamento coerente con le policy di rete.