Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Der ALB-Controller ist für die Übersetzung der Gateway-API- und Eingangs-API-Konfiguration innerhalb von Kubernetes in Lastenausgleichsregeln innerhalb von Application Gateway für Container zuständig. Im folgenden Leitfaden werden die Schritte erläutert, die erforderlich sind, um einen ALB-Controller in einem neuen oder vorhandenen Azure Kubernetes Service (AKS)-Cluster bereitzustellen.
Voraussetzungen
Sie müssen die folgenden Aufgaben ausführen, bevor Sie Application Gateway für Container in Azure bereitstellen und ALB Controller in Ihrem Cluster installieren:
Bereiten Sie Ihr Azure-Abonnement und Ihren
az-cli
-Client vor.# 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
Legen Sie einen AKS-Cluster für Ihre Workload fest.
Hinweis
Der AKS-Cluster muss sich in einer Region befinden, in der Anwendungsgateway für Container verfügbar ist; sollte der AKS-Cluster Azure CNI oder Azure CNI Overlay verwenden. Im AKS-Cluster sollte die Workloadidentitätsfunktion aktiviert sein. Erfahren Sie, wie Sie die Workloadidentität in einem vorhandenen AKS-Cluster aktivieren.
Achten Sie beim Verwenden eines vorhandenen Clusters darauf, die Workloadidentitätsunterstützung für Ihren AKS-Cluster zu aktivieren. Workloadidentitäten können über die folgenden Befehle aktiviert werden:
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
Wenn Sie nicht über einen vorhandenen Cluster verfügen, verwenden Sie die folgenden Befehle, um einen neuen AKS-Cluster mit aktiviertem Azure CNI und aktivierter Workloadidentität zu erstellen.
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
Installieren von Helm
Helm ist ein Open-Source-Pakettool, das zum Installieren des ALB-Controllers verwendet wird.
Hinweis
Helm ist bereits in Azure Cloud Shell verfügbar. Wenn Sie Azure Cloud Shell verwenden, ist keine zusätzliche Helm-Installation erforderlich.
Sie können außerdem die folgenden Schritte ausführen, um Helm auf einem lokalen Gerät unter Windows oder Linux zu installieren. Vergewissern Sie sich, dass die aktuelle Version von Helm installiert ist.
Verschiedene Installationsoptionen finden Sie in den Installationsanweisungen. Analog dazu können Sie den folgenden Befehl ausführen, wenn in Ihrer Windows-Version Windows-Paket-Manager Winget installiert ist:
winget install helm.helm
Installieren des ALB-Controllers
Erstellen Sie eine benutzerverwaltete Identität für den ALB-Controller und stellen Sie die Identität als Workloadidentität zusammen, die im AKS-Cluster verwendet werden soll.
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"
Der ALB-Controller erfordert Verbundanmeldeinformationen mit dem Namen
azure-alb-identity
. Alle anderen Namen von Verbundanmeldeinformationen werden nicht unterstützt.Hinweis
Die Zuweisung der verwalteten Identität unmittelbar nach der Erstellung kann zu einem Fehler führen, dass die principalId nicht vorhanden ist. Lassen Sie etwa eine Minute verstreichen, damit die Identität in Microsoft Entra ID repliziert werden kann, bevor Sie sie delegieren.
Installieren des ALB-Controllers mithilfe von Helm
Für neue Bereitstellungen
Verwenden Sie zum Installieren des ALB-Controllers den Befehl
helm install
.Wenn der Befehl
helm install
ausgeführt wird, wird das Helm-Diagramm im Standardnamespace bereitgestellt. Wenn Alb-Controller bereitgestellt wird, wird er imazure-alb-system
Namespace bereitgestellt. Beide Namespaces können je nach Wunsch unabhängig überschrieben werden. Um den Namespace zu überschreiben, in dem das Helm-Diagramm bereitgestellt wird, können Sie den Parameter „--namespace“ (oder „-n“) angeben. Um den von alb-controller verwendeten Namespaceazure-alb-system
zu überschreiben, können Sie die Eigenschaft „albController.namespace“ während der Installation festlegen (--set albController.namespace
). Wenn weder die--namespace
- noch die--set albController.namespace
-Parameter definiert sind, wird der default-Namespace für das Helm-Chart verwendet, und derazure-alb-system
-Namespace wird für die ALB-Controller-Komponenten verwendet. Wenn der Namespace für die Ressource des Helm-Diagramms noch nicht definiert ist, stellen Sie sicher, dass der Parameter--create-namespace
auch zusammen mit den Parametern--namespace
oder-n
angegeben wird.Der ALB-Controller kann mithilfe der folgenden Befehle installiert werden:
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.6.7 \ --set albController.namespace=$CONTROLLER_NAMESPACE \ --set albController.podIdentity.clientID=$(az identity show -g $RESOURCE_GROUP -n azure-alb-identity --query clientId -o tsv)
Für vorhandene Bereitstellungen
Für ALB kann ein Upgrade durchgeführt werden, indem Sie die folgenden Befehle ausführen:
Hinweis
Stellen Sie beim Upgrade sicher, dass Sie die Parameter
--namespace
oder--set albController.namespace
angeben, wenn die Namespaces in der zuvor installierten Installation überschrieben wurden. Um die zuvor verwendeten Namespaces zu ermitteln, können Sie den Befehlhelm list
für den Helm-Namespace undkubectl get pod -A -l app=alb-controller
für den ALB-Controller ausführen.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.6.7 \ --set albController.namespace=$CONTROLLER_NAMESPACE \ --set albController.podIdentity.clientID=$(az identity show -g $RESOURCE_GROUP -n azure-alb-identity --query clientId -o tsv)
Überprüfen der Installation des ALB-Controllers
Überprüfung, ob die ALB Controller-Pods bereit sind:
kubectl get pods -n azure-alb-system
Ihnen sollte die folgende Ausgabe angezeigt werden:
NAME BEREIT STATUS NEUSTARTS Alter alb-controller-bootstrap-6648c5d5c-hrmpc 1/1 Wird ausgeführt 0 4 Tage, 6 Stunden alb-controller-6648c5d5c-sdd9t 1/1 Wird ausgeführt 0 4 Tage, 6 Stunden alb-controller-6648c5d5c-au234 1/1 Wird ausgeführt 0 4 Tage, 6 Stunden Überprüfen Sie, ob GatewayClass
azure-application-lb
in Ihrem Cluster installiert ist:kubectl get gatewayclass azure-alb-external -o yaml
Sie sollten sehen, dass die GatewayClass über eine Bedingung verfügt, die Valid GatewayClass lautet. Diese Bedingung gibt an, dass eine Standardmäßige GatewayClass eingerichtet ist und alle Gatewayressourcen, die auf diese GatewayClass verweisen, automatisch vom ALB-Controller verwaltet werden.
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
Nächste Schritte
Nachdem Sie nun erfolgreich einen ALB-Controller in Ihrem Cluster installiert haben, können Sie die Application Gateway für Container-Ressourcen in Azure bereitstellen.
Der nächste Schritt besteht darin, Ihren ALB-Controller mit Application Gateway für Container zu verknüpfen. Wie Sie diese Verknüpfung erstellen, hängt von Ihrer Bereitstellungsstrategie ab.
Es gibt zwei Bereitstellungsstrategien für die Verwaltung von Application Gateway für Container:
-
Bring Your Own Deployment (BYOD): Bei dieser Bereitstellungsstrategie werden Bereitstellung und Lebenszyklus der Ressourcen für Application Gateway für Container sowie der Ressourcen für Zuordnungen und Front-End über Azure-Portal, CLI, PowerShell, Terraform usw. als korrekt angenommen, und in der Konfiguration in Kubernetes wird darauf verwiesen.
- Informationen zur Verwendung einer BYO-Bereitstellung finden Sie unter Erstellen von Application Gateway für Container – Bring Your Own Deployment.
-
Vom ALB-Controller verwaltet: Bei dieser Bereitstellungsstrategie ist der in Kubernetes bereitgestellte ALB-Controller für den Lebenszyklus der Application Gateway für Container-Ressourcen und deren untergeordnete Ressourcen zuständig. Der ALB-Controller erstellt eine Application Gateway für Container-Ressource, wenn eine benutzerdefinierte ApplicationLoadBalancer-Ressource im Cluster definiert ist. Der Dienstlebenszyklus basiert auf dem Lebenszyklus der benutzerdefinierten Ressource.
- Informationen zur Verwendung einer vom ALB verwalteten Bereitstellung finden Sie unter Anwendungsgateway für Container erstellen, verwaltet vom ALB-Controller.
Deinstallieren von Application Gateway für Container und ALB-Controllern
Wenn Sie den ALB-Controller deinstallieren möchten, führen Sie die folgenden Schritte aus.
Zum Löschen der Application Gateway für Container können Sie die Ressourcengruppe löschen, die die Application Gateway für Containerressourcen enthält:
az group delete --resource-group $RESOURCE_GROUP
Führen Sie zum Deinstallieren des ALB-Controllers und der zugehörigen Ressourcen aus Ihrem Cluster die folgenden Befehle aus:
helm uninstall alb-controller kubectl delete ns azure-alb-system kubectl delete gatewayclass azure-alb-external
Hinweis
Wenn für die Installation des ALB-Controllers ein anderer Namespace verwendet wurde, achten Sie darauf, im Deinstallationsbefehl von Helm den Parameter -n anzugeben, um den zu verwendenden richtigen Namespace zu definieren. Beispiel: helm uninstall alb-controller -n unique-namespace