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, Amazon VPC CNI asignará a los pods una dirección IP seleccionada de la subred principal. La subred principal es la subred a la CIDR que ENI está conectado el principal, normalmente la subred del nodo/host.

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

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

Las redes personalizadas abordan el problema del agotamiento de la IP al asignar el nodo y el pod IPs desde espacios de VPC direcciones secundarios (CIDR). El soporte de redes personalizado admite recursos ENIConfig personalizados. ENIConfigIncluye un CIDR rango de subredes alternativo (extraído de un rango secundario VPCCIDR), junto con los grupos de seguridad a los que pertenecerán los pods. Cuando se habilitan las redes personalizadas, se VPC CNI crea una secundaria ENIs en la subred definida en. ENIConfig Le CNI asigna a los pods direcciones IP de un CIDR rango definido en un. ENIConfig CRD

Como las redes personalizadas no utilizan el principalENI, la cantidad máxima de pods que puede ejecutar en un nodo es inferior. Los pods de la red host siguen utilizando la dirección IP asignada al principalENI. Además, la principal ENI se utiliza 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 VPC rango válido como CIDR rango secundario, le recomendamos que utilice CIDRs (/16) del NAT espacio CG, es decir, 100.64.0.0/10 o 198.19.0.0/16, ya que es menos probable que se usen en un entorno corporativo que en otros rangos. RFC1918 Para obtener información adicional sobre las asociaciones de bloques permitidas y restringidas que puede utilizar con su organizaciónVPC, consulte las restricciones de asociación de CIDR bloques en la sección sobre el tamaño de las subredes y el IPv4 CIDR tamaño de las subredes de la documentación. VPC VPC

Como se muestra en el diagrama siguiente, la interfaz de red elástica principal (ENI) del nodo trabajador sigue ENIs utilizando el VPC CIDR rango principal (en este caso 10.0.0.0/16), pero la secundaria usa el VPC CIDR rango secundario (en este caso 100.64.0.0/16). Ahora, para que los pods usen el rango 100.64.0.0/16, debes configurar el complemento CIDR para que utilice redes personalizadas. CNI Puedes seguir los pasos que se documentan aquí.

Si desea utilizar una red personalizada, CNI 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

CuandoAWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG=true, CNI asignará la dirección IP del pod desde una subred definida enENIConfig. 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 una red personalizada si está IPv4 agotada y IPv6 aún no puede utilizarla. El EKS soporte de Amazon para RFC6598el espacio te permite escalar los Pods más allá de RFC1918abordar los desafíos del agotamiento. Considera la posibilidad de utilizar la delegación de prefijos con redes personalizadas para aumentar la densidad de pods en un nodo.

Si tienes requisitos de seguridad para ejecutar los Pods en una red diferente con requisitos de grupo de seguridad diferentes, podrías considerar la posibilidad de utilizar redes personalizadas. Cuando están habilitadas las redes personalizadas, los pods utilizan subredes o grupos de seguridad diferentes, tal como se definen ENIConfig en la interfaz de red principal del nodo.

De hecho, las redes personalizadas son una opción ideal para implementar múltiples EKS clústeres y aplicaciones para conectar los servicios del centro de datos locales. Puedes aumentar el número de direcciones privadas (RFC1918) a las que puedes acceder EKS en tus VPC servicios, como Amazon Elastic Load Balancing y NAT -GW, a la vez que utilizas un NAT espacio CG- no enrutable para tus pods en varios clústeres. Las redes personalizadas con la puerta de enlace de tránsito y los servicios compartidos VPC (incluidas NAT las puertas de enlace en varias zonas de disponibilidad para una alta disponibilidad) te permiten ofrecer flujos de tráfico escalables y predecibles. Esta entrada de blog describe un patrón arquitectónico que es una de las formas más recomendadas de conectar los EKS pods a una red de centro de datos mediante redes personalizadas.

Evite las redes personalizadas cuando

¿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 un sistema de doble pila (IPv4/IPv6) VPC o si su plan incluye IPv6 soporte, le recomendamos implementar IPv6 clústeres en su lugar. Puede configurar IPv6 EKS clústeres y migrar sus aplicaciones. En un IPv6 EKS clúster, tanto Kubernetes como los Pods obtienen una IPv6 dirección y pueden comunicarse de entrada y salida tanto IPv4 con los puntos de conexión como con los terminales. IPv6 Consulta las prácticas recomendadas para ejecutar clústeres. IPv6 EKS

Espacio CG agotado NAT

Además, si actualmente lo utilizas CIDRs desde el NAT espacio CG o no puedes vincular un secundario CIDR a tu clústerVPC, es posible que tengas que explorar otras opciones, como utilizar una alternativa. CNI Te recomendamos encarecidamente que obtengas soporte comercial o que cuentes con los conocimientos técnicos necesarios para depurar y enviar parches al proyecto de CNI plugin de código abierto. Consulte la guía del usuario de CNIcomplementos alternativos para obtener más información.

Utilice Private NAT Gateway

Amazon VPC ahora ofrece capacidades de NATpuerta de enlace privada. La NAT puerta de enlace privada de Amazon permite que las instancias de subredes privadas se conecten a otras redes VPCs y a redes locales superpuestas. CIDRs Considere la posibilidad de utilizar el método descrito en esta entrada de blog para utilizar una NAT puerta de enlace privada para superar los problemas de comunicación relacionados con las EKS cargas de trabajo causadas por la superposiciónCIDRs, una queja importante expresada por nuestros clientes. Las redes personalizadas no pueden resolver las CIDR dificultades que se superponen por sí solas y agravan los desafíos de configuración.

La arquitectura de red utilizada en la implementación de esta entrada de blog sigue las recomendaciones de la VPC documentación de Amazon sobre Habilitar la comunicación entre redes superpuestas. Como se demuestra en esta entrada de blog, puede ampliar el uso de la NAT puerta de enlace privada junto con RFC6598 las direcciones para gestionar los problemas de agotamiento de la IP privada de los clientes. Los EKS clústeres y nodos de trabajo se implementan en el CIDR rango VPC secundario no enrutable de 100.64.0.0/16, mientras que la puerta de NAT enlace privada y la puerta de enlace se implementan en los rangos enrutables. NAT RFC1918 CIDR El blog explica cómo se usa una puerta de enlace de tránsito para conectarse a fin de facilitar la comunicación a través de rangos VPCs superpuestos que no se pueden enrutar. VPCs CIDR Para los casos de uso en EKS los que los recursos VPC de un rango de direcciones no enrutable necesitan comunicarse con otros VPCs que no tienen rangos de direcciones superpuestos, los clientes tienen la opción de utilizar el VPC peering para interconectarlos. VPCs Este método podría suponer un posible ahorro de costes, ya que todo el tránsito de datos dentro de una zona de disponibilidad a través de una conexión entre pares ahora es VPC 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 los pods en una subred desde un CIDR bloque secundario más grande (por ejemplo, 100.64.0.0/8). Tras instalar el nuevo nodo CIDR en la suyaVPC, puede implementar otro grupo de nodos mediante el nodo secundario CIDR y vaciar los nodos originales para volver a desplegar automáticamente los pods en los nuevos nodos trabajadores. Para obtener más información sobre cómo implementar esto, consulta esta entrada de blog.

Las redes personalizadas no se utilizan en la configuración que se muestra en el siguiente diagrama. Por el contrario, los nodos de trabajo de Kubernetes se implementan en subredes del VPC CIDR rango secundario VPC del usuario, como 100.64.0.0/10. Puede mantener el EKS clúster en funcionamiento (el plano de control permanecerá en el original). subnet/s), but the nodes and Pods will be moved to a secondary subnet/s Esta es otra técnica, aunque poco convencional, para mitigar el peligro de agotamiento de la propiedad intelectual en unVPC. Proponemos vaciar los nodos antiguos antes de volver a desplegarlos en los nuevos nodos de trabajo.

Automatice la configuración con etiquetas de zona de disponibilidad

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

Kubernetes añade automáticamente la etiqueta a tus nodos de trabajo. topology.kubernetes.io/zone Amazon EKS recomienda usar la zona de disponibilidad como nombre de ENI configuración cuando solo tengas una subred secundaria (alternativaCIDR) por zona de disponibilidad. Ten en cuenta que la etiqueta failure-domain.beta.kubernetes.io/zone está obsoleta y se ha sustituido por la etiqueta. topology.kubernetes.io/zone

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

si tiene varias subredes secundarias por zona de disponibilidad, debe crear una específicaENI_CONFIG_LABEL_DEF. Podría considerar configurar ENI_CONFIG_LABEL_DEF como k8s.amazonaws.com/eniConfigy etiquetar los nodos con eniConfig nombres personalizados, como k8s.amazonaws.com/eniConfig=us-west-2a-subnet-1y 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 realizar un reemplazo gradual de todos los nodos de trabajo del clúster después de habilitar las redes personalizadas, le sugerimos que actualice la AWS CloudFormation plantilla de la Guía de EKS introducción con un recurso personalizado que llame a una función de Lambda para actualizar el aws-node Daemonset con la variable de entorno a fin de habilitar las redes personalizadas antes de aprovisionar los nodos de trabajo.

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

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

Como el nodo principal ya no ENI se usa para asignar direcciones IP de pods, se ha reducido el número de pods que puedes ejecutar en un tipo de EC2 instancia 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 sustituye por un prefijo /28 en la secundaria. ENIs

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

La cantidad máxima de pods que puedes ejecutar sin la asignación de prefijos es 29

Al habilitar los adjuntos con prefijos, se aumenta la cantidad de pods a 290.

Sin embargo, te sugerimos configurar el número máximo de pods en 110 en lugar de 290, ya que la instancia tiene un número bastante pequeño de dispositivos virtuales. CPUs En los casos más grandes, se EKS recomienda un valor máximo de 250 pods. Si utilizas adjuntos de prefijo con tipos de instancias más pequeños (por ejemplo, m5.large), es posible que agotes los recursos de la instancia CPU y de memoria mucho antes que sus direcciones IP.

Identifique el uso actual del espacio CG NAT

Las redes personalizadas le permiten mitigar el problema del agotamiento de la IP, pero no pueden resolver todos los desafíos. Si ya utiliza el NAT espacio CG para su clúster, o simplemente no tiene la capacidad de asociar un espacio secundario CIDR a su clústerVPC, le sugerimos que explore otras opciones, como utilizar una alternativa CNI o pasarse a IPv6 clústeres.

📝 Edita esta página en GitHub