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.
Prácticas recomendadas para la creación de redes
sugerencia
Explore
Es fundamental comprender las redes de Kubernetes para operar el clúster y las aplicaciones de manera eficiente. Las redes de pods, también denominadas redes de clústeres, son el centro de las redes de Kubernetes. Kubernetes admite los complementos de interfaz de red de contenedores
Amazon EKS es compatible oficialmente con el complemento CNI Amazon Virtual Private Cloud (VPC) para implementar la red Kubernetes Pod. La VPC CNI proporciona una integración nativa con la VPC de AWS y funciona en modo subyacente. En el modo subyacente, los pods y los hosts se encuentran en la misma capa de red y comparten el espacio de nombres de la red. La dirección IP del pod es coherente desde el punto de vista del clúster y la VPC.
Esta guía presenta la interfaz de red de contenedores de Amazon VPC
Amazon EKS ejecuta Kubernetes en sentido ascendente y cuenta con la certificación de conformidad con Kubernetes. Si bien puede usar complementos de CNI alternativos, esta guía no ofrece recomendaciones para administrar CNI alternativos. Consulte la documentación de los CNI alternativos de EKS para obtener una lista de socios y recursos para gestionar los CNI alternativos de forma eficaz.
Modelo de red de Kubernetes
Kubernetes establece los siguientes requisitos para las redes de clústeres:
-
Los pods programados en el mismo nodo deben poder comunicarse con otros pods sin utilizar la NAT (traducción de direcciones de red).
-
Todos los daemons del sistema (procesos en segundo plano, por ejemplo, kubelet
) que se ejecutan en un nodo concreto pueden comunicarse con los pods que se ejecutan en el mismo nodo. -
Los pods que utilizan la red host
deben poder ponerse en contacto con todos los demás pods de todos los demás nodos sin utilizar la NAT.
Consulta el modelo de red de Kubernetes
Interfaz de red de contenedores (CNI)
Kubernetes admite las especificaciones y los complementos del CNI para implementar el modelo de red de Kubernetes. Un CNI consta de una especificación
El complemento CNI se habilita pasando a kubelet la opción de línea de comandos. --network-plugin=cni Kubelet lee un archivo --cni-conf-dir (predeterminado etc/cni /net.d) y usa la configuración CNI de ese archivo para configurar la red de cada Pod. El archivo de configuración del CNI debe coincidir con la especificación del CNI (versión 0.4.0 como mínimo) y todos los complementos de CNI necesarios a los que haga referencia la configuración deben estar presentes en el directorio (predeterminado //bin). --cni-bin-dir opt/cni Si hay varios archivos de configuración CNI en el directorio, el kubelet utiliza el archivo de configuración que aparece primero por su nombre en orden lexicográfico.
Amazon Virtual Private Cloud (VPC) CNI
El CNI de AWS-provided VPC es el complemento de red predeterminado para los clústeres de EKS. El complemento CNI de VPC se instala de forma predeterminada al aprovisionar clústeres de EKS. La CNI de VPC se ejecuta en los nodos de trabajo de Kubernetes. El complemento CNI de VPC consta del binario CNI y del complemento de administración de direcciones IP (ipamd). La CNI asigna una dirección IP de la red de VPC a un pod. El ipamd administra las interfaces de red elásticas (ENI) de AWS en cada nodo de Kubernetes y mantiene el conjunto caliente de IP. La CNI de VPC ofrece opciones de configuración para la preasignación de ENI y direcciones IP para acelerar los tiempos de inicio del pod. Consulte el CNI de Amazon VPC para obtener información sobre las prácticas recomendadas de administración de complementos.
Amazon EKS recomienda especificar subredes en al menos dos zonas de disponibilidad al crear un clúster. La CNI de Amazon VPC asigna direcciones IP a los pods desde las subredes de los nodos. Recomendamos encarecidamente comprobar las direcciones IP disponibles en las subredes. Tenga en cuenta las recomendaciones de VPC y subred antes de implementar clústeres de EKS.
El CNI de Amazon VPC asigna un conjunto caliente de ENI y direcciones IP secundarias de la subred conectada al ENI principal del nodo. Este modo de CNI de VPC se denomina modo IP secundario. El número de direcciones IP y, por lo tanto, el número de pods (densidad de pods) se define por el número de ENI y la dirección IP por ENI (límites), según lo definido por el tipo de instancia. El modo secundario es el predeterminado y funciona bien para clústeres pequeños con tipos de instancias más pequeños. Considere la posibilidad de utilizar el modo de prefijo si tiene problemas con la densidad de los pods. También puedes aumentar las direcciones IP disponibles en el nodo para los pods asignando prefijos a los ENI.
El CNI de Amazon VPC se integra de forma nativa con AWS VPC y permite a los usuarios aplicar las prácticas recomendadas de seguridad y redes de VPC de AWS existentes para crear clústeres de Kubernetes. Esto incluye la capacidad de usar registros de flujo de VPC, políticas de enrutamiento de VPC y grupos de seguridad para aislar el tráfico de la red. De forma predeterminada, la CNI de Amazon VPC aplica a los pods el grupo de seguridad asociado al ENI principal del nodo. Considere la posibilidad de habilitar grupos de seguridad para los pods cuando desee asignar reglas de red diferentes a un pod.
De forma predeterminada, la CNI de VPC asigna direcciones IP a los pods de la subred asignada al ENI principal de un nodo. Es habitual experimentar una escasez de direcciones IPv4 cuando se ejecutan clústeres grandes con miles de cargas de trabajo. AWS VPC le permite ampliar las IP disponibles mediante la asignación de un CIDR secundario para evitar el agotamiento de los bloques de CIDR de IPv4. El CNI de VPC de AWS le permite usar un rango CIDR de subred diferente para los pods. Esta función de la VPC CNI se denomina red personalizada. Podría considerar la posibilidad de utilizar redes personalizadas para utilizar los 100.64.0.0/10 198.19.0.0/16 CIDR (CG-NAT) con EKS. De hecho, esto le permite crear un entorno en el que los pods ya no consuman ninguna dirección IP RFC1918 de su VPC.
Las redes personalizadas son una opción para solucionar el problema del agotamiento de las direcciones IPv4, pero requieren una sobrecarga operativa. Para resolver este problema, recomendamos utilizar clústeres IPv6 en lugar de redes personalizadas. En concreto, recomendamos migrar a clústeres de IPv6 si ha agotado por completo todo el espacio de direcciones IPv4 disponible para su VPC. Evalúe los planes de su organización para admitir IPv6 y considere si invertir en IPv6 puede tener un valor a más largo plazo.
El soporte de EKS para IPv6 se centra en resolver el problema de agotamiento de la IP provocado por un espacio de direcciones IPv4 limitado. En respuesta a los problemas de los clientes relacionados con el agotamiento del IPv4, EKS ha priorizado los pods en lugar de los IPv6-only pods de doble pila. Es decir, los pods pueden acceder a los recursos de IPv4, pero no se les asigna una dirección IPv4 del rango CIDR de la VPC. La CNI de VPC asigna direcciones IPv6 a los pods del bloque CIDR de IPv6 de VPC administrado por AWS.
Calculadora de subredes
Este proyecto incluye un documento de Excel sobre la calculadora de subredesWARM_IP_TARGET y. WARM_ENI_TARGET El documento incluye dos hojas, una primera para el modo ENI cálido y una segunda para el modo IP cálido. Consulte la guía del CNI de VPC para obtener más información sobre estos modos.
Entradas:
-
Tamaño CIDR de subred
-
Objetivo ENI cálido o objetivo IP cálido
-
Lista de instancias
-
tipo, número y cantidad de módulos de carga de trabajo programados por instancia
-
Salidas:
-
Número total de pods alojados
-
Número de direcciones IP de subred consumidas
-
Número de direcciones IP de subred restantes
-
Detalles a nivel de instancia
-
Número de Warm IPs/ENIs por instancia
-
Número de activos IPs/ENIs por instancia
-