Aidez à améliorer cette page

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Pour contribuer à ce guide de l'utilisateur, cliquez sur le GitHub lien Modifier cette page sur qui se trouve dans le volet droit de chaque page.

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Résolution des problèmes liés aux politiques réseau Kubernetes pour Amazon EKS

Il s'agit du guide de dépannage relatif à la fonctionnalité de politique réseau de l'Amazon VPC CNI.

Ce guide couvre les sujets suivants :

Vous pouvez résoudre les problèmes et étudier les connexions réseau qui utilisent des politiques réseau en lisant les journaux des politiques réseau et en exécutant les outils du SDK eBPF.

Nouveau policyendpoints CRD et nouvelles autorisations

Pour la politique réseau, le VPC CNI crée un nouveau CustomResourceDefinition (CRD) appelé. policyendpoints.networking.k8s.aws Le CNI du VPC doit être autorisé à créer le CRD et à créer CustomResources (CR) celui-ci et l'autre CRD installé par le VPC CNI (). eniconfigs.crd.k8s.amazonaws.com Les deux CRDs sont disponibles dans le crds.yamlfichier sur GitHub. Plus précisément, le CNI du VPC doit disposer des autorisations verbales « get », « list » et « watch » pour. policyendpoints

La politique réseau Kubernetes fait partie de l'apiserviceappelv1.networking.k8s.io, et elle se trouve apiversion: networking.k8s.io/v1 dans vos fichiers YAML de politique. Le VPC CNI DaemonSet doit être autorisé à utiliser cette partie de l'API Kubernetes.

Les autorisations VPC CNI se trouvent dans un appel. ClusterRole aws-node Notez que les ClusterRole objets ne sont pas regroupés dans des espaces de noms. Ce qui suit montre le aws-node schéma d'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

En outre, un nouveau contrôleur s'exécute dans le plan de contrôle de chaque cluster EKS. Le contrôleur utilise les autorisations de l'ClusterRoleappeléeks:network-policy-controller. Ce qui suit montre le eks:network-policy-controller schéma d'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

Journaux de stratégie réseau

Chaque décision prise par le VPC CNI quant à savoir si les connexions sont autorisées ou refusées par une politique réseau est enregistrée dans des journaux de flux. Les journaux de stratégie réseau de chaque nœud incluent les journaux de flux pour chaque pod doté d'une stratégie réseau. Les journaux de stratégie réseau sont stockés sur /var/log/aws-routed-eni/network-policy-agent.log. L'exemple suivant est extrait d'un fichier 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"}

Les journaux de politique réseau sont désactivés par défaut. Pour activer les journaux de politique réseau, procédez comme suit :

Module complémentaire d'Amazon EKS

La capture d'écran suivante montre un exemple de ce scénario.

Module complémentaire autogéré

Envoyer des journaux de politique réseau à Amazon CloudWatch Logs

Vous pouvez surveiller les journaux de politique réseau à l'aide de services tels qu'Amazon CloudWatch Logs. Vous pouvez utiliser les méthodes suivantes pour envoyer les journaux de politique réseau à CloudWatch Logs.

Pour les clusters EKS, les journaux des politiques seront situés en dessous /aws/eks/cluster-name/cluster/ et pour les clusters K8S autogérés, les journaux seront placés en dessous. /aws/k8s-cluster/cluster/

Envoyez des journaux de politique réseau avec le plugin Amazon VPC CNI pour Kubernetes

Si vous activez la stratégie réseau, un deuxième conteneur est ajouté aux pods du aws-node pour unagent de nœud. Cet agent de nœud peut envoyer les journaux de politique réseau à CloudWatch Logs.

Prérequis

Module complémentaire d'Amazon EKS

Module complémentaire autogéré

Envoyer des journaux de politique réseau avec un Fluent Bit DaemonSet

Si vous utilisez Fluent Bit dans un DaemonSet pour envoyer des journaux depuis vos nœuds, vous pouvez ajouter une configuration pour inclure les journaux de politique réseau à partir des politiques réseau. Vous pouvez utiliser l'exemple de configuration suivant :

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

Le plug-in Amazon VPC CNI pour Kubernetes installe une collection d'outils du SDK eBPF sur les nœuds. Vous pouvez utiliser les outils du SDK eBPF pour identifier les problèmes liés aux politiques réseau. Par exemple, la commande suivante répertorie les programmes qui s'exécutent sur le nœud.

sudo /opt/cni/bin/aws-eks-na-cli ebpf progs

Pour exécuter cette commande, vous pouvez utiliser n'importe quelle méthode pour vous connecter au nœud.

Problèmes connus et solutions

Les sections suivantes décrivent les problèmes connus liés à la fonctionnalité de politique réseau CNI d'Amazon VPC et à leurs solutions.

Journaux de politique réseau générés même si la valeur enable-policy-event-logs est définie sur false

Problème : EKS VPC CNI génère des journaux de politique réseau même lorsque le enable-policy-event-logs paramètre est défini sur. false

Solution : le enable-policy-event-logs paramètre désactive uniquement les journaux des « décisions » relatives aux politiques, mais il ne désactive pas tous les journaux de l'agent Network Policy. Ce comportement est documenté dans le aws-network-policy-agent fichier README sur GitHub. Pour désactiver complètement la journalisation, vous devrez peut-être ajuster d'autres configurations de journalisation.

Problèmes liés au nettoyage de la carte des politiques réseau

Problème : les problèmes liés au réseau existent policyendpoint toujours et ne sont pas nettoyés après la suppression des pods.

Solution : Ce problème est dû à un problème lié à la version 1.19.3-eksbuild.1 du module complémentaire VPC CNI. Effectuez une mise à jour vers une version plus récente du module complémentaire VPC CNI pour résoudre ce problème.

Les politiques réseau ne sont pas appliquées

Problème : la fonctionnalité de politique réseau est activée dans le plug-in Amazon VPC CNI, mais les politiques réseau ne sont pas appliquées correctement.

Si vous définissez une politique réseau kind: NetworkPolicy et que cela n'affecte pas le pod, vérifiez que l'objet policyendpoint a été créé dans le même espace de noms que le pod. S'il n'y a aucun policyendpoint objet dans les espaces de noms, le contrôleur de politique réseau (qui fait partie du cluster EKS) n'a pas pu créer de règles de politique réseau à appliquer par l'agent de stratégie réseau (qui fait partie du CNI VPC).

Solution : La solution consiste à fixer les autorisations du VPC CNI (ClusterRole:aws-node) et du contrôleur de politique réseau (ClusterRole:eks:network-policy-controller) et à autoriser ces actions dans n'importe quel outil d'application des politiques tel que Kyverno. Assurez-vous que les politiques de Kyverno ne bloquent pas la création d'policyendpointobjets. Reportez-vous à la section précédente pour connaître les autorisations nécessaires dansNouveau policyendpoints CRD et nouvelles autorisations.

Les pods ne reviennent pas à l'état de refus par défaut après la suppression de la politique en mode strict

Problème : Lorsque les politiques réseau sont activées en mode strict, les pods démarrent avec une politique de refus par défaut. Une fois les politiques appliquées, le trafic est autorisé vers les points de terminaison spécifiés. Cependant, lorsque les politiques sont supprimées, le pod ne revient pas à l'état de refus par défaut mais passe à l'état d'autorisation par défaut.

Solution : Ce problème a été résolu dans la version 1.19.3 de VPC CNI, qui incluait la version 1.2.0 de l'agent de politique réseau. Après le correctif, lorsque le mode strict est activé, une fois les politiques supprimées, le pod reviendra à l'état de refus par défaut, comme prévu.

Groupes de sécurité pour la latence de démarrage des Pods

Problème : lorsque vous utilisez la fonctionnalité Security Groups for Pods dans EKS, la latence de démarrage des pods augmente.

Solution : La latence est due à la limitation du débit dans le contrôleur de ressources due à la limitation de l'CreateNetworkInterfaceAPI, que le contrôleur de ressources VPC utilise pour créer une branche ENIs pour les pods. Vérifiez les limites de l'API de votre compte pour cette opération et envisagez de demander une augmentation des limites si nécessaire.

FailedScheduling en raison d'une insuffisance de vpc.amazonaws.com/pod-eni

Problème : Impossible de planifier les pods avec le message d'erreur suivant : 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.

Solution : Comme dans le cas du problème précédent, l'attribution de groupes de sécurité aux pods augmente la latence de planification des pods et elle peut dépasser le seuil CNI nécessaire pour ajouter chaque ENI, ce qui entraîne des échecs lors du démarrage des pods. Ce comportement est attendu lors de l'utilisation de groupes de sécurité pour les pods. Tenez compte des implications en matière de planification lors de la conception de votre architecture de charge de travail.

Problèmes de connectivité IPAM et défauts de segmentation

Problème : plusieurs erreurs se produisent, notamment des problèmes de connectivité IPAM, des demandes de régulation et des erreurs de segmentation :

Solution : Ce problème se produit si vous installez systemd-udev le fichier AL2 023, car le fichier est réécrit avec une politique d'interruption. Cela peut se produire lors de la mise à jour vers un autre releasever package doté d'un package mis à jour ou lors de la mise à jour manuelle du package lui-même. Évitez d'installer ou de mettre à jour systemd-udev sur les nœuds AL2 023.

Impossible de trouver le périphérique par son nom d'erreur

Problème : message d'erreur : {"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})"}

Solution : ce problème a été identifié et résolu dans les dernières versions de l'agent de politique réseau Amazon VPC CNI (v1.2.0). Passez à la dernière version du VPC CNI pour résoudre ce problème.

Vulnérabilités CVE dans l'image Multus CNI

Problème : le rapport EKS ImageScan CVE amélioré identifie des vulnérabilités dans la version v4.1.4-eksbuild.2_thick de l'image Multus CNI.

Solution : passez à la nouvelle version de l'image Multus CNI et à la nouvelle image du Network Policy Controller, qui ne présentent aucune vulnérabilité. Le scanner peut être mis à jour pour corriger les vulnérabilités détectées dans la version précédente.

Flow Info : REFUSEZ les verdicts dans les logs

Problème : les journaux de politique réseau affichent les verdicts de refus : {"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"}

Solution : Ce problème a été résolu dans la nouvelle version du Network Policy Controller. Passez à la dernière version de la plateforme EKS pour résoudre les problèmes de journalisation.

Pod-to-pod problèmes de communication après la migration depuis Calico

Problème : Après la mise à niveau d'un cluster EKS vers la version 1.30 et le passage de Calico à Amazon VPC CNI pour la politique réseau, la pod-to-pod communication échoue lorsque les politiques réseau sont appliquées. La communication est rétablie lorsque les politiques réseau sont supprimées.

Solution : L'agent de politique réseau du VPC CNI ne peut pas avoir autant de ports spécifiés que Calico. Utilisez plutôt des plages de ports dans les politiques réseau. Le nombre maximum de combinaisons uniques de ports pour chaque protocole dans chaque egress: sélecteur ingress: d'une politique réseau est de 24. Utilisez des plages de ports pour réduire le nombre de ports uniques et éviter cette limitation.

L'agent de stratégie réseau ne prend pas en charge les modules autonomes

Problème : les politiques réseau appliquées aux pods autonomes peuvent avoir un comportement incohérent.

Solution : L'agent Network Policy ne prend actuellement en charge que les pods déployés dans le cadre d'un déployement/d'un ensemble de réplicasets. Si des politiques réseau sont appliquées à des pods autonomes, le comportement peut présenter des incohérences. Ceci est documenté en haut de cette page, dans le Considérations numéro et dans le aws-network-policy-agent GitHub numéro #327 sur GitHub. Déployez des pods dans le cadre d'un déploiement ou d'un réplicaset pour un comportement cohérent en matière de politique réseau.