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

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

Примечание.

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

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

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

  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
    
  1. Просмотрите сведения о службе с помощью 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
    

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

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

  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.