Leer en inglés

Compartir a través de


Implementación de una carga de trabajo de flujo de trabajo controlada por eventos (EDW) de AWS en Azure

En este artículo, implementará una carga de trabajo de AWS EDW en Azure.

Inicio de sesión en Azure

  1. Inicie sesión en Azure con el comando az login.

    az login
    
  2. Si la cuenta de Azure tiene varias suscripciones, asegúrese de seleccionar la correcta. Enumere los nombres e identificadores de las suscripciones mediante el comando az account list.

    az account list --query "[].{id: id, name:name }" --output table
    
  3. Seleccione una suscripción específica con el comando az account set.

    az account set --subscription $subscriptionId
    

Script de implementación de cargas de trabajo de EDW

Revise las variables de entorno del archivo deployment/environmentVariables.sh y, a continuación, use el script deploy.sh del directorio deployment/infra/ del repositorio de GitHub para implementar la aplicación en Azure.

El script comprueba primero que todas las herramientas de requisitos previos están instaladas. Si no es así, el script finaliza y muestra un mensaje de error que le indica qué requisitos previos faltan. Si esto sucede, revise los requisitos previos, instale las herramientas que faltan y vuelva a ejecutar el script. La característica Aprovisionamiento automático de nodos (NAP) para AKS debe estar registrada en la suscripción de Azure. Si aún no está registrado, el script ejecuta un comando de la CLI de Azure para registrar la marca de característica.

El script registra el estado de la implementación en un archivo denominado deploy.state, que se encuentra en el directorio deployment. Puede usar este archivo para establecer variables de entorno al implementar la aplicación.

A medida que el script ejecuta los comandos para configurar la infraestructura para el flujo de trabajo, comprueba que cada comando se ejecuta correctamente. Si se produce algún problema, se muestra un mensaje de error y la ejecución se detiene.

El script muestra un registro a medida que se ejecuta. Para conservar el registro, redirija la salida de información del registro y guárdela en el archivo install.log del directorio logs mediante los siguientes comandos:

mkdir ./logs
./deployment/infra/deploy.sh | tee ./logs/install.log

Para obtener más información, consulte el script de ./deployment/infra/deploy.sh en nuestro repositorio de GitHub.

Recursos de carga de trabajo

El script de implementación crea los siguientes recursos de Azure:

  • Grupo de recursos de Azure: el grupo de recursos de Azure que almacena los recursos creados por el script de implementación.

  • Cuenta de Azure Storage: la cuenta de Azure Storage que contiene la cola donde la aplicación de productor envía los mensajes y la lee la aplicación de consumidor y la tabla donde la aplicación consumidor almacena los mensajes procesados.

  • Registro de contenedor de Azure: el registro de contenedor proporciona un repositorio para el contenedor que implementa el código de la aplicación de consumidor refactorizado.

  • Clúster de Azure Kubernetes Service (AKS): el clúster de AKS proporciona orquestación de Kubernetes para el contenedor de aplicaciones de consumidor y tiene habilitadas las siguientes características:

    • Aprovisionamiento automático de nodos (NAP): la implementación del escalador automático de nodos Karpenter en AKS.
    • Escalado automático controlado por eventos (KEDA) de Kubernetes: KEDA permite el escalado de pods basado en eventos, como la superación de un umbral de profundidad de cola especificado.
    • Identidad de carga de trabajo: permite adjuntar directivas de acceso basadas en roles a identidades de pod para mejorar la seguridad.
    • Registro de contenedor de Azure asociado: esta característica permite que el clúster de AKS extraiga imágenes de repositorios en la instancia de ACR especificada.
  • Grupo de aplicaciones y nodos del sistema: el script también crea un grupo de nodos de aplicación y sistema en el clúster AKS que tiene un valor de intolerancia para evitar que los pods de aplicación se programen en el grupo de nodos de sistema.

  • Identidad administrada del clúster de AKS: el script asigna el rol acrPull a esta identidad administrada, lo que facilita el acceso al registro de contenedor de Azure asociado para extraer imágenes.

  • Identidad de carga de trabajo: el script asigna los roles Colaborador de datos de cola de Storage y Colaborador de datos de tabla de Storage para proporcionar acceso de control de acceso basado en rol (RBAC) a esta identidad administrada, que está asociada a la cuenta de servicio de Kubernetes que se usa como identidad para pods en los que se implementan los contenedores de aplicaciones consumidor.

  • Dos credenciales federadas: una credencial permite que la identidad administrada implemente la identidad de pod y la otra credencial se usa para la cuenta de servicio del operador KEDA para proporcionar acceso al escalador KEDA para recopilar las métricas necesarias para controlar el escalado automático del pod.

Validación de la implementación y ejecución de la carga de trabajo

Una vez completado el script de implementación, puede implementar la carga de trabajo en el clúster de AKS.

  1. Establezca el origen para recopilar y actualizar las variables de entorno para ./deployment/environmentVariables.sh mediante el comando siguiente:

    source ./deployment/environmentVariables.sh
    
  2. Necesita la información del archivo ./deployment/deploy.state para establecer variables de entorno para los nombres de los recursos creados en la implementación. Muestre el contenido del archivo con el siguiente comando cat:

    cat ./deployment/deploy.state
    

    La salida debe mostrar las siguientes variables:

    SUFFIX=
    RESOURCE_GROUP=
    AZURE_STORAGE_ACCOUNT_NAME=
    AZURE_QUEUE_NAME=
    AZURE_COSMOSDB_TABLE=
    AZURE_CONTAINER_REGISTRY_NAME=
    AKS_MANAGED_IDENTITY_NAME=
    AKS_CLUSTER_NAME=
    WORKLOAD_MANAGED_IDENTITY_NAME=
    SERVICE_ACCOUNT=
    FEDERATED_IDENTITY_CREDENTIAL_NAME=
    KEDA_SERVICE_ACCT_CRED_NAME=
    
  3. Lea el archivo y cree variables de entorno para los nombres de los recursos de Azure creados por el script de implementación mediante los siguientes comandos:

    while IFS= read -r; line do \
    echo "export $line" \
    export $line; \
    done < ./deployment/deploy.state
    
  4. Obtenga las credenciales del clúster de AKS mediante el comando az aks get-credentials.

    az aks get-credentials --resource-group $RESOURCE_GROUP --name $AKS_CLUSTER_NAME
    
  5. Compruebe que los pods del operador KEDA se ejecutan en el espacio de nombres kube-system en el clúster de AKS mediante el comando kubectl get.

    kubectl get pods --namespace kube-system | grep keda
    

    El resultado debería ser similar al ejemplo siguiente:

    Captura de pantalla que muestra una respuesta de ejemplo del comando para comprobar que los pods del operador KEDA se están ejecutando.

Generación de una carga simulada

Ahora, generará una carga simulada mediante la aplicación de productor para rellenar la cola con mensajes.

  1. En una ventana de terminal independiente, vaya al directorio del proyecto.

  2. Establezca las variables de entorno mediante los pasos descritos en la sección anterior. 1. Ejecute la aplicación de productor con el comando siguiente:

    python3 ./app/keda/aqs-producer.py
    
  3. Una vez que la aplicación empiece a enviar mensajes, vuelva a la otra ventana del terminal.

  4. Implemente el contenedor de aplicaciones de consumidor en el clúster de AKS mediante los siguientes comandos:

    chmod +x ./deployment/keda/deploy-keda-app-workload-id.sh
    ./deployment/keda/deploy-keda-app-workload-id.sh
    

    El script de implementación (deploy-keda-app-workload-id.sh) realiza plantillas en la especificación YAML del manifiesto de aplicación para pasar variables de entorno al pod. Revise el siguiente extracto de este script:

    cat <<EOF | kubectl apply -f -
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: $AQS_TARGET_DEPLOYMENT
      namespace: $AQS_TARGET_NAMESPACE
    spec:
      replicas: 1
      selector:
        matchLabels:
          app: aqs-reader
      template:
        metadata:
          labels:
            app: aqs-reader
            azure.workload.identity/use: "true"
        spec:
          serviceAccountName: $SERVICE_ACCOUNT
          containers:
          - name: keda-queue-reader
            image: ${AZURE_CONTAINER_REGISTRY_NAME}.azurecr.io/aws2azure/aqs-consumer
            imagePullPolicy: Always
            env:
            - name: AZURE_QUEUE_NAME
              value: $AZURE_QUEUE_NAME
            - name: AZURE_STORAGE_ACCOUNT_NAME
              value: $AZURE_STORAGE_ACCOUNT_NAME
            - name: AZURE_TABLE_NAME
              value: $AZURE_TABLE_NAME
            resources:
              requests:
                memory: "64Mi"
                cpu: "250m"
              limits:
                memory: "128Mi"
                cpu: "500m"
    EOF
    

    La etiqueta azure.workload.identity/use de la sección spec/template es la plantilla de pod de la implementación. Al establecer la etiqueta en true se especifica que usa la identidad de carga de trabajo. El serviceAccountName de la especificación del pod especifica la cuenta de servicio de Kubernetes que se va a asociar a la identidad de carga de trabajo. Aunque la especificación del pod contiene una referencia para una imagen en un repositorio privado, no se especifica ningún imagePullSecret.

  5. Compruebe que el script se ejecutó correctamente mediante el comando kubectl get.

    kubectl get pods --namespace $AQS_TARGET_NAMESPACE
    

    Debería ver un único pod en la salida.

  6. Compruebe que se creó un grupo de nodos de Karpenter. Para ello, use el comando kubectl get nodepool. La respuesta del comando tendrá un aspecto similar al siguiente:

    Captura de pantalla que muestra un ejemplo de la creación del grupo de nodos de Karpenter.

    Compruebe que el grupo de nodos predeterminado es un grupo de nodos de Karpenter mediante el comando kubectl describe nodepool. En la respuesta del comando, puede comprobar que el grupo de nodos es un grupo de nodos de Karpenter. Deberíamos ver algo parecido a lo siguiente:

    Captura de pantalla que muestra la respuesta del grupo de nodos, incluida la versión de API indicada como Karpenter.

Supervisión del escalado horizontal de pods y nodos con k9s

Puede usar varias herramientas para comprobar el funcionamiento de las aplicaciones implementadas en AKS, incluidos Azure Portal y k9s. Para obtener más información sobre k9s, consulte la introducción k9s.

  1. Instale k9s en el clúster de AKS mediante las instrucciones adecuadas para su entorno de la introducción a la instalación de k9s.

  2. Cree dos ventanas, una con una vista de los pods y la otra con una vista de los nodos del espacio de nombres que especificó en la variable de entorno AQS_TARGET_NAMESPACE (el valor predeterminado es aqs-demo) e inicie k9s en cada ventana.

    Debería ver algo parecido a lo siguiente:

    Recorte de pantalla que muestra un ejemplo de la vista de K9s en dos ventanas.

  3. Después de confirmar que el contenedor de aplicaciones de consumidor está instalado y en ejecución en el clúster de AKS, instale el ScaledObject y desencadene la autenticación usada por KEDA para el escalado automático del pod mediante la ejecución del script de instalación de objetos escalados (keda-scaleobject-workload-id.sh). con los siguientes comandos:

    chmod +x ./deployment/keda/keda-scaleobject-workload-id.sh
    ./deployment/keda/keda-scaleobject-workload-id.sh
    

    El script también realiza plantillas para insertar variables de entorno cuando sea necesario. Revise el siguiente extracto de este script:

    cat <<EOF | kubectl apply -f -
    apiVersion: keda.sh/v1alpha1
    kind: ScaledObject
    metadata:
      name: aws2az-queue-scaleobj
      namespace: ${AQS_TARGET_NAMESPACE}
    spec:
      scaleTargetRef:
        name: ${AQS_TARGET_DEPLOYMENT}     #K8s deployement to target
      minReplicaCount: 0  # We don't want pods if the queue is empty nginx-deployment
      maxReplicaCount: 15 # We don't want to have more than 15 replicas
      pollingInterval: 30 # How frequently we should go for metrics (in seconds)
      cooldownPeriod:  10 # How many seconds should we wait for downscale
      triggers:
      - type: azure-queue
        authenticationRef:
          name: keda-az-credentials
        metadata:
          queueName: ${AZURE_QUEUE_NAME}
          accountName: ${AZURE_STORAGE_ACCOUNT_NAME}
          queueLength: '5'
          activationQueueLength: '20' # threshold for when the scaler is active
          cloud: AzurePublicCloud
    ---
    apiVersion: keda.sh/v1alpha1
    kind: TriggerAuthentication
    metadata:
      name: keda-az-credentials
      namespace: $AQS_TARGET_NAMESPACE
    spec:
      podIdentity:
        provider: azure-workload
        identityId: '${workloadManagedIdentityClientId}'
    EOF
    

    El manifiesto describe dos recursos: el objeto TriggerAuthentication, que especifica a KEDA que el objeto escalado usa la identidad de pod para la autenticación y la propiedad identityID, que hace referencia a la identidad administrada usada como identidad de carga de trabajo.

    Cuando el objeto escalado se instala correctamente y KEDA detecta que se supera el umbral de escalado, comienza a programar pods. Si usa k9s, debería ver algo parecido a esto:

    Recorte de pantalla que muestra un ejemplo de la vista de K9s con pods de programación.

    Si permite que el productor rellene la cola con suficientes mensajes, es posible que KEDA tenga que programar más pods de los que hay nodos que servir. Para dar cabida a esto, Karpenter iniciará la programación de nodos. Si usa k9s, debería ver algo parecido a esto:

    Recorte de pantalla que muestra un ejemplo de la vista de K9s con nodos de programación.

    En estas dos imágenes, observe cómo el número de nodos cuyos nombres contienen aks-default aumentaron de uno a tres nodos. Si impide que la aplicación de productor coloque mensajes en la cola, los consumidores reducirán la profundidad de la cola por debajo del umbral y KEDA y Karpenter se escalarán. Si usa k9s, debería ver algo parecido a esto:

    Recorte de pantalla que muestra un ejemplo de la vista de K9s con una profundidad de cola reducida.

  4. Por último, puede ver la actividad de escalado automático de Karpenter mediante el comando kubectl get events como se muestra aquí:

    Captura de pantalla que muestra un ejemplo del comando kubectl.

Limpieza de recursos

Puede usar el script de limpieza (/deployment/infra/cleanup.sh) en nuestro repositorio de GitHub para quitar todos los recursos que creó.

Pasos siguientes

Para obtener más información sobre el desarrollo y ejecución de aplicaciones en AKS, consulte los siguientes recursos:

Colaboradores

Microsoft se encarga del mantenimiento de este artículo. Los siguientes colaboradores lo escribieron originalmente:

  • Ken Kilty | TPM de entidad de seguridad
  • Russell de Pina | TPM de entidad de seguridad
  • Jenny Hayes | Desarrollador de contenido sénior
  • Carol Smith | Desarrollador de contenido sénior
  • Erin Schaffer | Desarrollador de contenido 2