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:

Puede solucionar problemas e investigar las conexiones de red que utilizan políticas de red leyendo los registros de políticas de red y ejecutando las herramientas del eBPF SDK.

Nuevos permisos y CRD policyendpoints

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

Complemento de Amazon EKS

En la siguiente captura de pantalla se muestra un ejemplo de este escenario.

Complemento autoadministrado

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.

Requisitos previos

Complemento de Amazon EKS

Complemento autoadministrado

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

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ón1.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 siguiente 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:

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_thick 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 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, y en problema n.º 327 de aws-network-policy-agent 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.