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:
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
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
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
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à.
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='<your cluster name>' 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.0.2 \ --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 comandohelm list
per lo spazio dei nomi Helm ekubectl 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.0.2 \ --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
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 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.
- Per usare una distribuzione personalizzata (Bring Your Own Deployment), vedere Creare un gateway applicativo per contenitori - Bring Your Own Deployment
- 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.
- Per usare una distribuzione gestita da ALB, vedere Creare un Gateway applicativo per contenitori gestito dal controller ALB
Disinstallare il Gateway applicativo per contenitori e il controller ALB
Per disinstallare il controller ALB, seguire questa procedura.
- 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
- 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
Commenti e suggerimenti
https://aka.ms/ContentUserFeedback.
Presto disponibile: Nel corso del 2024 verranno gradualmente disattivati i problemi di GitHub come meccanismo di feedback per il contenuto e ciò verrà sostituito con un nuovo sistema di feedback. Per altre informazioni, vedereInvia e visualizza il feedback per