Ayude a mejorar esta página
¿Quiere contribuir a esta guía del usuario? Desplácese hasta el final de esta página y seleccione Editar esta página en GitHub. Sus contribuciones ayudarán a que nuestra guía del usuario sea mejor para todos.
Habilitación del acceso a internet saliente para pods
Aplicación: en nodos de Linux IPv4 Fargate, y nodos de Linux con instancias de Amazon EC2
Si ha implementado el clúster mediante la familia IPv6, la información de este tema no se aplica a su clúster, porque las direcciones IPv6 no están traducidas en red. Para obtener más información acerca del uso de IPv6 con su clúster, consulte Asignación de direcciones IPv6 a clústeres, pods y servicios.
De forma predeterminada, a cada Pod en el clúster se le asigna una dirección privada IPv4 de un bloque de enrutamiento entre dominios sin clase (CIDR) asociado a la VPC en la que el Pod se implementa. Los Pods en la misma VPC se comunican entre sí utilizando estas direcciones IP privadas como puntos de conexión. Cuando un Pod se comunica a cualquier dirección IPv4 que no se encuentra dentro de un bloque CIDR asociado a la VPC, el complemento CNI de Amazon VPC (tanto para LinuxIPv4 del Pod's a la dirección IPv4 privada principal de la interfaz de red elástica principal del nodo en el que el Pod se está ejecutando, de forma predeterminada *.
nota
En el caso de los nodos de Windows, hay detalles adicionales que se deben tener en cuenta. De forma predeterminada, el complemento CNI de VPC para Windows
Debido a este comportamiento:
-
Los Pods pueden comunicarse con recursos de Internet solo si el nodo en el que se están ejecutando tiene una dirección IP pública o elástica asignada y se encuentra en una subred pública. Una subred pública es una subred asociada a la tabla de enrutamiento con ruta a la puerta de enlace de internet. Recomendamos implementar nodos en subredes privadas, siempre que sea posible.
-
Para versiones del complemento anteriores a la
1.8.0, los recursos que se encuentran en redes o VPC que están conectadas a la VPC del clúster mediante un emparejamiento de VPC, una VPC de tránsito o AWS Direct Connect no pueden iniciar la comunicación con sus Pods mediante interfaces de redes elásticas secundarias. No obstante, sus Pods pueden iniciar la comunicación con esos recursos y recibir respuestas de ellos.
Si alguna de las siguientes afirmaciones es verdadera en su entorno, cambie la configuración predeterminada con el comando siguiente.
-
Tiene recursos en redes o VPC que están conectados a la VPC de clúster mediante Interconexión con VPC, una VPC de tránsito o AWS Direct Connect que deben iniciar la comunicación con su Pods mediante una dirección
IPv4y la versión del complemento es anterior a la1.8.0. -
Sus Pods se encuentran en una subred privada y necesitan comunicación saliente a Internet. La subred tiene una ruta hacia una puerta de enlace NAT.
kubectl set env daemonset -n kube-system aws-node AWS_VPC_K8S_CNI_EXTERNALSNAT=true
nota
Las variables de configuración de CNI AWS_VPC_K8S_CNI_EXTERNALSNAT y AWS_VPC_K8S_CNI_EXCLUDE_SNAT_CIDRS no se aplican a los nodos de Windows. No se admite la desactivación de SNAT para Windows. En cuanto a la exclusión de una lista de CIDR IPv4 de SNAT, puede definirla especificando el parámetro ExcludedSnatCIDRs en el script de arranque de Windows. Para obtener más información acerca del uso de este parámetro, consulte Parámetros de configuración del script de arranque.
Red del host
*Si las especificaciones de un Pod's contienen hostNetwork=true (el valor predeterminado es false), su dirección IP no se traduce a otra dirección. Este es el caso de la kube-proxy y Amazon VPC CNI plugin for Kubernetes Pods que se ejecutan en el clúster, de forma predeterminada. Para estos Pods, la dirección IP es la misma que la dirección IP principal del nodo, por lo que la dirección IP Pod's no está traducida. Para obtener más información acerca de la configuración de hostNetwork de Pod's, consulte Núcleo de PodSpec v1
