Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
CNI de Amazon VPC
sugerencia
Explore las
Amazon EKS implementa las redes de clústeres a través del complemento
El CNI de Amazon VPC tiene dos componentes:
-
CNI Binary, que configurará la red de pods para permitir la comunicación. Pod-to-Pod El binario CNI se ejecuta en el sistema de archivos raíz de un nodo y el kubelet lo invoca cuando se agrega un nuevo pod al nodo o se elimina un pod existente.
-
ipamd, un daemon de administración de direcciones IP (IPAM) local de nodo de larga duración que es responsable de:
-
administrar los ENI en un nodo, y
-
mantener un conjunto actualizado de direcciones IP o prefijos disponibles
-
Cuando se crea una instancia, EC2 crea y adjunta un ENI principal asociado a una subred principal. La subred principal puede ser pública o privada. Los pods que se ejecutan en el modo HostNetwork utilizan la dirección IP principal asignada al ENI principal del nodo y comparten el mismo espacio de nombres de red que el host.
El complemento CNI administra las interfaces de red elásticas (ENI) en el nodo. Cuando se aprovisiona un nodo, el complemento CNI asigna automáticamente un conjunto de ranuras (IP o prefijos) de la subred del nodo a la ENI principal. Este grupo se conoce como grupo activo y su tamaño viene determinado por el tipo de instancia del nodo. Según la configuración del CNI, una ranura puede ser una dirección IP o un prefijo. Cuando se ha asignado una ranura a un ENI, el CNI puede adjuntar a los nodos ENI adicionales con un conjunto fijo de ranuras. Estos ENI adicionales se denominan ENI secundarios. Cada ENI solo admite un número determinado de ranuras, según el tipo de instancia. El CNI adjunta más ENI a las instancias en función de la cantidad de ranuras necesarias, que normalmente corresponde a la cantidad de pods. Este proceso continúa hasta que el nodo ya no pueda admitir más ENI. El CNI también preasigna los ENI y ranuras «calientes» para acelerar el arranque de los Pod. Ten en cuenta que cada tipo de instancia tiene un número máximo de ENI que se pueden adjuntar. Esta es una restricción de la densidad de pods (número de pods por nodo), además de los recursos de procesamiento.
La cantidad máxima de interfaces de red y la cantidad máxima de ranuras que puede usar varían según el tipo de instancia EC2. Dado que cada pod consume una dirección IP en una ranura, la cantidad de pods que puede ejecutar en una instancia EC2 concreta depende del número de ENI que se le puedan conectar y del número de ranuras que admita cada ENI. Te sugerimos establecer el número máximo de pods por guía del usuario de EKS para evitar que se agoten los recursos de CPU y memoria de la instancia. El uso de pods hostNetwork se excluye de este cálculo. Para obtener más información, consulte Cómo se determinan los MaxPods en la guía del usuario de Amazon EKS.
Descripción general de
El modo IP secundario es el modo predeterminado para la CNI de VPC. Esta guía proporciona una descripción general del comportamiento del CNI de la VPC cuando el modo de IP secundaria está habilitado. La funcionalidad de ipamd (asignación de direcciones IP) puede variar en función de los ajustes de configuración del CNI de la VPC, como, y. Modo prefijo para Linux Grupos de seguridad por pod Redes personalizadas
El CNI de Amazon VPC se implementa como un daemonset de Kubernetes denominado aws-node en los nodos de trabajo. Cuando se aprovisiona un nodo de trabajo, se le adjunta un ENI predeterminado, denominado ENI principal. El CNI asigna un conjunto dinámico de ENI y direcciones IP secundarias de la subred conectada al ENI principal del nodo. De forma predeterminada, ipamd intenta asignar un ENI adicional al nodo. El IPAMD asigna un ENI adicional cuando se programa un solo pod y se le asigna una dirección IP secundaria del ENI principal. Este ENI «cálido» permite conectar los pods de forma más rápida. A medida que se agota el conjunto de direcciones IP secundarias, el CNI agrega otro ENI para asignar más.
La cantidad de ENI y direcciones IP de un grupo se configura mediante variables de entorno denominadas WARM_ENI_TARGET, WARM_IP_TARGET y MINIMUM_IP_TARGET. aws-node Se adjunta un número suficiente de ENI cuando se cumplen todas las condiciones WARM_ENI_TARGET o condicionesWARM_IP_TARGET. MINIMUM_IP_TARGET Si no hay suficientes ENI adjuntos, el CNI realizará una llamada de API a EC2 para adjuntar más hasta que MAX_ENI se alcance el límite.
-
WARM_ENI_TARGET- Entero, los valores superiores a 0 indican que el requisito está activado-
El número de ENI calientes que se deben mantener. Un ENI está «caliente» cuando se conecta como un ENI secundario a un nodo, pero no lo usa ningún pod. Más específicamente, no se ha asociado ninguna dirección IP del ENI a un pod.
-
Ejemplo: consideremos una instancia con 2 ENI, cada ENI compatible con 5 direcciones IP. WARM_ENI_TARGET está establecido en 1. Si hay exactamente 5 direcciones IP asociadas a la instancia, el CNI mantiene 2 ENI adjuntas a la instancia. El primer ENI está en uso y se utilizan las 5 direcciones IP posibles de este ENI. El segundo ENI es «cálido» y contiene las 5 direcciones IP agrupadas. Si se lanza otro pod en la instancia, se necesitará una sexta dirección IP. El CNI asignará a este sexto pod una dirección IP del segundo ENI y de 5 IP del grupo. El segundo ENI ya está en uso y ya no está en estado «caliente». El CNI asignará un tercer ENI para mantener al menos un ENI cálido.
-
nota
Los ENI calientes siguen consumiendo direcciones IP del CIDR de su VPC. Las direcciones IP «no se utilizan» o están «inactivas» hasta que se asocian a una carga de trabajo, como un pod.
-
WARM_IP_TARGET, Entero, los valores superiores a 0 indican que el requisito está activado-
El número de direcciones IP activas que se van a mantener. Una IP caliente está disponible en un ENI conectado activamente, pero no se ha asignado a un pod. En otras palabras, la cantidad de IP activas disponibles es la cantidad de IP que se pueden asignar a un pod sin necesidad de un ENI adicional.
-
Ejemplo: consideremos una instancia con 1 ENI, en la que cada ENI admite 20 direcciones IP. WARM_IP_TARGET está establecido en 5. WARM_ENI_TARGET está establecido en 0. Solo se adjuntará 1 ENI hasta que se necesite una decimosexta dirección IP. Luego, el CNI adjuntará un segundo ENI, que consumirá 20 direcciones posibles del CIDR de subred.
-
-
MINIMUM_IP_TARGET, Entero, los valores superiores a 0 indican que el requisito está activado-
El número mínimo de direcciones IP que se asignarán en cualquier momento. Por lo general, se usa para anticipar la asignación de varios ENI al lanzar la instancia.
-
Ejemplo: consideremos una instancia recién lanzada. Tiene 1 ENI y cada ENI admite 10 direcciones IP. MINIMUM_IP_TARGET está establecido en 100. El ENI adjunta inmediatamente 9 ENI más para un total de 100 direcciones. Esto ocurre independientemente de los valores de WARM_IP_TARGET o WARM_ENI_TARGET.
-
Este proyecto incluye un documento Excel de la calculadora de subredes. https://github.com/aws/aws-eks-best-practices/blob/master/latest/bpg/networking/subnet-calc/subnet-calc.xlsxWARM_IP_TARGET y. WARM_ENI_TARGET
Cuando Kubelet recibe una solicitud para agregar un pod, el binario CNI consulta a ipamd para obtener una dirección IP disponible, que ipamd luego proporciona al pod. El binario CNI conecta la red del host y del pod.
Los pods desplegados en un nodo se asignan, de forma predeterminada, a los mismos grupos de seguridad que el ENI principal. Como alternativa, los pods se pueden configurar con diferentes grupos de seguridad.
A medida que se agota el grupo de direcciones IP, el complemento asocia automáticamente otra interfaz de red elástica a la instancia y asigna otro conjunto de direcciones IP secundarias a esa interfaz. Este proceso continúa hasta que el nodo ya no puede admitir interfaces de red elásticas adicionales.
Cuando se elimina un pod, el CNI de la VPC coloca la dirección IP del pod en una caché de enfriamiento de 30 segundos. Las direcciones IP de una caché de enfriamiento no se asignan a los nuevos pods. Cuando finaliza el período de reflexión, el CNI de la VPC devuelve la IP del pod a la piscina caliente. Este período de reflexión evita que las direcciones IP de los pods se reciclen prematuramente y permite que kube-proxy termine de actualizar las reglas de iptables en todos los nodos del clúster. Cuando el número de IP o ENI supera el número de configuraciones de grupos activos, el complemento ipamd devuelve las IP y los ENI a la VPC.
Como se describió anteriormente, en el modo IP secundaria, cada pod recibe una dirección IP privada secundaria de una de las ENI conectadas a una instancia. Como cada pod usa una dirección IP, la cantidad de pods que puede ejecutar en una instancia EC2 concreta depende del número de ENI que se le puedan adjuntar y del número de direcciones IP que admita. El CNI de la VPC comprueba el archivo de
Puedes usar la siguiente fórmula para determinar la cantidad máxima de pods que puedes implementar en un nodo.
(Number of network interfaces for the instance type * (the number of IP addresses per network interface - 1)) + 2
El +2 indica los pods que requieren una red de host, como kube-proxy y VPC CNI. Amazon EKS requiere que el proxy de kube y el CNI de la VPC funcionen en cada nodo, y estos requisitos se tienen en cuenta en el valor máximo de los pods. Si desea ejecutar más pods de red de hosts, considere la posibilidad de actualizar el valor de max-pods. Puede especificarlos --kubelet-extra-args "—max-pods=110" como datos de usuario en la plantilla de lanzamiento.
Por ejemplo, en un clúster con 3 nodos c5.large (3 ENI y un máximo de 10 IP por ENI), cuando el clúster se inicie y tenga 2 pods de DNS principales, el CNI consumirá 50 direcciones IP y mantendrá 43 IP en un grupo activo. El grupo activo permite que los pods se lancen más rápido cuando se implementa la aplicación.
Nodo 1 (con el pod CoreDNS): 2 ENI, 20 IP asignadas
Nodo 2 (con el pod CoreDNS): 2 ENI, 20 IP asignadas
Nodo 3 (sin pod): 1 ENI. 10 IP asignadas.
Para el nodo 1 y el nodo 2 (configuración idéntica):
-
2 ENI × 10 IP por ENI = 20 IP en total
-
Reste 2 IP principales (1 por ENI) = 18 IP
-
Reste 1 IP para el pod de CoreDNS = 17 IP disponibles
-
Por lo tanto, cada uno de estos nodos tiene 17 IP en una piscina caliente
Para el nodo 3:
-
1 ENI × 10 IP = 10 IP en total
-
Reste 1 IP principal = 9 IP disponibles en una piscina caliente
Cálculo del total de una piscina caliente: - 17 (nodo 1) + 17 (nodo 2) + 9 (nodo 3) = 43 direcciones IP
Tenga en cuenta que cada uno de los pods de infraestructura, que a menudo se ejecutan como conjuntos de demonios, contribuye al número máximo de pods. Estos pueden incluir:
-
CoreDNS
-
Amazon Elastic LoadBalancer
-
Módulos operativos para Metrics-Server
Le sugerimos que planifique su infraestructura combinando las capacidades de estos pods. Para ver una lista del número máximo de pods que admite cada tipo de instancia, consulta eni-max-pods.txt
Recomendaciones
Implemente el clúster EKS con el modo automático
Cuando utiliza el modo automático de EKS para crear un clúster, AWS administra la configuración de la interfaz de red de contenedores (CNI) de la VPC para su clúster. Con el modo automático de Amazon EKS, no necesita instalar ni actualizar los complementos de red. Sin embargo, asegúrese de que sus cargas de trabajo sean compatibles con la configuración CNI de la VPC administrada.
Implemente VPC CNI Managed Add-On
Al aprovisionar un clúster, Amazon EKS instala automáticamente el CNI de la VPC. Sin embargo, Amazon EKS admite complementos gestionados que permiten al clúster interactuar con los recursos subyacentes de AWS, como la informática, el almacenamiento y las redes. Le recomendamos encarecidamente que implemente los clústeres con complementos administrados, incluido el CNI de VPC.
El complemento administrado de Amazon EKS ofrece la instalación y la administración del CNI de la VPC para los clústeres de Amazon EKS. Los complementos de Amazon EKS incluyen los parches de seguridad y las correcciones de errores más recientes y AWS los valida para que funcionen con Amazon EKS. El complemento CNI de VPC le permite garantizar de forma continua la seguridad y la estabilidad de los clústeres de Amazon EKS y reducir el esfuerzo necesario para instalar, configurar y actualizar los complementos. Además, se puede añadir, actualizar o eliminar un complemento administrado mediante la API de Amazon EKS, la consola de administración de AWS, la CLI de AWS y eksctl.
Para encontrar los campos gestionados de la VPC CNI, utilice --show-managed-fields la marca con el comando. kubectl get
kubectl get daemonset aws-node --show-managed-fields -n kube-system -o yaml
Los complementos administrados evitan que la configuración se desvíe al sobrescribirlas automáticamente cada 15 minutos. Esto significa que cualquier cambio en los complementos gestionados que se realice a través de la API de Kubernetes tras su creación se sobrescribirá mediante el proceso automatizado de prevención de errores y también se establecerá como predeterminado durante el proceso de actualización del complemento.
Los campos gestionados por EKS aparecen en ManagedFields y el administrador es EKS. Los campos gestionados por EKS incluyen la cuenta de servicio, la imagen, la URL de la imagen, la sonda de disponibilidad, la sonda de disponibilidad, las etiquetas, los volúmenes y los montajes de volúmenes.
nota
Los campos que se utilizan con más frecuencia, como WARM_ENI_TARGET, WARM_IP_TARGET y MINIMUM_IP_TARGET, no se administran y no se conciliarán. Los cambios en estos campos se conservarán cuando se actualice el complemento.
Te sugerimos que pruebes el comportamiento de los complementos en los clústeres que no son de producción para una configuración específica antes de actualizar los clústeres de producción. Además, siga los pasos de la guía del usuario de EKS para las configuraciones complementarias.
Migre a Managed Add-On
Gestionará la compatibilidad de las versiones y actualizará los parches de seguridad de la VPC CNI autogestionada. Para actualizar un complemento autogestionado, debes usar las API de Kubernetes y las instrucciones que se describen en la guía del usuario de EKS. https://docs.aws.amazon.com/eks/latest/userguide/managing-vpc-cni.html#updating-vpc-cni-add-on Recomendamos migrar a un complemento administrado para los clústeres de EKS existentes y te recomendamos encarecidamente que crees una copia de seguridad de tu configuración actual de CNI antes de la migración. Para configurar los complementos gestionados, puede utilizar la API de Amazon EKS, la consola de administración de AWS o la interfaz de línea de comandos de AWS.
kubectl apply view-last-applied daemonset aws-node -n kube-system aws-k8s-cni-old.yaml
Amazon EKS sustituirá los ajustes de configuración del CNI si el campo aparece como gestionado con la configuración predeterminada. Advertimos contra la modificación de los campos gestionados. El complemento no concilia los campos de configuración, como las variables de entorno cálido y los modos CNI. Los pods y las aplicaciones seguirán ejecutándose mientras migras a un CNI administrado.
Haga una copia de seguridad de la configuración del CNI antes de
El CNI de la VPC se ejecuta en el plano de datos del cliente (nodos) y, por lo tanto, Amazon EKS no actualiza automáticamente el complemento (gestionado y autogestionado) cuando se publican nuevas versiones o después de actualizar el clúster a una nueva versión secundaria de Kubernetes. Para actualizar el complemento para un clúster existente, debe activar una actualización mediante la API de complementos de actualización o hacer clic en el enlace actualizar ahora de la consola de EKS para ver los complementos. Si has implementado un complemento autogestionado, sigue los pasos que se indican en la sección sobre cómo actualizar el complemento CNI de VPC autogestionado. https://docs.aws.amazon.com/eks/latest/userguide/managing-vpc-cni.html#updating-vpc-cni-add-on
Le recomendamos encarecidamente que actualice una versión secundaria a la vez. Por ejemplo, si su versión secundaria actual es 1.9 y desea actualizarla a 1.11, primero debe actualizarse a la versión más reciente de revisión de 1.10 y, luego, actualizarse la última versión de revisión de 1.11.
Realice una inspección del daemonset de aws-node antes de actualizar el CNI de Amazon VPC. Realice una copia de seguridad de la configuración existente. Si utiliza un complemento gestionado, confirme que no ha actualizado ninguna configuración que Amazon EKS pueda anular. Le recomendamos incluir un enlace posterior a la actualización en su flujo de trabajo de automatización o aplicarlo manualmente después de actualizar un complemento.
kubectl apply view-last-applied daemonset aws-node -n kube-system aws-k8s-cni-old.yaml
En el caso de un complemento autogestionado, compara la copia de seguridad con releases la versión GitHub para ver las versiones disponibles y familiarizarte con los cambios en la versión a la que quieres actualizar. Te recomendamos usar Helm para gestionar los complementos autogestionados y aprovechar los archivos de valores para aplicar la configuración. Cualquier operación de actualización que implique la eliminación de Daemonset provocará un tiempo de inactividad de la aplicación y debe evitarse.
Comprenda el contexto de seguridad
Le recomendamos encarecidamente que comprenda los contextos de seguridad configurados para administrar el CNI de la VPC de manera eficiente. El CNI de Amazon VPC tiene dos componentes: CNI binario y ipamd (aws-node) Daemonset. El CNI se ejecuta como un binario en un nodo y tiene acceso al sistema de archivos raíz del nodo. También tiene acceso privilegiado, ya que se ocupa de iptables a nivel de nodo. El kubelet invoca el binario CNI cuando se añaden o eliminan pods.
El daemonset de aws-node es un proceso de larga duración responsable de la administración de las direcciones IP a nivel de nodo. El aws-node se ejecuta en hostNetwork modo y permite el acceso al dispositivo de bucle invertido y a la actividad de red de otros pods del mismo nodo. El contenedor de inicio de aws-node se ejecuta en modo privilegiado y monta el socket CRI, lo que permite al Daemonset supervisar el uso de la IP por parte de los pods que se ejecutan en el nodo. Amazon EKS está trabajando para eliminar el requisito de privilegios del contenedor de inicio aws-node. Además, el aws-node necesita actualizar las entradas de NAT y cargar los módulos de iptables, por lo que funciona con privilegios NET_ADMIN.
Amazon EKS recomienda implementar las políticas de seguridad definidas en el manifiesto de aws-node para administrar la IP de los pods y la configuración de red. Considere la posibilidad de actualizar a la versión más reciente de VPC CNI. Además, considera la posibilidad de abrir una GitHub edición
Usa un rol de IAM independiente para el CNI
El CNI de la VPC de AWS requiere los permisos de AWS Identity and Access Management (IAM). La política de CNI debe configurarse antes de poder utilizar la función de IAM. Puede utilizarla AmazonEKS_CNI_Policy
De forma predeterminada, el CNI de la VPC hereda la función de IAM del nodo Amazon EKS (tanto los grupos de nodos gestionados como los autogestionados).
Se recomienda encarecidamente configurar un rol de IAM independiente con las políticas pertinentes para el CNI de Amazon VPC. De lo contrario, los pods del CNI de Amazon VPC obtienen el permiso asignado al rol de IAM del nodo y tienen acceso al perfil de instancia asignado al nodo.
El complemento CNI de la VPC crea y configura una cuenta de servicio denominada aws-node. De forma predeterminada, la cuenta de servicio se vincula al rol de IAM del nodo de Amazon EKS con la política CNI de Amazon EKS adjunta. Para utilizar el rol de IAM independiente, le recomendamos que cree una nueva cuenta de servicio con la política CNI de Amazon EKS adjunta. Para usar una nueva cuenta de servicio, debe volver a implementar los pods de CNI. Considera la posibilidad de especificar un complemento administrado --service-account-role-arn por CNI para la VPC al crear nuevos clústeres. Asegúrese de eliminar la política CNI de Amazon EKS para IPv4 e IPv6 del rol de nodo de Amazon EKS.
Se recomienda bloquear los metadatos de la instancia de acceso para minimizar el alcance de la brecha de seguridad.
Gestione los errores Liveness/Readiness de Probe
Recomendamos aumentar los valores de tiempo de espera de las sondas (valores predeterminadostimeoutSeconds: 10) para los clústeres de EKS 1.20 y versiones posteriores para evitar que los errores de las sondas provoquen que el pod de la aplicación quede atascado en el estado de creación de contenedores. Este problema se ha observado en clústeres de procesamiento por lotes y con uso intensivo de datos. El uso excesivo de la CPU provoca fallos en el estado de las sondas de aws-node, lo que hace que las solicitudes de CPU de los pods no se satisfagan. Además de modificar el tiempo de espera de la sonda, asegúrese de que las solicitudes de recursos de CPU (predeterminadasCPU: 25m) para aws-node estén configuradas correctamente. No recomendamos actualizar la configuración a menos que su nodo tenga problemas.
Le recomendamos encarecidamente que ejecute sudo bash /opt/cni/bin/aws-cni-support.sh en un nodo mientras se pone en contacto con el soporte de Amazon EKS. El script ayudará a evaluar los registros de Kubelet y el uso de la memoria en el nodo. Considere instalar SSM Agent en los nodos de trabajo de Amazon EKS para ejecutar el script.
Configure la política de reenvío de IPTables en instancias de AMI no optimizadas para EKS
Si utiliza una AMI personalizada, asegúrese de configurar la política de reenvío de iptables en ACCEPT en kubelet.service. https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2023/runtime/rootfs/etc/systemd/system/kubelet.service
Actualice la versión CNI de forma rutinaria
El CNI de la VPC es compatible con versiones anteriores. La última versión funciona con todas las versiones de Kubernetes compatibles con Amazon EKS. Además, el CNI de la VPC se ofrece como un complemento de EKS (consulte «Implementar la VPC CNI gestionada» más arriba). Add-On Si bien los complementos de EKS organizan las actualizaciones de los complementos, no actualizarán automáticamente complementos como el CNI porque se ejecutan en el plano de datos. Usted es responsable de actualizar el complemento CNI de la VPC después de actualizar los nodos de trabajo gestionados y autogestionados.
