Configuración del escalado automático basado en eventos en Amazon EKS mediante Amazon EKS Pod Identity y KEDA - Recomendaciones de AWS

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.

Configuración del escalado automático basado en eventos en Amazon EKS mediante Amazon EKS Pod Identity y KEDA

Dipen Desai, Abhay Diwan, Kamal Joshi y Mahendra Revanasiddappa, Amazon Web Services

Resumen

Las plataformas de orquestación, como Amazon Elastic Kubernetes Service (Amazon EKS), han simplificado la administración del ciclo de vida de las aplicaciones basadas en contenedores. Esto ayuda a las organizaciones a centrarse en crear, proteger, operar y mantener aplicaciones basadas en contenedores. A medida que las implementaciones basadas en eventos se vuelven más comunes, las organizaciones escalan con mayor frecuencia las implementaciones de Kubernetes en función de diversos orígenes de eventos. Este método, combinado con el escalado automático, puede generar importantes ahorros de costos al proporcionar recursos de cómputo bajo demanda y un escalado eficiente que se adapta a la lógica de la aplicación.

KEDA es un escalador automático basado en eventos que se basa en Kubernetes. KEDA lo ayuda a escalar cualquier contenedor de Kubernetes en función de la cantidad de eventos que deben procesarse. Es ligero y se integra con cualquier clúster de Kubernetes. También funciona con componentes estándar de Kubernetes, como el escalado automático de pods horizontales (HPA). KEDA también ofrece una TriggerAuthenticationfunción que le ayuda a delegar la autenticación. Permite describir los parámetros de autenticación que están separados del contenedor de despliegue ScaledObject y del contenedor de despliegue.

AWS proporciona funciones AWS Identity and Access Management (IAM) que admiten diversas opciones de implementación de Kubernetes, incluidas Amazon EKS, Amazon EKS Anywhere Red Hat OpenShift Service en AWS (ROSA) y clústeres de Kubernetes autogestionados en Amazon Elastic Compute Cloud (Amazon). EC2 Estas funciones utilizan estructuras de IAM, como los proveedores de identidad de OpenID Connect (OIDC) y las políticas de confianza de IAM, para funcionar en diferentes entornos sin depender directamente de los servicios de Amazon EKS o. APIs Para obtener más información, consulte Roles de IAM para cuentas de servicio en la documentación de Amazon EKS.

Amazon EKS Pod Identity simplifica el proceso para que las cuentas de servicio de Kubernetes asuman roles de IAM sin necesidad de proveedores de OIDC. Ofrece la posibilidad de administrar las credenciales de sus aplicaciones. En lugar de crear y distribuir tus AWS credenciales a los contenedores o usar el rol de la EC2 instancia de Amazon, asocias un rol de IAM a una cuenta de servicio de Kubernetes y configuras tus Pods para que usen la cuenta de servicio. Esto lo ayuda a utilizar un rol de IAM en varios clústeres y simplifica la administración de políticas al permitir la reutilización de las políticas de permisos en todos los roles de IAM.

Al implementar KEDA con Amazon EKS Pod Identity, las empresas pueden lograr un escalado automático eficiente basado en eventos y una administración de credenciales simplificada. Las aplicaciones se escalan en función de la demanda, lo que optimiza la utilización de los recursos y reduce los costos.

Este patrón lo ayuda a integrar Amazon EKS Pod Identity con KEDA. Muestra cómo puede utilizar la cuenta de servicio keda-operator y delegar la autenticación con TriggerAuthentication. También describe cómo configurar una relación de confianza entre un rol de IAM para el operador de KEDA y un rol de IAM para la aplicación. Esta relación de confianza permite a KEDA supervisar los mensajes de las colas de eventos y ajustar la escala de los objetos de Kubernetes de destino.

Requisitos previos y limitaciones

Requisitos previos 

Limitaciones

  • Es necesario establecer una relación de confianza entre los roles keda-operator y keda-identity. Las instrucciones se proporcionan en la sección Epics de este patrón.

Arquitectura

En este patrón, se crean los siguientes recursos: AWS

  • Repositorio de Amazon Elastic Container Registry (Amazon ECR): en este patrón, este repositorio se denomina keda-pod-identity-registry. Este repositorio privado se usa para almacenar imágenes de Docker de la aplicación de muestra.

  • Cola de Amazon Simple Queue Service (Amazon SQS): en este patrón, esta cola se denomina event-messages-queue. La cola actúa como un búfer de mensajes que recopila y almacena los mensajes entrantes. KEDA supervisa las métricas de la cola, como el recuento de mensajes o la longitud de la cola, y escala automáticamente la aplicación en función de estas métricas.

  • Rol de IAM para la aplicación: en este patrón, este rol se denomina keda-identity. El rol keda-operator asume este rol. Este rol permite tener acceso a la cola de Amazon SQS.

  • Rol de IAM para el operador KEDA: en este patrón, este rol se denomina keda-operator. El operador KEDA usa esta función para realizar las llamadas a la AWS API necesarias. Este rol concede permisos para asumir el rol keda-identity. Debido a la relación de confianza entre los roles keda-operator y keda-identity, el rol keda-operator tiene permisos de Amazon SQS.

A través de los recursos personalizados TriggerAuthentication y ScaledObject de Kubernetes, el operador usa el rol keda-identity para conectarse con una cola de Amazon SQS. En función del tamaño de la cola, KEDA escala automáticamente la implementación de la aplicación. Añade 1 pod por cada 5 mensajes no leídos de la cola. En la configuración predeterminada, si no hay mensajes sin leer en la cola de Amazon SQS, la aplicación se reduce verticalmente a 0 pods. El operador de KEDA supervisa la cola en un intervalo especificado.

 

La siguiente imagen muestra cómo se utiliza Amazon EKS Pod Identity para proporcionar al rol keda-operator un acceso seguro a la cola de Amazon SQS.

Uso de KEDA y Amazon EKS Pod Identity para escalar automáticamente una aplicación basada en Kubernetes.

En el diagrama, se muestra el siguiente flujo de trabajo:

  1. El agente Amazon EKS Pod Identity se instala en el clúster de Amazon EKS.

  2. El operador de KEDA se implementa en el espacio de nombres de KEDA del clúster de Amazon EKS.

  3. Los roles keda-operator y de keda-identity IAM se crean en el destino. Cuenta de AWS

  4. Se establece una relación de confianza entre los roles de IAM.

  5. La aplicación se implementa en el espacio de nombres security.

  6. El operador de KEDA sondea los mensajes de una cola de Amazon SQS.

  7. KEDA inicia HPA, que escala automáticamente la aplicación en función del tamaño de la cola.

Tools (Herramientas)

Servicios de AWS

Otras herramientas

  • KEDA es un escalador automático basado en eventos que se basa en Kubernetes.

Repositorio de código

El código de este patrón está disponible en el escalado GitHub automático basado en eventos mediante EKS Pod Identity y el repositorio KEDA.

Prácticas recomendadas

Recomendamos que siga las siguientes prácticas recomendadas:

Epics

TareaDescripciónHabilidades requeridas

Cree el rol de IAM del operador de KEDA.

  1. Inicie sesión en la consola de IAM y Consola de administración de AWS, a continuación, ábrala.

  2. Seleccione Roles en el panel de navegación.

  3. Elija Crear rol.

  4. Elija el tipo de rol Custom trust policy (Política de confianza personalizada).

  5. En la sección Política de confianza personalizada, ingrese la política de confianza personalizada para este rol:

    { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "pods.eks.amazonaws.com" }, "Action": [ "sts:AssumeRole", "sts:TagSession" ] } ] }
  6. En la página Agregar permisos, elija Siguiente. No se agrega ninguna política a este rol.

  7. En Role name (Nombre del rol), introduzca keda-operator.

  8. Elija Create role (Crear rol).

Administrador de AWS

Cree un rol de IAM para la aplicación de muestra.

  1. En el panel de navegación de la consola de IAM, elija Roles.

  2. Seleccione Crear rol.

  3. Elija el tipo de rol Custom trust policy (Política de confianza personalizada).

  4. En la sección Política de confianza personalizada, ingrese la política de confianza personalizada para este rol. Sustituya <account number> por el número de su cuenta de destino:

    { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "pods.eks.amazonaws.com", "AWS": "arn:aws:iam::<account number>:role/keda-operator" }, "Action": [ "sts:AssumeRole", "sts:TagSession" ] } ] }
  5. En la página Añadir permisos, añada las siguientes políticas AWS gestionadas al rol:

    • AmazonSQSReadOnlyAccess

    • AWSLambdaSQSQueueExecutionRole

  6. Elija Siguiente.

  7. En Role name (Nombre del rol), introduzca keda-identity.

  8. Elija Create role (Crear rol).

Administrador de AWS

Crear una cola de Amazon SQS.

  1. Abra la consola de Amazon SQS.

  2. Elige Crear cola.

  3. En Tipo, seleccione Estándar.

  4. En la página Crear cola, en Nombre, introduzca event-messages-queue.

  5. Elige Crear cola. No cambie la configuración predeterminada de esta cola.

AWS general

Cree un repositorio de Amazon ECR.

  1. Abra la consola de Amazon ECR.

  2. Elija Create repository.

  3. En Nombre del repositorio, introduzca keda-pod-identity-registry.

  4. Elija Create repository. No cambie la configuración predeterminada de este repositorio.

AWS general
TareaDescripciónHabilidades requeridas

Implemente el agente Amazon EKS Pod Identity.

Para el clúster de Amazon EKS, configure el agente Amazon EKS Pod Identity. Siga las instrucciones de Configuración del agente Amazon EKS Pod Identity en la documentación de Amazon EKS.

AWS DevOps

Implemente KEDA.

  1. Introduzca los siguientes comandos para implementar KEDA en el clúster de Amazon EKS de destino:

    # Add Helm Repo for Keda helm repo add kedacore https://kedacore.github.io/charts # Update Helm repo helm repo update # Install Keda helm install keda kedacore/keda --namespace keda --create-namespace

    Para obtener más información, consulte Implementación de Helm en la documentación de KEDA.

  2. Tras una implementación correcta, en el resultado, valide que se hayan creado tres implementaciones para el operador de KEDA. A continuación, se muestra un ejemplo de la salida:

    NAME READY UP-TO-DATE AVAILABLE AGE keda-admission-webhooks 1/1 1 1 89s keda-operator 1/1 1 1 89s keda-operator-metrics-apiserver 1/1 1 1 89s
DevOps ingeniero

Asigne el rol de IAM a la cuenta de servicio de Kubernetes.

Siga las instrucciones de Asignación de un rol de IAM a una cuenta de servicio de Kubernetes en la documentación de Amazon EKS. Use los siguientes valores:

  • Para el rol de IAM, introduzca keda-operator.

  • Para el espacio de nombres de Kubernetes, introduzca keda.

  • Para la cuenta de servicio de Kubernetes, introduzca keda-operator.

AWS DevOps

Creación de un espacio de nombres de .

Introduzca el siguiente comando para crear un espacio de nombres security en el clúster de Amazon EKS de destino:

kubectl create ns security
DevOps ingeniero
TareaDescripciónHabilidades requeridas

Clone los archivos de la aplicación.

Introduzca el siguiente comando para clonar el autoescalado basado en eventos mediante EKS Pod Identity y el repositorio KEDA desde: GitHub

git clone https://github.com/aws-samples/event-driven-autoscaling-using-podidentity-and-keda.git
DevOps ingeniero

Cree la imagen de Docker.

  1. Introduzca el siguiente comando para ir al repositorio clonado:

    cd event-driven-autoscaling-using-podidentity-and-keda
  2. Introduzca el siguiente comando para crear la imagen de Docker para la aplicación de muestra:

    docker build -t keda-pod-identity-registry .
DevOps ingeniero

Envíe la imagen de Docker a Amazon ECR.

  1. En el terminal en el que creó la imagen de Docker, introduzca el siguiente comando para iniciar sesión en Amazon ECR. Sustituya <AWS_REGION> y <AWS_ACCOUNT_ID> con los valores de su AWS entorno:

    aws ecr get-login-password \ --region <AWS_REGION> | docker login \ --username AWS \ --password-stdin <AWS_ACCOUNT_ID>.dkr.ecr.<AWS_REGION>.amazonaws.com
  2. Introduzca el siguiente comando para etiquetar la imagen. Reemplace <AWS_REGION> y <AWS_ACCOUNT_ID> con valores de su AWS entorno:

    docker tag keda-pod-identity-registry:latest <AWS_ACCOUNT_ID>.dkr.ecr.<AWS_REGION>.amazonaws.com/keda-pod-identity-registry:latest

  3. Introduzca el siguiente comando para insertar la imagen en Amazon ECR. Reemplace <AWS_REGION> y <AWS_ACCOUNT_ID> con valores de su AWS entorno:

    docker push <AWS_ACCOUNT_ID>.dkr.ecr.<AWS_REGION>.amazonaws.com/keda-pod-identity-registry:latest

nota

Para encontrar los comandos de inserción, vaya a la página del repositorio de Amazon ECR y, a continuación, seleccione Ver comandos de inserción.

DevOps ingeniero

Implemente la aplicación de muestra.

  1. En el repositorio clonado, abra el archivo deploy.yaml.

  2. Sustituya <AWS_ACCOUNT_ID> y <AWS_REGION> por los valores correspondientes al entorno.

  3. Guarde y cierre el archivo deploy.yaml.

  4. Introduzca los siguientes comandos para implementar la misma aplicación en el clúster de Amazon EKS de destino:

    kubectl apply -f deploy.yaml

    Este comando crea una cuenta de implementación y servicio en el clúster.

DevOps ingeniero

Asigne el rol de IAM a la cuenta de servicio de la aplicación.

Realice una de las siguientes acciones para asociar el rol de IAM keda-identity a la cuenta de servicio de la aplicación de ejemplo:

  • Siga las instrucciones de Asignación de un rol de IAM a una cuenta de servicio de Kubernetes en la documentación de Amazon EKS. Use los siguientes valores:

    • Para el rol de IAM, introduzca keda-identity.

    • Para el espacio de nombres de Kubernetes, introduzca security.

    • Para la cuenta de servicio de Kubernetes, introduzca my-sqs-read-msgs.

  • Introduzca el siguiente AWS CLI comando. Sustituya <cluster-name> por el nombre del clúster de Amazon EKS de destino y <role-ARN> por el nombre de recurso de Amazon (ARN) del rol keda-identity:

    aws eks create-pod-identity-association \ --cluster-name <cluster-name> \ --role-arn <role-ARN> \ --namespace security \ --service-account my-sqs-read-msgs
DevOps ingeniero

Implemente ScaledObject y TriggerAuthentication.

  1. En el repositorio clonado, abra el archivo keda.yaml.

  2. {{AWS_ACCOUNT_ID}}Sustitúyalo por el ID de tu objetivo Cuenta de AWS.

  3. {{AWS_REGION}}Sustitúyalo por tu objetivo Región de AWS.

  4. (Opcional) En las líneas 21 a 24, actualice los parámetros de la política de escalado ScaledObject. Para obtener más información acerca del uso de estos parámetros, consulte lo siguiente:

  5. Guarde y cierre el archivo keda.yaml.

  6. Ingrese el comando siguiente para implementar los recursos ScaledObject y TriggerAuthentication.

    kubectl -n security apply -f keda.yaml
DevOps ingeniero
TareaDescripciónHabilidades requeridas

Envíe mensajes a la cola de Amazon SQS.

  1. Introduzca el siguiente comando para ir al repositorio clonado:

    cd event-driven-autoscaling-using-podidentity-and-keda
  2. Introduzca el siguiente comando para enviar mensajes de prueba a la cola de Amazon SQS:

    python sqs_send_msg.py

    El script sqs_send_msg.py actúa como una aplicación que genera mensajes para probar el escalado automático.

    nota

    Si está ejecutando Python 3, use python3 sqs_send_msg.py.

DevOps ingeniero

Supervise los pods de aplicaciones.

  1. En un terminal diferente, introduzca el siguiente comando para supervisar los pods:

    kubectl -n security get po 
  2. Por cada 5 mensajes no leídos de la cola de Amazon SQS, KEDA añade un pod. En el resultado del comando anterior, confirme que se están añadiendo nuevos pods. A continuación, se muestra un ejemplo de la salida:

    kubectl -n security get po NAME READY STATUS RESTARTS AGE q-read-797f4c7589-2bj76 1/1 Running 0 2s q-read-797f4c7589-4zxph 1/1 Running 0 49s q-read-797f4c7589-cg9dt 1/1 Running 0 18s q-read-797f4c7589-slc69 1/1 Running 0 33s
  3. Cuando finalice las pruebas, en el terminal original, introduzca CTRL + C (Windows) o CMD + C (macOS). Esta acción detiene el script python sqs_send_msg.py.

DevOps ingeniero

Resolución de problemas

ProblemaSolución

El operador de KEDA no puede escalar la aplicación.

Introduzca el siguiente comando para comprobar los registros del rol de IAM keda-operator:

kubectl logs -n keda -l app=keda-operator -c keda-operator

 

Si hay un código de respuestaHTTP 403, la aplicación y el escalador de KEDA no tienen permisos suficientes para acceder a la cola de Amazon SQS. Realice los siguientes pasos:

  1. Consulte las instrucciones y políticas de IAM del rol keda-identity para confirmar que se concede el acceso de lectura a la cola.

  2. Valide la relación de confianza entre los roles de IAM. A continuación, se muestra un ejemplo:

    { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "pods.eks.amazonaws.com" }, "Action": [ "sts:AssumeRole", "sts:TagSession" ] } ] }

Si se produce un error Assume-Role, el rol de IAM de un nodo de Amazon EKS no puede asumir el rol de IAM que está definido para TriggerAuthentication. Realice los siguientes pasos:

  1. Introduzca el siguiente comando para eliminar el pod keda-operator y crear uno nuevo:

    kubectl delete pod keda-operator-<alphenumeric-value> --namespace keda
  2. Introduzca el siguiente comando para comprobar la identidad que asume el pod:

    kubectl describe pod <keda-operator-pod-name> --namespace keda
  3. Cuando el pod se reinicie correctamente, confirme que se hayan añadido las dos variables siguientes a la descripción del pod:

    • AWS_CONTAINER_CREDENTIALS_FULL_URI

    • AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE

Recursos relacionados