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

  • Статья

Azure Load Balancer работает на уровне 4 модели взаимодействия с открытыми системами (OSI), которая поддерживает как входящие, так и исходящие сценарии. Он распределяет входящие потоки, поступающие в интерфейсную часть подсистемы балансировки нагрузки на экземпляры серверного пула.

Общедоступная подсистема балансировки нагрузки, интегрированная с AKS, служит двумя целями:

  1. Чтобы обеспечить исходящие подключения к узлам кластера в виртуальной сети AKS, превысив частный IP-адрес в часть своего исходящего пула.
  2. Чтобы обеспечить доступ к приложениям через службы Kubernetes типа LoadBalancer, что позволяет легко масштабировать приложения и создавать высокодоступные службы.

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

В этой статье рассматривается интеграция с общедоступной подсистемой балансировки нагрузки в AKS. Сведения об интеграции с внутренней подсистемой балансировки нагрузки см. в статье "Использование внутренней подсистемы балансировки нагрузки" в AKS.

Подготовка к работе

  • Azure Load Balancer доступен в двух номерах SKU: "Базовый" и "Стандартный". Номер SKU уровня "Стандартный" используется по умолчанию при создании кластера AKS. Номер SKU ценовой категории “Стандартный” позволяет получить доступ к дополнительным функциям, таким как увеличенный серверный пул, несколько пулов узлов, Зоны доступности, и является безопасным по умолчанию. Это рекомендуемый номер SKU подсистемы балансировки нагрузки для AKS. Дополнительные сведения о номерах SKU "Базовый" и "Стандартный" см. в сравнении SKU Azure Load Balancer.
  • Полный список поддерживаемых заметок для служб Kubernetes с типом LoadBalancerсм. в заметках LoadBalancer.
  • В этой статье предполагается, что у вас есть кластер AKS с Azure Load Balancer ценовой категории Стандартный. Если вам нужен кластер AKS, можно создать его с помощью Azure CLI, Azure PowerShell или портал Azure.
  • AKS управляет жизненным циклом и операциями узлов агента. Изменение ресурсов IaaS, связанных с узлами агента, не поддерживается. Пример неподдерживаемой операции — внесение вручную изменений в группу ресурсов подсистемы балансировки нагрузки.

Внимание

Если вы предпочитаете использовать собственный шлюз, брандмауэр или прокси-сервер для предоставления исходящего подключения, можно пропустить создание исходящего пула подсистемы балансировки нагрузки и соответствующего внешнего IP-адреса с помощью исходящего типа в качестве userDefinedRouting (UDR). Исходящий тип определяет метод исходящего трафика для кластера и по умолчанию для типа LoadBalancer.

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

После создания кластера AKS с исходящим типом LoadBalancer (по умолчанию) кластер готов использовать подсистему балансировки нагрузки для предоставления служб.

Создайте манифест службы с именем public-svc.yaml, который создает общедоступную службу типа LoadBalancer.

apiVersion: v1
kind: Service
metadata:
  name: public-svc
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: public-app

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

Если вы хотите использовать определенный IP-адрес с подсистемой балансировки нагрузки, существует два способа:

Внимание

Добавление свойства LoadBalancerIP в манифест YAML подсистемы балансировки нагрузки устарело после вышестоящий Kubernetes. Хотя текущее использование остается неизменным и существующие службы, как ожидается, работают без изменений, мы настоятельно рекомендуем задать заметки службы.

  • Задайте заметки службы: используется service.beta.kubernetes.io/azure-load-balancer-ipv4 для IPv4-адреса и service.beta.kubernetes.io/azure-load-balancer-ipv6 для IPv6-адреса.
  • Добавьте свойство LoadBalancerIP в манифест YAML подсистемы балансировки нагрузки: добавьте свойство Service.Spec.LoadBalancerIP в манифест YAML подсистемы балансировки нагрузки. Это поле устарело после вышестоящий Kubernetes и не поддерживает двойной стек. Текущее использование остается неизменным и существующие службы, как ожидается, будут работать без изменений.

Развертывание манифеста службы

Разверните манифест общедоступной службы с помощью kubectl apply и укажите имя манифеста YAML.

kubectl apply -f public-svc.yaml

Azure Load Balancer настраивается с новым общедоступным IP-адресом, который интерфейсирует новую службу. Так как в Azure Load Balancer может быть несколько интерфейсных IP-адресов, каждая новая служба, развернутая, получает новый выделенный ВНЕШНИй IP-адрес для уникального доступа.

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

kubectl get service public-svc

NAMESPACE     NAME          TYPE           CLUSTER-IP     EXTERNAL-IP     PORT(S)         AGE
default       public-svc    LoadBalancer   10.0.39.110    52.156.88.187   80:32068/TCP    52s

При просмотре сведений о службе в столбце EXTERNAL-IP отображается общедоступный IP-адрес, созданный для этой службы в подсистеме балансировки нагрузки. Для изменения <> IP-адреса на фактический общедоступный IP-адрес может потребоваться несколько минут.

Дополнительные сведения о службе см. в следующей команде.

kubectl describe service public-svc

Следующий пример выходных данных — это сокращенная версия выходных данных после выполнения kubectl describe service. LoadBalancer Ingress показывает внешний IP-адрес, предоставляемый службой. IP-адрес содержит внутренние адреса.

Name:                        public-svc
Namespace:                   default
Labels:                      <none>
Annotations:                 <none>
Selector:                    app=public-app
...
IP:                          10.0.39.110
...
LoadBalancer Ingress:        52.156.88.187
...
TargetPort:                  80/TCP
NodePort:                    32068/TCP
...
Session Affinity:            None
External Traffic Policy:     Cluster
...

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

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

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

Внимание

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

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

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

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

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

Требования

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

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

az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-backend-pool-type=nodeIP

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

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

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

az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --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 параметра.

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

Внимание

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

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

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

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

az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-managed-outbound-ip-count 2

В приведенном выше примере задано 2 управляемых общедоступных исходящих IP-адреса для кластера myAKSCluster в myResourceGroup.

Во время создания кластера можно также задать начальное число общедоступных IP-адресов управляемого исходящего трафика, добавив --load-balancer-managed-outbound-ip-count параметр и установив его в нужное значение. Значение по умолчанию для общедоступных IP-адресов управляемого исходящего трафика — 1.

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

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

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

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

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

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

az network public-ip show Используйте команду для перечисления идентификаторов общедоступных IP-адресов.

az network public-ip show --resource-group myResourceGroup --name myPublicIP --query id -o tsv

Приведенная выше команда отображает идентификатор общедоступного IP-адреса myPublicIP в группе ресурсов myResourceGroup.

Используйте команду az aks update с параметром load-balancer-outbound-ips, чтобы обновить кластер с помощью общедоступных IP-адресов.

В следующем примере используется load-balancer-outbound-ips параметр с идентификаторами из предыдущей команды.

az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-outbound-ips <publicIpId1>,<publicIpId2>

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

Для исходящего трафика подсистемы балансировки нагрузки ценовой категории "Стандартный" можно также использовать префиксы общедоступных IP-адресов. В следующем примере используется команда az network public-ip show command для перечисления идентификаторов префиксов общедоступного IP-адреса.

az network public-ip prefix show --resource-group myResourceGroup --name myPublicIPPrefix --query id -o tsv

Приведенная выше команда отображает идентификатор префикса общедоступного IP-адреса myPublicIPPrefix в группе ресурсов myResourceGroup.

В следующем примере используется параметр load-balancer-outbound-ip-prefixes с идентификаторами из предыдущей команды.

az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-outbound-ip-prefixes <publicIpPrefixId1>,<publicIpPrefixId2>

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

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

az aks create Используйте команду с параметромload-balancer-outbound-ips, чтобы создать новый кластер с собственными общедоступными IP-адресами.

az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-outbound-ips <publicIpId1>,<publicIpId2>

az aks create Используйте команду с load-balancer-outbound-ip-prefixes параметром, чтобы создать новый кластер с собственными префиксами общедоступного IP-адреса.

az aks create \
    --resource-group myResourceGroup \
    --load-balancer-outbound-ip-prefixes <publicIpPrefixId1>,<publicIpPrefixId2>

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

Внимание

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

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

По умолчанию AKS при создании кластера устанавливает для параметра AllocatedOutboundPorts в подсистеме балансировки нагрузки значение 0, что разрешает автоматическое назначение исходящих портов с учетом размера внутреннего пула. Например, если в кластере 50 или меньше узлов, то каждому узлу выделяется 1024 порта. По мере увеличения числа узлов в кластере на каждый узел доступно меньше портов.

Внимание

Существует жесткий предел в 1024 портах независимо от того, добавляются ли интерфейсные IP-адреса, если размер узла меньше или равен 50 (1–50).

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

NODE_RG=$(az aks show --resource-group myResourceGroup --name myAKSCluster --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

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

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

  • Число исходящих портов на узел исправлено на основе заданного значения.
  • Число исходящих портов должно быть кратно 8.
  • Добавление дополнительных IP-адресов не добавляет больше портов к любому узлу, но обеспечивает емкость для дополнительных узлов в кластере.
  • Необходимо учесть узлы, которые могут быть добавлены в рамках обновлений, включая количество узлов, указанных с помощью значений maxSurge.

В следующих примерах показано, как заданные значения влияют на количество исходящих портов и 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 портов для пикового числа узлов во время обновления.

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

az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-managed-outbound-ip-count 7 \
    --load-balancer-outbound-ports 4000

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

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

Вы также можете использовать транспорт (например, TCP keepalives или application-layer keepalives) для обновления потока простоя и сброса времени ожидания простоя при необходимости. Это время ожидания можно настроить в следующем примере.

az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-idle-timeout 4

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

Внимание

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

TCP RST отправляется только во время подключения TCP в состоянии “УСТАНОВЛЕНО”. Дополнительные сведения см. здесь.

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

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

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

Ограничение диапазона 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 не могут получить доступ к подсистеме балансировки нагрузки.

Примечание.

  • Входящий внешний трафик передается от подсистемы балансировки нагрузки в виртуальную сеть для кластера AKS. Виртуальная сеть имеет группу безопасности сети (NSG), которая разрешает весь входящий трафик из подсистемы балансировки нагрузки. Эта NSG использует тег службы типа LoadBalancer, чтобы разрешить трафик от подсистемы балансировки нагрузки.
  • Pod CIDR следует добавить в loadBalancerSourceRanges, если требуется доступ к IP-адресу LoadBalancer службы с версией 1.25 или более поздней.

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

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

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 .

Номер значение Описание
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-shared-securityrule true или false Укажите предоставление службы с помощью потенциально общего правила безопасности Azure для повышения уязвимости службы, используя расширенные правила безопасности Azure в группах безопасности сети.
service.beta.kubernetes.io/azure-load-balancer-resource-group Имя группы ресурсов Указывает группу ресурсов для общедоступных IP-адресов подсистемы балансировки нагрузки, которые находятся не в той же группе ресурсов, что и инфраструктура кластера (группа ресурсов узла).
service.beta.kubernetes.io/azure-allowed-service-tags Список разрешенных тегов службы Укажите список разрешенных тегов служб, разделенных запятыми.
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-адрес для назначения подсистеме балансировки нагрузки.

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

Номер значение Описание
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, для этого порта не создается правило lb или правило пробы работоспособности. Служба проверка проверка работоспособности не должна быть предоставлена общедоступному Интернету (например, служба здравоохранения istio/envoy)
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} — номер порта службы.

Как описано здесь, Tcp, Http и Https — это три протокола, поддерживаемые службой подсистемы балансировки нагрузки.

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

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

Примечание.

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

Начиная с версии 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 loadbalancer externalTrafficPolicy spec.ports.Protocol spec.ports.AppProtocol service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path Протокол пробы LB Путь запроса пробы LB
standard Локальная среда любое любое любое HTTP /healthz
standard cluster udp любое любое null null
standard cluster tcp (игнорируется) tcp null
standard cluster tcp tcp (игнорируется) tcp null
standard cluster tcp http/https TCP(=1.23) или http/https(<>=1.24) NULL(<=1.23) или /(>=1.24)
standard cluster tcp http/https /custom-path http/https /custom-path
standard cluster tcp неподдерживаемый протокол /custom-path tcp null
базовая Локальная среда любое любое любое HTTP /healthz
базовая cluster tcp (игнорируется) tcp null
базовая cluster tcp tcp (игнорируется) tcp null
базовая cluster tcp HTTP TCP(=1.23) или http/https(<>=1.24) NULL(<=1.23) или /(>=1.24)
базовая cluster tcp HTTP /custom-path HTTP /custom-path
базовая cluster tcp неподдерживаемый протокол /custom-path tcp null

С версии 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. И общая проба должна быть менее 120 секунд.

Настраиваемая проба работоспособности Load Balancer для порта

Для разных портов в службе могут потребоваться разные конфигурации пробы работоспособности. Это может быть связано с проектированием службы (например, одной конечной точкой работоспособности, контролирующей несколько портов), или функциями 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 Время между попытками пробы

Для следующего манифеста правило пробы для httpsserver порта отличается от правила httpserver, так как указываются заметки для порта httpsserver.

apiVersion: v1
kind: Service
metadata:
  name: appservice
  annotations:
    service.beta.kubernetes.io/azure-load-balancer-health-probe-num-of-probe: "5"
    service.beta.kubernetes.io/port_443_health-probe_num-of-probe: "4"
spec:
  type: LoadBalancer
  selector:
    app: server
  ports:
    - name: httpserver
      protocol: TCP
      port: 80
      targetPort: 30102
    - name: httpsserver
      protocol: TCP
      appProtocol: HTTPS
      port: 443
      targetPort: 30104

В этом манифесте https-порты используют другой порт узла, готовность HTTP проверка через порт 10256 в /healthz(конечная точка healthz kube-proxy).

apiVersion: v1
kind: Service
metadata:
  name: istio
  annotations:
    service.beta.kubernetes.io/azure-load-balancer-internal: "true"
    service.beta.kubernetes.io/port_443_health-probe_protocol: "http"
    service.beta.kubernetes.io/port_443_health-probe_port: "10256"
    service.beta.kubernetes.io/port_443_health-probe_request-path: "/healthz"
spec:
  ports:
    - name: https
      protocol: TCP
      port: 443
      targetPort: 8443
      nodePort: 30104
      appProtocol: https
  selector:
    app: istio-ingressgateway
    gateway: istio-ingressgateway
    istio: ingressgateway
  type: LoadBalancer
  sessionAffinity: None
  externalTrafficPolicy: Local
  ipFamilies:
    - IPv4
  ipFamilyPolicy: SingleStack
  allocateLoadBalancerNodePorts: true
  internalTrafficPolicy: Cluster

В этом манифесте порты https используют другую конечную точку пробы работоспособности, готовность HTTP проверка через порт 30000 на /healthz/ready.

apiVersion: v1
kind: Service
metadata:
  name: istio
  annotations:
    service.beta.kubernetes.io/azure-load-balancer-internal: "true"
    service.beta.kubernetes.io/port_443_health-probe_protocol: "http"
    service.beta.kubernetes.io/port_443_health-probe_port: "30000"
    service.beta.kubernetes.io/port_443_health-probe_request-path: "/healthz/ready"
spec:
  ports:
    - name: https
      protocol: TCP
      port: 443
      targetPort: 8443
      appProtocol: https
  selector:
    app: istio-ingressgateway
    gateway: istio-ingressgateway
    istio: ingressgateway
  type: LoadBalancer
  sessionAffinity: None
  externalTrafficPolicy: Local
  ipFamilies:
    - IPv4
  ipFamilyPolicy: SingleStack
  allocateLoadBalancerNodePorts: true
  internalTrafficPolicy: Cluster

Устранение неполадок SNAT

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

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

Шаги

  1. Убедитесь, что подключения уже давно неактивны, а для освобождения порта используется тайм-аут простоя по умолчанию. В этом случае может потребоваться сократить время ожидания по умолчанию в течение 30 минут.
  2. Узнайте, как приложение создает исходящее подключение (например, проверка кода или запись пакетов).
  3. Определите, является ли действие ожидаемым или поведение приложения некорректным. Для подтверждения результатов используйте метрики и журналы Azure Monitor, Например, используйте категорию "Сбой" для метрики подключений SNAT.
  4. Оцените, соблюдаются ли применимые шаблоны.
  5. Оцените, следует ли уменьшить исчерпание портов SNAT с более исходящими IP-адресами и более выделенными исходящими портами.

Конструктивные шаблоны

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

  • Атомарные запросы (один запрос на подключение) обычно не являются хорошим вариантом проектирования. Такие антишаблоны ограничивают масштаб, сокращают производительность и снижают надежность. Вместо этого повторно используйте подключения HTTP(S), чтобы уменьшить число подключений и занятых портов SNAT. Увеличение масштаба приложения и повышение производительности из-за снижения затрат на подтверждение, нагрузку и криптографическую операцию при использовании TLS.
  • Если вы используете из кластера или пользовательского DNS-сервера или пользовательские серверы вышестоящий в coreDNS, помните, что DNS может вводить множество отдельных потоков в том случае, если клиент не кэширования результата разрешения DNS. Сначала следует настроить coreDNS вместо использования пользовательских DNS-серверов и определить хорошее значение кэширования.
  • Потоки UDP (например, подстановки DNS) выделяют порты SNAT во время ожидания простоя. Чем дольше это время ожидания, тем выше нагрузка на порты SNAT. Используйте короткое время ожидания простоя (например, 4 минуты).
  • Используйте пулы соединений, чтобы контролировать число подключений.
  • Никогда не отменяйте поток TCP без оповещения и не доверяйте очистку потоков таймерам TCP. Если не разрешить TCP явно закрыть подключение, состояние остается выделенным в промежуточных системах и конечных точках, а порты SNAT недоступны для других подключений. Такой шаблон может привести к сбоям приложений и исчерпанию ресурсов SNAT.
  • Не изменяйте значения таймера на уровне ОС, связанные с закрытием подключений TCP, без экспертного понимания их влияния. Пока стек TCP восстанавливается, производительность приложения может негативно повлиять на то, что конечные точки подключения не совпадают с ожиданиями. Желание изменять таймеры обычно говорит о проблеме базовой архитектуры. Изучите приведенные ниже рекомендации.

Переход с балансировщика нагрузки SKU уровня "Базовый" на номер SKU уровня "Стандартный"

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

Например, создание синих и зеленых развертываний для переноса кластеров является распространенной практикой, учитывая load-balancer-sku тип кластера и может быть определен только во время создания кластера. Однако подсистемы балансировки нагрузки SKU уровня "Базовый" используют базовые IP-адреса SKU, которые несовместимы с подсистемами балансировки нагрузки SKU уровня "Стандартный". Для подсистем балансировки нагрузки SKU уровня "Стандартный" требуются IP-адреса SKU уровня "Стандартный". При переносе кластеров для обновления номеров SKU подсистемы балансировки нагрузки требуется новый IP-адрес с совместимым номером SKU IP-адреса.

Дополнительные сведения о переносе кластеров см . в нашей документации по вопросам миграции.

Ограничения

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

  • Необходим по крайней мере один общедоступный IP-адрес или префикс IP-адреса для передачи исходящего трафика из кластера AKS. Общедоступный IP-адрес или префикс IP-адреса требуется для поддержания связи между уровнем управления и узлами агентов, а также для обеспечения совместимости с предыдущими версиями AKS. У вас есть следующие параметры для указания общедоступных IP-адресов или префиксов IP-адресов с подсистемой балансировки нагрузки SKU уровня "Стандартный".
    • Предоставьте собственные общедоступные IP-адреса.
    • Предоставьте собственные префиксы общедоступных IP-адресов.
    • Укажите число до 100, чтобы разрешить кластеру AKS создавать несколько общедоступных IP-адресов SKU уровня "Стандартный " в той же группе ресурсов, что и кластер AKS. Эта группа ресурсов обычно называется MC_ в начале. AKS назначит общедоступный IP-адрес подсистеме балансировки нагрузки ценовой категории "Стандартный". По умолчанию один общедоступный IP-адрес автоматически создается в той же группе ресурсов, что и кластер AKS, если не указан общедоступный IP-адрес, префикс общедоступного IP-адреса или число IP-адресов. Кроме того, необходимо разрешить общедоступные адреса и не создавать политики Azure, запрещающие создание IP-адресов.
  • Общедоступный IP-адрес, созданный AKS, нельзя использовать повторно в качестве настраиваемого общедоступного IP-адреса. Пользователи должны создавать и управлять всеми пользовательскими IP-адресами.
  • Определить номер SKU подсистемы балансировки нагрузки можно только при создании кластера AKS. Вы не сможете изменить номер SKU подсистемы балансировки нагрузки после создания кластера AKS.
  • В одном кластере можно использовать только один тип SKU подсистемы балансировки нагрузки (базовый или стандартный).
  • Подсистемы балансировки нагрузки SKU уровня "Стандартный" поддерживают только IP-адреса SKU уровня "Стандартный".

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

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

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