Быстрый старт: Развертывание Шлюза приложений для ALB-контроллера контейнеров

Статья
2025-04-03

Контроллер ALB отвечает за преобразование конфигурации Gateway API и Ingress API в Kubernetes в правила балансировки нагрузки в Application Gateway для контейнеров. В следующем руководстве описаны шаги, необходимые для подготовки контроллера подсистемы балансировки нагрузки в новый или существующий кластер Службы Azure Kubernetes (AKS).

Предварительные условия

Перед развертыванием Application Gateway для контейнеров в Azure и установки контроллера ALB в вашем кластере необходимо выполнить следующие задачи:

Подготовьте подписку Azure и вашего клиента 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

Задайте кластер AKS для рабочей нагрузки.

Примечание.

Кластер AKS должен находиться в регионе, где шлюз приложений для контейнеров доступен кластер AKS, должен использовать Azure CNI или Наложение Azure CNI. Кластер AKS должен включать функцию идентификации рабочей нагрузки. Узнайте, как включить идентификацию рабочей нагрузки на уже существующем кластере AKS.

Если используется существующий кластер, убедитесь, что вы включили поддержку Workload Identity в кластере AKS. Идентификаторы рабочей нагрузки можно включить с помощью следующих команд:
```
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
```
Если у вас нет существующего кластера, используйте следующие команды, чтобы создать новый кластер AKS с включенной идентификацией azure CNI и рабочей нагрузки.
```
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
```
Установка Helm

Helm — это средство упаковки с открытым исходным кодом, которое используется для установки контроллера балансировки нагрузки.

Примечание.

Helm уже доступен в Azure Cloud Shell. Если вы используете Azure Cloud Shell, дополнительная установка Helm не требуется.

Вы также можете выполнить следующие действия, чтобы установить Helm на локальном устройстве под управлением Windows или Linux. Убедитесь, что у вас установлена последняя версия Helm.
- Windows
- Linux
См. инструкции по установке для различных способов установки. Аналогичным образом, если в вашей версии Windows установлен Диспетчер пакетов Windows winget, можно выполнить следующую команду:
```
winget install helm.helm
```
Следующая команда может использоваться для установки Helm. Команды, использующие Helm с Azure CLI в этой статье, также могут выполняться с помощью Bash.
```
curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash
```

Установка контроллера ALB

Создайте пользовательскую управляемую идентичность для контроллера ALB и интегрируйте эту идентичность в качестве идентичности рабочей нагрузки для использования в кластере AKS.

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"

Контроллер ALB требует федеративные учетные данные под названием azure-alb-identity. Любое другое федеративное имя учетных данных не поддерживается.

Примечание.

Назначение управляемого удостоверения сразу после создания может привести к ошибке, указывающей, что principalId не существует. Разрешите около минуты, чтобы учётная запись была реплицирована в Microsoft Entra ID, прежде чем делегировать её.

Установка контроллера ALB с помощью Helm

Для новых развертываний

Чтобы установить контроллер ALB, используйте helm install команду.

helm install Когда выполняется команда, она развертывает helm-чарт в пространстве имен по умолчанию. При развертывании контроллера alb-controller он развертывается в пространстве имен azure-alb-system . Обе эти пространства имен могут быть переопределены независимо друг от друга по мере необходимости. Чтобы переопределить пространство имен, в которое развертывается диаграмма helm, можно указать параметр --namespace (или -n). Чтобы переопределить пространство имен azure-alb-system, используемое контроллером, можно задать свойство albController.namespace во время установки (--set albController.namespace). Если ни параметры --namespace, ни --set albController.namespace не определены, используется пространство имен по умолчанию для диаграммы helm, а пространство имен azure-alb-system используется для компонентов контроллера ALB. Наконец, если пространство имен для ресурса диаграммы helm еще не определено, удостоверьтесь в том, что параметр --create-namespace также указан вместе с параметром --namespace или параметрами -n.

Контроллер ALB можно установить, выполнив следующие команды:
```
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.5.2 \
     --set albController.namespace=$CONTROLLER_NAMESPACE \
     --set albController.podIdentity.clientID=$(az identity show -g $RESOURCE_GROUP -n azure-alb-identity --query clientId -o tsv)
```
Для существующих развертываний

ALB можно обновить, выполнив следующие команды:

Примечание.

Во время обновления укажите параметры --namespace или --set albController.namespace, если пространства имен были переопределены в предыдущей установке. Чтобы определить предыдущие пространства имен, можно выполнить helm list команда для пространства имен Helm и kubectl get pod -A -l app=alb-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.5.2 \
    --set albController.namespace=$CONTROLLER_NAMESPACE \
    --set albController.podIdentity.clientID=$(az identity show -g $RESOURCE_GROUP -n azure-alb-identity --query clientId -o tsv)
```

Проверка установки контроллера балансировки нагрузки

Убедитесь, что поды контроллера ALB готовы.

kubectl get pods -n azure-alb-system

Вы увидите следующие выходные данные:

ИМЯ	ГОТОВО	СОСТОЯНИЕ	ВОЗРАСТ
alb-controller-bootstrap-6648c5d5c-hrmpc	1/1	Бег	4д6ч
alb-controller-6648c5d5c-sdd9t	1/1	Бег	4д6ч
alb-controller-6648c5d5c-au234	1/1	Бег	4д6ч

Убедитесь, что ШлюзКласс azure-application-lb установлен в кластере:
```
kubectl get gatewayclass azure-alb-external -o yaml
```
Вы увидите, что класс Gateway имеет условие, которое гласит Допустимый класс Gateway. Это условие указывает, что класс шлюза по умолчанию настроен и что все ресурсы шлюза, ссылающиеся на этот класс шлюза, автоматически управляются контроллером 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
```

Следующие шаги

После успешной установки ALB-контроллера в кластере можно подготовить ресурсы шлюза приложений для контейнеров в Azure.

Следующим шагом является связывание контроллера ALB с Шлюзом приложений для контейнеров. Создание этой ссылки зависит от стратегии развертывания.

Существует две стратегии развертывания для управления Шлюзом приложений для контейнеров:

Собственное развертывание (BYO): в этой стратегии развертывания развертывание и жизненный цикл ресурса Шлюза приложений для контейнеров, ресурса ассоциации и ресурса внешнего интерфейса осуществляются через портал Azure, CLI, PowerShell, Terraform и т. д. и указываются в конфигурации в Kubernetes.
- Сведения об использовании развертывания BYO см. в статье "Создание Шлюз приложений для контейнеров" — создание собственного развертывания
Управляется контроллером ALB: В этой стратегии развертывания контроллер ALB, развернутый в Kubernetes, отвечает за жизненный цикл ресурса Шлюза приложений для контейнеров и его вложенных ресурсов. Контроллер ALB создает шлюз приложений для контейнеров, когда в кластере определяется настраиваемый ресурс ApplicationLoadBalancer. Жизненный цикл службы основан на жизненном цикле пользовательского ресурса.
- Сведения об использовании управляемого развертывания ALB см. в статье "Создание Шлюз приложений для контейнеров, управляемых контроллером ALB"

Удаление шлюза приложений для контейнеров и контроллера ALB

Если вы хотите удалить контроллер ALB, выполните следующие действия.

Удалите Шлюз приложений для контейнеров, вы можете удалить группу ресурсов, содержащую Шлюз приложений для ресурсов контейнеров:

az group delete --resource-group $RESOURCE_GROUP

Удалите контроллер ALB и его ресурсы из кластера, выполнив следующие команды:

helm uninstall alb-controller
kubectl delete ns azure-alb-system
kubectl delete gatewayclass azure-alb-external

Примечание.

Если для установки alb-контроллера использовалось другое пространство имен, убедитесь, что в команде удаления helm укажете параметр -n, чтобы указать правильное пространство имен для использования. Например: helm uninstall alb-controller -n unique-namespace

Поделиться через

Быстрый старт: Развертывание Шлюза приложений для ALB-контроллера контейнеров

Предварительные условия

Установка контроллера ALB

Для новых развертываний

Для существующих развертываний

Проверка установки контроллера балансировки нагрузки

Следующие шаги

Удаление шлюза приложений для контейнеров и контроллера ALB

Обратная связь

Дополнительные ресурсы