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.
Consideraciones sobre la VPC y la subred
sugerencia
Explore las
El funcionamiento de un clúster de EKS requiere conocimientos sobre las redes de VPC de AWS, además de las redes de Kubernetes.
Le recomendamos que comprenda los mecanismos de comunicación del plano de control de EKS antes de empezar a diseñar su VPC o a implementar clústeres en las VPC existentes.
Consulte las consideraciones sobre las VPC en clúster y las consideraciones sobre los grupos de seguridad de Amazon EKS al diseñar una VPC y subredes para utilizarlas con EKS.
Descripción general de
Arquitectura de clúster de EKS
Un clúster de EKS consta de dos VPC:
-
Una AWS-managed VPC que aloja el plano de control de Kubernetes. Esta VPC no aparece en la cuenta del cliente.
-
Una VPC gestionada por el cliente que aloja los nodos de Kubernetes. Aquí es donde se ejecutan los contenedores, así como otras infraestructuras de AWS administradas por los clientes, como los balanceadores de carga que usa el clúster. Esta VPC aparece en la cuenta del cliente. Debe crear una VPC gestionada por el cliente antes de crear un clúster. El eksctl crea una VPC si no se proporciona una.
Los nodos de la VPC del cliente deben poder conectarse al punto final del servidor de API administrado en la VPC de AWS. Esto permite que los nodos se registren en el plano de control de Kubernetes y reciban solicitudes para ejecutar los pods de aplicaciones.
Los nodos se conectan al plano de control de EKS a través de (a) un punto final público de EKS o (b) una interfaz de red Cross-Account elástica (X-ENI) gestionada por EKS. Cuando se crea un clúster, debe especificar al menos dos subredes de VPC. EKS coloca una X-ENI en cada subred especificada durante la creación del clúster (también denominadas subredes de clúster). El servidor API de Kubernetes usa estas Cross-Account ENI para comunicarse con los nodos implementados en las subredes de VPC del clúster administradas por el cliente.
Cuando se inicia el nodo, se ejecuta el script de arranque de EKS 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 tiempo 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 fuera de la VPC o con el punto final privado dentro de la VPC. Kubelet recibe instrucciones de la API y proporciona actualizaciones de estado y latidos al punto de enlace de forma regular.
Comunicación en el plano de control EKS
EKS tiene dos formas de controlar el acceso al punto final del clúster. El control de acceso a los puntos finales le permite elegir si se puede acceder al punto final desde la Internet pública o solo a través de su VPC. Puede activar el punto final público (que es el predeterminado), el punto final privado o ambos a la vez.
La configuración del punto final de la API del clúster determina la ruta que siguen los nodos para comunicarse con el plano de control. Tenga en cuenta que esta configuración de punto final se puede cambiar en cualquier momento a través de la consola o la API de EKS.
Punto final público
Este es el comportamiento predeterminado para los clústeres de Amazon EKS nuevos. Cuando solo está habilitado el punto final público del clúster, las solicitudes de la API de Kubernetes que se originan en la VPC del clúster (como la comunicación entre el nodo de trabajo y el plano de control) salen de la VPC, pero no de la red 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 enlace de NAT donde puedan usar la dirección IP pública de la puerta de enlace de NAT.
Punto final público y privado
Cuando los puntos de enlace públicos y privados están habilitados, las solicitudes de la API de Kubernetes desde la VPC se comunican con el plano de control a través de la VPC. X-ENIs Se puede acceder al servidor de la API del clúster desde Internet.
Punto final privado
No hay acceso público a su servidor de API desde Internet cuando solo está habilitado el punto final privado. Todo el tráfico al servidor de la API del clúster debe proceder desde dentro de la VPC de su clúster o de una red conectada. Los nodos se comunican con el servidor de API a través X-ENIs de su VPC. Tenga en cuenta que las herramientas de administración de clústeres deben tener acceso al punto final privado. Obtenga más información sobre cómo conectarse a un punto de enlace de clúster privado de Amazon EKS desde fuera de la Amazon VPC.
Tenga en cuenta que los servidores DNS públicos resuelven el punto final del servidor de API del clúster en una dirección IP privada desde la VPC. En el pasado, el punto de conexión se podía resolver desde dentro de la VPC.
Configuraciones de VPC
Amazon VPC admite el direccionamiento IPv4 e IPv6. Amazon EKS admite IPv4 de forma predeterminada. La VPC debe tener un bloque de CIDR IPv4 asociado. Si lo desea, puede asociar varios bloques de Inter-Domain enrutamiento sin clases /16 prefijo (65 536 direcciones IP) y un prefijo (16 direcciones IP). /28
Al crear una nueva VPC, puede adjuntar un único bloque de CIDR de IPv6 y hasta cinco al cambiar una VPC existente. La longitud del prefijo del bloque de CIDR de IPv6 puede estar entre /44 y /60 y, en el caso de las subredes de IPv6, entre /44/ y /64. Puede solicitar un bloque de CIDR de IPv6 desde el conjunto de direcciones IPv6 que mantiene Amazon. Consulte la sección sobre los bloques de CIDR de la VPC de la Guía del usuario de la VPC para obtener más información.
Los clústeres de Amazon EKS admiten tanto IPv4 como IPv6. De forma predeterminada, los clústeres de EKS utilizan IP IPv4. Especificar IPv6 en el momento de la creación del clúster permitirá el uso de clústeres IPv6. Los clústeres de IPv6 requieren subredes y VPC de doble pila.
Amazon EKS requiere que especifique al menos dos subredes en dos zonas de disponibilidad diferentes al crear un clúster. Las subredes que especifique se conocen como subredes de clúster. Amazon EKS aprovisiona dos ENI multicuenta (X-ENI) en diferentes zonas de disponibilidad para permitir la comunicación con los nodos de trabajo. Al crear un clúster, Amazon EKS crea de 2 a 4 X-ENI en las subredes especificadas. Amazon EKS siempre implementa los X-enis y los usa para el tráfico de administración de clústeres, como la entrega de registros, la ejecución y el proxy. Para obtener más información sobre los requisitos de VPC y subred, consulte los requisitos de VPC y subred en la Guía del usuario de Amazon EKS.
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 ENI adicionales en las subredes del clúster. Cuando el clúster se amplía, los nodos de trabajo y los pods pueden consumir las IP disponibles en la subred del clúster. Por lo tanto, para asegurarte de que hay suficientes IP disponibles, puedes considerar la posibilidad de usar subredes de clúster dedicadas con una máscara de red /28.
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 a Internet. https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html Las subredes públicas tienen una entrada en la tabla de rutas a Internet a través de la puerta de enlace a Internet, pero las subredes privadas no.
El tráfico que se origina en otro lugar y llega a los nodos se denomina ingreso. El tráfico que se origina en los nodos y sale de la red se denomina salida. Los nodos con direcciones IP (EIP) públicas o elásticas dentro de una subred configurada con una puerta de enlace a Internet permiten la entrada desde fuera de la VPC. Las subredes privadas suelen tener una ruta a una puerta de enlace NAT, que no permite la entrada de tráfico a los nodos de las subredes desde fuera de la VPC y, al mismo tiempo, permite que el tráfico de los nodos salga de la VPC (salida).
En el mundo de IPv6, todas las direcciones se pueden enrutar a Internet. Las direcciones IPv6 asociadas a los nodos y los pods son públicas. Las subredes privadas se admiten mediante la implementación de puertas de enlace a Internet de solo salida (EIGW) en una VPC, lo que permite el tráfico saliente y bloquea todo el tráfico entrante. Las mejores prácticas para implementar subredes IPv6 se encuentran en la guía del usuario de la VPC. https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Scenario2.html
Puede configurar la VPC y 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 este botón kubernetes.io/role/elb para crear balanceadores de carga orientados a Internet. En esta configuración, el punto final del clúster se puede configurar para que sea público, privado o ambos (público y privado).
Uso de subredes públicas y privadas
Los nodos se crean en subredes privadas, mientras que los recursos de Ingress se crean instancias 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 nodos ingresará a través de la puerta de enlace NAT o el ENI.
Usar solo subredes privadas
Tanto los nodos como la entrada se crean en subredes privadas. Usar la etiqueta de kubernetes.io/role/internal-elb subred para crear balanceadores de cargas internos. Para acceder al punto final del clúster se necesitará una conexión VPN. Debe activar AWS PrivateLink para EC2 y todos los repositorios de Amazon ECR y S3. Solo se debe habilitar el punto final privado del clúster. Le sugerimos que revise los requisitos de los clústeres privados de EKS antes de aprovisionar los clústeres privados.
Comunicación entre VPC
Hay muchos escenarios en los que se necesitan varias VPC y clústeres de EKS independientes implementados en estas VPC.
Puede usar Amazon VPC Lattice
Amazon VPC Lattice funciona en el espacio de direcciones locales de enlace en IPv4 e IPv6, y proporciona conectividad entre servicios que pueden tener direcciones IPv4 superpuestas. Para garantizar la eficiencia operativa, recomendamos encarecidamente implementar los clústeres y nodos de EKS en rangos de IP que no se superpongan. En caso de que su infraestructura incluya VPC con rangos de IP superpuestos, debe diseñar su red en consecuencia. Recomendamos usar Private NAT Gateway (VPC CNI) en modo de red personalizado, junto con Transit Gateway, para integrar las cargas de trabajo en EKS y resolver los problemas de CIDR superpuestos y, al mismo tiempo, preservar las direcciones IP enrutables del RFC1918.
Considere la posibilidad de utilizar AWS PrivateLink, también conocido como servicio de punto final, si es el proveedor del servicio y desea compartir su servicio e ingreso de Kubernetes (ALB o NLB) con la VPC de su cliente en cuentas separadas.
Compartir la VPC entre varias cuentas
Muchas empresas adoptaron las VPC compartidas de Amazon como medio para simplificar la administración de la red, reducir los costos y mejorar la seguridad en varias cuentas de AWS en una organización de AWS. Utilizan AWS Resource Access Manager (RAM) para compartir de forma segura los recursos de AWS compatibles con cuentas de AWS individuales, unidades organizativas (OU) o con toda la organización de AWS.
Puede implementar clústeres de Amazon EKS, grupos de nodos gestionados y otros recursos de AWS compatibles (como grupos de seguridad LoadBalancers, puntos finales, etc.) en subredes de VPC compartidas desde otra cuenta de AWS mediante la RAM de AWS. La siguiente figura muestra un ejemplo de arquitectura de alto nivel. Esto permite a los equipos centrales de redes controlar las estructuras de red, como las VPC, las subredes, etc., y a los equipos de aplicaciones o plataformas implementar los clústeres de Amazon EKS en sus respectivas cuentas de AWS. En este repositorio de github encontrará un recorrido completo sobre este escenario. https://github.com/aws-samples/eks-shared-subnets
Consideraciones a la hora de utilizar subredes compartidas
-
Los clústeres y nodos de trabajo de Amazon EKS se pueden crear en subredes compartidas que formen parte de la misma VPC. Amazon EKS no admite la creación de clústeres en varias VPC.
-
Amazon EKS usa los grupos de seguridad (SG) de VPC de AWS 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 recursos de la VPC, así como las direcciones IP externas. Debe crear estos grupos de seguridad en la application/participant cuenta. Asegúrese de que los grupos de seguridad que piensa usar para sus pods también se encuentren en la cuenta del participante. Puedes configurar las reglas de entrada y salida en tus grupos de seguridad para permitir el tráfico necesario hacia y desde los grupos de seguridad ubicados en la cuenta de VPC central.
-
Cree las funciones de IAM y las políticas asociadas en la cuenta de participante en la que reside su clúster de Amazon EKS. Estas funciones y políticas de IAM son esenciales para conceder los permisos necesarios a los clústeres de Kubernetes gestionados por Amazon EKS, así como a los nodos y pods que se ejecutan en Fargate. Los permisos permiten a Amazon EKS realizar llamadas a otros servicios de AWS en su nombre.
-
Puede seguir los siguientes enfoques para permitir el acceso multicuenta a los recursos de AWS, 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 servicio de AWS admite las políticas de recursos, puede añadir la política basada en los recursos adecuada para permitir el acceso entre cuentas a las funciones de IAM asignadas a los pods de Kubernetes. En este escenario, el proveedor de OIDC, las funciones de IAM y las políticas de permisos existen en la cuenta de la aplicación. Para encontrar servicios de AWS que admitan políticas basadas en recursos, consulte los servicios de AWS que funcionan con IAM y busque los servicios que digan Sí en la columna Basado en recursos.
-
Enfoque de proveedor de OIDC: los recursos de IAM, como las políticas de proveedor de OIDC, funciones de IAM, permisos y confianza, se crearán en la cuenta de AWS de otro participante en la que 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
sobre roles de IAM entre cuentas para cuentas de servicio de Kubernetes para ver un recorrido completo sobre este enfoque.
-
-
Puede implementar los recursos de Amazon Elastic Loadbalancer (ELB) (ALB o NLB) para dirigir el tráfico a los pods k8s de las cuentas de red centrales o de la aplicación. Consulte el tutorial
Expose Amazon EKS Pods Through Cross-Account Load Balancer para obtener instrucciones detalladas sobre cómo implementar los recursos de ELB en la cuenta de red central. Esta opción ofrece una mayor flexibilidad, ya que otorga a la cuenta de Central Networking un control total sobre la configuración de seguridad de los recursos del balanceador de carga. -
Cuando utilice
custom networking featurela CNI de Amazon VPC, debe utilizar las asignaciones de ID de la 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 las zonas de disponibilidad físicas a los nombres de las zonas de disponibilidad de cada cuenta de AWS.
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 denominado eks-cluster-sg-my-cluster-uniqueID. EKS asocia estos grupos de seguridad a las ENI administradas 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 Multi-AZ implementación
Las regiones de AWS proporcionan varias zonas de disponibilidad (AZ) físicamente separadas y aisladas, 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 se conmuten automáticamente entre zonas de disponibilidad sin interrupciones. Amazon EKS recomienda encarecidamente implementar clústeres de EKS 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 agrega automáticamente etiquetas al objeto del nodo, como. topology.kubernetes.io/region=us-west-2
Puedes definir las subredes o las zonas de disponibilidad al crear nodos. Los nodos se colocan en subredes del clúster si no hay ninguna subred configurada. La compatibilidad de EKS con los grupos de nodos gestionados distribuye automáticamente los nodos en varias zonas de disponibilidad según la capacidad disponible. Karpenter
Los Elastic Load Balancers de AWS se administran mediante el controlador AWS Load Balancer para un clúster de Kubernetes. Proporciona un balanceador de carga de aplicaciones (ALB) para los recursos de entrada de Kubernetes y un balanceador de carga de red (NLB) para los servicios de Kubernetes del tipo Loadbalancer. El controlador https://aws.amazon.com/premiumsupport/knowledge-center/eks-vpc-subnet-discovery/
Implemente nodos en subredes privadas
Una VPC que incluya subredes públicas y privadas es el método ideal para implementar cargas de trabajo de Kubernetes en 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 puerta de enlace NAT. Las pasarelas de Internet de solo salida en el entorno IPv6 (EIGW) admiten subredes privadas.
La creación de instancias de nodos en subredes privadas ofrece un control máximo sobre el tráfico a 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 subredes públicas y dirigen el tráfico a los pods que funcionan en subredes privadas.
Considere el modo solo privado si exige una seguridad estricta y un aislamiento de la red. En esta configuración, se implementan tres subredes privadas en distintas zonas de disponibilidad dentro de la VPC de la región de AWS. Los recursos implementados en las subredes no pueden acceder a Internet ni Internet puede acceder a los recursos de las subredes. Para que su aplicación de Kubernetes pueda acceder a otros servicios de AWS, debe configurar las interfaces y los puntos de enlace de las puertas de enlace. PrivateLink and/or Puede configurar balanceadores de carga internos para redirigir el tráfico a los pods mediante AWS Load Balancer Controller. Las subredes privadas deben estar etiquetadas con (kubernetes.io/role/internal-elb: 1) para que el controlador pueda aprovisionar los balanceadores de carga. Para que los nodos se registren en el clúster, el punto final del clúster debe estar configurado en modo privado. Visite la guía de clústeres privados para ver todos los requisitos y consideraciones.
Considere los modos público y privado para los terminales de clúster
Amazon EKS ofrece modos de punto de enlace de clúster solo público, público y privado y solo privado. 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 llamadas a la API de Kubernetes dentro de la VPC del clúster (como la comunicación entre el nodo y el plano de control) utilicen el punto de enlace de la VPC privada y el tráfico permanezca dentro de la VPC del clúster. Por otro lado, se puede acceder al servidor de API del clúster desde Internet. Sin embargo, recomendamos encarecidamente limitar los bloques de CIDR que pueden usar el punto final público. Aprenda a configurar el acceso a los puntos finales públicos y privados, incluida la limitación de los bloqueos de CIDR.
Le sugerimos un punto final solo privado cuando necesite seguridad y aislamiento de la red. Recomendamos utilizar cualquiera de las opciones que figuran en la guía del usuario de EKS para conectarse a un servidor API 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. Comprueba los requisitos de los puertos y configura las reglas manualmente cuando tu organización no permita la comunicación abierta.
EKS aplica 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
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 saliente a Internet para acceder al punto final del clúster. Evalúe los requisitos de acceso externo, como la conexión local y el acceso al registro de contenedores, y establezca las reglas de manera adecuada. Antes de poner los cambios en producción, te recomendamos encarecidamente que compruebes cuidadosamente las conexiones en tu entorno de desarrollo.
Implemente puertas de enlace NAT en cada zona de disponibilidad
Si implementa nodos en subredes privadas (IPv4 e IPv6), considere la posibilidad de crear una puerta de enlace NAT en cada zona de disponibilidad (AZ) para garantizar una arquitectura independiente de la zona y reducir los gastos entre zonas de disponibilidad. Cada puerta de enlace NAT de una zona de disponibilidad se implementa con redundancia.
