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.
VPCy consideraciones sobre la subred
El funcionamiento de un EKS clúster requiere conocimientos de AWS VPC redes, además de los conocimientos de redes de Kubernetes.
Le recomendamos que comprenda los mecanismos de comunicación del plano de EKS control antes de empezar a diseñar sus clústeres VPC o a desplegarlos en los existentes. VPCs
Consulte las consideraciones sobre el clúster y VPC las consideraciones sobre los grupos EKS de seguridad de Amazon a la hora de diseñar una VPC y subredes con las que se vaya a utilizar. EKS
Información general
EKSArquitectura de clústeres
Un EKS clúster consta de dosVPCs:
-
Uno AWS administrado VPC que aloja el plano de control de Kubernetes. Esto VPC no aparece en la cuenta del cliente.
-
Una gestionada por el cliente VPC que aloja los nodos de Kubernetes. Aquí es donde se ejecutan los contenedores, así como otras AWS infraestructuras gestionadas por el cliente, como los balanceadores de carga que utiliza el clúster. VPCAparece en la cuenta del cliente. Debe crear un clúster gestionado por el cliente VPC antes de crear un clúster. El eksctl crea un VPC si no lo proporciona.
Los nodos del cliente VPC necesitan la capacidad de conectarse al punto final del API servidor gestionado en el. AWS VPC Esto permite a los nodos registrarse en el plano de control de Kubernetes y recibir solicitudes para ejecutar pods de aplicaciones.
Los nodos se conectan al plano de EKS control a través de (a) un punto final EKS público o (b) una interfaz de red elástica entre cuentas (X-ENI) gestionada por. EKS Cuando se crea un clúster, debe especificar al menos dos VPC subredes. EKScoloca una X- ENI en cada subred especificada durante la creación del clúster (también denominadas subredes de clúster). El API servidor de Kubernetes usa estas cuentas cruzadas ENIs para comunicarse con los nodos desplegados en las subredes del clúster administradas por el cliente. VPC
Cuando se inicia el nodo, se ejecuta el script de EKS arranque y se instalan los archivos de configuración del nodo de Kubernetes. Como parte del proceso de arranque de cada instancia, se lanzan los agentes de ejecución del contenedor, kubelet y los agentes de nodo de Kubernetes.
Para registrar un nodo, Kubelet contacta con el punto final del clúster de Kubernetes. Establece una conexión con el punto final público situado fuera del punto final VPC o con el punto final privado situado dentro del. VPC Kubelet recibe API instrucciones y proporciona actualizaciones de estado y latidos al punto final de forma periódica.
EKSComunicación en el plano de control
EKStiene dos formas de controlar el acceso al punto final del clúster. El control de acceso al punto final le permite elegir si se puede acceder al punto final desde la Internet pública o solo a través de la suyaVPC. Puede activar el punto final público (que es el predeterminado), el punto final privado o ambos a la vez.
La configuración del API punto final del clúster determina la ruta que siguen los nodos para comunicarse con el plano de control. Tenga en cuenta que estos ajustes de punto final se pueden cambiar en cualquier momento a través de la EKS consola oAPI.
Punto final público
Este es el comportamiento predeterminado de los nuevos EKS clústeres de Amazon. Cuando solo está habilitado el punto final público del clúster, las API solicitudes de Kubernetes que se originan en el clúster VPC (como la comunicación entre el nodo de trabajo y el plano de control) salen de la redVPC, pero no de Amazon. Para que los nodos se conecten al plano de control, deben tener una dirección IP pública y una ruta a una puerta de enlace de Internet o una ruta a una puerta de NAT enlace en la que puedan usar la dirección IP pública de la puerta de enlace. NAT
Punto final público y privado
Cuando los puntos de enlace públicos y privados están habilitados, las API solicitudes de Kubernetes desde dentro del plano de control se VPC comunican con el plano de control a través de la X- que está dentro del suyo. ENIs VPC Se puede acceder a su API servidor de clúster desde Internet.
Punto final privado
No hay acceso público a su API servidor desde Internet cuando solo está habilitado el punto final privado. Todo el tráfico API del servidor del clúster debe provenir de la red del clúster VPC o de una red conectada. Los nodos se comunican con el API servidor a través de una X- ENIs dentro de la suyaVPC. Tenga en cuenta que las herramientas de administración de clústeres deben tener acceso al punto final privado. Obtén más información sobre cómo conectarte a un punto de conexión privado de un EKS clúster de Amazon desde fuera de AmazonVPC.
Tenga en cuenta que los DNS servidores públicos resuelven el punto final API del servidor del clúster en una dirección IP privada delVPC. En el pasado, el punto final solo podía resolverse desde dentro delVPC.
VPCconfiguraciones
Amazon VPC apoya IPv4 y IPv6 direcciona. Amazon lo EKS admite IPv4 de forma predeterminada. VPCDebe tener un IPv4 CIDR bloque asociado. Si lo desea, puede asociar varios bloques de IPv4 Classless Inter-Domain Routing/16 prefijo (65 536 direcciones IP) y un /28 prefijo (16 direcciones IP).
Al crear uno nuevoVPC, puede adjuntar un solo IPv6 CIDR bloque y hasta cinco al cambiar uno existente. VPC La longitud del prefijo del tamaño del IPv6 CIDR bloque puede estar entre /44 y /60 y, para las IPv6 subredes, entre /44/ y /64. Puedes solicitar un IPv6 CIDR bloqueo del conjunto de IPv6 direcciones que mantiene Amazon. Consulta la sección de VPCCIDRbloques de la Guía del VPC usuario para obtener más información.
EKSLos clústeres de Amazon admiten IPv4 tanto comoIPv6. De forma predeterminada, EKS los clústeres utilizan IPv4 IP. Si se especifica IPv6 en el momento de la creación del clúster, se habilitará el uso de IPv6 clústeres. IPv6los clústeres requieren doble pila VPCs y subredes.
Amazon EKS recomienda utilizar al menos dos subredes que estén en distintas zonas de disponibilidad durante la creación del clúster. Las subredes que se transmiten durante la creación del clúster se conocen como subredes de clúster. Cuando creas un clúster, Amazon EKS crea hasta 4 cuentas cruzadas (cuenta x o x-ENIs) ENIs en las subredes que especifiques. Las x- siempre ENIs se implementan y se utilizan para el tráfico de administración de clústeres, como la entrega de registros, la ejecución y el proxy. Consulte la guía del EKS usuario para obtener información completa VPCy sobre los requisitos de subred.
Los nodos de trabajo de Kubernetes se pueden ejecutar en las subredes del clúster, pero no se recomienda. Durante las actualizaciones del clúster, Amazon EKS aprovisiona más ENIs en las subredes del clúster. Cuando el clúster se amplía, es posible que los nodos y pods trabajadores consuman lo disponible IPs en la subred del clúster. Por lo tanto, para asegurarse de que hay suficientes disponiblesIPs, puede considerar la posibilidad de utilizar subredes de clúster dedicadas con /28 netmask.
Los nodos de trabajo de Kubernetes pueden ejecutarse en una subred pública o privada. El hecho de que una subred sea pública o privada se refiere a si el tráfico dentro de la subred se enruta a través de una puerta de enlace de Internet. Las subredes públicas tienen una entrada en la tabla de enrutamiento a Internet a través de la puerta de enlace de Internet, pero las subredes privadas no.
El tráfico que se origina en otro lugar y llega a los nodos se denomina entrada. El tráfico que se origina en los nodos y sale de la red se denomina de salida. Los nodos con direcciones IP públicas o elásticas (EIPs) dentro de una subred configurada con una puerta de enlace a Internet permiten la entrada desde fuera de. VPC Las subredes privadas suelen tener un enrutamiento a una NATpuerta de enlace, lo que impide que el tráfico entre a los nodos de las subredes desde fuera o desde fuera y, al VPC mismo tiempo, permite que el tráfico de los nodos salga (de salida). VPC
En el IPv6 mundo, todas las direcciones se pueden enrutar por Internet. Las IPv6 direcciones asociadas a los nodos y los pods son públicas. Se admiten las subredes privadas mediante la implementación de pasarelas de Internet solo de salida (EIGW) en aVPC, lo que permite el tráfico saliente y bloquea todo el tráfico entrante. Las prácticas recomendadas para implementar IPv6 subredes se encuentran en la guía del usuario. VPC
Puede configurar VPC las subredes de tres maneras diferentes:
Usar solo subredes públicas
En las mismas subredes públicas, se crean tanto los nodos como los recursos de entrada (como los balanceadores de carga). Etiquete la subred pública con el kubernetes.io/role/elb
Uso de subredes públicas y privadas
Los nodos se crean en subredes privadas, mientras que los recursos de Ingress se instancian en subredes públicas. Puede habilitar el acceso público, privado o ambos (público y privado) al punto final del clúster. Según la configuración del punto final del clúster, el tráfico de los nodos ingresará a través de la NAT puerta de enlace o delENI.
Usando solo subredes privadas
Tanto los nodos como la entrada se crean en subredes privadas. Uso de la etiqueta de kubernetes.io/role/internal-elb
Comunicación entre VPCs
Hay muchos escenarios en los que es necesario implementar EKS clústeres múltiples VPCs e independientes en ellosVPCs.
Puede usar Amazon VPC Lattice
Amazon VPC Lattice opera en el espacio de direcciones locales del enlace en IPv4 y IPv6 proporciona conectividad entre servicios que pueden tener direcciones superpuestas. IPv4 Para lograr una mayor eficiencia operativa, recomendamos encarecidamente implementar EKS clústeres y nodos en rangos de IP que no se superpongan. En caso de que su infraestructura incluya VPCs rangos de IP superpuestos, necesitará diseñar su red en consecuencia. Sugerimos una NATpuerta de enlace privada o VPC CNI un modo de red personalizado junto con una puerta de enlace de tránsito para integrar las cargas de trabajo y resolver CIDR los problemas que se superponen y, EKS al mismo tiempo, conservar las RFC1918 direcciones IP enrutables.
Considere la posibilidad de utilizar AWS PrivateLinkun servicio de punto final, si usted es el proveedor del servicio y desea compartir su servicio de Kubernetes y sus ingresos (uno ALB o variosNLB) con su cliente VPC en cuentas separadas.
Compartir en varias cuentas VPC
Muchas empresas adoptaron Amazon compartido VPCs como un medio para agilizar la administración de la red, reducir los costos y mejorar la seguridad en AWS las múltiples cuentas de una AWS organización. Utilizan AWS Resource Access Manager (RAM) para compartir de forma segura AWSlos recursos compatibles con AWS cuentas individuales, unidades organizativas (OUs) o toda AWS la organización.
Puede implementar EKS clústeres de Amazon, grupos de nodos gestionados y otros AWS recursos de apoyo (como grupos de seguridad LoadBalancers, puntos finales, etc.) en VPC subredes compartidas desde otra AWS cuenta utilizando AWSRAM. La siguiente figura muestra un ejemplo de arquitectura de alto nivel. Esto permite a los equipos de redes centrales controlar las estructuras de redVPCs, como las subredes, etc., al tiempo que permite a los equipos de aplicaciones o plataformas implementar EKS clústeres de Amazon en sus cuentas respectivasAWS. Un recorrido completo de este escenario está disponible en este repositorio de GitHub.
Consideraciones a la hora de utilizar subredes compartidas
-
EKSLos clústeres de Amazon y los nodos de trabajo se pueden crear dentro de subredes compartidas que forman parte de la mismaVPC. Amazon EKS no admite la creación de clústeres en variosVPCs.
-
Amazon EKS usa AWS VPC Security Groups (SGs) para controlar el tráfico entre el plano de control de Kubernetes y los nodos de trabajo del clúster. Los grupos de seguridad también se utilizan para controlar el tráfico entre los nodos de trabajo y otros VPC recursos, así como entre las direcciones IP externas. Debe crear estos grupos de seguridad en la cuenta de la aplicación o del participante. Asegúrese de que los grupos de seguridad que piensa usar para sus pods también estén ubicados en la cuenta del participante. Puede configurar las reglas de entrada y salida de sus grupos de seguridad para permitir el tráfico necesario hacia y desde los grupos de seguridad ubicados en la cuenta CentralVPC.
-
Crea IAM roles y políticas asociadas en la cuenta del participante en la que reside tu EKS clúster de Amazon. Estas IAM funciones y políticas son esenciales para conceder los permisos necesarios a los clústeres de Kubernetes gestionados por AmazonEKS, así como a los nodos y pods que se ejecutan en Fargate. Los permisos permiten EKS a Amazon realizar llamadas a otros AWS servicios en tu nombre.
-
Puedes seguir los siguientes enfoques para permitir el acceso multicuenta a AWS recursos como los buckets de Amazon S3, las tablas de Dynamodb, etc., desde los pods de k8s:
-
Enfoque político basado en los recursos: si el AWS servicio admite políticas de recursos, puedes añadir la política basada en los recursos adecuada para permitir el acceso entre cuentas a las IAM funciones asignadas a los pods de kubernetes. En este escenario, las políticas OIDC de proveedores, IAM roles y permisos existen en la cuenta de la aplicación. Para encontrar AWS los servicios que admiten políticas basadas en recursos, consulte AWSlos servicios que funcionan con ellos IAM y busque los servicios que tengan la palabra «Sí» en la columna Basado en recursos.
-
OIDCEnfoque de proveedor: IAM recursos como el OIDC proveedor, las IAM funciones, los permisos y las políticas de confianza se crearán en la AWS cuenta de otro participante donde existan los recursos. Estas funciones se asignarán a los pods de Kubernetes en la cuenta de la aplicación para que puedan acceder a los recursos de varias cuentas. Consulta el blog IAMFunciones multicuentas para cuentas de servicio de Kubernetes
para obtener una explicación completa de este enfoque.
-
-
Puede implementar los recursos (ALBo) de Amazon Elastic Loadbalancer (ELBNLB) para enrutar el tráfico a los pods de k8s, ya sea en las cuentas de aplicaciones o de redes centrales. Consulta el tutorial Expose Amazon EKS Pods Through Cross-Account Load
Balancer para obtener instrucciones detalladas sobre cómo implementar ELB los recursos en una cuenta de red central. Esta opción ofrece una mayor flexibilidad, ya que otorga a la cuenta de Central Networking el control total sobre la configuración de seguridad de los recursos del Load Balancer. -
Al utilizar Amazon VPCCNI, debe utilizar las asignaciones
custom networking featurede ID de zona de disponibilidad (AZ) que figuran en la cuenta de red central para crear cada una de ellas.ENIConfigEsto se debe a la asignación aleatoria de los nombres físicos AZs a los de las AZ de cada AWS cuenta.
Grupos de seguridad
Un grupo de seguridad controla el tráfico al que se permite llegar y dejar los recursos a los que está asociado. Amazon EKS utiliza grupos de seguridad para gestionar la comunicación entre el plano de control y los nodos. Al crear un clúster, Amazon EKS crea un grupo de seguridad que recibe un nombreeks-cluster-sg-my-cluster-uniqueID. EKSasocia estos grupos de seguridad a los nodos gestionados ENIs y a los nodos. Las reglas predeterminadas permiten que todo el tráfico fluya libremente entre el clúster y los nodos, y permite que todo el tráfico saliente llegue a cualquier destino.
Al crear un clúster, puede especificar sus propios grupos de seguridad. Consulte la recomendación de grupos de seguridad cuando especifique sus propios grupos de seguridad.
Recomendaciones
Considere la posibilidad de implementar Multi-AZ
AWSLas regiones ofrecen varias zonas de disponibilidad (AZ) aisladas y separadas físicamente, que están conectadas mediante redes de baja latencia, alto rendimiento y alta redundancia. Con las zonas de disponibilidad, puede diseñar y operar aplicaciones que conmuten automáticamente entre zonas de disponibilidad sin interrupciones. Amazon recomienda EKS encarecidamente implementar EKS clústeres en varias zonas de disponibilidad. Considere la posibilidad de especificar subredes en al menos dos zonas de disponibilidad al crear el clúster.
Kubelet, que se ejecuta en los nodos, añade automáticamente etiquetas al objeto del nodo, por ejemplo. topology.kubernetes.io/region=us-west-2
Puedes definir las subredes o las zonas de disponibilidad al crear los nodos. Los nodos se colocan en subredes de clúster si no hay subredes configuradas. EKSLa compatibilidad con grupos de nodos gestionados distribuye automáticamente los nodos entre varias zonas de disponibilidad según la capacidad disponible. Karpenter
AWSLos balanceadores de carga elásticos se administran mediante el controlador de balanceadores de AWS carga de un clúster de Kubernetes. Proporciona un Application Load Balancer (ALB) para los recursos de entrada de Kubernetes y un Network Load Balancer (NLB) para los servicios de Kubernetes del tipo Loadbalancer. El controlador Elastic Load Balancer utiliza etiquetas
Implemente nodos en subredes privadas
La VPC inclusión de subredes públicas y privadas es el método ideal para implementar cargas de trabajo de Kubernetes en ellas. EKS Considere la posibilidad de establecer un mínimo de dos subredes públicas y dos subredes privadas en dos zonas de disponibilidad distintas. La tabla de rutas relacionada de una subred pública contiene una ruta a una puerta de enlace a Internet. Los pods pueden interactuar con Internet a través de una NAT puerta de enlace. Las subredes privadas son compatibles con las pasarelas de Internet del entorno que solo permiten la salida (). IPv6 EIGW
La creación de instancias de nodos en subredes privadas ofrece el máximo control sobre el tráfico hacia los nodos y es eficaz para la gran mayoría de las aplicaciones de Kubernetes. Los recursos de entrada (como los balanceadores de carga) se instancian en las subredes públicas y redirigen el tráfico a los pods que funcionan en subredes privadas.
Considera el modo solo privado si exiges una seguridad y un aislamiento estrictos de la red. En esta configuración, se implementan tres subredes privadas en distintas zonas de disponibilidad dentro de la AWS región. VPC Los recursos desplegados en las subredes no pueden acceder a Internet, ni Internet puede acceder a los recursos de las subredes. Para que tu aplicación de Kubernetes acceda a otros AWS servicios, debes configurar PrivateLink las interfaces o los puntos de enlace de las puertas de enlace. Puedes configurar balanceadores de carga internos para redirigir el tráfico a los pods mediante el AWS Load Balancer Controller. Las subredes privadas deben estar etiquetadas (kubernetes.io/role/internal-elb: 1
Considere el modo público y privado para el punto final del clúster
Amazon EKS ofrece modos de punto final public-and-private de clúster solo públicos y privados. El modo predeterminado es solo público, sin embargo, recomendamos configurar el punto final del clúster en modo público y privado. Esta opción permite que las API llamadas de Kubernetes dentro del clúster VPC (como las node-to-control-plane comunicaciones) utilicen el VPC punto final privado y que el tráfico permanezca dentro del clúster. VPC Por otro lado, se puede acceder a su API servidor de clúster desde Internet. Sin embargo, recomendamos encarecidamente limitar los CIDR bloques que pueden utilizar el punto final público. Aprenda a configurar el acceso a los terminales públicos y privados, incluida la limitación de CIDR los bloques.
Le sugerimos un terminal exclusivamente privado cuando necesite seguridad y aislamiento de la red. Te recomendamos que utilices cualquiera de las opciones que aparecen en la guía del EKS usuario para conectarte a un API servidor de forma privada.
Configure los grupos de seguridad con cuidado
Amazon EKS admite el uso de grupos de seguridad personalizados. Todos los grupos de seguridad personalizados deben permitir la comunicación entre los nodos y el plano de control de Kubernetes. Compruebe los requisitos de los puertos y configure las reglas manualmente cuando su organización no permita la comunicación abierta.
EKSaplica los grupos de seguridad personalizados que usted proporciona durante la creación del clúster a las interfaces administradas (X-ENIs). Sin embargo, no los asocia inmediatamente a los nodos. Al crear grupos de nodos, se recomienda encarecidamente asociar los grupos de seguridad personalizados de
Recomendamos encarecidamente crear un grupo de seguridad para permitir todo el tráfico de comunicación entre nodos. Durante el proceso de arranque, los nodos requieren conectividad a Internet saliente para acceder al punto final del clúster. Evalúe los requisitos de acceso saliente, como la conexión local y el acceso al registro del contenedor, y establezca las reglas adecuadas. Antes de poner los cambios en producción, le recomendamos encarecidamente que compruebe detenidamente las conexiones en su entorno de desarrollo.
Implemente NAT puertas de enlace en cada zona de disponibilidad
Si implementa nodos en subredes privadas (IPv4yIPv6), considere la posibilidad de crear una NAT puerta de enlace en cada zona de disponibilidad (AZ) para garantizar una arquitectura independiente de la zona y reducir los gastos entre zonas de disponibilidad. Cada NAT puerta de enlace de una zona de disponibilidad se implementa con redundancia.
Usa Cloud9 para acceder a clústeres privados
AWSCloud9 está basado en la web y puede IDE ejecutarse de forma segura en subredes privadas sin acceso de entrada mediante Systems Manager. AWS La salida también se puede deshabilitar en la instancia Cloud9. Obtenga más información sobre el uso de Cloud9 para acceder a clústeres y subredes privados.
📝 Edite esta página
