Настройка стандартного общедоступного балансировщика нагрузки в Azure Kubernetes Service (AKS)

Вы можете настроить различные параметры для стандартного общедоступного балансировщика нагрузки во время создания кластера или при его обновлении. Эти параметры настройки позволяют создать подсистему балансировки нагрузки, которая соответствует потребностям рабочей нагрузки. С помощью стандартной подсистемы балансировки нагрузки можно:

Измените тип входящего пула.
Задайте или масштабируйте число управляемых исходящих IP-адресов.
Укажите собственные пользовательские IP-адреса исходящего трафика или префикс исходящего IP-адреса.
Настройте количество выделенных исходящих портов для каждого узла в кластере.
Настройте параметр времени ожидания для неактивных подключений.

Это важно

Вы можете использовать только одну из следующих опций для исходящего IP-адреса одновременно: управляемые IP-адреса, собственный IP-адрес или префикс IP-адреса.

Перед тем как начать

Выполните действия, описанные в Использование общедоступного стандартного балансировщика нагрузки в Azure Kubernetes Service (AKS) для создания и развертывания службы балансировки нагрузки в AKS.

Изменение типа входящего пула

Вы можете ссылаться на узлы AKS в пулах серверной части балансировщика нагрузки по их IP-конфигурации (основанной на наборах масштабирования виртуальных машин Azure) или только по IP-адресу. Членство серверного пула на основе IP-адресов обеспечивает более высокую эффективность при обновлении служб и подготовке подсистем балансировки нагрузки, особенно при большом количестве узлов. При сочетании с шлюзом NAT или типами исходящего трафика, определяемым пользователем , подготовка новых узлов и служб является более производительной.

Доступны два разных типа членства в пуле:

nodeIPConfiguration: Устаревший тип членства в пуле для Масштабируемые наборы виртуальных машин с конфигурацией на основе IP.
nodeIP: тип членства на основе IP-адресов.

Требования к изменению типа входящего пула

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

Кластер AKS должен быть версии 1.23 или более поздней.
Кластер AKS должен использовать стандартные подсистемы балансировки нагрузки и Масштабируемые наборы виртуальных машин.

Создайте новый кластер AKS с членством в пуле IP-адресов для входящих подключений
Обновление существующего кластера AKS для использования членства входящего пула на основе IP-адресов

Создайте кластер AKS, используя команду az aks create с параметром --load-balancer-backend-pool-type=nodeIP, для членства во входящем пуле на основе IP-адресов.
```
az aks create \
    --resource-group $RESOURCE_GROUP \
    --name $CLUSTER_NAME \
    --load-balancer-backend-pool-type=nodeIP \
    --generate-ssh-keys
```

Предупреждение

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

Обновите существующий кластер AKS, чтобы использовать членство во входящем пуле на основе IP-адресов с помощью команды az aks update с параметром --load-balancer-backend-pool-type=nodeIP.
```
az aks update \
    --resource-group $RESOURCE_GROUP \
    --name $CLUSTER_NAME \
    --load-balancer-backend-pool-type=nodeIP
```

Масштабирование количества управляемых общедоступных исходящих IP-адресов

Azure Load Balancer обеспечивает исходящее и входящее подключение из виртуальной сети. Правила исходящего трафика упрощают настройку преобразования сетевых адресов для стандартного общедоступного балансировщика нагрузки.

Правила исходящего трафика соответствуют тому же синтаксису, что и балансировка нагрузки и правила NAT для входящего трафика: интерфейсные IP-адреса и параметры и внутренний пул

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

Хотя вы можете использовать правило исходящего трафика с одним общедоступным IP-адресом, правила исходящего трафика отлично подходят для масштабирования исходящего NAT, так как они упрощают нагрузку на конфигурацию. Вы можете использовать несколько IP-адресов для планирования крупномасштабных сценариев, а также правила исходящего трафика для снижения риска паттернов, склонных к исчерпанию SNAT. Каждый IP-адрес, предоставляемый фронтендом, предоставляет 64 тыс. временных портов для балансировки нагрузки, используемых в качестве портов SNAT.

При использовании подсистемы балансировки нагрузки SKU уровня "Стандартный" с управляемыми общедоступными IP-адресами исходящего трафика (которые создаются по умолчанию), можно масштабировать число управляемых общедоступных IP-адресов с помощью --load-balancer-managed-outbound-ip-count параметра.

Это важно

Мы не рекомендуем использовать портал Azure для внесения изменений в правило исходящего трафика. При внесении этих изменений следует осуществлять изменения через кластер AKS, а не непосредственно в ресурсе балансировщика нагрузки.

Изменения правила исходящего трафика, внесенные непосредственно в ресурс Load Balancer, удаляются каждый раз, когда кластер синхронизируется, например, при его остановке, запуске, обновлении или масштабировании.

Используйте Azure CLI, как показано в примерах. Изменения правила исходящего трафика, внесенные с помощью az aks команд CLI, являются постоянными во время простоя кластера.

Для получения дополнительной информации см. раздел правила исходящего трафика для Azure Load Balancer.

Задайте количество общедоступных IP-адресов управляемого исходящего трафика

Создание нового кластера с определенным числом управляемых исходящих общедоступных IP-адресов
Обновление существующего кластера для масштабирования количества управляемых исходящих общедоступных IP-адресов

Создайте новый кластер AKS с определенным числом управляемых общедоступных IP-адресов с помощью az aks create команды с параметром --load-balancer-managed-outbound-ip-count . В следующем примере количество управляемых общедоступных IP-адресов для исходящего трафика установлено на два.
```
az aks create \
    --resource-group $RESOURCE_GROUP \
    --name $CLUSTER_NAME \
    --load-balancer-managed-outbound-ip-count 2 \
    --generate-ssh-keys
```

Обновите существующий кластер AKS, чтобы масштабировать количество управляемых исходящих общедоступных IP-адресов с помощью команды az aks update с параметром --load-balancer-managed-outbound-ip-count. В следующем примере количество управляемых общедоступных IP-адресов для исходящего трафика установлено на два.
```
az aks update \
    --resource-group $RESOURCE_GROUP \
    --name $CLUSTER_NAME \
    --load-balancer-managed-outbound-ip-count 2
```

Настройка собственных общедоступных исходящих IP-адресов или префиксов

При использовании балансировщика нагрузки SKU уровня Standard кластер AKS автоматически создает общедоступный IP-адрес в группе ресурсов инфраструктуры, управляемой AKS, и назначает его исходящему пулу балансировщика нагрузки по умолчанию.

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

Требования к использованию собственных общедоступных IP-адресов или префиксов исходящего трафика

Прежде чем предоставлять собственные общедоступные IP-адреса или префиксы для исходящего трафика, убедитесь, что выполнены следующие требования:

Вы должны создать и владеть собственными общедоступными IP-адресами. Вы не можете повторно использовать управляемые общедоступные IP-адреса, созданные AKS, как "принести собственный настраиваемый IP-адрес", так как это может привести к конфликтам управления.
Необходимо убедиться, что идентификатор кластера AKS имеет разрешения на доступ к внешнему IP-адресу в соответствии со списком необходимых разрешений общедоступного IP-адреса.
Убедитесь, что выполнены предварительные требования и ограничения, необходимые для настройки исходящих IP-адресов или их префиксов.

Предоставление собственных общедоступных IP-адресов исходящего трафика

Предоставление собственных общедоступных IP-адресов исходящего трафика при создании нового кластера
Обновление существующего кластера для использования собственных исходящих общедоступных IP-адресов

Создайте кластер AKS с собственными общедоступными IP-адресами исходящего трафика с помощью az aks create команды с параметром --load-balancer-outbound-ips . Убедитесь, что вы заменили значения заполнителей на свои собственные.
```
az aks create \
    --resource-group $RESOURCE_GROUP \
    --name $CLUSTER_NAME \
    --load-balancer-outbound-ips $PUBLIC_IP_ID1,$PUBLIC_IP_ID2 \
    --generate-ssh-keys
```

Обновите существующий кластер AKS, чтобы использовать собственные исходящие общедоступные IP-адреса с помощью команды az aks update с параметром --load-balancer-outbound-ips. Убедитесь, что вы заменили значения заполнителей на свои собственные.
```
az aks update \
    --resource-group $RESOURCE_GROUP \
    --name $CLUSTER_NAME \
    --load-balancer-outbound-ips $PUBLIC_IP_ID1,$PUBLIC_IP_ID2
```

Предоставление собственных общедоступных IP-префиксов

Укажите собственные исходящие префиксы общедоступных IP-адресов при создании нового кластера.
Обновление существующего кластера для использования собственных префиксов для исходящего общедоступного IP-адреса

Создайте новый кластер AKS с собственными префиксами общедоступного IP-адреса с помощью az aks create команды с параметром --load-balancer-outbound-ip-prefixes. Убедитесь, что вы заменили значения заполнителей на свои собственные.
```
az aks create \
    --name $CLUSTER_NAME \
    --resource-group $RESOURCE_GROUP \
    --load-balancer-outbound-ip-prefixes $PUBLIC_IP_PREFIX_ID1,$PUBLIC_IP_PREFIX_ID2 \
    --generate-ssh-keys
```

Обновите существующий кластер AKS для использования ваших собственных префиксов общедоступных IP-адресов исходящего трафика с помощью команды az aks update и параметра --load-balancer-outbound-ip-prefixes. Убедитесь, что вы заменили значения заполнителей на свои собственные.
```
az aks update \
    --resource-group $RESOURCE_GROUP \
    --name $CLUSTER_NAME \
    --load-balancer-outbound-ip-prefixes $PUBLIC_IP_PREFIX_ID1,$PUBLIC_IP_PREFIX_ID2
```

Настройка выделенных исходящих портов

Это важно

Если у вас есть приложения в кластере, которые могут установить большое количество подключений к небольшому набору назначений на общедоступных IP-адресах, таких как многие экземпляры интерфейсного приложения, подключающегося к базе данных, может возникнуть сценарий, подверженный нехватке портов SNAT. Нехватка портов SNAT возникает, когда приложение исчерпывает доступные исходящие порты для установки соединения с другим приложением или узлом. Если у вас есть сценарий, подверженный нехватке портов SNAT, настоятельно рекомендуется увеличить выделенные исходящие порты и исходящие IP-адреса внешнего интерфейса в подсистеме балансировки нагрузки.

Дополнительные сведения о SNAT см. в разделе "Использование SNAT для исходящих подключений".

По умолчанию AKS при создании кластера устанавливает для параметра AllocatedOutboundPorts в подсистеме балансировки нагрузки значение 0, что разрешает автоматическое назначение исходящих портов с учетом размера внутреннего пула. Например, если в кластере 50 или меньше узлов, то каждому узлу выделяется 1024 порта. Это значение позволяет масштабировать до максимального количества узлов в кластере, не требуя перенастройки сети, но может привести к более частому исчерпанию портов SNAT по мере добавления дополнительных узлов. По мере увеличения числа узлов в кластере на каждый узел доступно меньше портов. Увеличение количества узлов за границы диаграммы (например, с 50 до 51 узла или со 100 до 101) может нарушить подключение, так как количество портов SNAT, выделяемых существующим узлам, сокращается для размещения большего числа узлов. Мы рекомендуем использовать явное значение для AllocatedOutboundPorts.

Просмотр текущих выделенных исходящих портов

Получите значение AllocatedOutboundPorts для балансировщика нагрузки кластера AKS, используя команду az network lb outbound-rule list.

NODE_RG=$(az aks show --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --query nodeResourceGroup -o tsv)
az network lb outbound-rule list --resource-group $NODE_RG --lb-name kubernetes -o table

В следующем примере выходных данных показано, что автоматическое назначение исходящего порта на основе размера внутреннего пула включено для кластера:

AllocatedOutboundPorts    EnableTcpReset    IdleTimeoutInMinutes    Name             Protocol    ProvisioningState    ResourceGroup
------------------------  ----------------  ----------------------  ---------------  ----------  -------------------  -------------
0                         True              30                      aksOutboundRule  All         Succeeded            MC_myResourceGroup_myAKSCluster_eastus

Вычисление и проверка необходимых исходящих портов и IP-адресов

Прежде чем задать определенное значение или увеличить существующее значение для исходящих портов или исходящих IP-адресов, необходимо вычислить соответствующее количество исходящих портов и IP-адресов. Для этого расчета используйте следующую формулу, округляя результат до ближайшего целого числа: 64,000 ports per IP / <outbound ports per node> * <number of outbound IPs> = <maximum number of nodes in the cluster>.

Примеры вычисления исходящих портов и IP-адресов

В следующих примерах показано, как заданные значения влияют на количество исходящих портов и IP-адресов:

Если используются значения по умолчанию и кластер имеет 48 узлов, каждый узел имеет 1024 порты.
Если используются значения по умолчанию и кластер масштабируется с 48 до 52 узлов, каждый узел обновляется с 1024 портов, доступных до 512 портов.
Если для количества исходящих портов задано значение 1000, а число исходящих IP-адресов равно 2, кластер может поддерживать не более 128 узлов: 64,000 ports per IP / 1,000 ports per node * 2 IPs = 128 nodes
Если для количества исходящих портов задано значение 1000, а число исходящих IP-адресов равно 7, кластер может поддерживать не более 448 узлов: 64,000 ports per IP / 1,000 ports per node * 7 IPs = 448 nodes
Если для количества исходящих портов задано значение 4000, а число исходящих IP-адресов равно 2, кластер может поддерживать не более 32 узлов: 64,000 ports per IP / 4,000 ports per node * 2 IPs = 32 nodes
Если для количества исходящих портов задано значение 4000, а число исходящих IP-адресов равно 7, кластер может поддерживать не более 112 узлов: 64,000 ports per IP / 4,000 ports per node * 7 IPs = 112 nodes

Это важно

После вычисления количества исходящих портов и IP-адресов убедитесь, что у вас есть дополнительная емкость исходящего порта для обработки всплеска узлов во время обновления. Важно выделить достаточные избыточные порты для дополнительных узлов, необходимых для обновления и других операций. AKS по умолчанию использует один буферный узел для операций обновления. Если вы используете maxSurge значения, умножьте количество исходящих портов на каждый узел на maxSurge значение, чтобы определить необходимое количество портов. Например, если вы вычисляете, что на каждый узел требуется 4000 портов с 7 IP-адресами в кластере с максимумом 100 узлов и максимальным всплеском 2:

2 пиковых узла * 4000 портов на узел = 8000 портов, необходимых для пикового роста числа узлов во время обновления.
100 узлов * 4000 портов на узел = 400 000 портов, необходимых для вашего кластера.
7 IP-адресов * 64000 портов на IP-адрес = 448 000 портов, доступных для вашего кластера.

В этом примере показано, что кластер имеет избыточный объем 48 000 портов, что достаточно для обработки 8000 портов, необходимых для всплеска узлов во время обновления.

Настройка выделенных исходящих портов и исходящих IP-адресов

После расчета и проверки значений вы можете применить их с помощью load-balancer-outbound-ports и load-balancer-managed-outbound-ip-count, load-balancer-outbound-ips или load-balancer-outbound-ip-prefixes при создании или обновлении кластера.

Создание кластера с определенными исходящими портами и IP-адресами
Обновление существующего кластера с определенными исходящими портами и IP-адресами

Создайте новый кластер AKS с определенными исходящими портами и IP-адресами с помощью az aks create команды. В следующем примере для параметра задано --load-balancer-managed-outbound-ip-count значение 7 , а параметр --load-balancer-outbound-ports — 4000:
```
az aks create \
    --resource-group $RESOURCE_GROUP \
    --name $CLUSTER_NAME \
    --load-balancer-managed-outbound-ip-count 7 \
    --load-balancer-outbound-ports 4000 \
    --generate-ssh-keys
```

Обновите существующий кластер AKS с определенными исходящими портами и IP-адресами с помощью az aks update команды. В следующем примере для параметра задано --load-balancer-managed-outbound-ip-count значение 7 , а параметр --load-balancer-outbound-ports — 4000:
```
az aks update \
    --resource-group $RESOURCE_GROUP \
    --name $CLUSTER_NAME \
    --load-balancer-managed-outbound-ip-count 7 \
    --load-balancer-outbound-ports 4000
```

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

Если ресурс портов SNAT исчерпан, исходящие потоки прекращаются, пока имеющиеся потоки не освободят порты SNAT. Подсистема балансировки нагрузки освобождает порты SNAT при закрытии потока, а настроенная подсистема балансировки нагрузки AKS использует 30-минутное время ожидания простоя для восстановления портов SNAT из неактивных потоков. Вы также можете использовать транспорт (например, TCP keepalives или application-layer keepalives) для активирования потока простоя и сброса таймаута простоя при необходимости.

Если вы ожидаете многочисленные короткие подключения и отсутствие длительных подключений, которые могут простаивать долго, например при использовании kubectl proxy или kubectl port-forward, рассмотрите возможность использования низкого значения времени ожидания, например 4 минуты. Если используются TCP keepalive, достаточно включить их на одной стороне подключения. Например, достаточно включить их на стороне сервера только для сброса таймера простоя потока. Для обеих сторон не обязательно инициировать TCP keepalive. Этот же подход применим и для уровня приложений, в том числе в системах баз данных "клиент — сервер". Выясните, какие средства на стороне сервера позволяют поддерживать проверку активности конкретного приложения.

Это важно

AKS включает сброс TCP при бездействии по умолчанию. Мы рекомендуем сохранить эту конфигурацию и использовать ее для более предсказуемого поведения приложения в сценариях. Дополнительные сведения см. в разделе Сброс TCP в Azure Load Balancer.

Если параметр IdleTimeoutInMinutes имеет значение, отличное от значения по умолчанию, равного 30 минутам, следует учитывать, сколько времени для рабочих нагрузок требуется исходящее подключение. Кроме того, следует учитывать, что значение времени ожидания по умолчанию для подсистемы балансировки нагрузки SKU уровня "Стандартный" , используемой за пределами AKS, составляет 4 минуты. Значение IdleTimeoutInMinutes, более точно отражающее специфику вашей рабочей нагрузки на AKS, может помочь уменьшить истощение ресурсов SNAT, вызванное поддержанием неиспользуемых подключений.

Предупреждение

Изменение значений для AllocatedOutboundPorts и IdleTimeoutInMinutes может значительно изменить поведение правила исходящего трафика для вашего балансировщика нагрузки и не должно производиться легкомысленно. Просмотрите Troubleshoot SNAT и просмотрите правила исходящего трафика Load Balancer и исходящие подключения в Azure перед обновлением этих значений, чтобы полностью понять влияние изменений.

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

Создайте новый кластер AKS с определенным временем ожидания простоя с помощью az aks create команды с параметром --load-balancer-idle-timeout . В следующем примере устанавливается время ожидания простоя на 4 минуты:
```
az aks create \
    --resource-group $RESOURCE_GROUP \
    --name $CLUSTER_NAME \
    --load-balancer-idle-timeout 4 \
    --generate-ssh-keys
```

Обновите существующий кластер AKS, установив конкретное время ожидания в режиме простоя с помощью команды az aks update и параметра --load-balancer-idle-timeout. В следующем примере устанавливается время ожидания простоя на 4 минуты:
```
az aks update \
    --resource-group $RESOURCE_GROUP \
    --name $CLUSTER_NAME \
    --load-balancer-idle-timeout 4
```

Ограничение диапазона IP-адресов для входящего трафика

Следующий манифест используется loadBalancerSourceRanges для указания нового диапазона IP-адресов для входящего внешнего трафика:

apiVersion: v1
kind: Service
metadata:
  name: azure-vote-front
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: azure-vote-front
  loadBalancerSourceRanges:
  - MY_EXTERNAL_IP_RANGE

В этом выше примере правило изменено таким образом, чтобы разрешить внешний входящий трафик только из диапазона MY_EXTERNAL_IP_RANGE. При замене MY_EXTERNAL_IP_RANGE внутренним IP-адресом подсети трафик будет передаваться только через внутренние IP-адреса кластера. Если трафик ограничен внутренними IP-адресами кластера, клиенты за пределами кластера Kubernetes не могут получить доступ к подсистеме балансировки нагрузки.

Замечание

При ограничении входящего трафика следует учитывать следующие сведения:

Если необходимо разрешить как блоки CIDR, так и теги службы Azure, удалите свойство loadBalancerSourceRanges и добавьте аннотации service.beta.kubernetes.io/azure-allowed-ip-ranges и/или service.beta.kubernetes.io/azure-allowed-service-tags для балансировщика нагрузки. Эта конфигурация применяет фильтрацию только на уровне NSG и пропускает правила kube-proxy уровня узла. Если вы задали loadBalancerSourceRanges свойство вместе с azure-allowed-service-tags заметкой, AKS сообщит об ошибке при попытке применить спецификацию.
Входящий, внешний трафик поступает от балансировщика нагрузки в виртуальную сеть для вашего кластера AKS. Виртуальная сеть имеет группу безопасности сети (NSG), которая разрешает весь входящий трафик из подсистемы балансировки нагрузки. Эта NSG использует тег службы типа LoadBalancer, чтобы разрешить трафик, отправляемый от балансировщика нагрузки.
CiDR pod следует добавить в loadBalancerSourceRanges, если требуется доступ к IP-адресу службы Load Balancer для кластеров с Kubernetes версии 1.25 или более поздней.

Поддержание IP-адреса клиента для входящих подключений

По умолчанию служба типа LoadBalancerв Kubernetes и в AKS не сохраняет IP-адрес клиента в подключении к pod. Исходный IP-адрес пакета, доставленного в pod, становится частным IP-адресом узла. Чтобы сохранить IP-адрес клиента, необходимо задать значение service.spec.externalTrafficPolicylocal в определении службы. В следующем манифесте показан пример:

apiVersion: v1
kind: Service
metadata:
  name: azure-vote-front
spec:
  type: LoadBalancer
  externalTrafficPolicy: Local
  ports:
  - port: 80
  selector:
    app: azure-vote-front

Кастомизация с помощью аннотаций Kubernetes

Следующие заметки поддерживаются для служб Kubernetes с типом LoadBalancerи применяются только к потокам INBOUND .

Annotation	Ценность	Description
`service.beta.kubernetes.io/azure-load-balancer-internal`	`true` или `false`	Указывает, должна ли подсистема балансировки нагрузки быть внутренней. Если не задано, по умолчанию установлено общедоступное.
`service.beta.kubernetes.io/azure-load-balancer-internal-subnet`	Имя подсети	Указывает подсеть, к которой должна быть привязана внутренняя подсистема балансировки нагрузки. Если он не задан, по умолчанию используется подсеть, настроенная в файле конфигурации облака.
`service.beta.kubernetes.io/azure-dns-label-name`	Имя DNS-метки в общедоступных IP-адресах	Указывает имя DNS-метки для общедоступной службы. Если для него задана пустая строка, запись DNS в общедоступном IP-адресе не используется.
`service.beta.kubernetes.io/azure-load-balancer-resource-group`	Имя группы ресурсов	Указывает группу ресурсов для общедоступных IP-адресов подсистемы балансировки нагрузки, которые находятся не в той же группе ресурсов, что и инфраструктура кластера (группа ресурсов узла).
`service.beta.kubernetes.io/azure-allowed-service-tags`	Список разрешенных тегов службы	Укажите список разрешенных тегов служб, разделенных запятыми.
`service.beta.kubernetes.io/azure-allowed-ip-ranges`	список разрешенных диапазонов IP-адресов	Укажите список разрешенных диапазонов IP-адресов, разделенных запятыми.
`service.beta.kubernetes.io/azure-load-balancer-tcp-idle-timeout`	Тайм-ауты простоя TCP в минутах	Укажите время в минутах для таймаута бездействия TCP-соединения на балансировщике нагрузки. Значение по умолчанию и минимальное значение равно 4. Максимальное значение равно 30. Значением должно быть целое число.
`service.beta.kubernetes.io/azure-load-balancer-disable-tcp-reset`	`true` или `false`	Укажите, следует ли подсистеме балансировки нагрузки отключить сброс TCP при истечении времени ожидания простоя.
`service.beta.kubernetes.io/azure-load-balancer-ipv4`	IPv4-адрес	Укажите IPv4-адрес для назначения системе балансировки нагрузки.
`service.beta.kubernetes.io/azure-load-balancer-ipv6`	Адрес IPv6	Укажите IPv6-адрес для назначения подсистеме балансировки нагрузки.

Настройка разрешенных диапазонов IP-адресов (предварительная версия)

Вы можете использовать заметки azure-allowed-service-tags и azure-allowed-ip-ranges для объединения блоков CIDR и тегов службы Azure в подсистеме балансировки нагрузки. Добавьте service.beta.kubernetes.io/azure-allowed-ip-ranges с разделенным запятыми список префиксов IP-адресов и добавьте service.beta.kubernetes.io/azure-allowed-service-tags с одним или несколькими тегами службы Azure. Поставщик облачных служб AKS объединяет оба значения в одно правило NSG, поэтому трафик отфильтровывается централизованно в NSG, предоставляя вам единый, ориентированный на NSG уровень управления как для IP-адресов, так и для тегов служб.

Вы можете продолжить использовать свойство loadBalancerSourceRanges в тех случаях, когда требуется применение ограничений на основе CIDR как в NSG, так и в хосте. Это свойство нельзя использовать с аннотацией azure-allowed-service-tags. Если оба указаны, AKS сообщает об ошибке при попытке применить спецификацию службы балансировщика нагрузки.

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

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

Annotation	Ценность	Description
`service.beta.kubernetes.io/azure-load-balancer-health-probe-interval`	Интервал пробы работоспособности
`service.beta.kubernetes.io/azure-load-balancer-health-probe-num-of-probe`	Минимальное количество неработоспособных ответов пробы работоспособности
`service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path`	Путь запроса пробы работоспособности
`service.beta.kubernetes.io/port_{port}_no_lb_rule`	true/false	{port} — номер порта службы. Если задано значение `true`, для этого порта не создаются правила балансировки нагрузки или проб работоспособности. Служба проверки состояния не должна быть открыта для общедоступного Интернета.
`service.beta.kubernetes.io/port_{port}_no_probe_rule`	true/false	{port} — номер порта службы. Если задано значение `true`, для этого порта не создаются правила пробы работоспособности.
`service.beta.kubernetes.io/port_{port}_health-probe_protocol`	Протокол пробы работоспособности	{port} — номер порта службы. Явный протокол для контрольной проверки служебного порта {port}, переопределяющий port.appProtocol, если задан.
`service.beta.kubernetes.io/port_{port}_health-probe_port`	номер порта или имя порта в манифесте службы	{port} — номер порта службы. Явный порт проверки работоспособности для порта службы {port}, который переопределяет значение по умолчанию.
`service.beta.kubernetes.io/port_{port}_health-probe_interval`	Интервал пробы работоспособности	{port} — номер порта службы.
`service.beta.kubernetes.io/port_{port}_health-probe_num-of-probe`	Минимальное количество неработоспособных ответов пробы работоспособности	{port} — номер порта службы.
`service.beta.kubernetes.io/port_{port}_health-probe_request-path`	Путь запроса пробы работоспособности	{port} — номер порта службы.

Замечание

AKS теперь поддерживает общие пробы работоспособности для externalTrafficPolicy: Cluster служб. Дополнительные сведения см. в статье Использование общих проб работоспособности для служб externalTrafficPolicy: Cluster (предварительная версия) в Azure Kubernetes Service (AKS).

Поведение пробы работоспособности по умолчанию

В настоящее время протокол проверки работоспособности по умолчанию зависит от служб с различными транспортными протоколами, протоколами приложений, заметками и внешними политиками трафика.

Для локальных служб будет использоваться протокол HTTP и /healthz. Проба работоспособности будет запрашивать NodeHealthPort , а не фактическую серверную службу.
Для служб TCP кластера будет использоваться TCP.
Для служб UDP кластера не выполняется проб работоспособности.

Замечание

Для локальных служб с включенной интеграцией PLS и протоколом прокси-сервера PLS проба работоспособности HTTP и /healthz по умолчанию не работает. Таким образом, проверка состояния может быть настроена так же, как и службы кластера для поддержки этого сценария.

Аннотация пути запроса проверки работоспособности

Начиная с версии Kubernetes 1.20, была введена аннотация службы service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path для определения поведения проверки работоспособности.

Для кластеров <=1.23 spec.ports.appProtocol будет использоваться только в качестве протокола пробы, если service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path он также задан.
Для кластеров >1.24 spec.ports.appProtocol будет использоваться в качестве протокола пробы и / будет использоваться в качестве пути запроса пробы по умолчанию (service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path можно использовать для изменения на другой путь запроса).

Обратите внимание, что путь запроса будет игнорироваться при использовании TCP или spec.ports.appProtocol пустого. В следующей таблице приведены сведения о поведении пробы работоспособности по умолчанию:

SKU балансировщика нагрузки	`externalTrafficPolicy`	spec.ports.Protocol	spec.ports.AppProtocol	`service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path`	Протокол зонда балансировки нагрузки	Путь запроса для пробы балансировки нагрузки
стандарт	local	any	any	any	HTTP	`/healthz`
стандарт	кластер	UDP	any	any	ноль	ноль
стандарт	кластер	tcp		(ignored)	tcp	ноль
стандарт	кластер	tcp	tcp	(ignored)	tcp	ноль
стандарт	кластер	tcp	http/https		TCP(=1.23) или http/https(<>=1.24)	NULL(<=1.23) или `/`(>=1.24)
стандарт	кластер	tcp	http/https	`/custom-path`	http/https	`/custom-path`
стандарт	кластер	tcp	неподдерживаемый протокол	`/custom-path`	tcp	ноль
базовая	local	any	any	any	HTTP	`/healthz`
базовая	кластер	tcp		(ignored)	tcp	ноль
базовая	кластер	tcp	tcp	(ignored)	tcp	ноль
базовая	кластер	tcp	HTTP		TCP(=1.23) или http/https(<>=1.24)	NULL(<=1.23) или `/`(>=1.24)
базовая	кластер	tcp	HTTP	`/custom-path`	HTTP	`/custom-path`
базовая	кластер	tcp	неподдерживаемый протокол	`/custom-path`	tcp	ноль

Интервал пробы работоспособности и количество заметок проб

Начиная с версии Kubernetes 1.21, были введены две аннотации службы service.beta.kubernetes.io/azure-load-balancer-health-probe-interval и load-balancer-health-probe-num-of-probe, которые настраивают конфигурацию проверки работоспособности. Если service.beta.kubernetes.io/azure-load-balancer-health-probe-interval не задано, применяется значение по умолчанию 5 . Если load-balancer-health-probe-num-of-probe не задано, применяется значение по умолчанию 2 .

Пользовательская проверка работоспособности балансировщика нагрузки для порта

Для разных портов в службе могут потребоваться разные конфигурации пробы работоспособности. Это может быть связано с проектированием службы (например, когда одна точка состояния службы контролирует несколько портов) или функциями Kubernetes, такими как MixedProtocolLBService.

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

Заметка для конкретного порта	Глобальная аннотация зондов	Поведение
`service.beta.kubernetes.io/port_{port}_no_lb_rule`	N/A (без эквивалента глобально)	Если задано значение `true`, не создаются правила балансировки нагрузки или пробы.
`service.beta.kubernetes.io/port_{port}_no_probe_rule`	N/A (без эквивалента глобально)	Если задано значение `true`, правила пробы не создаются.
`service.beta.kubernetes.io/port_{port}_health-probe_protocol`	N/A (без эквивалента глобально)	Задает протокол пробы работоспособности для этого порта службы (например, Http, Https, Tcp).
`service.beta.kubernetes.io/port_{port}_health-probe_port`	N/A (без эквивалента глобально)	Задает порт проверки работоспособности для данного порта службы (например, 15021).
`service.beta.kubernetes.io/port_{port}_health-probe_request-path`	`service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path`	Для http или Https задает путь запроса пробы работоспособности (по умолчанию — /).
`service.beta.kubernetes.io/port_{port}_health-probe_num-of-probe`	`service.beta.kubernetes.io/azure-load-balancer-health-probe-num-of-probe`	Число последовательных сбоев пробы до того, как порт считается неработоспособным.
`service.beta.kubernetes.io/port_{port}_health-probe_interval`	`service.beta.kubernetes.io/azure-load-balancer-health-probe-interval`	Промежуток времени между повторными попытками выполнения пробы.

Исключение пула узлов из пула бэкенда балансировщика нагрузки

В некоторых сценариях может потребоваться запретить пулу узлов быть частью серверного пула подсистемы балансировки нагрузки. Для этого примените метку node.kubernetes.io/exclude-from-external-load-balancers=true к пулу узлов.

Замечание

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

az aks nodepool update \
    --resource-group $RESOURCE_GROUP \
    --cluster-name $CLUSTER_NAME \
    --name $NODEPOOL_NAME \
    --labels node.kubernetes.io/exclude-from-external-load-balancers=true

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

Дополнительные сведения о службах Kubernetes см. в документации по службам Kubernetes.

Дополнительные сведения об использовании внутренней подсистемы балансировки нагрузки для входящего трафика см. в документации по внутренней подсистеме балансировки нагрузки AKS.

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

Были ли сведения на этой странице полезными?

Last updated on 2025-11-05

Настройка стандартного общедоступного балансировщика нагрузки в Azure Kubernetes Service (AKS)

Перед тем как начать

Изменение типа входящего пула

Требования к изменению типа входящего пула

Масштабирование количества управляемых общедоступных исходящих IP-адресов

Задайте количество общедоступных IP-адресов управляемого исходящего трафика

Настройка собственных общедоступных исходящих IP-адресов или префиксов

Требования к использованию собственных общедоступных IP-адресов или префиксов исходящего трафика

Предоставление собственных общедоступных IP-адресов исходящего трафика

Предоставление собственных общедоступных IP-префиксов

Настройка выделенных исходящих портов

Просмотр текущих выделенных исходящих портов

Вычисление и проверка необходимых исходящих портов и IP-адресов

Рекомендации по вычислению исходящих портов и IP-адресов

Примеры вычисления исходящих портов и IP-адресов

Настройка выделенных исходящих портов и исходящих IP-адресов

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

Ограничение диапазона IP-адресов для входящего трафика

Поддержание IP-адреса клиента для входящих подключений

Кастомизация с помощью аннотаций Kubernetes

Настройка разрешенных диапазонов IP-адресов (предварительная версия)

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

Поведение пробы работоспособности по умолчанию

Аннотация пути запроса проверки работоспособности

Интервал пробы работоспособности и количество заметок проб

Пользовательская проверка работоспособности балансировщика нагрузки для порта

Исключение пула узлов из пула бэкенда балансировщика нагрузки

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

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

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