Udostępnij przez

Bezpiecznie skaluj swoje aplikacje, korzystając z dodatku KEDA oraz identyfikatora obciążenia w usłudze Azure Kubernetes Service (AKS)

W tym artykule pokazano, jak bezpiecznie skalować aplikacje za pomocą dodatku Kubernetes Event-driven Autoscaling (KEDA) i tożsamości obciążenia w usłudze Azure Kubernetes Service (AKS).

Ważne

Wersja Kubernetes w klastrze określa, jaka wersja KEDA zostanie zainstalowana w klastrze AKS. Aby zobaczyć, która wersja KEDA jest przypisana do każdej wersji AKS, zobacz kolumnę AKS managed add-ons w tabeli wersji składników Kubernetes.

W przypadku wersji GA platformy Kubernetes usługa AKS oferuje pełną obsługę odpowiadającej wersji pomocniczej KEDA wymienionej w tabeli. Wersje zapoznawcze Kubernetes i najnowsza poprawka KEDA są częściowo objęte pomocą techniczną na zasadzie najlepszych starań. W związku z tym te funkcje nie są przeznaczone do użytku produkcyjnego. Aby uzyskać więcej informacji, zobacz następujące artykuły pomocy technicznej:

Zanim rozpoczniesz

Tworzenie grupy zasobów

  • Utwórz grupę zasobów przy użyciu az group create polecenia . Pamiętaj, aby zastąpić wartości symboli zastępczych swoimi wartościami.

    LOCATION=<azure-region>
RG_NAME=<resource-group-name>

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

Tworzenie klastra AKS

  1. Utwórz klaster AKS z włączonym dodatkiem KEDA, tożsamością obciążeń i wystawcą OIDC, używając polecenia az aks create z flagami --enable-workload-identity, --enable-keda i --enable-oidc-issuer. Upewnij się, że zastąpisz wartość symbolu zastępczego własną wartością.

    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

  2. Sprawdź, czy wdrożenie zakończyło się pomyślnie, i upewnij się, że klaster ma włączone funkcje KEDA, uwierzytelniania tożsamości obciążenia oraz wystawcę OIDC, używając polecenia az aks show z flagą --query ustawioną na "[workloadAutoScalerProfile, securityProfile, oidcIssuerProfile]".

    az aks show \
    --name $AKS_NAME \
    --resource-group $RG_NAME \
    --query "[workloadAutoScalerProfile, securityProfile, oidcIssuerProfile]"

  3. Połącz się z klastrem az aks get-credentials przy użyciu polecenia .

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

Tworzenie usługi Azure Service Bus

  1. Utwórz przestrzeń nazw usługi Azure Service Bus przy użyciu az servicebus namespace create polecenia . Pamiętaj, aby zastąpić wartość symbolu zastępczego własną wartością.

    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

  2. Utwórz kolejkę usługi Azure Service Bus przy użyciu az servicebus queue create polecenia . Pamiętaj, aby zastąpić wartość symbolu zastępczego własną wartością.

    SB_QUEUE_NAME=<service-bus-queue-name>

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

Tworzenie tożsamości zarządzanej

  1. Utwórz tożsamość zarządzaną przy użyciu az identity create polecenia . Pamiętaj, aby zastąpić wartość symbolu zastępczego własną wartością.

    MI_NAME=<managed-identity-name>

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

  2. Pobierz adres URL wystawcy OIDC przy użyciu az aks show polecenia z flagą ustawioną na --queryoidcIssuerProfile.issuerUrl.

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

  3. Utwórz poświadczenia federacyjne między tożsamością zarządzaną a przestrzenią nazw i kontem usługi, które są używane przez obciążenie, przy użyciu polecenia az identity federated-credential create. Pamiętaj, aby zastąpić wartość symbolu zastępczego własną wartością.

    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

  4. Utwórz drugie poświadczenie federacyjne między tożsamością zarządzaną a przestrzenią nazw i kontem usługi używanym przez operator Keda za pomocą polecenia az identity federated-credential create. Pamiętaj, aby zastąpić wartość symbolu zastępczego własną wartością.

    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

Tworzenie przypisań roli

  1. Pobierz identyfikator obiektu tożsamości zarządzanej przy użyciu az identity show polecenia z flagą ustawioną --query na "principalId".

    MI_OBJECT_ID=$(az identity show \
    --name $MI_NAME \
    --resource-group $RG_NAME \
    --query "principalId" \
    --output tsv)

  2. Pobierz identyfikator zasobu przestrzeni nazw usługi Service Bus przy użyciu az servicebus namespace show polecenia z flagą ustawioną na --query"id".

    SB_ID=$(az servicebus namespace show \
    --name $SB_NAME \
    --resource-group $RG_NAME \
    --query "id" \
    --output tsv)

  3. Przypisz rolę Właściciela danych usługi Azure Service Bus do tożsamości zarządzanej, używając polecenia 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

Włącz tożsamość obciążeń dla operatora KEDA

  1. Po utworzeniu poświadczeń federacyjnych dla keda-operator konta usługi należy ręcznie uruchomić ponownie keda-operator zasobniki, aby upewnić się, że zmienne środowiskowe Workload Identity są wstrzykiwane do zasobniku.

    kubectl rollout restart deploy keda-operator -n kube-system

  2. Potwierdzanie ponownego uruchomienia zasobników keda-operator

    kubectl get pod -n kube-system -lapp=keda-operator -w

  3. Po potwierdzeniu, że zasobniki keda-operator zostały zaktualizowane, naciśnij Ctrl+c w celu przerwania poprzedniego polecenia monitorującego, a następnie upewnij się, że zmienne środowiskowe Workload Identity zostały wprowadzone.

    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

  4. Powinny zostać wyświetlone dane wyjściowe podobne do poniższych w obszarze Środowisko.

    ---
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/
---

  5. Wdróż zasób KEDA TriggerAuthentication zawierający identyfikator klienta tożsamości zarządzanej przypisanej przez użytkownika.

    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

    Uwaga

    Dzięki obecności TriggerAuthentication, KEDA będzie mogła uwierzytelniać się przy użyciu tożsamości obciążenia. Zasobniki keda-operator używają polecenia identityId do uwierzytelniania względem zasobów platformy Azure podczas oceniania wyzwalaczy skalowania.

Publikowanie komunikatów w usłudze Azure Service Bus

W tym momencie wszystko jest skonfigurowane do skalowania przy użyciu KEDA i Microsoft Entra Workload Identity. Przetestujemy to, wdrażając obciążenia producentów i konsumentów.

  1. Utwórz nowe konto usługi dla zadań.

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

  2. Wdróż zadanie, aby opublikować 100 komunikatów.

    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

Korzystanie z komunikatów z usługi Azure Service Bus

Po opublikowaniu komunikatów w kolejce usługi Azure Service Bus wdrożymy obiekt ScaledJob w celu korzystania z komunikatów. To zadanie ScaledJob będzie używać zasobu KEDA TriggerAuthentication do uwierzytelniania w kolejce usługi Azure Service Bus przy użyciu tożsamości zadania i skalowania poziomego co 10 komunikatów.

  1. Wdróż zasób ScaledJob, aby przetwarzać komunikaty. Wyzwalacz skalowania zostanie skonfigurowany, aby zwiększać skalę po każdych 10 komunikatach. Program skalowania KEDA utworzy 10 zadań do korzystania z 100 komunikatów.

    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

    Uwaga

    Zadanie ScaledJob tworzy zasób zadania Kubernetes za każdym razem, gdy wystąpi zdarzenie skalowania, w związku z czym szablon zadania musi zostać przekazany podczas tworzenia zasobu. Po utworzeniu nowych zadań zasobniki będą wdrażane z bitami tożsamości obciążenia w celu korzystania z komunikatów.

  2. Sprawdź, czy skalowanie KEDA działało zgodnie z oczekiwaniami.

    kubectl describe scaledjob myconsumer-scaledjob

  3. Powinny zostać wyświetlone zdarzenia podobne do poniższych.

    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

Czyszczenie zasobów

Po sprawdzeniu, czy wdrożenie zakończy się pomyślnie, możesz wyczyścić zasoby, aby uniknąć ponoszenia kosztów platformy Azure.

  1. Usuń grupę zasobów platformy Azure i wszystkie zasoby w niej przy użyciu polecenia [az group delete][az-group-delete].

    az group delete --name $RG_NAME --yes --no-wait

Następne kroki

W tym artykule pokazano, jak bezpiecznie skalować swoje aplikacje przy użyciu dodatku KEDA oraz tożsamości obciążenia w usłudze AKS.

Aby uzyskać informacje na temat rozwiązywania problemów z usługą KEDA, zobacz Rozwiązywanie problemów z dodatkiem Kubernetes Event-driven Autoscaling (KEDA).

Aby dowiedzieć się więcej na temat KEDA, zobacz dokumentację źródłową KEDA.

  • Last updated on