Бөлісу құралы:

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

  • Мақала

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

В этой статье описывается создание статического общедоступного IP-адреса и его назначение службе Kubernetes.

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

  • Вам понадобится Azure CLI версии 2.0.59 или более поздней версии. Чтобы узнать версию, выполните команду az --version. Если вам необходимо выполнить установку или обновление, см. статью Установка Azure CLI 2.0.
  • В этой статье рассматривается использование IP-адреса с номером SKU Стандартный и подсистемы балансировки нагрузки с номером SKUСтандартный. Дополнительные сведения см. в статье Типы IP-адресов и методы их распределения в Azure.

Создание кластера AKS

  1. Создайте группу ресурсов Azure с помощью az group create команды.

    az group create --name myNetworkResourceGroup --location eastus

  2. Создайте кластер AKS с помощью az aks create команды.

    az aks create --name myAKSCluster --resource-group myNetworkResourceGroup --generate-ssh-keys

Создание статического IP-адреса

  1. Получите имя группы ресурсов узла с помощью az aks show команды и запроса для nodeResourceGroup свойства.

    az aks show --name myAKSCluster --resource-group myNetworkResourceGroup --query nodeResourceGroup -o tsv

  2. Создайте статический общедоступный IP-адрес в группе ресурсов узла с помощью az network public ip create команды.

    az network public-ip create \
    --resource-group <node resource group name> \
    --name myAKSPublicIP \
    --sku Standard \
    --allocation-method static

    Примечание.

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

  3. Получите статический общедоступный IP-адрес с помощью az network public-ip list команды. Укажите имя созданной группы ресурсов узла и общедоступный IP-адрес и запросите для нее ipAddress.

    az network public-ip show --resource-group <node resource group name> --name myAKSPublicIP --query ipAddress --output tsv

Создание службы со статическим IP-адресом

  1. Сначала определите тип управляемого удостоверения, используемого кластером AKS, назначаемого системой или назначаемого пользователем. Если вы не уверены, вызовите команду az aks show и запросите свойство типа удостоверения.

    az aks show \
    --name myAKSCluster \
    --resource-group myResourceGroup \
    --query identity.type \
    --output tsv

    Если кластер использует управляемое удостоверение, значение свойства типа будет иметь значение SystemAssigned или UserAssigned.

    Если кластер использует субъект-службу, значение свойства типа будет иметь значение NULL. Рассмотрите возможность обновления кластера для использования управляемого удостоверения.

  2. Если кластер AKS использует управляемое удостоверение, назначаемое системой, запросите идентификатор субъекта управляемого удостоверения следующим образом:

    # Get the principal ID for a system-assigned managed identity.
CLIENT_ID=$(az aks show \
    --name myAKSCluster \
    --resource-group myNetworkResourceGroup \
    --query identity.principalId \
    --output tsv)

    Если кластер AKS использует управляемое удостоверение, назначаемое пользователем, идентификатор субъекта будет иметь значение NULL. Запросите идентификатор клиента управляемого удостоверения, назначаемого пользователем, вместо этого:

    # Get the client ID for a user-assigned managed identity.
CLIENT_ID=$(az aks show \
    --name myAKSCluster \
    --resource-group myNetworkResourceGroup \
    --query identity.userAssignedIdentities.*.clientId \
    --output tsv

  3. Назначьте делегированные разрешения для управляемого удостоверения, используемого кластером AKS для группы ресурсов общедоступного IP-адреса, вызвав az role assignment create команду.

    # Get the resource ID for the node resource group.
RG_SCOPE=$(az group show \
    --name <node resource group> \
    --query id \
    --output tsv)

# Assign the Network Contributor role to the managed identity,
# scoped to the node resource group.
az role assignment create \
    --assignee ${CLIENT_ID} \
    --role "Network Contributor" \
    --scope ${RG_SCOPE}

    Внимание

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

  4. Создайте файл с именем load-balancer-service.yaml и скопируйте содержимое следующего ФАЙЛА YAML, указав собственный общедоступный IP-адрес, созданный на предыдущем шаге, и имя группы ресурсов узла.

    Внимание

    loadBalancerIP Добавление свойства в манифест YAML подсистемы балансировки нагрузки устарело после вышестоящего Kubernetes. Хотя текущее использование остается неизменным и существующие службы, как ожидается, работают без изменений, мы настоятельно рекомендуем задать заметки службы. Чтобы задать заметки службы, можно использовать service.beta.kubernetes.io/azure-pip-name для общедоступного IP-имени или service.beta.kubernetes.io/azure-load-balancer-ipv4 использовать для IPv4-адреса и service.beta.kubernetes.io/azure-load-balancer-ipv6 для IPv6-адреса, как показано в примере YAML.

    apiVersion: v1
kind: Service
metadata:
  annotations:
    service.beta.kubernetes.io/azure-load-balancer-resource-group: <node resource group name>
    service.beta.kubernetes.io/azure-pip-name: myAKSPublicIP
  name: azure-load-balancer
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: azure-load-balancer

    Примечание.

    service.beta.kubernetes.io/azure-pip-name Добавление заметки гарантирует наиболее эффективное создание LoadBalancer и настоятельно рекомендуется избежать потенциального регулирования.

  5. Задайте общедоступную метку DNS для службы с помощью заметки service.beta.kubernetes.io/azure-dns-label-name службы. Эта служба публикует полное доменное имя (FQDN) для службы с помощью общедоступных DNS-серверов Azure и домена верхнего уровня. Значение заметки должно быть уникальным в расположении Azure, поэтому рекомендуется использовать достаточно квалифицированную метку. Azure автоматически добавляет суффикс по умолчанию в выбранном расположении, например <location>.cloudapp.azure.comв указанное имя, создав полное доменное имя.

    Примечание.

    Если вы хотите опубликовать службу в собственном домене, ознакомьтесь с azure DNS и проектом внешнего DNS .

    apiVersion: v1
kind: Service
metadata:
  annotations:
    service.beta.kubernetes.io/azure-load-balancer-resource-group: <node resource group name>
    service.beta.kubernetes.io/azure-pip-name: myAKSPublicIP
    service.beta.kubernetes.io/azure-dns-label-name: <unique-service-label>
  name: azure-load-balancer
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: azure-load-balancer

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

    kubectl apply -f load-balancer-service.yaml

  7. Чтобы просмотреть метку DNS для подсистемы балансировки нагрузки, используйте kubectl describe service команду.

    kubectl describe service azure-load-balancer

    Метка DNS будет указана в Annotationsсписке, как показано в следующем сжатом примере выходных данных:

    Name:                    azure-load-balancer
Namespace:               default
Labels:                  <none>
Annotations:             service.beta.kuberenetes.io/azure-dns-label-name: <unique-service-label>

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

Если статический IP-адрес, определенный в свойстве манифеста службы Kubernetes, не существует или не был создан в loadBalancerIP группе ресурсов узла и нет других делегирований, создание службы балансировки нагрузки завершается ошибкой. Чтобы устранить неполадки, просмотрите события создания службы с помощью kubectl describe команды. Укажите имя службы, указанной в манифесте YAML, как показано в следующем примере:

kubectl describe service azure-load-balancer

В выходных данных отображаются сведения о ресурсе службы Kubernetes. В следующем примере выходных данных показано Warning в следующем примере : Events"user supplied IP address was not found". В этом сценарии убедитесь, что вы создали статический общедоступный IP-адрес в группе ресурсов узла и что IP-адрес, указанный в манифесте службы Kubernetes, правильно.

Name:                     azure-load-balancer
Namespace:                default
Labels:                   <none>
Annotations:              <none>
Selector:                 app=azure-load-balancer
Type:                     LoadBalancer
IP:                       10.0.18.125
IP:                       40.121.183.52
Port:                     <unset>  80/TCP
TargetPort:               80/TCP
NodePort:                 <unset>  32582/TCP
Endpoints:                <none>
Session Affinity:         None
External Traffic Policy:  Cluster
Events:
  Type     Reason                      Age               From                Message
  ----     ------                      ----              ----                -------
  Normal   CreatingLoadBalancer        7s (x2 over 22s)  service-controller  Creating load balancer
  Warning  CreatingLoadBalancerFailed  6s (x2 over 12s)  service-controller  Error creating load balancer (will retry): Failed to create load balancer for service default/azure-load-balancer: user supplied IP Address 40.121.183.52 was not found

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

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