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.
Habilite el modo automático de Amazon EKS en todos los clústeres de EKS mediante GitHub acciones
Urbija Goswami y Anugrah Lakra, Amazon Web Services
Resumen
Los clústeres de Amazon Elastic Kubernetes Service (EKS) suelen requerir la administración manual de los recursos informáticos a través de grupos de nodos. Esto genera una sobrecarga operativa para:
Decisiones de planificación y escalamiento de la capacidad
Aprovisionamiento de nodos y administración del ciclo de vida
Optimización de costos en diferentes tipos de carga de trabajo
Mantenimiento y actualizaciones de la infraestructura
Amazon EKS Auto Mode automatiza la administración de los recursos informáticos al aprovisionar y escalar los nodos de forma dinámica en función de las demandas de carga de trabajo, lo que elimina la necesidad de administrar manualmente los grupos de nodos.
Sin embargo, muchas organizaciones tienen dificultades para habilitar y administrar Amazon EKS Auto Mode de manera uniforme en sus clústeres nuevos y existentes. Los desafíos más comunes incluyen:
Procesos de migración complejos desde grupos de nodos existentes
Riesgo de interrupción del servicio durante la transición
Necesidad de planificar y probar cuidadosamente la capacidad
Requisito de permisos y configuraciones específicos de Amazon IAM
Coordinación entre varios equipos y entornos
Este patrón implementa un flujo de trabajo de GitHub acciones
Tras activar el modo automático, el flujo de trabajo vacía y elimina los grupos de nodos antiguos, actualiza los permisos de los roles del clúster y limpia los componentes de escalado anteriores, como Karpenter y Cluster Autoscaler. El flujo de trabajo se puede integrar con las canalizaciones de integración continua y continua () existentes. delivery/deployment CI/CD
Requisitos previos y limitaciones
Requisitos previos
1. Necesario
Una GitHub cuenta
y tu propio GitHub repositorio para ejecutar el flujo de trabajo Una cuenta de AWS
activa con permisos administrativos
2. Instalación de herramientas locales
Terraform
versión 1.13.0 o posterior GitHub CLI
(gh), configurada con las credenciales adecuadas kubectl y eksctl, configurados para la administración de clústeres
3. Requisitos del clúster EKS
Kubernetes versión 1.29 o posterior
Configuración de acceso al punto final:
O bien está configurada para puntos finales públicos y privados
O punto final privado con puerta de enlace NAT en subredes privadas
La API de EKS y el acceso a los ConfigMapclústeres están habilitados (se requiere para que EKS pueda gestionar dinámicamente los nodos del modo automático y actualizar el aws-auth ConfigMap para una correcta autenticación del clúster durante la migración)
Grupos de nodos activos o grupos de nodos gestionados
4. Requisitos de configuración de IAM OIDC
El rol de IAM y el proveedor de identidades para ello incluyen: GitHub
Política de confianza para OIDC GitHub
Permisos para:
Administración de clústeres de EKS
acceso a buckets de S3
Administración de roles de IAM
Administración de redes EC2
Consulte el código iam.tf
para una configuración sencilla con Terraform. El rol de IAM (GitHubActionsEKSRole) se creará cuando se aplique el código de Terraform.
Limitaciones
Solo es compatible con clústeres de EKS con la versión 1.29 y superior de Kubernetes
Solo es compatible con la versión 1.1.0 y superior de Karpenter
Region-specific implementación. Algunos servicios de AWS no están disponibles en todas las regiones de AWS. Para conocer la disponibilidad regional, consulte los servicios de AWS por región
Requiere accesibilidad a los puntos de conexión del clúster
Limitado a grupos AWS-managed de nodos
Arquitectura
Pila de tecnología de destino
Arquitectura de destino

El usuario activa el flujo de trabajo de GitHub acciones desde el GitHub repositorio.
El flujo de trabajo de GitHub acciones asume una función de IAM y utiliza OIDC para realizar los cambios necesarios en la cuenta de AWS. También comprueba la presencia del rol EKS Auto Node en la cuenta y, si no está presente, se crea el rol y se adjuntan las políticas necesarias.
Se carga en un bucket de S3 una copia de seguridad del estado actual del clúster de EKS que necesita el modo automático activado.
Se recupera la función de clúster del clúster que necesita el modo automático activado y se le añaden permisos adicionales (AmazonEKSComputePolicy AmazonEKSBlockStoragePolicy AmazonEKSLoadBalancingPolicy, AmazonEKSNetworkingPolicy,,, AmazonEKSClusterPolicy) si no están presentes en el modo automático de EKS. Además, como paso previo a la migración, las subredes de los clústeres se actualizan con etiquetas para habilitar el modo automático de EKS.
El flujo de trabajo habilita el modo automático de EKS en el clúster de EKS.
Los grupos de nodos antiguos se identifican y eliminan. Esto se omite si el usuario no ha concedido los permisos para la función de IAM que se describen en los pasos de configuración opcionales que se indican a continuación.
Los componentes de escalado (Karpenter y Cluster Autoscaler) también se eliminan si estaban presentes anteriormente.
El flujo de trabajo de GitHub Actions consta de tres tareas principales:
check-clusters: identifica los clústeres que no tienen el modo automático activado y actualiza las políticas de IAM y las etiquetas de subred.backup-and-check: Realiza una copia de seguridad del estado del clúster antes de la migración.gradual-migration: Activa el modo automático y, al mismo tiempo, agota gradualmente los grupos de nodos existentes y limpia los componentes de escalado antiguos. También realiza una verificación final del estado de los clústeres tras la migración.
nota
Si necesita copias de seguridad de la configuración de los nodos o planea eliminar nodes/node grupos durante la migración al modo automático de EKS, puede añadir a aws-auth el rol de IAM creado con el código terraform. ConfigMap Sin él, aún puede ver las configuraciones de los grupos de nodos.
Tools (Herramientas)
AWS CLI:
La Interfaz de la línea de comandos de AWS (AWS CLI) es una herramienta de código abierto que le permite interactuar con los servicios de AWS mediante comandos en el intérprete de comandos de la línea de comandos. En nuestra solución, utilizamos la interfaz de línea de comandos para que los servicios de AWS ejecuten las actualizaciones de la configuración del clúster de EKS, las actualizaciones de los roles de IAM y consulten el estado del clúster durante todo el proceso de automatización.
Amazon EKS:
Amazon Elastic Kubernetes Service (Amazon EKS) lo ayuda a ejecutar Kubernetes en AWS sin necesidad de instalar ni mantener su propio plano de control o nodos de Kubernetes. En este patrón, Amazon EKS es el servicio de destino en el que el modo automático está habilitado para automatizar el aprovisionamiento informático y el escalado de nodos en los clústeres de una región específica.
IAM:
AWS Identity and Access Management (IAM) le permite administrar de forma segura el acceso a los recursos de AWS mediante el control de quién está autenticado y autorizado a utilizarlos. En nuestra solución, lo utilizamos para administrar los permisos de GitHub Actions para modificar las configuraciones de los clústeres de EKS mediante la federación OIDC. La solución también modifica los permisos de los roles del clúster y añade una tarea para crear el rol de nodo de EKS, de modo que el modo automático de EKS pueda programar los módulos pendientes en los nuevos nodos que activa como parte de los grupos de nodos.
Amazon S3:
Amazon Simple Storage Service (Amazon S3) es un servicio de almacenamiento de objetos basado en la nube que lo ayuda a almacenar, proteger y recuperar cualquier cantidad de datos. En nuestra solución, utilizamos un depósito S3 para almacenar las copias de seguridad con fecha y hora de los clústeres antes de que se habilite el modo automático de EKS en ellos, lo que ayudaría a la recuperación ante desastres.
Otras herramientas:
GitHub Acciones:
GitHub Actions
HashiCorp Terraform:
Terraform
Repositorio de código
El código de este patrón está disponible en el repositorio GitHub EKS Auto Mode Enablement
Prácticas recomendadas
Seguridad:
Siga el principio de privilegio mínimo y conceda los permisos mínimos necesarios para llevar a cabo una tarea. Para obtener más información, consulte las mejores prácticas de seguridad y concesión de privilegios mínimos en la documentación de IAM. Consulte el archivo iam.tf
del repositorio para ver la configuración mínima requerida. Aplica la política de confianza de roles de IAM a tu GitHub repositorio y sucursal específicos para evitar que grupos de trabajo no autorizados asuman ese rol.
Habilite el registro del plano de control de EKS (servidor API, auditoría, autenticador) antes de iniciar la migración para poder diagnosticar los problemas de programación o autenticación una vez activado el modo automático.
Añada --sse AES256 a todos los comandos aws s3 cp del script de respaldo para aplicar el cifrado del lado del servidor en las copias
de seguridad del estado del clúster.
Fiabilidad:
Pruebe primero el flujo de trabajo con un clúster que no sea de producción. Compruebe que las cargas de trabajo se reprograman correctamente en los nodos de modo automático antes de migrar los clústeres de producción.
Compruebe que las copias de seguridad de S3 se hayan completado correctamente y que contengan datos válidos sobre la configuración del clúster, el grupo de nodos, la versión de Helm y los recursos personalizados antes de continuar con la activación del modo automático.
Tras activar el modo automático, supervise los eventos de programación de los pods y la latencia de aprovisionamiento de nodos mediante Amazon CloudWatch Container Insights para detectar problemas de forma temprana.
Rendimiento:
Revise periódicamente los patrones de escalado del grupo de nodos en modo automático y ajuste las solicitudes y los límites de los recursos de la carga de trabajo para evitar el sobreaprovisionamiento o los retrasos en la programación.
Costo:
Etiquete los clústeres de EKS y los recursos asociados (funciones de IAM, depósitos de backup de S3, subredes) con metadatos de entorno y propiedad para facilitar el seguimiento de los costes y la visibilidad operativa. Para obtener más información, consulte la documentación sobre el etiquetado de los recursos de AWS. Puede editar el archivo de flujo de trabajo para añadir etiquetas personalizadas durante el proceso de migración.
Configure alertas de AWS Cost Explorer para monitorear los cambios en los costos de procesamiento después de habilitar el modo automático, ya que el modo automático puede cambiar los tipos de instancias y el comportamiento de escalado. Para obtener más información, consulte la documentación sobre cómo analizar los costos con AWS Cost Explorer.
Operaciones:
Mantenga el archivo de flujo de trabajo y las configuraciones de Terraform en el control de versiones y documente cualquier anulación específica del entorno, como la región, el ARN del rol o el nombre del bucket de S3.
Epics
| Tarea | Descripción | Habilidades requeridas |
|---|---|---|
Configure el GitHub repositorio. |
| AWS DevOps, arquitecto de nube |
| Tarea | Descripción | Habilidades requeridas |
|---|---|---|
Configure IAM para realizar copias de seguridad y eliminar grupos de nodos |
Sustituya $CLUSTER_NAME y $ACCOUNT_ID por los valores adecuados.
Sustituya $AWS_REGION y $ROLE_ARN por la región específica y el ARN del rol de IAM creado anteriormente, respectivamente. | AWS DevOps, arquitecto de nube |
| Tarea | Descripción | Habilidades requeridas |
|---|---|---|
Activa el flujo de trabajo de GitHub acciones. | El flujo de trabajo se activa automáticamente cuando se introduce algún cambio en las ramas de funciones, principales o de desarrollo. Para activarlo manualmente mediante la GitHub interfaz de usuario: 1. Ve al repositorio el GitHub 2. Haga clic en la pestaña «Acciones» 3. Seleccione el flujo de trabajo (canalización de modo automático) 4. Haga clic en el botón «Ejecutar flujo de trabajo» 5. Elija la rama y haga clic en «Ejecutar flujo de trabajo» El flujo de trabajo gestiona la verificación | AWS DevOps, arquitecto de nube |
| Tarea | Descripción | Habilidades requeridas |
|---|---|---|
Implementación de un despliegue en varios entornos. |
|
| Tarea | Descripción | Habilidades requeridas |
|---|---|---|
Eliminación de recursos. |
| AWS general, arquitecto de nube |
Resolución de problemas
| Problema | Solución |
|---|---|
Problemas de autenticación | • Compruebe que el proveedor de GitHub OIDC esté configurado correctamente en AWS IAM • Comprueba que el ARN del rol de IAM en git secrets coincide con el rol real creado con terraform () GitHubActionsEKSRole • Asegúrese de que el GitHub repositorio tenga configurados los secretos necesarios: AWS_REGION y. AWS_ROLE_ARN • Valide que la configuración de la región de AWS coincida con las ubicaciones de sus clústeres |
¿Problemas con los permisos | <role-arn>• Pruebe los permisos de los roles de IAM localmente: bash aws sts assume-role --role-arn --role-session-name test-session aws eks list-clusters • Asegúrese de UpdateClusterConfig que el DescribeCluster rol tenga los permisos eks: y eks: |
Compatibilidad de clústeres | <cluster-name>• Confirme que los clústeres de EKS ejecutan Kubernetes 1.29 o superior: bash aws eks describe-cluster --name --query 'cluster.version' • Compruebe que los clústeres estén en estado ACTIVO antes de activar el modo automático |
Fallos en el flujo | • Compruebe los registros de GitHub acciones para ver si hay mensajes de error específicos • Compruebe la sintaxis del archivo de flujo de trabajo en. github/workflows/auto-mode-pipeline.yml • Asegúrese de que las variables de entorno estén configuradas correctamente en el flujo de trabajo |