Condividi tramite


Guida introduttiva: Distribuire gateway applicazione per contenitori per il controller ALB

Il controller ALB è responsabile della conversione della configurazione dell'API gateway e dell'API in ingresso all'interno di Kubernetes in regole di bilanciamento del carico all'interno del gateway applicativo per contenitori. La guida seguente illustra i passaggi necessari per effettuare il provisioning di un controller ALB in un cluster del servizio Azure Kubernetes nuovo o esistente.

Prerequisiti

È necessario completare le attività seguenti prima di distribuire il gateway applicativo per contenitori in Azure e installare il controller ALB nel cluster:

  1. Preparare la sottoscrizione di Azure e il client az-cli.

    # Sign in to your Azure subscription.
    SUBSCRIPTION_ID='<your subscription id>'
    az login
    az account set --subscription $SUBSCRIPTION_ID
    
    # Register required resource providers on Azure.
    az provider register --namespace Microsoft.ContainerService
    az provider register --namespace Microsoft.Network
    az provider register --namespace Microsoft.NetworkFunction
    az provider register --namespace Microsoft.ServiceNetworking
    
    # Install Azure CLI extensions.
    az extension add --name alb
    
  2. Impostare un cluster del servizio Azure Kubernetes per il carico di lavoro.

    Nota

    Il cluster del servizio Azure Kubernetes deve risiedere in un'area in cui è disponibile il gateway applicativo per contenitori e il cluster del servizio Azure Kubernetes deve usare Azure CNI. La funzionalità di identità del carico di lavoro deve essere abilitata nel cluster del servizio Azure Kubernetes. Informazioni su come abilitare l'identità del carico di lavoro in un cluster del servizio Azure Kubernetes esistente.

    Se si usa un cluster esistente, assicurarsi di abilitare il supporto dell'identità del carico di lavoro nel cluster del servizio Azure Kubernetes. Le identità del carico di lavoro possono essere abilitate come indicato di seguito:

    AKS_NAME='<your cluster name>'
    RESOURCE_GROUP='<your resource group name>'
    az aks update -g $RESOURCE_GROUP -n $AKS_NAME --enable-oidc-issuer --enable-workload-identity --no-wait
    

    Se non è presente un cluster esistente, usare i comandi seguenti per creare un nuovo cluster del servizio Azure Kubernetes con Azure CNI e l'identità del carico di lavoro abilitata.

    AKS_NAME='<your cluster name>'
    RESOURCE_GROUP='<your resource group name>'
    LOCATION='northeurope'
    VM_SIZE='<the size of the vm in AKS>' # The size needs to be available in your location
    
    az group create --name $RESOURCE_GROUP --location $LOCATION
    az aks create \
        --resource-group $RESOURCE_GROUP \
        --name $AKS_NAME \
        --location $LOCATION \
        --node-vm-size $VM_SIZE \
        --network-plugin azure \
        --enable-oidc-issuer \
        --enable-workload-identity \
        --generate-ssh-key
    
  3. Installare Helm

    Helm è uno strumento di creazione pacchetti open source usato per installare il controller ALB.

    Nota

    Helm è già disponibile in Azure Cloud Shell. Se si usa Azure Cloud Shell, non è necessaria alcuna installazione aggiuntiva per Helm.

    È anche possibile usare la procedura seguente per installare Helm in un dispositivo locale che esegue Windows o Linux. Assicurarsi che sia installata la versione più recente di Helm.

    Vedere le istruzioni per l'installazione per varie opzioni di installazione. Analogamente, se nella versione di Windows è installato lo strumento winget Windows Package Manager, è possibile eseguire il comando seguente:

    winget install helm.helm
    

Installare il controller ALB

  1. Creare un'identità gestita dall'utente per il controller ALB e federate l'identità come identità del carico di lavoro da usare nel cluster del servizio Azure Kubernetes.

    RESOURCE_GROUP='<your resource group name>'
    AKS_NAME='<your aks cluster name>'
    IDENTITY_RESOURCE_NAME='azure-alb-identity'
    
    mcResourceGroup=$(az aks show --resource-group $RESOURCE_GROUP --name $AKS_NAME --query "nodeResourceGroup" -o tsv)
    mcResourceGroupId=$(az group show --name $mcResourceGroup --query id -otsv)
    
    echo "Creating identity $IDENTITY_RESOURCE_NAME in resource group $RESOURCE_GROUP"
    az identity create --resource-group $RESOURCE_GROUP --name $IDENTITY_RESOURCE_NAME
    principalId="$(az identity show -g $RESOURCE_GROUP -n $IDENTITY_RESOURCE_NAME --query principalId -otsv)"
    
    echo "Waiting 60 seconds to allow for replication of the identity..."
    sleep 60
    
    echo "Apply Reader role to the AKS managed cluster resource group for the newly provisioned identity"
    az role assignment create --assignee-object-id $principalId --assignee-principal-type ServicePrincipal --scope $mcResourceGroupId --role "acdd72a7-3385-48ef-bd42-f606fba81ae7" # Reader role
    
    echo "Set up federation with AKS OIDC issuer"
    AKS_OIDC_ISSUER="$(az aks show -n "$AKS_NAME" -g "$RESOURCE_GROUP" --query "oidcIssuerProfile.issuerUrl" -o tsv)"
    az identity federated-credential create --name "azure-alb-identity" \
        --identity-name "$IDENTITY_RESOURCE_NAME" \
        --resource-group $RESOURCE_GROUP \
        --issuer "$AKS_OIDC_ISSUER" \
        --subject "system:serviceaccount:azure-alb-system:alb-controller-sa"
    

    Il controller ALB richiede credenziali federate con il nome azure-alb-identity. Tutti gli altri nomi di credenziali federate non sono supportati.

    Nota

    L'assegnazione dell'identità gestita immediatamente dopo la creazione può generare un errore che indica che principalId non esiste. Attendere circa un minuto per consentire la replica dell'identità in Microsoft Entra ID prima di delegare l'identità.

  2. Installare il controller ALB con Helm

    Per le nuove distribuzioni

    Per installare ALB Controller, usare il comando helm install.

    Quando viene eseguito il comando helm install, il grafico Helm viene distribuito nello spazio dei nomi predefinito. Il controller ALB viene distribuito nello spazio dei nomi azure-alb-system. È possibile eseguire l'override di entrambi questi spazi dei nomi in modo indipendente in base alle esigenze. Per eseguire l'override dello spazio dei nomi in cui viene distribuito il grafico Helm, è possibile specificare il parametro --namespace (o -n). Per eseguire l'override dello spazio dei nomi azure-alb-system usato dal controller ALB, è possibile impostare la proprietà albController.namespace durante l'installazione (--set albController.namespace). Se non vengono definiti i parametri --namespace o --set albController.namespace, viene usato lo spazio dei nomi predefinito per il grafico Helm e viene usato lo spazio dei nomi azure-alb-system per i componenti del controller ALB. Infine, se lo spazio dei nomi per la risorsa grafico Helm non è ancora definito, assicurarsi che sia specificato anche il parametro --create-namespace insieme ai parametri --namespace o -n.

    Il controller ALB può essere installato eseguendo i comandi seguenti:

    HELM_NAMESPACE='<namespace for deployment>'
    CONTROLLER_NAMESPACE='azure-alb-system'
    az aks get-credentials --resource-group $RESOURCE_GROUP --name $AKS_NAME
    helm install alb-controller oci://mcr.microsoft.com/application-lb/charts/alb-controller \
         --namespace $HELM_NAMESPACE \
         --version 1.3.7 \
         --set albController.namespace=$CONTROLLER_NAMESPACE \
         --set albController.podIdentity.clientID=$(az identity show -g $RESOURCE_GROUP -n azure-alb-identity --query clientId -o tsv)
    

    Per le distribuzioni esistenti

    Per aggiornare il controller ALB, eseguire i comandi seguenti:

    Nota

    Durante l'aggiornamento, assicurarsi di specificare i parametri --namespace o --set albController.namespace se gli spazi dei nomi sono stati sottoposti a override nell'installazione precedente. Per determinare gli spazi dei nomi precedenti usati, è possibile eseguire il comando helm list per lo spazio dei nomi Helm e kubectl get pod -A -l app=alb-controller per il controller ALB.

    HELM_NAMESPACE='<your cluster name>'
    CONTROLLER_NAMESPACE='azure-alb-system'
    az aks get-credentials --resource-group $RESOURCE_GROUP --name $AKS_NAME
    helm upgrade alb-controller oci://mcr.microsoft.com/application-lb/charts/alb-controller \
        --namespace $HELM_NAMESPACE \
        --version 1.3.7 \
        --set albController.namespace=$CONTROLLER_NAMESPACE \
        --set albController.podIdentity.clientID=$(az identity show -g $RESOURCE_GROUP -n azure-alb-identity --query clientId -o tsv)
    

Verificare l'installazione del controller ALB

  1. Verificare che i pod del controller ALB siano pronti:

    kubectl get pods -n azure-alb-system
    

    Dovrebbe essere visualizzata la seguente schermata:

    NOME READY STATO RIAVVII AGE
    alb-controller-bootstrap-6648c5d5c-hrmpc 1/1 In esecuzione 0 4d6h
    alb-controller-6648c5d5c-sdd9t 1/1 In esecuzione 0 4d6h
    alb-controller-6648c5d5c-au234 1/1 In esecuzione 0 4d6h
  2. Verificare che la classe GatewayClass azure-application-lb sia installata nel cluster:

    kubectl get gatewayclass azure-alb-external -o yaml
    

    Si noterà che GatewayClass ha una condizione che indica Valid GatewayClass. Questo indica che è stata configurata una classe GatewayClass predefinita e che tutte le risorse del gateway che fanno riferimento a questa classe GatewayClass vengono gestite automaticamente dal controller ALB.

    apiVersion: gateway.networking.k8s.io/v1beta1
    kind: GatewayClass
    metadata:
      creationTimestamp: "2023-07-31T13:07:00Z"
      generation: 1
      name: azure-alb-external
      resourceVersion: "64270"
      uid: 6c1443af-63e6-4b79-952f-6c3af1f1c41e
    spec:
      controllerName: alb.networking.azure.io/alb-controller
    status:
      conditions:
        - lastTransitionTime: "2023-07-31T13:07:23Z"
        message: Valid GatewayClass
        observedGeneration: 1
        reason: Accepted
        status: "True"
        type: Accepted
    

Passaggi successivi

Dopo aver installato un controller ALB nel cluster, è possibile effettuare il provisioning delle risorse Gateway applicativo per contenitori in Azure.

Il passaggio successivo consiste nel collegare il controller ALB al Gateway applicativo per contenitori. La modalità di creazione di questo collegamento dipende dalla strategia di distribuzione.

Esistono due strategie di distribuzione per la gestione di gateway applicazione per i contenitori:

  • Distribuzione personalizzata (BYO): in questa strategia di distribuzione, distribuzione e ciclo di vita delle risorse Gateway applicativo per contenitori, Associazione e Front-end viene usata tramite il portale di Azure, l'interfaccia della riga di comando, PowerShell, Terraform e così via e facendo riferimento nella configurazione all'interno di Kubernetes.
  • Gestito dal controller ALB: in questa strategia di distribuzione, il controller ALB distribuito in Kubernetes è responsabile del ciclo di vita della risorsa Gateway applicativo per contenitori e delle relative risorse secondarie. Il controller ALB crea la risorsa Gateway applicativo per contenitori quando una risorsa personalizzata ApplicationLoadBalancer viene definita nel cluster. Il ciclo di vita del servizio è basato sul ciclo di vita della risorsa personalizzata.

Disinstallare il Gateway applicativo per contenitori e il controller ALB

Per disinstallare il controller ALB, seguire questa procedura.

  1. Per eliminare il Gateway applicativo per contenitori, è possibile eliminare il gruppo di risorse contenente le risorse del Gateway applicativo per contenitori:
az group delete --resource-group $RESOURCE_GROUP
  1. Per disinstallare il controller ALB e le relative risorse dal cluster eseguire i comandi seguenti:
helm uninstall alb-controller
kubectl delete ns azure-alb-system
kubectl delete gatewayclass azure-alb-external

Nota

Se è stato usato uno spazio dei nomi diverso per l'installazione del controller ALB, assicurarsi di specificare il parametro -n nel comando helm uninstall per definire lo spazio dei nomi appropriato da usare. ad esempio helm uninstall alb-controller -n unique-namespace