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.
Inicie sesión en Azure con el comando
az login
.az login
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
Seleccione una suscripción específica con el comando
az account set
.az account set --subscription $subscriptionId
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.
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.
Una vez completado el script de implementación, puede implementar la carga de trabajo en el clúster de AKS.
Establezca el origen para recopilar y actualizar las variables de entorno para
./deployment/environmentVariables.sh
mediante el comando siguiente:source ./deployment/environmentVariables.sh
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 comandocat
: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=
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
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
Compruebe que los pods del operador KEDA se ejecutan en el espacio de nombres
kube-system
en el clúster de AKS mediante el comandokubectl get
.kubectl get pods --namespace kube-system | grep keda
El resultado debería ser similar al ejemplo siguiente:
Ahora, generará una carga simulada mediante la aplicación de productor para rellenar la cola con mensajes.
En una ventana de terminal independiente, vaya al directorio del proyecto.
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
Una vez que la aplicación empiece a enviar mensajes, vuelva a la otra ventana del terminal.
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ónspec/template
es la plantilla de pod de la implementación. Al establecer la etiqueta entrue
se especifica que usa la identidad de carga de trabajo. ElserviceAccountName
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únimagePullSecret
.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.
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: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:
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.
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.
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 esaqs-demo
) e inicie k9s en cada ventana.Debería ver algo parecido a lo siguiente:
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 propiedadidentityID
, 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:
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:
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:Por último, puede ver la actividad de escalado automático de Karpenter mediante el comando
kubectl get events
como se muestra aquí:
Puede usar el script de limpieza (/deployment/infra/cleanup.sh
) en nuestro repositorio de GitHub para quitar todos los recursos que creó.
Para obtener más información sobre el desarrollo y ejecución de aplicaciones en AKS, consulte los siguientes recursos:
- Instalación de aplicaciones existentes con Helm en AKS
- Implementación y administración de una aplicación de Kubernetes desde Azure Marketplace en AKS
- Implementación de una aplicación que usa OpenAI en AKS
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
Comentarios de Azure Kubernetes Service
Azure Kubernetes Service es un proyecto de código abierto. Seleccione un vínculo para proporcionar comentarios: