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:

È possibile risolvere i problemi e analizzare le connessioni di rete che utilizzano le policy di rete leggendo i log della policy di rete ed eseguendo gli strumenti da eBPF SDK.

Nuovo CRD policyendpoints e autorizzazioni

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 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:

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 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

Prerequisiti

Componenti aggiuntivi di Amazon EKS

Componenti aggiuntivi autogestiti

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 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.

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'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 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:

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 paginaConsiderazioni, nel e nel aws-network-policy-agent GitHub numero #327 successivo. GitHub Implementa i pod come parte di un’implementazione o di un set di replica per un comportamento coerente delle policy di rete.