|
Este documento ha sido traducido utilizando tecnología de traducción automática. Si bien nos esforzamos por proporcionar traducciones precisas, no ofrecemos garantías sobre la integridad, precisión o confiabilidad del contenido traducido. En caso de discrepancia, la versión original en inglés prevalecerá y constituirá el texto autorizado. |
Referencia de configuración del clúster EKS
Acceso a la cuenta
Completa cada menú desplegable y campo utilizando la información obtenida para tu política IAM.
| Valor | Descripción |
|---|---|
Región |
En el menú desplegable, elige la región geográfica en la que deseas construir tu clúster. |
Credenciales de nube |
Selecciona las credenciales de nube que creaste para tu política IAM. Para más información sobre cómo crear credenciales de nube en Rancher, consulta esta página. |
Rol de Servicio
Elige un rol de servicio.
| Rol de Servicio | Descripción |
|---|---|
Estándar: Rol de servicio generado por Rancher |
Si eliges este rol, Rancher añade automáticamente un rol de servicio para usar con el clúster. |
Personalizado: Elige entre tus roles de servicio existentes |
Si eliges este rol, Rancher te permite elegir entre los roles de servicio que ya has creado en AWS. Para más información sobre cómo crear un rol de servicio personalizado en AWS, consulta la documentación de Amazon. |
Cifrado de secretos
Opcional: Para cifrar secretos, selecciona o introduce una clave creada en el Servicio de Gestión de Claves de AWS (KMS).
Acceso al Punto de Entrada del Servidor API
Configurar el acceso API público/privado es un caso de uso avanzado. Para más detalles, consulta el control de acceso al punto de entrada del clúster EKS documentación.
Puntos de Entrada API Solo Privados
Si habilitas el acceso al punto de entrada API privado y deshabilitas el acceso público al crear un clúster, entonces hay un paso adicional que debes realizar para que Rancher se conecte al clúster con éxito. En este caso, se mostrará un pop-up con un comando que deberás ejecutar en el clúster para registrarlo con Rancher. Una vez que el clúster esté provisionado, puedes ejecutar el comando mostrado en cualquier lugar donde puedas conectarte a la API de Kubernetes del clúster.
Hay dos maneras de evitar este paso manual adicional:
-
Puedes crear el clúster con acceso a ambos puntos de entrada API, privado y público, en la creación del clúster. Puedes deshabilitar el acceso público después de que el clúster esté creado y en un estado activo, y Rancher continuará comunicándose con el clúster EKS.
-
Puedes asegurarte de que Rancher comparta una subred con el clúster EKS. Entonces, se pueden utilizar grupos de seguridad para permitir que Rancher se comunique con el punto de entrada API del clúster. En este caso, no se necesita el comando para registrar el clúster, y Rancher podrá comunicarse con tu clúster. Para más información sobre cómo configurar grupos de seguridad, consulta la documentación de grupos de seguridad.
Puntos finales de acceso público
Opcionalmente, limita el acceso al punto de entrada público a través de bloques CIDR explícitos.
Si limitas el acceso a bloques CIDR específicos, se recomienda que también habilites el acceso privado para evitar perder la comunicación de red con el clúster.
Uno de los siguientes es necesario para habilitar el acceso privado:
-
La IP del Rancher debe ser parte de un bloque CIDR permitido
-
El acceso privado debe estar habilitado, y Rancher debe compartir una subred con el clúster y tener acceso a la red del clúster, lo cual se puede configurar con un grupo de seguridad
Para más información sobre el acceso público y privado al punto final del clúster, consulta la documentación de Amazon EKS.
Redes IPv6 / Dual-stack
Rancher admite la provisión y gestión de clústeres de Amazon EKS con enrutamiento de red IPv6. Cuando se habilita IPv6, los pods y servicios de Kubernetes reciben direcciones IPv6. Sin embargo, los nodos de trabajo EC2 subyacentes operan en un modo dual-stack (recibiendo tanto direcciones IPv4 como IPv6). Esta arquitectura dual-stack asegura que los nodos aún puedan comunicarse con la API de AWS y el plano de control de Kubernetes a través de IPv4, mientras que las cargas de trabajo de tu aplicación se comunican a través de IPv6.
Para provisionar un clúster dual-stack desde la interfaz de usuario de Rancher:
-
Durante la creación del clúster, expande la sección Redes.
-
Bajo Familia IP, selecciona el botón de opción IPv6.
Cambiar la Familia IP borra cualquier selección de subred actual que hayas hecho en el formulario.
-
Bajo VPCs y Subredes, elige entre Crear una nueva VPC y subred automáticamente o Seleccionar de subredes existentes.
Advertencia para VPCs personalizadasSi eliges seleccionar subredes existentes, debes seleccionar subredes Dual-Stack. Las subredes seleccionadas deben tener tanto un bloque CIDR IPv4 como un bloque CIDR IPv6. Las subredes solo IPv6 no son compatibles.
-
Completa el resto de la configuración del clúster (Grupos de Nodos, etc.).
-
Haga clic en Crear.
|
La configuración de la Familia IP es inmutable. Después de que se crea un clúster EKS, no puedes convertir un clúster IPv4 a IPv6, ni puedes convertir un clúster IPv6 a IPv4. |
Importando clústeres IPv6 existentes
Rancher admite completamente el registro (importación) de clústeres de Amazon EKS existentes que fueron configurados con redes IPv6 fuera de Rancher (por ejemplo, a través de Terraform o la Consola de AWS).
Cuando registras un clúster EKS existente:
-
Sigue el proceso estándar de registro de clústeres (Gestión de clústeres > Añadir clúster > Genérico).
-
Rancher consulta la API de AWS EKS para leer el estado en sentido ascendente del clúster.
-
Rancher detecta automáticamente si el clúster fue aprovisionado con IPv6.
Al configurar un clúster IPv6, se aplican varios comportamientos automatizados y requisitos estrictos:
-
Service CIDR: AWS asigna automáticamente el Service CIDR de un rango IPv6 fijo (
fd00::/108). No puedes personalizar el Service CIDR para un clúster IPv6. -
Requisito del Proveedor OIDC (IRSA): En un clúster IPv6, el plugin Amazon VPC CNI requiere estrictamente permisos de IAM para asignar prefijos IPv6 a Interfaces de Red Elásticas (ENIs). Esta autenticación se maneja a través de Roles IAM para Cuentas de Servicio (IRSA). Por lo tanto, un proveedor OIDC de IAM es obligatorio y se habilita automáticamente por Rancher al aprovisionar un clúster IPv6. Sin él, los pods no pueden adquirir direcciones IP.
Ejemplo de Referencia de EKSClusterConfig (IPv6)
Si estás desplegando clústeres EKS programáticamente utilizando el eksclusterconfigs.eks.cattle.io Recurso Personalizado, puedes habilitar IPv6 configurando el campo ipFamily a ipv6.
A continuación se muestra un ejemplo de un EKSClusterConfig mínimo configurado para IPv6. Observa que se establece el ipFamily, y se omiten campos estándar de IPv4 como serviceCidr porque AWS los gestiona automáticamente en modo IPv6.
apiVersion: eks.cattle.io/v1
kind: EKSClusterConfig
metadata:
name: my-ipv6-cluster
namespace: cluster-fleet-default
spec:
amazonCredentialSecret: cattle-global-data/my-aws-credentials
displayName: my-ipv6-cluster
region: us-west-2
imported: false
kubernetesVersion: "1.33"
ipFamily: "ipv6" # Enables Dual-Stack IPv6 networking. Triggers automatic OIDC creation.
nodeGroups:
- nodegroupName: initial-nodegroup
desiredSize: 2
maxSize: 3
minSize: 1
instanceType: t3.medium
diskSize: 20
requestSpotInstances: false
version: "1.33"
privateAccess: false
publicAccess: true
secretsEncryption: falseSubred
| Opción | Descripción |
|---|---|
Estándar: VPC y Subred generadas por Rancher |
Mientras aprovisionas tu clúster, Rancher genera una nueva VPC con 3 subredes públicas. |
Personalizado: Elige entre tu VPC y subredes existentes. |
Mientras aprovisionas tu clúster, Rancher configura tu plano de control y nodos para usar una VPC y subred que ya has creado en AWS. |
Para más información, consulta la documentación de AWS sobre Consideraciones de VPC del clúster. Sigue uno de los conjuntos de instrucciones a continuación según tu selección del paso anterior.
|
Advertencia para VPCs personalizadas
Si has seleccionado |
Registro
Configura los registros del plano de control para enviarlos a Amazon CloudWatch. Se te cobrarán los costos estándar de ingestión y almacenamiento de datos de CloudWatch Logs por cualquier registro enviado a CloudWatch Logs desde tus clústeres.
Cada tipo de registro corresponde a un componente del plano de control de Kubernetes. Para aprender más sobre estos componentes, consulta Componentes de Kubernetes en la documentación de Kubernetes.
Para más información sobre el registro del plano de control de EKS, consulta la documentación oficial.
Grupos de nodos gestionados
Los grupos de nodos gestionados de Amazon EKS automatizan la provisión y gestión del ciclo de vida de los nodos (instancias de Amazon EC2) para los clústeres de Kubernetes de Amazon EKS.
Para más información sobre cómo funcionan los grupos de nodos y cómo se configuran, consulta la documentación de EKS.
Plantillas de lanzamiento proporcionadas por el usuario
Puedes proporcionar tu propio ID de plantilla de lanzamiento y versión para configurar las instancias de EC2 en un grupo de nodos. Si proporcionas la plantilla de lanzamiento, ninguna de las configuraciones de la plantilla será configurable desde Rancher. Debes establecer todas las opciones requeridas que se enumeran a continuación en tu plantilla de lanzamiento.
Además, si proporcionas la plantilla de lanzamiento, solo puedes actualizar la versión de la plantilla, no el ID de la plantilla. Para usar un nuevo ID de plantilla, crea un nuevo grupo de nodos gestionados.
| Opción | Descripción | Necesario/Opcional |
|---|---|---|
Tipo de instancia |
Elige las especificaciones de hardware para la instancia que estás aprovisionando. |
required |
ID de imagen |
Especifica un AMI personalizado para los nodos. Los AMIs personalizados utilizados con EKS deben estar configurados correctamente |
Opcional |
Tamaño del volumen del nodo |
La plantilla de lanzamiento debe especificar un volumen EBS con el tamaño deseado |
required |
Clave SSH |
Una clave que se añadirá a las instancias para proporcionar acceso SSH a los nodos |
Opcional |
Datos de los usuarios |
Guion init en la nube en formato MIME de múltiples partes |
Opcional |
Etiquetas de recursos de instancia |
Etiqueta cada instancia de EC2 y sus volúmenes en el grupo de nodos |
Opcional |
|
No puedes actualizar directamente un grupo de nodos a una versión más nueva de Kubernetes si el grupo de nodos fue creado a partir de una plantilla de lanzamiento personalizada. Debes crear una nueva plantilla de lanzamiento con la versión adecuada de Kubernetes y asociar el grupo de nodos con la nueva plantilla. |
Plantillas de lanzamiento gestionadas por Rancher
Si no especificas una plantilla de lanzamiento, podrás configurar las opciones anteriores en la interfaz de usuario de Rancher y todas ellas se pueden actualizar después de la creación. Para aprovechar todas estas opciones, Rancher creará y gestionará una plantilla de lanzamiento para ti. Cada clúster en Rancher tendrá una plantilla de lanzamiento gestionada por Rancher y cada grupo de nodos gestionado que no tenga una plantilla de lanzamiento especificada tendrá una versión de la plantilla de lanzamiento gestionada. El nombre de esta plantilla de lanzamiento tendrá el prefijo "rancher-managed-lt-" seguido del nombre de visualización del clúster. Además, la plantilla de lanzamiento gestionada por Rancher estará etiquetada con la clave "rancher-managed-template" y el valor "do-not-modify-or-delete" para ayudar a identificarla como gestionada por Rancher. Es importante que esta plantilla de lanzamiento y sus versiones no sean modificadas, eliminadas o utilizadas con otros clústeres o grupos de nodos gestionados. Hacerlo podría resultar en que tus grupos de nodos estén "degradados" y necesiten ser destruidos y recreados.
AMIs personalizadas
Si especificas una AMI personalizada, ya sea en una plantilla de lanzamiento o en Rancher, entonces la imagen debe estar configurada correctamente y debes proporcionar datos de usuario para iniciar el nodo. Esto se considera un caso de uso avanzado y es imperativo entender los requisitos.
Si especificas una plantilla de lanzamiento que no contiene una AMI personalizada, entonces Amazon utilizará la AMI optimizada para EKS para la versión de Kubernetes y la región seleccionada. También puedes seleccionar una instancia habilitada para GPU para cargas de trabajo que se beneficiarían de ello.
|
La configuración de instancia habilitada para GPU en Rancher se ignora si se proporciona una AMI personalizada, ya sea en el menú desplegable o en una plantilla de lanzamiento. |
Instancias Spot
Las instancias Spot ahora son compatibles con EKS. Si se especifica una plantilla de lanzamiento, Amazon recomienda que la plantilla no proporcione un tipo de instancia. En su lugar, Amazon recomienda proporcionar múltiples tipos de instancia. Si la casilla "Solicitar instancias Spot" está habilitada para un grupo de nodos, entonces tendrás la oportunidad de proporcionar múltiples tipos de instancia.
|
Cualquier selección que hayas hecho en el menú desplegable de tipos de instancia será ignorada en esta situación y debes especificar al menos un tipo de instancia en la sección "Tipos de Instancia Spot". Además, una plantilla de lanzamiento utilizada con EKS no puede solicitar instancias spot. Solicitar instancias spot debe ser parte de la configuración de EKS. |
Configuraciones del Grupo de Nodos
Las siguientes configuraciones también son configurables. Todas estas, excepto el "Nombre del Grupo de Nodos", son editables después de que se crea el grupo de nodos.
| Opción | Descripción |
|---|---|
Nombre del Grupo de Nodos |
El nombre del grupo de nodos. |
Tamaño Deseado del ASG |
El número deseado de instancias. |
Tamaño Máximo del ASG |
El número máximo de instancias. Esta configuración no tendrá efecto hasta que el Escalador Automático de Clúster esté instalado. |
Tamaño Mínimo del ASG |
El número mínimo de instancias. Esta configuración no tendrá efecto hasta que el Escalador Automático de Clúster esté instalado. |
Etiquetas |
Etiquetas de Kubernetes aplicadas a los nodos en el grupo de nodos gestionado. |
Etiquetas |
Estas son etiquetas para el grupo de nodos gestionado y no se propagan a ninguno de los recursos asociados. |
Nodos de Amazon Linux autogestionados
Puedes registrar un clúster EKS que contenga nodos de Amazon Linux autogestionados. Debes configurar este tipo de clúster según las instrucciones en la documentación oficial de AWS para lanzar nodos de Amazon Linux autogestionados. Los clústeres de EKS que contienen nodos de Amazon Linux autogestionados suelen ser operados por el proyecto Karpenter. Después de aprovisionar un clúster de EKS que contenga nodos de Amazon Linux autogestionados, registra el clúster para que pueda ser gestionado por Rancher. Sin embargo, los nodos no serán visibles en la interfaz de usuario de Rancher.
Roles de IAM para cuentas de servicio
Un despliegue de aplicaciones que se ejecute en un clúster de EKS puede hacer solicitudes a los servicios de AWS a través de permisos de IAM. Estas aplicaciones deben firmar sus solicitudes con credenciales de AWS. Los roles de IAM para cuentas de servicio gestionan estas credenciales utilizando un punto final OIDC de AWS. En lugar de distribuir credenciales de AWS a los contenedores o depender del rol de una instancia de EC2, puedes vincular un rol de IAM a una cuenta de servicio de Kubernetes y configurar tus Pods para usar esta cuenta.
|
La vinculación a un rol de IAM no es compatible con los pods de Rancher en un clúster de EKS. |
Para habilitar roles de IAM para cuentas de servicio:
Configurando el intervalo de actualización
La configuración eks-refresh-cron queda obsoleta. Se ha migrado a la configuración eks-refresh, que es un entero que representa segundos.
El valor por defecto es 300 segundos.
El intervalo de sincronización se puede cambiar ejecutando kubectl edit setting eks-refresh.
Si la configuración eks-refresh-cron se había establecido previamente, la migración ocurrirá automáticamente.
Cuanto más corto sea el intervalo de actualización, menos probable será que ocurran condiciones de carrera, pero aumenta la probabilidad de encontrar límites de solicitudes que puedan estar establecidos para las API de AWS.