**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 : + Informations d’installation, autorisations CRD et RBAC [Nouveaux CRD et autorisations `policyendpoints`](#network-policies-troubleshooting-permissions) + Journaliser les journaux lors du diagnostic des problèmes de politique réseau [Journaux de stratégie réseau](#network-policies-troubleshooting-flowlogs) + Exécution de la collection d’outils du kit SDK eBPF pour le dépannage + Problèmes connus et solutions [Problèmes connus et solutions](#network-policies-troubleshooting-known-issues) **Note** Veuillez noter que les politiques réseau ne s’appliquent qu’aux pods créés par les *déploiements* Kubernetes. Pour plus d’informations sur les limitations des politiques réseau dans le CNI VPC, consultez [Considérations](cni-network-policy.md#cni-network-policy-considerations). Vous pouvez dépanner et analyser les connexions réseau qui utilisent des politiques réseau en lisant les [journaux des politiques réseau](#network-policies-troubleshooting-flowlogs) et en exécutant les outils du [kit SDK eBPF](#network-policies-ebpf-sdk). ## Nouveaux CRD et autorisations `policyendpoints` + CRD : `policyendpoints.networking.k8s.aws` + API Kubernetes : `apiservice` appelé `v1.networking.k8s.io` + Ressource Kubernetes : `Kind: NetworkPolicy` + RBAC : `ClusterRole` appelé `aws-node` (CNI VPC), `ClusterRole` appelé `eks:network-policy-controller` (contrôleur de politique réseau dans le plan de contrôle du cluster EKS) 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.yaml`fichier](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/charts/aws-vpc-cni/crds/customresourcedefinition.yaml) 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 : **Note** Les journaux de politique réseau nécessitent 1 vCPU supplémentaire pour le conteneur `aws-network-policy-agent` dans le manifeste `aws-node` `DaemonSet` du CNI Amazon VPC. ### Module complémentaire d'Amazon EKS ** AWS Management Console ** 1. Ouvrez la [console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters). 1. Dans le panneau de navigation de gauche, sélectionnez **Clusters**, puis sélectionnez le nom du cluster pour lequel vous souhaitez configurer le module complémentaire Amazon VPC CNI. 1. Choisissez l’onglet **Modules complémentaires**. 1. Cochez la case en haut à droite de la zone du module complémentaire, puis sélectionnez **Edit** (Modifier). 1. Sur la page **Configurer *Amazon VPC CNI*** : 1. Sélectionnez une version `v1.14.0-eksbuild.3` ou  ultérieure dans la liste déroulante **Version**. 1. Sélectionnez **Paramètres de configuration facultatifs**. 1. Saisissez la clé JSON de niveau supérieur de l'`"nodeAgent":` et la valeur est un objet avec une clé `"enablePolicyEventLogs":` et une valeur de `"true"` dans**Valeurs de configuration**. Le texte obtenu doit être un objet JSON valide. L'exemple suivant montre la politique réseau et les journaux de stratégie réseau sont activés, et les journaux de stratégie réseau sont envoyés à CloudWatch Logs : ``` { "enableNetworkPolicy": "true", "nodeAgent": { "enablePolicyEventLogs": "true" } } ``` La capture d'écran suivante montre un exemple de ce scénario. ![\[montrant le module complémentaire VPC CNI avec la politique réseau et les CloudWatch journaux dans la configuration optionnelle.\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/images/console-cni-config-network-policy-logs.png) AWS CLI 1. Exécutez la commande AWS CLI suivante. Remplacez `my-cluster` par le nom de votre cluster et l'ARN du rôle IAM par le rôle que vous utilisez. ``` 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"}}' ``` ### Module complémentaire autogéré Helm Si vous avez installé le plug-in CNI Amazon VPC pour Kubernetes via `helm`, vous pouvez mettre à jour la configuration pour écrire les journaux de politique réseau. 1. Exécutez la commande suivante pour activer la stratégie réseau. ``` helm upgrade --set nodeAgent.enablePolicyEventLogs=true aws-vpc-cni --namespace kube-system eks/aws-vpc-cni ``` kubectl Si vous avez installé le plug-in CNI Amazon VPC pour Kubernetes via `kubectl`, vous pouvez mettre à jour la configuration pour écrire les journaux de politique réseau. 1. Ouvrez le `aws-node` `DaemonSet` dans votre éditeur. ``` kubectl edit daemonset -n kube-system aws-node ``` 1. Remplacez `false` par `true` dans l’argument de commande `--enable-policy-event-logs=false` pour le `args:` du conteneur `aws-network-policy-agent` dans le manifeste CNI VPC `aws-node` `DaemonSet`. ``` - args: - --enable-policy-event-logs=true ``` ### 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 un*agent de nœud*. Cet agent de nœud peut envoyer les journaux de politique réseau à CloudWatch Logs. **Note** Seuls les journaux de stratégie réseau sont envoyés par l'agent de nœud. Les autres journaux créés par le CNI Amazon VPC ne sont pas inclus. ##### Conditions préalables + Ajoutez les autorisations suivantes sous forme de strophe ou de stratégie distincte au rôle IAM que vous utilisez pour le VPC CNI. ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": [ "logs:DescribeLogGroups", "logs:CreateLogGroup", "logs:CreateLogStream", "logs:PutLogEvents" ], "Resource": "*" } ] } ``` ##### Module complémentaire d'Amazon EKS ** AWS Management Console ** 1. Ouvrez la [console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters). 1. Dans le panneau de navigation de gauche, sélectionnez **Clusters**, puis sélectionnez le nom du cluster pour lequel vous souhaitez configurer le module complémentaire Amazon VPC CNI. 1. Choisissez l’onglet **Modules complémentaires**. 1. Cochez la case en haut à droite de la zone du module complémentaire, puis sélectionnez **Edit** (Modifier). 1. Sur la page **Configurer *Amazon VPC CNI*** : 1. Sélectionnez une version `v1.14.0-eksbuild.3` ou  ultérieure dans la liste déroulante **Version**. 1. Sélectionnez **Paramètres de configuration facultatifs**. 1. Saisissez la clé JSON de niveau supérieur de l'`"nodeAgent":` et la valeur est un objet avec une clé `"enableCloudWatchLogs":` et une valeur de `"true"` dans**Valeurs de configuration**. Le texte obtenu doit être un objet JSON valide. L'exemple suivant montre la politique réseau, les journaux de stratégie réseau sont activés et les journaux sont envoyés à CloudWatch Logs : ``` { "enableNetworkPolicy": "true", "nodeAgent": { "enablePolicyEventLogs": "true", "enableCloudWatchLogs": "true", } } ``` La capture d'écran suivante montre un exemple de ce scénario. ![\[montrant le module complémentaire VPC CNI avec la politique réseau et les CloudWatch journaux dans la configuration optionnelle.\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/images/console-cni-config-network-policy-logs-cwl.png) ** AWS CLI** 1. Exécutez la commande AWS CLI suivante. Remplacez `my-cluster` par le nom de votre cluster et l'ARN du rôle IAM par le rôle que vous utilisez. ``` 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"}}' ``` ##### Module complémentaire autogéré **Casque** Si vous avez installé le plug-in Amazon VPC CNI pour Kubernetes via`helm`, vous pouvez mettre à jour la configuration pour envoyer les journaux de politique réseau à Logs. CloudWatch 1. Exécutez la commande suivante pour activer les journaux de politique réseau et les envoyer à CloudWatch Logs. ``` helm upgrade --set nodeAgent.enablePolicyEventLogs=true --set nodeAgent.enableCloudWatchLogs=true aws-vpc-cni --namespace kube-system eks/aws-vpc-cni ``` **kubectl** 1. Ouvrez le `aws-node` `DaemonSet` dans votre éditeur. ``` kubectl edit daemonset -n kube-system aws-node ``` 1. Remplacez `false` par `true` dans les deux arguments de commande `--enable-policy-event-logs=false` et `--enable-cloudwatch-logs=false` dans `args:` dans le conteneur `aws-network-policy-agent` du manifeste `aws-node` `DaemonSet` de VPC CNI. ``` - args: - --enable-policy-event-logs=true - --enable-cloudwatch-logs=true ``` #### 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](https://github.com/aws/aws-network-policy-agent/) 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`](#network-policies-troubleshooting-permissions). ### 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'`CreateNetworkInterface`API, 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 : + `Checking for IPAM connectivity …​` + `Throttling request took 1.047064274s` + `Retrying waiting for IPAM-D` + `panic: runtime error: invalid memory address or nil pointer dereference` **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\$1thick 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](cni-network-policy.md#cni-network-policy-considerations) numéro et dans le [aws-network-policy-agent GitHub numéro \$1327](https://github.com/aws/aws-network-policy-agent/issues/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.