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.

Redes personalizadas

De forma predeterminada, el CNI de Amazon VPC asignará a los pods una dirección IP seleccionada de la subred principal. La subred principal es la subred CIDR a la que está conectado el ENI principal, normalmente la subred del. node/host

Si el CIDR de la subred es demasiado pequeño, es posible que el CNI no pueda adquirir suficientes direcciones IP secundarias para asignarlas a tus pods. Este es un desafío común para los clústeres IPv4 de EKS.

Las redes personalizadas son una solución a este problema.

Las redes personalizadas solucionan el problema del agotamiento de la IP asignando las IP de los nodos y los pods desde los espacios de direcciones de VPC (CIDR) secundarios. La compatibilidad con redes personalizadas admite el recurso personalizado de EniConfig. El EniConfig incluye un rango de CIDR de subred alternativo (creado a partir de un CIDR de VPC secundario), junto con los grupos de seguridad a los que pertenecerán los pods. Cuando se habilitan las redes personalizadas, el CNI de la VPC crea ENI secundarios en la subred definida en ENIconfig. El CNI asigna a los pods una dirección IP de un rango de CIDR definido en un CRD de ENIConfig.

Como las redes personalizadas no utilizan el ENI principal, la cantidad máxima de pods que puedes ejecutar en un nodo es menor. Los pods de la red host siguen usando la dirección IP asignada al ENI principal. Además, el ENI principal se usa para gestionar la traducción de la red de origen y enrutar el tráfico de los Pods fuera del nodo.

Configuración de ejemplo

Si bien las redes personalizadas aceptan un rango de VPC válido para el rango de CIDR secundario, te recomendamos que utilices los CIDR del espacio de direcciones 100.64.0.0/10 compartido (RFC 6598), ya que es menos probable que se usen en un entorno corporativo que otros rangos de RFC1918. Por ejemplo, puedes usarlo 100.64.0.0/16 como un CIDR secundario para tu VPC. Para obtener información adicional sobre las asociaciones de bloques de CIDR permitidas y restringidas que puedes usar con tu VPC, consulta las restricciones de asociación de bloques de CIDR de IPv4 en la sección de tamaños de subredes y VPC de la documentación de la VPC.

Como se muestra en el siguiente diagrama, la interfaz de red elástica (ENI) principal del nodo de trabajo sigue utilizando el rango de CIDR de la VPC principal (en este caso, 10.0.0). 0/16) pero los ENI secundarios usan el rango CIDR de la VPC secundario (en este caso 100.64.0). 0/16). Ahora, para tener los Pods usa el 100.64.0. 0/16 En el rango CIDR, debes configurar el complemento CNI para usar redes personalizadas. Puede seguir los pasos que se documentan aquí.

Si desea que el CNI utilice redes personalizadas, defina la variable de AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG entorno en. true

kubectl set env daemonset aws-node -n kube-system AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG=true

CuándoAWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG=true, el CNI asignará la dirección IP del pod desde una subred definida en. ENIConfig El recurso ENIConfig personalizado se usa para definir la subred en la que se programarán los pods.

apiVersion : crd.k8s.amazonaws.com/v1alpha1
kind : ENIConfig
metadata:
  name: us-west-2a
spec:
  securityGroups:
    - sg-0dff111a1d11c1c11
  subnet: subnet-011b111c1f11fdf11

Al crear los recursos ENIconfig personalizados, tendrás que crear nuevos nodos de trabajo y agotar los nodos existentes. Los nodos de trabajo y los pods existentes no se verán afectados.

Recomendaciones

Utilice redes personalizadas cuando

Le recomendamos que considere la posibilidad de utilizar redes personalizadas si está agotando IPv4 y todavía no puede utilizar IPv6. La compatibilidad de Amazon EKS con el espacio de la RFC6598 le permite escalar los pods más allá de lo establecido en la RFC1918 para hacer frente a los desafíos de agotamiento. Considere la posibilidad de utilizar la delegación de prefijos con redes personalizadas para aumentar la densidad de pods en un nodo.

Puedes usar redes personalizadas si tienes un requisito de seguridad para ejecutar Pods en una red diferente con diferentes requisitos de grupo de seguridad. Cuando se habilitan las redes personalizadas, los pods utilizan subredes o grupos de seguridad diferentes a los de la interfaz de red principal del nodo, tal como se define en la ENIConfig.

De hecho, las redes personalizadas son una opción ideal para implementar varios clústeres y aplicaciones de EKS para conectar los servicios de centros de datos locales. Puedes aumentar la cantidad de direcciones privadas (RFC1918) a las que EKS tiene acceso en tu VPC para servicios como Amazon Elastic Load Balancing y NAT-GW, al mismo tiempo, utilizar espacio no enrutable CG-NAT para tus pods en varios clústeres. Las redes personalizadas con la puerta de enlace de tránsito y una VPC de servicios compartidos (que incluyen puertas de enlace NAT en varias zonas de disponibilidad para lograr una alta disponibilidad) le permiten ofrecer flujos de tráfico escalables y predecibles. En esta entrada de blog se describe un patrón arquitectónico que es una de las formas más recomendadas de conectar los EKS Pods a una red de centros de datos mediante redes personalizadas.

Evite las redes personalizadas cuando

¿Está listo para implementar IPv6

Las redes personalizadas pueden mitigar los problemas de agotamiento de la IP, pero requieren una sobrecarga operativa adicional. Si actualmente está implementando una VPC de doble pila (IPv4/IPv6) o si su plan incluye soporte para IPv6, le recomendamos implementar clústeres IPv6 en su lugar. Puede configurar clústeres EKS de IPv6 y migrar sus aplicaciones. En un clúster EKS de IPv6, tanto Kubernetes como Pods obtienen una dirección IPv6 y pueden comunicarse de entrada y salida con los puntos finales IPv4 e IPv6. Revise las prácticas recomendadas para ejecutar clústeres EKS de IPv6. Ejecución de clústeres EKS de IPv6

Espacio agotado CG-NAT

Además, si actualmente utilizas CIDR desde el CG-NAT espacio o no puedes vincular un CIDR secundario con tu VPC de clúster, es posible que tengas que explorar otras opciones, como usar un CNI alternativo. Te recomendamos encarecidamente que obtengas soporte comercial o que poseas los conocimientos internos necesarios para depurar y enviar parches al proyecto de complementos de código abierto de CNI. Consulta la guía del usuario de complementos de CNI alternativos para obtener más información.

Utilice una puerta de enlace NAT privada

Amazon VPC ahora ofrece capacidades de puerta de enlace NAT privada. La puerta de enlace NAT privada de Amazon permite que las instancias de subredes privadas se conecten a otras VPC y redes locales mediante CIDR superpuestos. Considere la posibilidad de utilizar el método descrito en esta entrada de blog para emplear una puerta de enlace NAT privada a fin de solucionar los problemas de comunicación relacionados con las cargas de trabajo de EKS causados por la superposición de CIDR, una queja importante que han expresado nuestros clientes. Las redes personalizadas no pueden resolver por sí solas los problemas de los CIDR que se superponen y, además, aumentan los desafíos de configuración.

La arquitectura de red utilizada en la implementación de esta entrada de blog sigue las recomendaciones de Habilitar la comunicación entre redes superpuestas en la documentación de Amazon VPC. Como se demuestra en esta entrada de blog, puede ampliar el uso de una puerta de enlace NAT privada junto con las direcciones RFC6598 para gestionar los problemas de agotamiento de la IP privada de los clientes. Los clústeres EKS y los nodos de trabajo se implementan en el 100.64.0 no enrutable. 0/16 El rango de CIDR secundario de la VPC, mientras que la puerta de enlace NAT privada y la puerta de enlace NAT se implementan en los rangos de CIDR enrutables del RFC1918. En el blog se explica cómo se usa una puerta de enlace de tránsito para conectar las VPC con el fin de facilitar la comunicación entre las VPC con rangos de CIDR no enrutables que se superponen. En los casos de uso en los que los recursos de EKS del rango de direcciones no enrutables de una VPC necesitan comunicarse con otras VPC que no tienen rangos de direcciones superpuestos, los clientes tienen la opción de usar la interconexión de VPC para interconectar dichas VPC. Este método podría suponer un posible ahorro de costes, ya que ahora todo el tránsito de datos dentro de una zona de disponibilidad a través de una conexión de interconexión de VPC es gratuito.

Red única para nodos y pods

Si necesitas aislar tus nodos y pods en una red específica por motivos de seguridad, te recomendamos que despliegues los nodos y pods en una subred desde un bloque CIDR secundario más grande (por ejemplo, 100.64.0). 0/8). Tras instalar el nuevo CIDR en tu VPC, puedes implementar otro grupo de nodos mediante el CIDR secundario y agotar los nodos originales para volver a implementar automáticamente los pods en los nuevos nodos de trabajo. Para obtener más información sobre cómo implementar esto, consulta esta entrada de blog. https://aws.amazon.com/blogs/containers/optimize-ip-addresses-usage-by-pods-in-your-amazon-eks-cluster/

Las redes personalizadas no se utilizan en la configuración que se representa en el siguiente diagrama. Por el contrario, los nodos de trabajo de Kubernetes se implementan en subredes del rango CIDR de VPC secundario de la VPC, como 100.64.0. 0/10. Puedes mantener el clúster de EKS en funcionamiento (el plano de control permanecerá en el original subnet/s), pero los nodos y los pods se moverán a un secundario subnet/s. Esta es otra técnica, aunque poco convencional, para mitigar el peligro de que se agote la propiedad intelectual en una VPC. Proponemos drenar los nodos antiguos antes de volver a distribuir los pods en los nuevos nodos de trabajo.

Automatice la configuración con etiquetas de zona de disponibilidad

Puede permitir que Kubernetes aplique automáticamente la ENIConfig correspondiente a la zona de disponibilidad (AZ) del nodo de trabajo.

Kubernetes agrega automáticamente la etiqueta a los nodos de trabajo. topology.kubernetes.io/zone Amazon EKS recomienda usar la zona de disponibilidad como nombre de configuración de ENI cuando solo tenga una subred secundaria (CIDR alternativa) por zona de disponibilidad. A continuación, puede configurar la etiqueta utilizada para descubrir el nombre de configuración de ENI en. topology.kubernetes.io/zone Tenga en cuenta que la etiqueta failure-domain.beta.kubernetes.io/zone está obsoleta y se reemplaza por la etiquetatopology.kubernetes.io/zone.

kubectl set env daemonset aws-node -n kube-system "AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG=true"
kubectl set env daemonset aws-node -n kube-system "ENI_CONFIG_LABEL_DEF=topology.kubernetes.io/zone"

Si tiene varias subredes secundarias por zona de disponibilidad, debe crear una específicaENI_CONFIG_LABEL_DEF. Puede considerar configurar los nodos ENI_CONFIG_LABEL_DEF como k8s.amazonaws.com/eniConfig y etiquetarlos con nombres de ENIConfig personalizados, como k8s.amazonaws.com/eniConfig=us-west-2a-subnet-1 y. k8s.amazonaws.com/eniConfig=us-west-2a-subnet-2

Sustituya los pods al configurar una red secundaria

La activación de redes personalizadas no modifica los nodos existentes. Las redes personalizadas son una acción disruptiva. En lugar de reemplazar progresivamente todos los nodos de trabajo del clúster después de habilitar las redes personalizadas, le sugerimos que actualice la CloudFormation plantilla de AWS de la Guía de introducción de EKS con un recurso personalizado que llame a una función de Lambda para actualizar el aws-node Daemonset con la variable de entorno que permita habilitar las redes personalizadas antes de aprovisionar los nodos de trabajo.

Si tenías algún nodo en tu clúster con pods en ejecución antes de cambiarte a la función de red CNI personalizada, debes acordonar y drenar los nodos para cerrar correctamente los pods y, a continuación, terminar con los nodos. Solo los nodos nuevos que coincidan con la etiqueta o las anotaciones de ENIConfig utilizan redes personalizadas y, por lo tanto, a los pods programados en estos nuevos nodos se les puede asignar una IP desde el CIDR secundario.

Calcule el número máximo de pods por nodo

Como el ENI principal del nodo ya no se usa para asignar direcciones IP a los pods, se ha reducido el número de pods que se pueden ejecutar en un tipo de instancia EC2 determinado. Para evitar esta limitación, puedes usar la asignación de prefijos con redes personalizadas. Con la asignación de prefijos, cada IP secundaria se reemplaza por un prefijo /28 en los ENI secundarios.

Ten en cuenta la cantidad máxima de pods para una instancia m5.large con redes personalizadas.

El número máximo de pods que puedes ejecutar sin asignación de prefijo es 29

Al habilitar los archivos adjuntos con prefijos, el número de pods aumenta a 290.

Sin embargo, te recomendamos configurar el número máximo de pods en 110 en lugar de 290, ya que la instancia tiene una cantidad bastante pequeña de CPU virtuales. En instancias más grandes, EKS recomienda un valor máximo de módulos de 250. Si utilizas prefijos adjuntos con tipos de instancias más pequeñas (por ejemplo, m5.large), es posible que agotes los recursos de CPU y memoria de la instancia mucho antes que sus direcciones IP.

Identifique el uso actual del espacio CG-NAT

Las redes personalizadas permiten mitigar el problema del agotamiento de la propiedad intelectual, pero no pueden resolver todos los desafíos. Si ya utilizas CG-NAT espacio para tu clúster o simplemente no puedes asociar un CIDR secundario a la VPC de tu clúster, te sugerimos que estudies otras opciones, como usar un CNI alternativo o pasarte a clústeres IPv6.