Escalado seguro de las aplicaciones mediante la identidad de carga de trabajo y el complemento KEDA en Azure Kubernetes Service (AKS)

Artículo
08/02/2024

En este artículo se muestra cómo escalar de forma segura las aplicaciones con el complemento de escalado automático controlado por eventos (KEDA) de Kubernetes y la identidad de carga de trabajo en Azure Kubernetes Service (AKS).

Importante

La versión de Kubernetes del clúster determina qué versión de KEDA se instalará en el clúster de AKS. Para ver qué versión de KEDA se asigna a cada versión de AKS, vea la columna de complementos administrados de AKS de la tabla de versiones de componentes de Kubernetes.

En el caso de las versiones de Kubernetes de disponibilidad general, AKS ofrece compatibilidad completa con la versión secundaria de KEDA correspondiente en la tabla. Las versiones preliminares de Kubernetes y la revisión más reciente de KEDA están parcialmente cubiertas por el soporte técnico al cliente de la mejor manera posible. Por lo tanto, estas características no están diseñadas para su uso en producción. Para más información, consulte los siguientes artículos de soporte:

Antes de empezar

Necesita una suscripción de Azure. Si no tiene una suscripción a Azure, puede crear una cuenta gratuita.
Necesita tener instalada la CLI de Azure.
Asegúrese de que tiene configuradas las reglas de firewall para permitir el acceso al servidor de API de Kubernetes. Para más información, consulte Reglas de FQDN y red de salida para clústeres de Azure Kubernetes Service (AKS).

Crear un grupo de recursos

Cree un grupo de recursos con el comando az group create. Asegúrese de reemplazar los valores de marcador de posición por sus propios valores.
```
LOCATION=<azure-region>
RG_NAME=<resource-group-name>

az group create --name $RG_NAME --location $LOCATION
```

Creación de un clúster de AKS

Cree un clúster de AKS con el emisor de OIDC, la identidad de carga de trabajo y el complemento KEDA habilitados mediante el comando az aks create con las marcas --enable-workload-identity, --enable-keda y --enable-oidc-issuer. Asegúrese de reemplazar el valor del marcador de posición por su propio valor.
```
AKS_NAME=<cluster-name>

az aks create \
    --name $AKS_NAME \
    --resource-group $RG_NAME \
    --enable-workload-identity \
    --enable-oidc-issuer \
    --enable-keda \
    --generate-ssh-keys 
```
Valide que la implementación se realizó correctamente y asegúrese de que el clúster tiene habilitado el KEDA, la identidad de carga de trabajo y el emisor de OIDC mediante el comando az aks show con la marca --query establecida en "[workloadAutoScalerProfile, securityProfile, oidcIssuerProfile]".
```
az aks show \
    --name $AKS_NAME \
    --resource-group $RG_NAME \
    --query "[workloadAutoScalerProfile, securityProfile, oidcIssuerProfile]"
```

Conéctese al clúster mediante el comando az aks get-credentials.

az aks get-credentials \
    --name $AKS_NAME \
    --resource-group $RG_NAME \
    --overwrite-existing

Creación de un Azure Service Bus

Creación de un espacio de nombres de Azure Service Bus con el comando az servicebus namespace create. Asegúrese de reemplazar los valores del marcador de posición por los propios.

SB_NAME=<service-bus-name>
SB_HOSTNAME="${SB_NAME}.servicebus.windows.net"

az servicebus namespace create \
    --name $SB_NAME \
    --resource-group $RG_NAME \
    --disable-local-auth

Creación de una cola de Azure Service Bus con el comando az servicebus queue create. Asegúrese de reemplazar los valores del marcador de posición por los propios.
```
SB_QUEUE_NAME=<service-bus-queue-name>

az servicebus queue create \
    --name $SB_QUEUE_NAME \
    --namespace $SB_NAME \
    --resource-group $RG_NAME
```

Creación de una entidad administrada

Crear una identidad administrada usando el comando az identity create. Asegúrese de reemplazar los valores del marcador de posición por los propios.

MI_NAME=<managed-identity-name>

MI_CLIENT_ID=$(az identity create \
    --name $MI_NAME \
    --resource-group $RG_NAME \
    --query "clientId" \
    --output tsv)

Obtenga la dirección URL del emisor de OIDC mediante el comando az aks show con la marca --query establecida en oidcIssuerProfile.issuerUrl.

AKS_OIDC_ISSUER=$(az aks show \
    --name $AKS_NAME \
    --resource-group $RG_NAME \
    --query oidcIssuerProfile.issuerUrl \
    --output tsv)

Cree una credencial federada entre la identidad administrada y el espacio de nombres y la cuenta de servicio que usa la carga de trabajo mediante el comando az identity federated-credential create. Asegúrese de reemplazar los valores del marcador de posición por los propios.

FED_WORKLOAD=<federated-credential-workload-name>

az identity federated-credential create \
    --name $FED_WORKLOAD \
    --identity-name $MI_NAME \
    --resource-group $RG_NAME \
    --issuer $AKS_OIDC_ISSUER \
    --subject system:serviceaccount:default:$MI_NAME \
    --audience api://AzureADTokenExchange

Cree una segunda credencial federada entre la identidad administrada y el espacio de nombres y la cuenta de servicio usadas por el operador KEDA mediante el comando az identity federated-credential create. Asegúrese de reemplazar los valores del marcador de posición por los propios.

FED_KEDA=<federated-credential-keda-name>

az identity federated-credential create \
    --name $FED_KEDA \
    --identity-name $MI_NAME \
    --resource-group $RG_NAME \
    --issuer $AKS_OIDC_ISSUER \
    --subject system:serviceaccount:kube-system:keda-operator \
    --audience api://AzureADTokenExchange

Crear asignaciones de roles

Obtenga el identificador de objeto de la identidad administrada mediante el comando az identity show con la marca --query establecida en "principalId".
```
MI_OBJECT_ID=$(az identity show \
    --name $MI_NAME \
    --resource-group $RG_NAME \
    --query "principalId" \
    --output tsv)
```
Obtenga el identificador de recurso del espacio de nombres de Service Bus mediante el comando az servicebus namespace show con la marca --query establecida en "id".
```
SB_ID=$(az servicebus namespace show \
    --name $SB_NAME \
    --resource-group $RG_NAME \
    --query "id" \
    --output tsv)
```

Asigne el rol Propietario de datos de Azure Service Bus a la identidad administrada mediante el comando az role assignment create.

az role assignment create \
    --role "Azure Service Bus Data Owner" \
    --assignee-object-id $MI_OBJECT_ID \
    --assignee-principal-type ServicePrincipal \
    --scope $SB_ID

Habilitación de la identidad de carga de trabajo en el operador KEDA

Después de crear la credencial federada para la ServiceAccount keda-operator, deberá reiniciar manualmente los pods de keda-operator para asegurarse de que las variables de entorno de Identidad de carga de trabajo se insertan en el pod.
```
kubectl rollout restart deploy keda-operator -n kube-system
```
Confirmación del reinicio de los pods del operador KEDA
```
kubectl get pod -n kube-system -lapp=keda-operator -w
```
Una vez que haya confirmado que los pods del operador KEDA han terminado de ejecutarCtrl+c para interrumpir el comando de inspección anterior, confirme que se han insertado las variables de entorno de Identidad de carga de trabajo.
```
KEDA_POD_ID=$(kubectl get po -n kube-system -l app.kubernetes.io/name=keda-operator -ojsonpath='{.items[0].metadata.name}')
kubectl describe po $KEDA_POD_ID -n kube-system
```

Debería ver una salida similar a la siguiente en Entorno.

---
AZURE_CLIENT_ID:
AZURE_TENANT_ID:               xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx
AZURE_FEDERATED_TOKEN_FILE:    /var/run/secrets/azure/tokens/azure-identity-token
AZURE_AUTHORITY_HOST:          https://login.microsoftonline.com/
---

Implemente un recurso TriggerAuthentication de KEDA que incluya el identificador de cliente de la identidad administrada asignada por el usuario.
```
kubectl apply -f - <<EOF
apiVersion: keda.sh/v1alpha1
kind: TriggerAuthentication
metadata:
  name: azure-servicebus-auth
  namespace: default  # this must be same namespace as the ScaledObject/ScaledJob that will use it
spec:
  podIdentity:
    provider:  azure-workload
    identityId: $MI_CLIENT_ID
EOF
```
Nota:

Con el recurso TriggerAuthentication implementado, KEDA podrá autenticarse a través de la identidad de carga de trabajo. Los pods de keda-operator usan el identityId para autenticarse en los recursos de Azure al evaluar los desencadenadores de escalado.

Publicación de mensajes en Azure Service Bus

En este momento, todo está configurado para el escalado con KEDA e Identidad de carga de trabajo de Microsoft Entra. Para probarlo, implementaremos cargas de trabajo de productor y consumidor.

Cree una nueva ServiceAccount para las cargas de trabajo.

kubectl apply -f - <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    azure.workload.identity/client-id: $MI_CLIENT_ID
  name: $MI_NAME
EOF

Implemente un trabajo para publicar 100 mensajes.

kubectl apply -f - <<EOF
apiVersion: batch/v1
kind: Job
metadata:
  name: myproducer
spec:
  template:
    metadata:
      labels:
        azure.workload.identity/use: "true"
    spec:
      serviceAccountName: $MI_NAME
      containers:
      - image: ghcr.io/azure-samples/aks-app-samples/servicebusdemo:latest
        name: myproducer
        resources: {}
        env:
        - name: OPERATION_MODE
          value: "producer"
        - name: MESSAGE_COUNT
          value: "100"
        - name: AZURE_SERVICEBUS_QUEUE_NAME
          value: $SB_QUEUE_NAME
        - name: AZURE_SERVICEBUS_HOSTNAME
          value: $SB_HOSTNAME
      restartPolicy: Never
EOF

Consumo de mensajes desde Azure Service Bus

Ahora que ha publicado mensajes en la cola de Azure Service Bus, se implementará una instancia de ScaledJob para consumirlos. Esta instancia de ScaledJob usará el recurso TriggerAuthentication de KEDA para autenticarse en la cola de Azure Service Bus mediante la identidad de carga de trabajo y escalar horizontalmente cada 10 mensajes.

Implemente un recurso ScaledJob para consumir los mensajes. El desencadenador de escalado se configurará para escalar horizontalmente cada 10 mensajes. El escalador KEDA creará 10 trabajos para consumir los 100 mensajes.

kubectl apply -f - <<EOF
apiVersion: keda.sh/v1alpha1
kind: ScaledJob
metadata:
  name: myconsumer-scaledjob
spec:
  jobTargetRef:
    template:
      metadata:
        labels:
          azure.workload.identity/use: "true"
      spec:
        serviceAccountName: $MI_NAME
        containers:
        - image: ghcr.io/azure-samples/aks-app-samples/servicebusdemo:latest
          name: myconsumer
          env:
          - name: OPERATION_MODE
            value: "consumer"
          - name: MESSAGE_COUNT
            value: "10"
          - name: AZURE_SERVICEBUS_QUEUE_NAME
            value: $SB_QUEUE_NAME
          - name: AZURE_SERVICEBUS_HOSTNAME
            value: $SB_HOSTNAME
        restartPolicy: Never
  triggers:
  - type: azure-servicebus
    metadata:
      queueName: $SB_QUEUE_NAME
      namespace: $SB_NAME
      messageCount: "10"
    authenticationRef:
      name: azure-servicebus-auth
EOF

Nota:

ScaledJob crea un recurso de trabajo de Kubernetes cada vez que se produce un evento de escalado y, por tanto, es necesario pasar una plantilla de trabajo al crear el recurso. A medida que se crean nuevos trabajos, los pods se implementarán con bits de identidad de carga de trabajo para consumir mensajes.

Compruebe que el escalador KEDA funcionó según lo previsto.
```
kubectl describe scaledjob myconsumer-scaledjob
```

Debería ver eventos similares a los siguientes.

Events:
Type     Reason              Age   From           Message
----     ------              ----  ----           -------
Normal   KEDAScalersStarted  10m   scale-handler  Started scalers watch
Normal   ScaledJobReady      10m   keda-operator  ScaledJob is ready for scaling
Warning  KEDAScalerFailed    10m   scale-handler  context canceled
Normal   KEDAJobsCreated     10m   scale-handler  Created 10 jobs

Limpieza de recursos

Después de comprobar que la implementación es correcta, puede limpiar los recursos para evitar incurrir en costos de Azure.

Elimine el grupo de recursos de Azure y todos sus recursos mediante el comando [az group delete][az-group-delete].
```
az group delete --name $RG_NAME --yes --no-wait
```

Pasos siguientes

En este artículo se muestra cómo escalar de forma segura las aplicaciones mediante la identidad de carga de trabajo y el complemento KEDA en AKS.

Para obtener información sobre la solución de problemas de KEDA, consulte Solución de problemas del complemento de Escalado automático controlado por eventos de Kubernetes (KEDA).

Para obtener más información sobre KEDA, consulte la documentación de KEDA ascendente.

Compartir a través de