Использование общедоступной подсистемы балансировки нагрузки уровня "Стандартный" в Служба 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, связанных с узлами агента, не поддерживается. Пример неподдерживаемой операции — внесение вручную изменений в группу ресурсов подсистемы балансировки нагрузки.

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

После создания кластера 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-адрес с подсистемой балансировки нагрузки, существует два способа:

• Задайте заметки службы: используется 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    203.0.113.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:        203.0.113.187
...
TargetPort:                  80/TCP
NodePort:                    32068/TCP
...
Session Affinity:            None
External Traffic Policy:     Cluster
...

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

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

• Задайте или масштабируйте число управляемых исходящих 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 \
    --generate-ssh-keys

Обновление существующего кластера 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-адресов.

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> \
    --generate-ssh-keys

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

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

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

По умолчанию 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 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

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

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

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

Обслуживание 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 кластера не выполняется проб работоспособности.

Начиная с версии 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 endpoint of 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.