Conexión de pods en red (CNI) - Amazon EKS

Conexión de pods en red (CNI)

Amazon EKS admite redes VPC nativas con el complemento de interfaz de red de contenedores (CNI) de Amazon VPC para Kubernetes. Este complemento asigna una dirección IP de su VPC a cada pod. El complemento es un proyecto de código abierto que se mantiene en GitHub. Para obtener más información, consulte amazon-vpc-cni-k8s y Propuesta: Complemento CNI para redes de Kubernetes a través de Amazon VPC en GitHub. El complemento CNI de Amazon VPC es totalmente compatible para su uso en clústeres de Amazon EKS y de Kubernetes autoadministrados en AWS.

nota

Kubernetes puede utilizar la interfaz de red de contenedores (CNI) para los ajustes de red configurables. Es posible que el complemento CNI de Amazon VPC no cumpla los requisitos para todos los casos de uso. Amazon EKS mantiene una red de socios que ofrecen soluciones alternativas de CNI con opciones de soporte comercial. Para obtener más información, consulte Complementos CNI compatibles alternativos.

Cuando crea un nodo de Amazon EKS, tiene una interfaz de red. Todos los tipos de instancias de Amazon EC2 admiten más de una interfaz de red. La interfaz de red adjunta a la instancia cuando se crea la instancia se denomina interfaz de red principal. Cualquier interfaz de red adicional adjunta a la instancia se denomina interfaz de red secundaria. A cada interfaz de red se le pueden asignar varias direcciones IP privadas. Una de las direcciones IP privadas es la dirección IP principal, mientras que todas las demás direcciones asignadas a la interfaz de red son direcciones IP secundarias. A fin de obtener más información sobre las interfaces de red, consulte Interfaces de red elástica en la Guía del usuario de Amazon EC2 para instancias de Linux. A fin de obtener más información sobre cuántas interfaces de red y direcciones IP privadas se admiten para cada interfaz de red, consulte Direcciones IP por interfaz de red por tipo de instancias en la Guía del usuario de Amazon EC2 para instancias de Linux. Por ejemplo, un tipo de instancias m5.large admite tres interfaces de red y diez direcciones IP privadas por cada interfaz de red.

El complemento de interfaz de red de contenedores (CNI) de Amazon VPC para Kubernetes se implementa con cada uno de sus nodos de Amazon EC2 en un Daemonset con el nombre aws-node. El complemento consta de dos componentes principales:

  • Daemon L-IPAM: responsable de crear interfaces de red y adjuntar las interfaces de red a las instancias de Amazon EC2, asignar direcciones IP secundarias a las interfaces de red y mantener un grupo activo de direcciones IP en cada nodo para asignarlas a los pods de Kubernetes cuando se programan. Cuando el número de pods que se ejecutan en el nodo supera el número de direcciones que se pueden asignar a una interfaz de red única, el complemento comienza a asignar una interfaz de red nueva, siempre y cuando el número máximo de interfaces de red para la instancia no se encuentre conectado. Hay variables de configuración que permiten cambiar el valor predeterminado para cuando el complemento crea interfaces de red nuevas. Para obtener más información, consulte WARM_ENI_TARGET, WARM_IP_TARGET y MINIMUM_IP_TARGET en GitHub.

    A cada pod que implemente se le asigna una dirección IP privada secundaria desde una de las interfaces de red adjuntas a la instancia. Anteriormente, se mencionó que una instancia m5.large admite tres interfaces de red y diez direcciones IP privadas por cada interfaz de red. A pesar de que una instancia m5.large admite 30 direcciones IP privadas, no puede implementar 30 pods en ese nodo. Para determinar cuántos pods puede implementar en un nodo, utilice la siguiente fórmula:

    (Number of network interfaces for the instance type × (the number of IP addressess per network interface - 1)) + 2

    Con esta fórmula, un tipo de instancias m5.large puede admitir un máximo de 29 pods. Para obtener una lista del número máximo de pods admitidos por cada tipo de instancias, consulte eni-max-pods.txt en GitHub. Los pods del sistema cuentan para el máximo de pods. Por ejemplo, el complemento CNI y los pods kube-proxy se ejecutan en todos los nodos de un clúster, por lo que solo puede implementar 27 pods adicionales en una instancia m5.large, no 29. Además, CoreDNS se ejecuta en algunos de los nodos del clúster, lo que disminuye el número máximo de pods en otro para los nodos en los que se ejecuta.

    De forma predeterminada, a todos los pods implementados en un nodo se les asignan los mismos grupos de seguridad y se les asignan direcciones IP privadas desde un bloque de CIDR que se asigna a la subred a la que se encuentra conectada una de las interfaces de red de la instancia. Puede asignar direcciones IP desde un bloque de CIDR diferente de la subred a la que se encuentra conectada la interfaz de red principal al configurar Redes personalizadas de CNI. También puede utilizar la red personalizada de CNI para asignar a todos los pods de un nodo los mismos grupos de seguridad. Los grupos de seguridad asignados a todos los pods pueden ser diferentes a los grupos de seguridad asignados a la interfaz de red principal. Puede asignar grupos de seguridad únicos a los pods implementados en muchos tipos de instancias de Amazon EC2 mediante grupos de seguridad para los pods. Para obtener más información, consulte Grupos de seguridad de pods.

  • Complemento CNI: responsable de las conexiones de red del anfitrión (por ejemplo, de la configuración de las interfaces de red y los pares Ethernet virtuales) y de agregar la interfaz de red correcta al espacio de nombres del pod.

importante

Si utiliza la versión 1.7.0 o posterior del complemento CNI y asigna una política de seguridad de pod personalizada a la cuenta de servicio de aws-node Kubernetes utilizada para los pods de aws-node implementados por el Daemonset, la política debe contar con control de versiones NET_ADMIN en su sección de allowedCapabilities junto con hostNetwork: true y privileged: true en la política de spec. Para obtener más información, consulte Política de seguridad del pod.