AKS(Azure Kubernetes Service)에서 KEDA 추가 기능 및 워크로드 ID를 사용하여 애플리케이션의 크기를 안전하게 조정하기

이 문서에서는 AKS(Azure Kubernetes Service)에서 KEDA(Kubernetes 이벤트 기반 자동 크기 조정) 추가 기능 및 워크로드 ID를 사용하여 애플리케이션의 크기를 안전하게 조정하는 방법을 보여 줍니다.

Important

클러스터 Kubernetes 버전은 AKS 클러스터에 설치될 KEDA 버전을 결정합니다. 각 AKS 버전에 매핑되는 KEDA 버전을 확인하려면 Kubernetes 구성 요소 버전 테이블의 AKS 관리되는 추가 기능 열을 참조하세요.

GA Kubernetes 버전의 경우 AKS는 테이블에 있는 해당 KEDA 부 버전을 완벽히 지원합니다. Kubernetes 미리 보기 버전과 최신 KEDA 패치 일부는 고객 지원팀에서 최선을 다해 지원합니다. 따라서 이러한 기능은 프로덕션 용도로 사용할 수 없습니다. 자세한 내용은 다음 지원 문서를 참조하세요.

• AKS 지원 정책
• Azure 지원 FAQ

시작하기 전에

• Azure 구독이 필요합니다. Azure 구독이 없는 경우 무료 계정을 만들 수 있습니다.
• Azure CLI를 설치해야 합니다.
• Kubernetes API 서버에 대한 액세스를 허용하도록 방화벽 규칙이 구성되어 있는지 확인합니다. 자세한 내용은 AKS(Azure Kubernetes Service) 클러스터에 대한 아웃바운드 네트워크 및 FQDN 규칙을 참조하세요.

리소스 그룹 만들기

• az group create 명령을 사용하여 리소스 그룹을 만듭니다. 자리 표시자 값을 사용자 고유의 값으로 바꿔야 합니다.

  LOCATION=<azure-region>
  RG_NAME=<resource-group-name>
  
  az group create --name $RG_NAME --location $LOCATION
  

AKS 클러스터 만들기

1. --enable-workload-identity, --enable-keda 및 --enable-oidc-issuer 플래그와 함께 az aks create 명령을 사용하여 KEDA 추가 기능, 워크로드 ID 및 OIDC 발급자를 사용하도록 설정된 AKS 클러스터를 만듭니다. 자리 표시자 값을 사용자 고유의 값으로 바꿔야 합니다.

   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. 배포가 성공했는지 확인하고 --query 플래그가 "[workloadAutoScalerProfile, securityProfile, oidcIssuerProfile]"로 설정된 az aks show 명령을 사용하여 클러스터에서 KEDA, 워크로드 ID 및 OIDC 발급자를 사용하도록 설정했는지 확인합니다.

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

3. az aks get-credentials 명령을 사용하여 클러스터에 연결합니다.

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

Azure Service Bus 만들기

1. az servicebus namespace create 명령을 사용하여 Azure Service Bus 네임스페이스를 만듭니다. 자리 표시자 값을 사용자 고유의 값으로 바꿔야 합니다.

   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. az servicebus queue create 명령을 사용하여 Azure Service Bus 큐를 만듭니다. 자리 표시자 값을 사용자 고유의 값으로 바꿔야 합니다.

   SB_QUEUE_NAME=<service-bus-queue-name>
   
   az servicebus queue create \
       --name $SB_QUEUE_NAME \
       --namespace $SB_NAME \
       --resource-group $RG_NAME
   

관리 ID 만들기

1. az identity create 명령을 사용하여 관리 ID를 만듭니다. 자리 표시자 값을 사용자 고유의 값으로 바꿔야 합니다.

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

2. --query 플래그가 oidcIssuerProfile.issuerUrl로 설정된 az aks show 명령을 사용하여 OIDC 발급자 URL을 가져옵니다.

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

3. az identity federated-credential create 명령을 사용하여 관리 ID와 워크로드에서 사용하는 네임스페이스 및 서비스 계정 간에 페더레이션 자격 증명을 만듭니다. 자리 표시자 값을 사용자 고유의 값으로 바꿔야 합니다.

   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. az identity federated-credential create 명령을 사용하여 keda-operator에서 사용하는 관리 ID와 네임스페이스 및 서비스 계정 간에 두 번째 페더레이션 자격 증명을 만듭니다. 자리 표시자 값을 사용자 고유의 값으로 바꿔야 합니다.

   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
   

역할 할당 만들기

1. --query 플래그가 "principalId"로 설정된 az identity show 명령을 사용하여 관리 ID의 개체 ID를 가져옵니다.

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

2. --query 플래그가 "id"로 설정된 az servicebus namespace show 명령을 사용하여 Service Bus 네임스페이스 리소스 ID를 가져옵니다.

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

3. az role assignment create 명령을 사용하여 관리 ID에 Azure Service Bus 데이터 소유자 역할을 할당합니다.

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

KEDA 연산자에서 워크로드 ID 사용

1. keda-operator ServiceAccount에 대한 페더레이션 자격 증명을 만든 후에는 keda-operator Pod를 수동으로 다시 시작하여 워크로드 ID 환경 변수가 Pod에 삽입되도록 해야 합니다.

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

2. keda-operator Pod 다시 시작 확인

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

3. keda-operator Pod의 롤링이 완료되었음을 확인하면 Ctrl+c를 눌러 이전 감시 명령을 중단한 다음 워크로드 ID 환경 변수가 삽입되었는지 확인합니다.

   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. 환경 아래에 다음과 유사한 출력이 표시됩니다.

   ---
   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. 사용자가 할당한 관리 ID의 클라이언트 ID를 포함하는 KEDA TriggerAuthentication 리소스를 배포합니다.

   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
   

   참고 항목

   TriggerAuthentication이 적용되면 KEDA는 워크로드 ID를 통해 인증할 수 있습니다. keda-operator Pod는 크기 조정 트리거를 평가할 때 identityId를 사용하여 Azure 리소스에 대해 인증합니다.

Azure Service Bus에 메시지 게시

이 시점에서 모든 항목은 KEDA 및 Microsoft Entra 워크로드 ID를 사용하여 크기 조정을 위해 구성됩니다. 생산자 및 소비자 워크로드를 배포하여 이를 테스트합니다.

1. 워크로드에 대한 새 ServiceAccount를 만듭니다.

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

2. 100 메시지를 게시하는 작업을 배포합니다.

   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
   

Azure Service Bus에서 메시지 사용

이제 Azure Service Bus 큐에 메시지를 게시했으므로 메시지를 사용하기 위해 ScaledJob을 배포할 예정입니다. 이 ScaledJob은 KEDA TriggerAuthentication 리소스를 사용하여 워크로드 ID를 사용하여 Azure Service Bus 큐에 대해 인증하고 메시지 10개마다 스케일 아웃합니다.

1. ScaledJob 리소스를 배포하여 메시지를 사용합니다. 크기 조정 트리거는 메시지 10개마다 규모를 확장하도록 구성됩니다. KEDA 스케일러는 10개의 작업을 만들어 100개의 메시지를 사용합니다.

   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
   

   참고 항목

   ScaledJob은 크기 조정 이벤트가 발생할 때마다 Kubernetes 작업 리소스를 만들므로 리소스를 만들 때 작업 템플릿을 전달해야 합니다. 새 작업이 만들어질 때 Pod는 메시지를 사용하기 위해 워크로드 ID 비트와 함께 배포됩니다.

2. KEDA 스케일러가 의도한 대로 작동하는지 확인합니다.

   kubectl describe scaledjob myconsumer-scaledjob
   

3. 다음과 유사한 이벤트가 표시됩니다.

   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
   

리소스 정리

배포가 성공했는지 확인한 후에는 리소스를 정리하여 Azure 비용이 발생하지 않도록 할 수 있습니다.

1. [az group delete][az-group-delete] 명령을 사용하여 Azure 리소스 그룹과 그 안에 있는 모든 리소스를 삭제합니다.

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

다음 단계

이 문서에서는 AKS에서 KEDA 추가 기능 및 워크로드 ID를 사용하여 애플리케이션의 크기를 안전하게 조정하는 방법을 보여 줍니다.

KEDA 문제 해결에 대한 자세한 내용은 KEDA(Kubernetes Event-driven Autoscaling) 부가기능 문제 해결을 참조하세요.

KEDA에 대한 자세한 내용은 업스트림 KEDA 문서를 참조하세요.