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.
Mejores prácticas para la creación de redes
sugerencia
Explore las
Es fundamental comprender las redes de Kubernetes para operar su clúster y sus 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 la interfaz de red de contenedores
Amazon EKS admite oficialmente el complemento CNI de Amazon Virtual Private Cloud (VPC) para implementar la red Kubernetes Pod. El CNI de la VPC 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 de la VPC.
Esta guía presenta la interfaz de red de contenedores (VPC CNI) de
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 los CNI alternativos. Consulte la documentación del CNI alternativo 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 usar NAT (traducción de direcciones de red).
-
Todos los demonios del sistema (procesos en segundo plano, por ejemplo, Kubelet
) que se ejecutan en un nodo determinado pueden comunicarse con los pods que se ejecutan en el mismo nodo. -
Los pods que usan la red host
deben poder contactar con todos los demás pods de todos los demás nodos sin usar NAT.
Consulta el modelo de red de Kubernetes
Interfaz de red de contenedores (CNI)
Kubernetes admite las especificaciones y 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 del CNI en el directorio, el kubelet usa el archivo de configuración que aparece primero por su nombre en orden lexicográfico.
CNI de Amazon Virtual Private Cloud (VPC)
El CNI de la 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. El CNI de la VPC se ejecuta en los nodos de trabajo de Kubernetes. El complemento CNI de la VPC consiste en el binario CNI y el complemento de administración de direcciones IP (ipamd). El 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 para cada nodo de Kubernetes y mantiene el conjunto activo de IP. El CNI de la VPC ofrece opciones de configuración para la asignación previa de las ENI y las direcciones IP a fin de acelerar el inicio de los pods. Consulte el CNI de Amazon VPC para conocer las mejores prácticas recomendadas para la administración de complementos.
Amazon EKS recomienda especificar subredes en al menos dos zonas de disponibilidad al crear un clúster. El 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 los clústeres de EKS.
El CNI de Amazon VPC asigna un conjunto fijo de ENI y direcciones IP secundarias de la subred conectada a la ENI principal del nodo. Este modo de CNI de VPC se denomina modo IP secundario. CNI de Amazon VPC La cantidad de direcciones IP y, por lo tanto, la cantidad de pods (densidad de pods) se define por la cantidad 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. Considera la posibilidad de usar el modo de prefijo si tienes problemas de densidad de 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 AWS VPC existentes para crear clústeres de Kubernetes. Esto incluye la posibilidad de usar los registros de flujo de la VPC, las políticas de enrutamiento de la VPC y los grupos de seguridad para aislar el tráfico de la red. De forma predeterminada, el CNI de Amazon VPC aplica a los pods el grupo de seguridad asociado al ENI principal del nodo. Considera la posibilidad de habilitar los grupos de seguridad para los pods cuando quieras asignar diferentes reglas de red a un pod.
De forma predeterminada, el CNI de la VPC asigna direcciones IP a los pods de la subred asignada al ENI principal de un nodo. Es habitual que haya escasez de direcciones IPv4 cuando se ejecutan clústeres grandes con miles de cargas de trabajo. AWS VPC le permite ampliar las IP disponibles asignando un CIDR secundario para evitar el agotamiento de los bloques de CIDR de IPv4. El CNI de AWS VPC le permite usar un rango de CIDR de subred diferente para los pods. Esta función del CNI de la VPC se denomina red personalizada. Redes personalizadas Podrías considerar la posibilidad de usar redes personalizadas con un CIDR del 100.64.0.0/10 rango (espacio de direcciones compartido, RFC 6598) para EKS. De hecho, esto te permite crear un entorno en el que los pods ya no consuman ninguna dirección IP RFC1918 de tu 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 usar clústeres IPv6 en lugar de redes personalizadas. En concreto, recomendamos migrar a clústeres IPv6 si has agotado por completo todo el espacio de direcciones IPv4 disponible para tu VPC. Evalúe los planes de su organización para admitir IPv6 y considere si invertir en IPv6 puede tener un mayor valor a largo plazo.
El soporte de EKS para IPv6 se centra en resolver el problema de agotamiento de la IP causado por un espacio de direcciones IPv4 limitado. En respuesta a los problemas de los clientes relacionados con el agotamiento de IPv4, EKS ha dado prioridad a los pods en lugar de a los IPv6-only pods de doble pila. Es decir, es posible que los pods puedan acceder a los recursos de IPv4, pero no se les asigna una dirección IPv4 del rango de CIDR de la VPC. El CNI de la VPC asigna direcciones IPv6 a los pods del bloque CIDR de IPv6 de la VPC administrado por AWS.
Calculadora de subredes
Este proyecto incluye un documento de Excel sobre la calculadora de subredes. WARM_IP_TARGET y. WARM_ENI_TARGET El documento incluye dos hojas, una primera para el modo Warm ENI y otra para el modo Warm IP. Consulta la guía de CNI de la VPC para obtener más información sobre estos modos.
Entradas:
-
Tamaño de 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
-
Cantidad de IP de subred consumidas
-
Número de IP de subred restantes
-
Detalles a nivel de instancia
-
Cantidad de Warm IPs/ENIs por instancia
-
Número de activos IPs/ENIs por instancia
-