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.

Dépannage des politiques réseau Kubernetes pour Amazon EKS

Ce guide de dépannage concerne la fonctionnalité de politique réseau d’Amazon VPC CNI.

Ce guide couvre les points suivants :

Vous pouvez dépanner et analyser 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 kit SDK eBPF.

Nouveaux CRD et autorisations policyendpoints

Pour la politique réseau, le CNI VPC crée une nouvelle CustomResourceDefinition (CRD) appelée 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 VPC doit disposer des autorisations « get », « list » et « watch » pour policyendpoints.

La politique réseau Kubernetes fait partie du apiservice appelé v1.networking.k8s.io, et il s’agit de apiversion: networking.k8s.io/v1 dans vos fichiers YAML de politique. Le DaemonSet CNI VPC doit disposer des autorisations nécessaires pour utiliser cette partie de l’API Kubernetes.

Les autorisations CNI VPC se trouvent dans un ClusterRole appelé aws-node. Veuillez noter que les objets ClusterRole ne sont pas regroupés dans des espaces de noms. Voici l’aws-node 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

De plus, un nouveau contrôleur s’exécute dans le plan de contrôle de chaque cluster EKS. Le contrôleur utilise les autorisations du ClusterRole appelé eks:network-policy-controller. Voici l’eks:network-policy-controller 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 concernant l’autorisation ou le refus des connexions par les politiques réseau est journalisée dans les 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 stratégie 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 de politique seront situés sous /aws/eks/cluster-name/cluster/ et pour les clusters K8S autogérés, les journaux seront placés sous /aws/k8s-cluster/cluster/.

Envoyer les journaux de politique réseau avec le plug-in CNI Amazon VPC 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.

Conditions préalables

Module complémentaire d'Amazon EKS

Module complémentaire autogéré

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

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

Kit SDK eBPF inclus

Le plug-in CNI Amazon VPC pour Kubernetes installe la collection d’outils du kit SDK eBPF sur les nœuds. Vous pouvez utiliser les outils du kit 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 du CNI 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 : le CNI VPC EKS génère des journaux de politique réseau même lorsque le paramètre enable-policy-event-logs est défini sur false.

Solution : le paramètre enable-policy-event-logs désactive uniquement les journaux de « décision » de politique, mais il ne désactive pas tous les journaux de l’agent de politique réseau. 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 du mappage des politiques réseau

Problème : des problèmes liés au policyendpoint réseau persistent et ne sont pas résolus après la suppression des pods.

Solution : ce problème était dû à un dysfonctionnement du module complémentaire CNI Amazon VPC version 1.19.3-eksbuild.1. Veuillez mettre à jour le module complémentaire CNI Amazon VPC vers une version plus récente 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 module complémentaire CNI Amazon VPC, mais les politiques réseau ne sont pas appliquées correctement.

Si vous créez une politique réseau kind: NetworkPolicy et qu’elle n’a aucun effet sur 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 pas d’objets policyendpoint 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 politique réseau (qui fait partie du VPC CNI).

Solution : la solution consiste à corriger les autorisations du CNI VPC (ClusterRole : aws-node) et du contrôleur de politique réseau (ClusterRole : eks:network-policy-controller) et à autoriser ces actions dans tout outil d’application de politique tel que Kyverno. Assurez-vous que les politiques Kyverno ne bloquent pas la création d’objets policyendpoint. Consultez la section précédente pour connaître les autorisations nécessaires dans Nouveaux CRD et autorisations policyendpoints.

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 à un état d’autorisation par défaut.

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

Latence de démarrage des groupes de sécurité pour les pods

Problème : lorsque vous utilisez la fonctionnalité Groupes de sécurité pour les 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. Veuillez vérifier les limites API de votre compte pour cette opération et envisager de demander une augmentation de la limite si nécessaire.

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

Problème : les pods ne parviennent pas à se planifier et l’erreur suivante s’affiche : 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 pour le problème précédent, l’attribution de groupes de sécurité aux pods augmente la latence de planification des pods et peut dépasser le seuil CNI pour le temps nécessaire à l’ajout de chaque ENI, ce qui entraîne des échecs au démarrage des pods. Il s’agit d’un comportement normal lorsque vous utilisez des groupes de sécurité pour les pods. Tenez compte des implications en matière de planification lorsque vous concevez l’architecture de votre charge de travail.

Problèmes de connectivité IPAM et erreurs de segmentation

Problème : plusieurs erreurs se produisent, notamment des problèmes de connectivité IPAM, des demandes de limitation 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 une autre releasever qui dispose 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.

Erreur : impossible de trouver le dispositif par son nom

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 : les dernières versions de l’agent de politique réseau CNI Amazon VPC (v1.2.0) identifient et corrigent ce problème. Veuillez mettre à jour vers la dernière version du CNI VPC pour résoudre ce problème.

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

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 : veuillez mettre à jour vers la nouvelle version de l’image CNI Multus et la nouvelle image du contrôleur de politique réseau, qui ne présentent aucune vulnérabilité. Vous pouvez mettre à jour l’analyseur pour corriger les vulnérabilités détectées dans la version précédente.

Verdicts DENY des informations de flux dans les journaux

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

Solution : le problème a été résolu dans la nouvelle version du contrôleur de politique réseau. Veuillez mettre à jour vers la dernière version de 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 dans le CNI VPC 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 maximal de combinaisons uniques de ports pour chaque protocole dans chaque sélecteur ingress: ou egress: 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 politique réseau ne prend pas en charge les pods autonomes

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

Solution : l’agent de politique réseau ne prend actuellement en charge que les pods déployés dans le cadre d’un déploiement/réplicaset. Si des politiques réseau sont appliquées à des pods autonomes, leur comportement peut présenter certaines 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 les pods dans le cadre d’un déploiement ou d’un réplicaset pour garantir un comportement cohérent des politiques réseau.