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

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

Примечание.

Azure Load Balancer доступен в двух номерах SKU: "Базовый" и "Стандартный". Номер SKU уровня "Стандартный" используется по умолчанию при создании кластера AKS. При создании типа службы LoadBalancer вы получите тот же тип подсистемы балансировки нагрузки, что и при подготовке кластера. Дополнительные сведения см. в разделе Сравнение номеров SKU для Azure Load Balancer.

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

• В этой статье предполагается, что у вас есть кластер AKS. Если вам нужен кластер AKS, можно создать его с помощью Azure CLI, Azure PowerShell или портал Azure.
• Вам потребуется Azure CLI версии 2.0.59 или более поздней. Чтобы узнать версию, выполните команду az --version. Если вам необходимо выполнить установку или обновление, см. статью Установка Azure CLI 2.0.
• Если вы хотите использовать существующую подсеть или группу ресурсов, удостоверение кластера AKS должно иметь разрешение на управление сетевыми ресурсами. Дополнительные сведения см. в статье "Использование сети kubenet с собственными диапазонами IP-адресов в AKS" или "Настройка сети Azure CNI" в AKS. Если вы настраиваете подсистему балансировки нагрузки для использования IP-адреса в другой подсети, убедитесь, что удостоверение кластера AKS также имеет доступ на чтение к этой подсети.
  • Дополнительные сведения о разрешениях см. в разделе Делегирование прав доступа другим ресурсам Azure.

Создание внутреннего балансировщика нагрузки

1. Создайте манифест службы с именем internal-lb.yaml типа LoadBalancer службы и заметки azure-load-balancer-internal .

   apiVersion: v1
   kind: Service
   metadata:
     name: internal-app
     annotations:
       service.beta.kubernetes.io/azure-load-balancer-internal: "true"
   spec:
     type: LoadBalancer
     ports:
     - port: 80
     selector:
       app: internal-app
   

2. Разверните внутреннюю подсистему балансировки нагрузки с помощью kubectl apply команды. Эта команда создает подсистему балансировки нагрузки Azure в группе ресурсов узла, подключенной к той же виртуальной сети, что и кластер AKS.

   kubectl apply -f internal-lb.yaml
   

3. Просмотрите сведения о службе с помощью kubectl get service команды.

   kubectl get service internal-app
   

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

   NAME           TYPE           CLUSTER-IP    EXTERNAL-IP   PORT(S)        AGE
   internal-app   LoadBalancer   10.0.248.59   10.240.0.7    80:30555/TCP   2m
   

Указание IP-адреса

При указании IP-адреса подсистемы балансировки нагрузки указанный IP-адрес должен находиться в той же виртуальной сети, что и кластер AKS, но он еще не может быть назначен другому ресурсу в виртуальной сети. Например, не следует использовать IP-адрес в диапазоне, указанном для подсети Kubernetes в кластере AKS. Использование IP-адреса, который уже назначен другому ресурсу в той же виртуальной сети, может вызвать проблемы с подсистемой балансировки нагрузки.

Для получения подсетей в виртуальной сети можно использовать az network vnet subnet list команду Azure CLI или Get-AzVirtualNetworkSubnetConfig командлет PowerShell.

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

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

Внимание

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

Настройка заметок службы

1. Задайте заметки службы, использующие service.beta.kubernetes.io/azure-load-balancer-ipv4 для IPv4-адреса и service.beta.kubernetes.io/azure-load-balancer-ipv6 для IPv6-адреса.

   apiVersion: v1
   kind: Service
   metadata:
     name: internal-app
     annotations:
       service.beta.kubernetes.io/azure-load-balancer-ipv4: 10.240.0.25
       service.beta.kubernetes.io/azure-load-balancer-internal: "true"
   spec:
     type: LoadBalancer
     ports:
     - port: 80
     selector:
       app: internal-app
   

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

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

   apiVersion: v1
   kind: Service
   metadata:
     name: internal-app
     annotations:
       service.beta.kubernetes.io/azure-load-balancer-internal: "true"
   spec:
     type: LoadBalancer
     loadBalancerIP: 10.240.0.25
     ports:
     - port: 80
     selector:
       app: internal-app
   

2. Просмотрите сведения о службе с помощью kubectl get service команды.

   kubectl get service internal-app
   

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

   NAME           TYPE           CLUSTER-IP     EXTERNAL-IP   PORT(S)        AGE
   internal-app   LoadBalancer   10.0.184.168   10.240.0.25   80:30225/TCP   4m
   

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

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

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

• Вам потребуется Kubernetes версии 1.22.x или более поздней.
• Вам нужна существующая группа ресурсов с виртуальной сетью и подсетью. Эта группа ресурсов позволяет создать частную конечную точку. Если у вас нет этих ресурсов, см. статью "Создание виртуальной сети и подсети".

Создание подключения службы "Приватный канал"

1. Создайте манифест службы с именем internal-lb-pls.yaml типа LoadBalancer службы и azure-load-balancer-internal azure-pls-create заметками. Дополнительные варианты см. в документе проектирования интеграции служб Приватный канал Azure.

   apiVersion: v1
   kind: Service
   metadata:
     name: internal-app
     annotations:
       service.beta.kubernetes.io/azure-load-balancer-internal: "true"
       service.beta.kubernetes.io/azure-pls-create: "true"
   spec:
     type: LoadBalancer
     ports:
     - port: 80
     selector:
       app: internal-app
   

2. Разверните внутреннюю подсистему балансировки нагрузки с помощью kubectl apply команды. Эта команда создает подсистему балансировки нагрузки Azure в группе ресурсов узла, подключенной к той же виртуальной сети, что и кластер AKS. Он также создает объект службы Приватный канал, который подключается к конфигурации внешнего IP-адреса подсистемы балансировки нагрузки, связанной со службой Kubernetes.

   kubectl apply -f internal-lb-pls.yaml
   

3. Просмотрите сведения о службе с помощью kubectl get service команды.

   kubectl get service internal-app
   

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

   NAME           TYPE           CLUSTER-IP    EXTERNAL-IP   PORT(S)        AGE
   internal-app   LoadBalancer   10.125.17.53  10.125.0.66   80:30430/TCP   64m
   

4. Просмотрите сведения об объекте службы Приватный канал с помощью az network private-link-service list команды.

   # Create a variable for the node resource group
   
   AKS_MC_RG=$(az aks show -g myResourceGroup --name myAKSCluster --query nodeResourceGroup -o tsv)
   
   # View the details of the Private Link Service object
   
   az network private-link-service list -g $AKS_MC_RG --query "[].{Name:name,Alias:alias}" -o table
   

   Выходные данные должны выглядеть примерно так:

   Name      Alias
   --------  -------------------------------------------------------------------------
   pls-xyz   pls-xyz.abc123-defg-4hij-56kl-789mnop.eastus2.azure.privatelinkservice
   

Создание частной конечной точки для службы "Приватный канал"

Частная конечная точка позволяет приватно подключаться к объекту службы Kubernetes с помощью созданной службы Приватный канал.

• Создайте частную конечную точку az network private-endpoint create с помощью команды.

  # Create a variable for the private link service
  
  AKS_PLS_ID=$(az network private-link-service list -g $AKS_MC_RG --query "[].id" -o tsv)
  
  # Create the private endpoint
  
  $ az network private-endpoint create \
      -g myOtherResourceGroup \
      --name myAKSServicePE \
      --vnet-name myOtherVNET \
      --subnet pe-subnet \
      --private-connection-resource-id $AKS_PLS_ID \
      --connection-name connectToMyK8sService
  

Настройки PLS с помощью заметок

Ниже приведены заметки, которые можно использовать для настройки ресурса PLS.

Номер	значение	Описание	Обязательное поле	По умолчанию.
service.beta.kubernetes.io/azure-pls-create	"true"	Логическое значение, указывающее, требуется ли создать PLS.	Обязательное поле
service.beta.kubernetes.io/azure-pls-name	<PLS name>	Строка, указывающая имя создаваемого ресурса PLS.	Необязательно	"pls-<LB frontend config name>"
service.beta.kubernetes.io/azure-pls-resource-group	Resource Group name	Строка, указывающая имя группы ресурсов, в которой будет создан ресурс PLS.	Необязательно	MC_ resource
service.beta.kubernetes.io/azure-pls-ip-configuration-subnet	<Subnet name>	Строка, указывающая подсеть, в которую будет развертываться PLS. Эта подсеть должна существовать в той же виртуальной сети, что и внутренний пул. IP-адреса NAT PLS выделяются в этой подсети.	Необязательно	Если service.beta.kubernetes.io/azure-load-balancer-internal-subnetиспользуется подсеть ILB. В противном случае используется подсеть по умолчанию из файла конфигурации.
service.beta.kubernetes.io/azure-pls-ip-configuration-ip-address-count	[1-8]	Общее количество выделенных частных IP-адресов NAT.	Необязательно	1
service.beta.kubernetes.io/azure-pls-ip-configuration-ip-address	"10.0.0.7 ... 10.0.0.10"	Разделенный пробелом список статических IP-адресов IPv4 , которые необходимо выделить. (IPv6 сейчас не поддерживается.) Общее число IP-адресов не должно превышать число IP-адресов, указанное в service.beta.kubernetes.io/azure-pls-ip-configuration-ip-address-count. Если указано меньше IP-адресов, остальные динамически выделяются. Первый IP-адрес в списке задается как Primary.	Необязательно	Все IP-адреса динамически выделяются.
service.beta.kubernetes.io/azure-pls-fqdns	"fqdn1 fqdn2"	Разделенный пробелом список полных имен, связанных с PLS.	Необязательно	[]
service.beta.kubernetes.io/azure-pls-proxy-protocol	"true" или "false"	Логическое значение, указывающее, следует ли включить протокол TCP PROXY в PLS для передачи сведений о подключении, включая идентификатор ссылки и исходный IP-адрес. Обратите внимание, что серверная служба должна поддерживать протокол PROXY или подключения завершаются ошибкой.	Необязательно	false
service.beta.kubernetes.io/azure-pls-visibility	"sub1 sub2 sub3 … subN" или "*"	Разделенный пробелом список идентификаторов подписки Azure, для которых отображается служба приватного канала. Используется "*" для предоставления PLS всем дочерним (наименее строгим).	Необязательно	Пустой список [] , указывающий только управление доступом на основе ролей: эта служба приватного канала будет доступна только пользователям с разрешениями управления доступом на основе ролей в каталоге. (Наиболее строгий)
service.beta.kubernetes.io/azure-pls-auto-approval	"sub1 sub2 sub3 … subN"	Разделенный пробелом список идентификаторов подписки Azure. Это позволяет автоматически утверждать запросы на подключение PE из подписок, перечисленных в PLS. Это работает только в том случае, если для видимости задано значение "*".	Необязательно	[]

Использование частных сетей

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

Дополнительные сведения см. в статье о настройке собственных подсетей виртуальной сети с помощью Kubenet или Azure CNI.

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

$ kubectl get service internal-app

NAME           TYPE           CLUSTER-IP    EXTERNAL-IP   PORT(S)        AGE
internal-app   LoadBalancer   10.1.15.188   10.0.0.35     80:31669/TCP   1m

Примечание.

Удостоверение кластера, используемое кластером AKS, должно иметь по крайней мере роль участника сети в ресурсе виртуальной сети. Вы можете просмотреть удостоверение кластера с помощью az aks show команды, например az aks show --resource-group <resource-group-name> --name <cluster-name> --query "identity". Роль участника сети можно назначить с помощью az role assignment create команды, например az role assignment create --assignee <identity-resource-id> --scope <virtual-network-resource-id> --role "Network Contributor".

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

• Microsoft.Network/virtualNetworks/subnets/join/action
• Microsoft.Network/virtualNetworks/subnets/read

Дополнительные сведения см. в разделе "Добавление, изменение" или удаление подсети виртуальной сети.

Назначение другой подсети

• Добавьте заметку azure-load-balancer-internal-subnet в службу, чтобы указать подсеть для подсистемы балансировки нагрузки. Здесь нужно указать подсеть в той же виртуальной сети, где расположен кластер AKS. При развертывании адрес подсистемы EXTERNAL-IP балансировки нагрузки является частью указанной подсети.

  apiVersion: v1
  kind: Service
  metadata:
    name: internal-app
    annotations:
      service.beta.kubernetes.io/azure-load-balancer-internal: "true"
      service.beta.kubernetes.io/azure-load-balancer-internal-subnet: "apps-subnet"
  spec:
    type: LoadBalancer
    ports:
    - port: 80
    selector:
      app: internal-app
  

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

Подсистема балансировки нагрузки удаляется при удалении всех служб.

Как и в случае с любым ресурсом Kubernetes, вы можете напрямую удалить службу, например kubectl delete service internal-app, которая также удаляет базовую подсистему балансировки нагрузки Azure.

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

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