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

Использование нескольких подсистем балансировки нагрузки в службе Azure Kubernetes (предварительная версия)

Служба Azure Kubernetes (AKS) обычно подготавливает одну стандартную подсистему балансировки нагрузки (SLB) для всех LoadBalancer служб в кластере. Так как каждый сетевой адаптер узла ограничен 300 правилами балансировки нагрузки входящего трафика и 8 служб приватного канала, крупные кластеры или рабочие нагрузки с большим количеством портов могут быстро исчерпать эти ограничения.

Многократная предварительная версия SLB устраняет узкие места, позволяя создавать несколько SLB в одном кластере и распределять узлы и Сервисы между ними. Вы определяете конфигурации балансировщика нагрузки, каждая из которых привязана к основному пулу агентов и к необязательным пространствам имен, меткам или селекторам узлов, при этом AKS автоматически размещает узлы и службы на соответствующем балансировщике нагрузки. Поведение исходящего SNAT не изменяется, если outboundTypeloadBalancer. Исходящий трафик по-прежнему проходит через первый SLB.

Используйте эту функцию для:

  • Масштабируйте свыше 300 входящих правил без добавления кластеров.
  • Изоляция трафика клиента или рабочей нагрузки путем привязки выделенной подсистемы балансировки нагрузки к собственному пулу агентов.
  • Распределяйте службы с приватным подключением между несколькими системами балансировки нагрузки (SLB) при приближении к ограничению на балансировку нагрузки.

Предпосылки

  • aks-preview extension 18.0.0b1 или более поздней версии.
  • Зарегистрирован флаг Microsoft.ContainerService/MultipleStandardLoadBalancersPreview компонента подписки.
  • Kubernetes версии 1.28 или более поздней.
  • Кластер создан с --load-balancer-backend-pool-type nodeIP, или обновлён и существует кластер с az aks update.

Установите расширение Azure CLI aks-preview

Это важно

Предварительные версии функций AKS доступны на условиях самообслуживания и добровольного выбора. Предварительные версии предоставляются "как есть" и "при наличии". На них не распространяются соглашения об уровне обслуживания и ограниченная гарантия. Предварительные версии AKS сопровождаются частичной поддержкой клиентов на основе принципа лучших усилий. Как таковые, эти функции не предназначены для использования в производстве. Для получения дополнительной информации ознакомьтесь со следующими статьями поддержки:

  • Установите расширение aks-preview с помощью az extension add команды.

    az extension add --name aks-preview

  • Обновите до последней версии расширения, выпущенной с использованием команды az extension update.

    az extension update --name aks-preview

Регистрация флага компонента MultipleStandardLoadBalancersPreview

  1. Зарегистрируйте флаг функции MultipleStandardLoadBalancersPreview с помощью команды az feature register.

    az feature register --namespace "Microsoft.ContainerService" --name "MultipleStandardLoadBalancersPreview"

    Через несколько минут отобразится состояние Registered (Зарегистрировано).

  2. Проверьте состояние регистрации с помощью az feature show команды:

    az feature show --namespace "Microsoft.ContainerService" --name "MultipleStandardLoadBalancersPreview"

  3. Когда состояние отражает зарегистрировано, обновите регистрацию поставщика ресурсов Microsoft.ContainerService с помощью az provider register команды.

    az provider register --namespace Microsoft.ContainerService

Как AKS выбирает подсистему балансировки нагрузки (размещение узлов и служб)

AKS использует несколько входных данных для определения места узлов и предоставления служб LoadBalancer. Эти входные данные определяются в каждой конфигурации подсистемы балансировки нагрузки и влияют на выбор SLB для каждого ресурса.

Тип входных данных Применимо к Описание
Пул первичных агентов
--primary-agent-pool-name		 Узлы Обязательное. Все узлы в этом пуле всегда добавляются в серверный пул SLB. Гарантирует, что каждый SLB имеет по крайней мере один работоспособный узел.
Селектор узлов
--node-selector		 Узлы Необязательно. Добавляет любой узел с соответствующими метками в SLB в дополнение к основному пулу.
Селектор пространства имен службы
--service-namespace-selector		 Услуги Необязательно. Для этого SLB рассматриваются только службы в пространствах имен с соответствующими метками.
Селектор меток службы
--service-label-selector		 Услуги Необязательно. Только службы с соответствующими метками имеют право использовать этот SLB.
Заметка службы
service.beta.kubernetes.io/azure-load-balancer-configurations		 Услуги Необязательно. Ограничивает размещение одной или нескольких явно именованных конфигураций SLB. Без него любая соответствующая конфигурация может быть использована.

Замечание

Селекторы определяют допустимость. Аннотация (если используется) ограничивает контроллер определенным подмножеством SLB.

Как AKS использует эти входные данные

Плоскость управления AKS постоянно согласовывает узлы и состояние службы с помощью приведенных выше правил:

Размещение узла

При добавлении или обновлении узла AKS проверяет, какие подходящие стандартные балансировщики нагрузки (SLB) соответствуют на основе первичного пула и селектора узлов.

  • Если совпадает несколько SLB, контроллер выбирает тот с меньшим количеством текущих узлов.
  • Узел добавляется в серверный пул SLB.

Размещение служб

При создании или обновлении службы LoadBalancer:

  1. AKS находит SLB, пространство имен и селекторы меток которых соответствуют службе.
  2. Если аннотация службы присутствует, рассматриваются только те именованные SLBs.
  3. SLBs, имеющие allowServicePlacement=false или превышающие ограничения Azure (300 правил или 8 служб Private Link) исключаются.
  4. Среди допустимых опций выбирается SLB с меньшим количеством правил.

Поведение параметра externalTrafficPolicy (ETP)

AKS обрабатывает службы по-разному в зависимости от значения externalTrafficPolicy.

Режим Как работает выбор подсистемы балансировки нагрузки Как формируется членство в серверном пуле Примечания.
Кластер (по умолчанию) Контроллер следует стандартным правилам размещения, описанным выше. Одно правило балансировки нагрузки предназначено для общего серверного пула Kubernetes на выбранном SLB. Все узлы в пуле SLB kubernetes являются здоровыми целевыми объектами. Узлы без сопоставления модулей Pod автоматически удаляются пробами работоспособности. То же поведение, что и сегодня в кластерах с одной подсистемой балансировки нагрузки.
Локальная среда Контроллер по-прежнему использует алгоритм на основе селектора для выбора SLB, но создает выделенный внутренний пул для каждой службы вместо использования общего пула. Членство синхронизируется с объектами EndpointSlice службы, поэтому добавляются только узлы, которые действительно участвуют в размещении готовых подов. Проверки работоспособности продолжают использовать healthCheckNodePort, чтобы отключать неработоспособные узлы. Гарантирует сохранение IP-адресов клиента и избегает маршрутизации через узлы, которые не имеют модулей Pod, даже если узлы сегментируются по нескольким SLB.

Почему выделенный пул для ETP Local?
В режиме множественных SLB узлы, размещающие Pods для данной службы, могут находиться на разных SLB по сравнению с виртуальным IP-адресом, ориентированным на клиента. Общий серверный пул часто содержит ноль подходящих узлов, что приводит к сбоям в работе трафика. Выделяя пул служб и синхронизируя его из EndpointSlice, AKS гарантирует, что подсистема балансировки нагрузки службы всегда указывает на правильные узлы.

Влияние на квоты

  • Каждая локальная служба ETP добавляет один пул серверов и одно правило балансировки нагрузки в свой SLB.
  • Эти правила засчитываются в ограничение на 300 правил, поэтому отслеживайте их расходование при наличии большого количества локальных служб ETP.

Нет изменений в исходящем трафике

Исходящий SNAT по-прежнему выполняется через первый SLB aksOutboundBackendPooloutboundTypeloadBalancer, независимо от параметров ETP.

Необязательно. Перебалансирование

Вы можете повторно сбалансировать распределение узлов вручную позже с помощью az aks loadbalancer rebalance.

Эта конструкция позволяет определять гибкую маршрутизацию на основе меток как для инфраструктуры, так и для рабочих нагрузок, а AKS автоматически обрабатывает размещение, чтобы поддерживать баланс и избежать проблем с квотами.

Добавление первой конфигурации подсистемы балансировки нагрузки

Добавьте конфигурацию с именем kubernetes и привязать ее к основному пулу агентов , который всегда имеет по крайней мере один узел. Удаление всех конфигураций переключает кластер обратно в режим single‑SLB.

Это важно

Чтобы включить режим с несколькими подсистемами балансировки нагрузки , необходимо добавить конфигурацию kubernetes подсистемы балансировки нагрузки и подключить ее к основному пулу агентов, который всегда имеет по крайней мере один готовый узел.
Наличие этой конфигурации переключает поддержку мульти‑SLB; в выборе службы она не имеет особого приоритета и обрабатывается как любая другая конфигурация балансировщика нагрузки.
При удалении каждой конфигурации подсистемы балансировки нагрузки кластер автоматически возвращается в режим одноранговой балансировки нагрузки, что может кратко нарушить маршрутизацию служб или потоки SNAT.

  1. Задайте переменные среды для использования в этом руководстве. Вы можете заменить все значения заполнителей собственными, за исключением DEFAULT_LB_NAMEтого, что должно оставаться как kubernetes.

    RESOURCE_GROUP="rg-aks-multislb"
CLUSTER_NAME="aks-multi-slb"
LOCATION="westus"
DEFAULT_LB_NAME="kubernetes"
PRIMARY_POOL="nodepool1"

  2. Создайте группу az group create ресурсов с помощью команды.

    az group create --name $RESOURCE_GROUP --location $LOCATION

  3. Создайте кластер AKS с помощью az aks create команды.\

    az aks create --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME \
  --load-balancer-backend-pool-type nodeIP \
  --node-count 3

  4. Добавьте подсистему балансировки нагрузки по умолчанию с помощью az aks loadbalancer add команды.

    az aks loadbalancer add --resource-group $RESOURCE_GROUP --cluster-name $CLUSTER_NAME \
  --name $DEFAULT_LB_NAME \
  --primary-agent-pool-name $PRIMARY_POOL \
  --allow-service-placement true

Добавление дополнительных подсистем балансировки нагрузки

Создайте конфигурации для конкретного клиента, указав другой первичный пул, а также необязательные пространства имен, метки или селекторы узлов.

  1. Команда 1 будет запускать собственные рабочие нагрузки в отдельном пуле нод. tenant=team1 Назначьте метку, чтобы рабочие нагрузки могли быть запланированы с помощью селекторов:

    TEAM1_POOL="team1pool"
TEAM1_LB_NAME="team1-lb"

  2. Создайте второй пул узлов для команды 1 с помощью az aks nodepool add команды.

    az aks nodepool add --resource-group $RESOURCE_GROUP --cluster-name $CLUSTER_NAME \
  --name $TEAM1_POOL \
  --labels tenant=team1 \
  --node-count 2

  3. Создайте подсистему балансировки нагрузки для команды 1 с помощью az aks loadbalancer add команды.

    az aks loadbalancer add --resource-group $RESOURCE_GROUP --cluster-name $CLUSTER_NAME \
  --name $TEAM1_LB_NAME \
  --primary-agent-pool-name $TEAM1_POOL \
  --service-namespace-selector "tenant=team1" \
  --node-selector "tenant=team1"

  4. Обозначьте целевое пространство имен (например, team1-apps), чтобы сопоставить его с селектором с помощью команды az aks command invoke.

    az aks command invoke \
  --resource-group $RESOURCE_GROUP \
  --name $CLUSTER_NAME \
  --command "
kubectl create namespace team1-apps --dry-run=client -o yaml | kubectl apply -f -
kubectl label namespace team1-apps tenant=team1 --overwrite
"

  5. Теперь вы можете перечислить подсистемы балансировки нагрузки в кластере, чтобы просмотреть несколько конфигураций с помощью az aks loadbalancer list команды.

    az aks loadbalancer list --resource-group $RESOURCE_GROUP --cluster-name $CLUSTER_NAME --output table

    Пример выходных данных:

    AllowServicePlacement    ETag     Name        PrimaryAgentPoolName    ProvisioningState    ResourceGroup
-----------------------  -------  ----------  ----------------------  -------------------  ---------------
True                     <ETAG>   kubernetes  nodepool1               Succeeded            rg-aks-multislb
True                     <ETAG>   team1-lb    team1pool               Succeeded            rg-aks-multislb

Развертывание службы в определенной подсистеме балансировки нагрузки

Добавьте заметку service.beta.kubernetes.io/azure-load-balancer-configurations с разделенным запятыми списком имен конфигурации. Если аннотация не указана, контроллер выбирается автоматически.

az aks command invoke \
  --resource-group $RESOURCE_GROUP \
  --name $CLUSTER_NAME \
  --command "
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Service
metadata:
  name: lb-svc-1
  namespace: team1-apps
  labels:
    app: nginx-test
  annotations:
    service.beta.kubernetes.io/azure-load-balancer-configurations: \"team1-lb\"
    # service.beta.kubernetes.io/azure-load-balancer-internal: "true" # If you want to create an internal load balancer. 
spec:
  selector:
    app: nginx-test
  ports:
  - name: port1
    port: 80
    targetPort: 80
    protocol: TCP
  type: LoadBalancer
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-test
  namespace: team1-apps
  labels:
    app: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx-test
  template:
    metadata:
      labels:
        app: nginx-test
    spec:
      containers:
      - image: nginx
        imagePullPolicy: Always
        name: nginx
        ports:
        - containerPort: 80
          protocol: TCP
        resources:
          limits:
            cpu: \"150m\"
            memory: \"300Mi\"
EOF
"

Перебалансировать узлы (необязательно)

Выполните операцию перебалансирования после масштабирования, если количество правил становится несбалансировано с помощью az aks loadbalancer rebalance команды. Эта команда нарушает активные потоки, поэтому запланируйте его во время периода обслуживания.

az aks loadbalancer rebalance --resource-group $RESOURCE_GROUP --cluster-name $CLUSTER_NAME

Мониторинг и устранение неполадок

  • Проверьте события контроллера (kubectl get events …), чтобы убедиться, что службы согласованы.
  • Если внешнее подключение заблокировано, откройте оболочку узла и выполните curl для VIP службы, чтобы подтвердить маршрутизацию через kube-proxy.

Ограничения и известные проблемы

Ограничение Сведения
Исходящий SNAT Всегда использует первую подсистему балансировки нагрузки; Исходящие потоки не сегментированы.
Тип пула бэкенда Создание или обновление существующего кластера для использования nodeIP пулов серверов.
Автоматическое масштабирование до нуля Основной пул агентов не может масштабироваться до 0 узлов.
Рост правил ETP local Каждая служба ETP local использует собственное правило и внутренний пул, поэтому количество правил может увеличиваться быстрее, чем в cluster режиме.
Перебалансировка сбоев Удаление узла из внутреннего пула удаляет подключения в тестовом режиме. Планирование периодов обслуживания.
Время перезагрузки конфигурации После выполнения az aks loadbalancer изменения могут не вступить в силу сразу. Операция AKS завершается быстро, но на применение обновлений диспетчером облачных контроллеров может потребоваться больше времени. Подождите, пока событие EnsuredLoadBalancer подтвердит, что изменения активны.

Очистите ресурсы

Удалите группу ресурсов после завершения удаления кластера и подсистем балансировки нагрузки с помощью az group delete команды.

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

Дальнейшие шаги

Функция нескольких SLB помогает масштабировать и изолировать рабочие нагрузки на сетевом уровне, сохраняя простоту благодаря конфигурации, управляемой Azure. Дополнительные сведения см. в следующих ресурсах:

  • Last updated on