**Ayude a mejorar esta página** Para contribuir a esta guía del usuario, elija el enlace **Edit this page on GitHub** que se encuentra en el panel derecho de cada página. # Resolución de problemas de políticas de red de Kubernetes para Amazon EKS Esta es la guía de solución de problemas para la característica de la política de red de la CNI de Amazon VPC. Esta guía aborda los siguientes temas: + Información de instalación, CRD y permisos [Nuevos permisos y CRD `policyendpoints`](#network-policies-troubleshooting-permissions) de RBAC + Registros que se deben examinar durante el diagnóstico de problemas [Registros de políticas de red](#network-policies-troubleshooting-flowlogs) en la política de la red + Ejecución de la colección de herramientas del SDK de eBPF para solucionar problemas + Problemas conocidos y soluciones [Problemas conocidos y soluciones](#network-policies-troubleshooting-known-issues) **nota** Tenga en cuenta que las políticas de red solo se aplican a los pods creados por Kubernetes *Deployments*. Para obtener más información sobre las limitaciones de las políticas de red en la CNI de la VPC, consulte [Consideraciones](cni-network-policy.md#cni-network-policy-considerations). Puede solucionar problemas e investigar las conexiones de red que utilizan políticas de red leyendo los [registros de políticas de red](#network-policies-troubleshooting-flowlogs) y ejecutando las herramientas del [eBPF SDK](#network-policies-ebpf-sdk). ## Nuevos permisos y CRD `policyendpoints` + CRD: `policyendpoints.networking.k8s.aws` + Kubernetes API: `apiservice` denominado `v1.networking.k8s.io` + Recurso de Kubernetes: `Kind: NetworkPolicy` + RBAC: `ClusterRole` denominado `aws-node` (CNI de la VPC), `ClusterRole` llamó a `eks:network-policy-controller` (controlador de políticas de red en el plano de control del clúster de EKS) Para la política de red, la CNI de la VPC crea una nueva `CustomResourceDefinition` (CRD) llamada `policyendpoints.networking.k8s.aws`. La CNI de la VPC debe tener permisos para crear la CRD y crear CustomResources (CR) de esta y de las otras CRD instaladas por la CNI de la VPC (`eniconfigs.crd.k8s.amazonaws.com`). Ambas CRD están disponibles en el [archivo `crds.yaml`](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/charts/aws-vpc-cni/crds/customresourcedefinition.yaml) de GitHub. En concreto, la CNI de la VPC debe tener los permisos verbales “get”, “list” y “watch” para `policyendpoints`. La *política de red* de Kubernetes forma parte del `apiservice` denominado `v1.networking.k8s.io`, que es `apiversion: networking.k8s.io/v1` en los archivos YAML de la política. La CNI de la VPC `DaemonSet` debe tener permisos para usar esta parte de la API de Kubernetes. Los permisos de la CNI de la VPC están en un `ClusterRole` denominado `aws-node`. Tenga en cuenta que los objetos `ClusterRole` no se agrupan en los espacios de nombres. A continuación se muestra el `aws-node` de un clúster: ``` 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 ``` Además, se ejecuta un nuevo controlador en el plano de control de cada clúster de EKS. El controlador usa los permisos del `ClusterRole` denominado `eks:network-policy-controller`. A continuación se muestra el `eks:network-policy-controller` de un clúster: ``` 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 ``` ## Registros de políticas de red Cada decisión que la CNI de la VPC toma con respecto a si las políticas de red permiten o deniegan las conexiones se registra en los *registros de flujo*. Los registros de políticas de red de cada nodo incluyen los registros de flujo de cada pod que tiene una política de red. Los registros de políticas de red se almacenan en `/var/log/aws-routed-eni/network-policy-agent.log`. A continuación se muestra un ejemplo de un archivo `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"} ``` Los registros de políticas de red está deshabilitados de manera predeterminada. Para habilitar los registros de políticas de red, siga estos pasos: **nota** Los registros de políticas de red requieren 1 vCPU adicional para el contenedor `aws-network-policy-agent` del manifiesto `aws-node` `DaemonSet` de la CNI de la VPC. ### Complemento de Amazon EKS ** Consola de administración de AWS ** 1. Abra la [consola de Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters). 1. En el panel de navegación izquierdo, seleccione **Clústeres** y, a continuación, seleccione el nombre del clúster para el que desea configurar el complemento CNI de Amazon VPC. 1. Elija la pestaña **Complementos**. 1. Seleccione la casilla situada en la parte superior derecha del cuadro y, a continuación, elija **Edit** (Editar). 1. En la página **Configurar *CNI de Amazon VPC***: 1. Seleccione la versión `v1.14.0-eksbuild.3` o posterior en la lista desplegable **Versión**. 1. Seleccione **Ajustes de configuración opcionales**. 1. Introduzca la clave de JSON de nivel superior `"nodeAgent":` y el valor en un objeto con una clave `"enablePolicyEventLogs":` y un valor de `"true"` en **Valores de configuración**. El texto resultante debe ser un objeto JSON válido. En el siguiente ejemplo se muestra que la política de red y los registros de políticas de red están habilitados, y que estos últimos se envían a los Registros de CloudWatch: ``` { "enableNetworkPolicy": "true", "nodeAgent": { "enablePolicyEventLogs": "true" } } ``` En la siguiente captura de pantalla se muestra un ejemplo de este escenario. ![\[ mostrando el complemento CNI de VPC con la política de red y los Registros de CloudWatch en la configuración opcional.\]](http://docs.aws.amazon.com/es_es/eks/latest/userguide/images/console-cni-config-network-policy-logs.png) AWS CLI 1. Ejecute el siguiente comando de AWS CLI. Reemplace `my-cluster` por el nombre del clúster y el ARN del rol de IAM por el rol que va a usar. ``` 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"}}' ``` ### Complemento autoadministrado Helm Si ha instalado el complemento CNI de Amazon VPC para Kubernetes mediante `helm`, puede actualizar la configuración para escribir los registros de la política de red. 1. Ejecute el siguiente comando para habilitar la política de red. ``` helm upgrade --set nodeAgent.enablePolicyEventLogs=true aws-vpc-cni --namespace kube-system eks/aws-vpc-cni ``` kubectl Si ha instalado el complemento CNI de Amazon VPC para Kubernetes mediante `kubectl`, puede actualizar la configuración para escribir los registros de la política de red. 1. Abra el `DaemonSet` de `aws-node` en el editor. ``` kubectl edit daemonset -n kube-system aws-node ``` 1. Sustituya el `false` por `true` en el argumento del comando `--enable-policy-event-logs=false` en el `args:` del contenedor `aws-network-policy-agent` en el manifiesto `aws-node` `DaemonSet` de la CNI de la VPC. ``` - args: - --enable-policy-event-logs=true ``` ### Enviar los registros de políticas de red a los Registros de Amazon CloudWatch Puede supervisar los registros de políticas de red mediante servicios como los Registros de Amazon CloudWatch. Puede usar los siguientes métodos para enviar los registros de políticas de red a los Registros de CloudWatch. En el caso de los clústeres de EKS, los registros de políticas se ubicarán en `/aws/eks/cluster-name/cluster/` y, en el caso de los clústeres K8S autoadministrados, los registros se colocarán en `/aws/k8s-cluster/cluster/`. #### Envío de registros de la política de red con el complemento CNI de Amazon VPC para Kubernetes Si habilita la política de red, se añade un segundo contenedor a los pods de `aws-node` para un *agente de nodos*. Este agente de nodos puede enviar los registros de políticas de red a los Registros de CloudWatch. **nota** El agente de nodos solo envía los registros de políticas de red. No se incluyen otros registros creados por el CNI de VPC. ##### Requisitos previos + Añada los siguientes permisos como una política individual o independiente al rol de IAM que está utilizando para el CNI de VPC. ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": [ "logs:DescribeLogGroups", "logs:CreateLogGroup", "logs:CreateLogStream", "logs:PutLogEvents" ], "Resource": "*" } ] } ``` ##### Complemento de Amazon EKS ** Consola de administración de AWS ** 1. Abra la [consola de Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters). 1. En el panel de navegación izquierdo, seleccione **Clústeres** y, a continuación, seleccione el nombre del clúster para el que desea configurar el complemento CNI de Amazon VPC. 1. Elija la pestaña **Complementos**. 1. Seleccione la casilla situada en la parte superior derecha del cuadro y, a continuación, elija **Edit** (Editar). 1. En la página **Configurar *CNI de Amazon VPC***: 1. Seleccione la versión `v1.14.0-eksbuild.3` o posterior en la lista desplegable **Versión**. 1. Seleccione **Ajustes de configuración opcionales**. 1. Introduzca la clave de JSON de nivel superior `"nodeAgent":` y el valor en un objeto con una clave `"enableCloudWatchLogs":` y un valor de `"true"` en **Valores de configuración**. El texto resultante debe ser un objeto JSON válido. En el siguiente ejemplo se muestra que la política de red y los registros de políticas de red están habilitados, y que estos últimos se envían a los Registros de CloudWatch: ``` { "enableNetworkPolicy": "true", "nodeAgent": { "enablePolicyEventLogs": "true", "enableCloudWatchLogs": "true", } } ``` En la siguiente captura de pantalla se muestra un ejemplo de este escenario. ![\[ mostrando el complemento CNI de VPC con la política de red y los Registros de CloudWatch en la configuración opcional.\]](http://docs.aws.amazon.com/es_es/eks/latest/userguide/images/console-cni-config-network-policy-logs-cwl.png) ** AWS CLI** 1. Ejecute el siguiente comando de AWS CLI. Reemplace `my-cluster` por el nombre del clúster y el ARN del rol de IAM por el rol que va a usar. ``` 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"}}' ``` ##### Complemento autoadministrado **Helm** Si ha instalado el complemento CNI de Amazon VPC para Kubernetes mediante `helm`, puede enviar la configuración para enviar registros de la política de red a Registros de CloudWatch. 1. Ejecute el siguiente comando para habilitar los registros de políticas de red y enviarlos a los Registros de CloudWatch. ``` helm upgrade --set nodeAgent.enablePolicyEventLogs=true --set nodeAgent.enableCloudWatchLogs=true aws-vpc-cni --namespace kube-system eks/aws-vpc-cni ``` **kubectl** 1. Abra el `DaemonSet` de `aws-node` en el editor. ``` kubectl edit daemonset -n kube-system aws-node ``` 1. Sustituya `false` por `true` en los dos argumentos de comando `--enable-policy-event-logs=false` y `--enable-cloudwatch-logs=false` de `args:` del contenedor `aws-network-policy-agent` en el manifiesto `aws-node` `DaemonSet` de la CNI de la VPC. ``` - args: - --enable-policy-event-logs=true - --enable-cloudwatch-logs=true ``` #### Envío de registros de políticas de red con un `DaemonSet` de Fluent Bit Si utiliza Fluent Bit en un `DaemonSet` para enviar registros desde sus nodos, puede agregar una configuración para incluir los registros de políticas de red de las políticas de red. Puede utilizar la siguiente configuración de ejemplo: ``` [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 de eBPF incluido El complemento CNI de Amazon VPC para Kubernetes instala el conjunto de herramientas del SDK de eBPF en los nodos. Puede utilizar las herramientas del SDK de eBPF para identificar problemas con las políticas de red. Por ejemplo, el siguiente comando muestra los programas que se ejecutan en el nodo. ``` sudo /opt/cni/bin/aws-eks-na-cli ebpf progs ``` Para ejecutar este comando, puede utilizar cualquier método para conectarse al nodo. ## Problemas conocidos y soluciones En las siguientes secciones se describen los problemas conocidos con la característica de la política de red de la CNI de Amazon VPC y sus soluciones. ### Los registros de políticas de red se generan a pesar de que enable-policy-event-logs esté establecido en false **Problema**: la CNI de VPC de EKS genera registros de políticas de red incluso cuando la configuración `enable-policy-event-logs` está establecida en `false`. **Solución**: la configuración `enable-policy-event-logs` solo deshabilita los registros de “decisiones” de las políticas, pero no deshabilita todos los registros del agente de políticas de red. Este comportamiento se documenta en el archivo [README aws-network-policy-agent](https://github.com/aws/aws-network-policy-agent/) de GitHub. Para deshabilitar por completo el registro, es posible que tenga que ajustar otras configuraciones de registro. ### Problemas de limpieza de asignación de políticas de red **Problema**: los problemas con la red `policyendpoint` siguen existiendo y no se están limpiando después de eliminar los pods. **Solución**: Esto se debe a un problema con la versión 1.19.3-eksbuild.1 del complemento CNI de VPC. Actualice el complemento CNI de VPC a una versión más reciente para resolver este problema. ### No se aplican políticas de red **Problema**: la característica de políticas de red está habilitada en el complemento CNI de Amazon VPC, pero las políticas de red no se aplican correctamente. Si crea una política de red `kind: NetworkPolicy` y no impacta en el pod, compruebe que el objeto policyendpoint se haya creado en el mismo espacio de nombres que el pod. Si no hay objetos `policyendpoint` en los espacios de nombres, el controlador de políticas de red (parte del clúster de EKS) no pudo crear reglas de políticas de red para que las aplicara el agente de políticas de red (parte de la CNI de la VPC). **Solución**: la solución consiste en corregir los permisos de la CNI de la VPC (`ClusterRole` - `aws-node`) y del controlador de políticas de red (`ClusterRole` - `eks:network-policy-controller`) y permitir estas acciones en cualquier herramienta de aplicación de políticas, como Kyverno. Asegúrese de que las políticas de Kyverno no bloqueen la creación de objetos `policyendpoint`. Consulte la sección anterior para conocer los permisos necesarios en [Nuevos permisos y CRD `policyendpoints`](#network-policies-troubleshooting-permissions). ### Los pods no vuelven al estado de denegación predeterminado después de eliminar la política en modo estricto **Problema**: cuando las políticas de red están habilitadas en modo estricto, los pods comienzan con una política de denegación predeterminada. Una vez aplicadas las políticas, se permite el tráfico a los puntos de conexión especificados. Sin embargo, cuando se eliminan las políticas, el pod no vuelve al estado de denegación predeterminado, sino que pasa a un estado de permiso predeterminado. **Solución**: este problema se solucionó en la versión 1.19.3 de la CNI de la VPC, que incluía la versión 1.2.0 del agente de políticas de red. Tras la corrección, con el modo estricto habilitado, una vez eliminadas las políticas, el pod vuelve al estado de denegación predeterminado, tal y como se esperaba. ### Latencia de inicio de los grupos de seguridad para los pods **Problema**: cuando se utiliza la característica Grupos de seguridad para los pods en EKS, aumenta la latencia de inicio de los pods. **Solución**: la latencia se debe a la limitación de velocidad del controlador de recursos debido a la limitación de la API de `CreateNetworkInterface`, que el controlador de recursos de la VPC utiliza para crear ENI de rama para los pods. Compruebe los límites de la API de su cuenta para esta operación y considere la posibilidad de solicitar un aumento del límite si es necesario. ### FailedScheduling debido a una cantidad insuficiente de vpc.amazonaws.com/pod-eni **Problema**: los pods no se programan y se produce el error `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.` **Solución**: al igual que en el problema anterior, la asignación de grupos de seguridad a los pods aumenta la latencia de programación de los pods y puede sobrepasar el umbral de la CNI para añadir cada ENI, lo que provoca errores al iniciar los pods. Este es el comportamiento previsto cuando se utilizan grupos de seguridad para los pods. Considere las implicaciones de la programación al momento de diseñar la arquitectura de su carga de trabajo. ### Problemas de conectividad de IPAM y errores de segmentación **Problema**: se producen varios errores, incluidos problemas de conectividad de IPAM, solicitudes de limitación y errores de segmentación. + `Checking for IPAM connectivity …​` + `Throttling request took 1.047064274s` + `Retrying waiting for IPAM-D` + `panic: runtime error: invalid memory address or nil pointer dereference` **Solución**: este problema se produce si se instala `systemd-udev` en AL2023, ya que el archivo se reescribe con una política de interrupción. Esto puede ocurrir cuando se actualiza a un `releasever` diferente que tiene un paquete actualizado o cuando se actualiza manualmente el paquete en sí. Evite instalar o actualizar `systemd-udev` en los nodos AL2023. ### Error al buscar el dispositivo por su nombre **Problema**: mensaje de error `{"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})"}` **Solución**: este problema se ha identificado y corregido en las versiones más recientes del agente de políticas de red CNI de Amazon VPC (v1.2.0). Actualice a la última versión de la CNI de VPC para resolver este problema. ### Vulnerabilidades de CVE en la imagen CNI de Multus **Problema**: el informe CVE mejorado de EKS ImageScan identifica vulnerabilidades en la versión v4.1.4-eksbuild.2\$1thick de la imagen CNI de Multus. **Solución**: actualice a la nueva versión de la imagen CNI de Multus y a la nueva imagen del Controlador de políticas de red, que no tienen vulnerabilidades. El escáner se puede actualizar para corregir las vulnerabilidades encontradas en la versión anterior. ### Veredictos de denegación del flujo de información en los registros **Problema**: los registros de políticas de red muestran veredictos de denegación `{"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"}` **Solución**: este problema se ha resuelto en la nueva versión del Controlador de políticas de red. Actualice a la versión más reciente de la plataforma de EKS para resolver los problemas de registro. ### Problemas de comunicación entre pods después de migrar desde Calico **Problema**: tras actualizar un clúster de EKS a la versión 1.30 y cambiar de Calico a la CNI de Amazon VPC para la política de red, la comunicación entre pods falla cuando se aplican las políticas de red. La comunicación se restablece cuando se eliminan las políticas de red. **Solución**: el agente de políticas de red de la CNI de la VPC no puede tener tantos puertos especificados como Calico. En su lugar, utilice rangos de puertos en las políticas de red. El número máximo de combinaciones únicas de puertos para cada protocolo en cada selector de `ingress:` o `egress:` en una política de red es 24. Utilice rangos de puertos para reducir la cantidad de puertos únicos y evitar esta limitación. ### El agente de políticas de red no admite pods independientes **Problema**: las políticas de red aplicadas a los pods independientes pueden tener un comportamiento inconsistente. **Solución**: actualmente, el agente de políticas de red solo admite los pods que se implementan como parte de un conjunto de réplicas/implementación. Si las políticas de red se aplican a los pods independientes, es posible que se produzcan algunas inconsistencias en el comportamiento. Esto se documenta en la parte superior de esta página, en [Consideraciones](cni-network-policy.md#cni-network-policy-considerations), y en [aws-network-policy-agent GitHub issue \$1327](https://github.com/aws/aws-network-policy-agent/issues/327) en GitHub. Implemente los pods como parte de un conjunto de réplicas o implementación para lograr un comportamiento consistente de las políticas de red.