Предварительные требования для развертывания рабочих нагрузок клиента

  • Статья

В этом руководстве описываются предварительные требования для создания:

  • Виртуальные машины (виртуальные машины) для рабочих нагрузок функции виртуальной сети (VNF).
  • Развертывания кластера Nexus Kubernetes для рабочих нагрузок облачной сетевой функции (CNF).

Схема потока развертывания рабочей нагрузки клиента.

Предварительные требования к сети

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

  • Определите типы сетей, необходимых для поддержки рабочих нагрузок:
    • Для сети уровня 3 (L3) требуется назначение виртуальной локальной сети и подсети. Подсеть должна быть достаточно большой, чтобы поддерживать назначение IP-адресов для каждой из виртуальных машин. Платформа резервирует первые три доступных IP-адреса для внутреннего использования. Например, для поддержки шести виртуальных машин минимальное значение CIDR для подсети равно /28 (14 доступных адресов — 3 зарезервированных = 11 адресов).
    • Для сети уровня 2 (L2) требуется только одно назначение виртуальной локальной сети.
    • Для магистральной сети требуется назначение нескольких виртуальных ЛС.
  • Определите, сколько сетей каждого типа требуется.
  • Определите размер MTU каждой из сетей (максимум 9 000).
  • Определите сведения об пиринге BGP для каждой сети и необходимо ли взаимодействовать с сетями друг с другом. Следует группировать сети, которые должны взаимодействовать друг с другом в одном домене изоляции L3, так как каждый домен изоляции L3 может поддерживать несколько сетей L3.
  • Платформа предоставляет прокси-сервер для предоставления виртуальной машине доступа к другим внешним конечным точкам. cloudservicesnetwork Для создания экземпляра требуется, чтобы конечные точки были прокси-серверы, поэтому соберите список конечных точек. Список конечных точек можно изменить после создания сети.

Создание доменов изоляции

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

Создание сетей для рабочих нагрузок клиента

В следующих разделах описывается создание этих сетей:

  • Сеть уровня 2
  • Сеть уровня 3
  • Магистральная сеть

Создание сети L2

При необходимости создайте сеть L2 для рабочих нагрузок. Инструкции для каждой требуемой сети L2 можно повторить.

Соберите идентификатор ресурса домена изоляции L2, созданного для настройки виртуальной локальной сети для этой сети.

  az networkcloud l2network create --name "<YourL2NetworkName>" \
    --resource-group "<YourResourceGroupName>" \
    --subscription "<YourSubscription>" \
    --extended-location name="<ClusterCustomLocationId>" type="CustomLocation" \
    --location "<ClusterAzureRegion>" \
    --l2-isolation-domain-id "<YourL2IsolationDomainId>"

Создание сети L3

При необходимости создайте сеть L3 для рабочих нагрузок. Повторите инструкции для каждой требуемой сети L3.

Необходимые компоненты:

  • resourceID Значение домена изоляции L3, созданного для настройки виртуальной локальной сети для этой сети.
  • Значение ipv4-connected-prefix , которое должно соответствовать i-pv4-connected-prefix значению, которое находится в домене изоляции L3.
  • Значение ipv6-connected-prefix , которое должно соответствовать i-pv6-connected-prefix значению, которое находится в домене изоляции L3.
  • Значение ip-allocation-type , которое может быть IPv4, IPv6или DualStack (по умолчанию).
  • Значение vlan , которое должно соответствовать тому, что находится в домене изоляции L3.
  az networkcloud l3network create --name "<YourL3NetworkName>" \
    --resource-group "<YourResourceGroupName>" \
    --subscription "<YourSubscription>" \
    --extended-location name="<ClusterCustomLocationId>" type="CustomLocation" \
    --location "<ClusterAzureRegion>" \
    --ip-allocation-type "<YourNetworkIpAllocation>" \
    --ipv4-connected-prefix "<YourNetworkIpv4Prefix>" \
    --ipv6-connected-prefix "<YourNetworkIpv6Prefix>" \
    --l3-isolation-domain-id "<YourL3IsolationDomainId>" \
    --vlan <YourNetworkVlan>

Создание магистральной сети

При необходимости создайте магистральную сеть для виртуальной машины. Повторите инструкции для каждой требуемой магистральной сети.

resourceId Соберите значения доменов изоляции L2 и L3, созданных ранее для настройки виртуальных ЛС для этой сети. При необходимости можно включить столько доменов изоляции L2 и L3.

  az networkcloud trunkednetwork create --name "<YourTrunkedNetworkName>" \
    --resource-group "<YourResourceGroupName>" \
    --subscription "<YourSubscription>" \
    --extended-location name="<ClusterCustomLocationId>" type="CustomLocation" \
    --location "<ClusterAzureRegion>" \
    --interface-name "<YourNetworkInterfaceName>" \
    --isolation-domain-ids \
      "<YourL3IsolationDomainId1>" \
      "<YourL3IsolationDomainId2>" \
      "<YourL2IsolationDomainId1>" \
      "<YourL2IsolationDomainId2>" \
      "<YourL3IsolationDomainId3>" \
    --vlans <YourVlanList>

Создание сети облачных служб

Чтобы создать виртуальную машину Оператора Nexus или кластер Nexus Kubernetes, необходимо иметь сеть облачных служб. Без этой сети невозможно создать виртуальную машину или кластер.

Хотя сеть облачных служб автоматически обеспечивает доступ к основным конечным точкам платформы, необходимо добавить других пользователей, например docker.io, если приложение требует их. Настройка прокси-сервера сети облачных служб является важным шагом в обеспечении успешного подключения к нужным конечным точкам. Для этого можно добавить конечные точки исходящего трафика в сеть облачных служб во время первоначального создания или в качестве обновления с помощью --additional-egress-endpoints параметра. Хотя дикие карта для конечных точек URL-адреса могут показаться удобными, не рекомендуется по соображениям безопасности. Например, если вы хотите настроить прокси-сервер, чтобы разрешить извлечение образа из любого репозитория, размещенного вне docker.io, можно указать .docker.io в качестве конечной точки.

Конечные точки исходящего трафика должны соответствовать структурам доменных имен и спецификациям имен узлов, описанным в RFC 1034, RFC 1035 и RFC 1123. Допустимые доменные имена включают буквенно-цифровые символы, дефисы (не в начале или конце) и могут иметь поддомены, разделенные точками. Конечные точки могут быть одним полным доменом или поддоменом (префиксом домена с a .). Ниже приведены несколько примеров для демонстрации соглашений об именовании в соответствии с соглашениями об именовании домена и узла.

  • contoso.com: базовый домен, обслуживающийся в качестве домена второго уровня в .com домен верхнего уровня.
  • sales.contoso.com: поддомен contoso.com, который служит в качестве домена третьего уровня в .com домене верхнего уровня.
  • web-server-1.contoso.com: имя узла для определенного веб-сервера с помощью дефисов для разделения слов и числовых.
  • api.v1.contoso.com: включает два поддомена (v1 и api) над базовым доменом contoso.com.
  • .api.contoso.com: дикий карта для любого поддомена, api.contoso.comохватывающего несколько доменов третьего уровня.
  az networkcloud cloudservicesnetwork create --name "<YourCloudServicesNetworkName>" \
    --resource-group "<YourResourceGroupName >" \
    --subscription "<YourSubscription>" \
    --extended-location name="<ClusterCustomLocationId >" type="CustomLocation" \
    --location "<ClusterAzureRegion>" \
    --additional-egress-endpoints "[{\"category\":\"<YourCategory >\",\"endpoints\":[{\"<domainName1 >\":\"< endpoint1 >\",\"port\":<portnumber1 >}]}]"

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

Примечание.

Чтобы убедиться, что образ VNF можно извлечь правильно, убедитесь, что URL-адрес ACR находится в списке исходящих разрешений сети облачных служб, которую вы будете использовать с виртуальной машиной Operator Nexus.

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

Использование прокси-сервера для доступа за пределами виртуальной машины

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

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

export HTTPS_PROXY=http://169.254.0.11:3128
export https_proxy=http://169.254.0.11:3128

После задания переменных среды прокси-сервера виртуальная машина сможет получить доступ к настроенным конечным точкам исходящего трафика.

Примечание.

HTTP не поддерживается из-за причин безопасности при использовании прокси-сервера для доступа к ресурсам за пределами виртуальной машины. Необходимо использовать ПРОТОКОЛ HTTPS для безопасного взаимодействия при управлении пакетами или установке программного обеспечения на виртуальной машине Оператора Nexus или кластере Nexus Kubernetes с этой сетью облачных служб.

Внимание

При использовании прокси-сервера также важно правильно задать no_proxy переменную среды. Эту переменную можно использовать для указания доменов или IP-адресов, к которым не следует обращаться через прокси-сервер. Если не задано правильно, это может привести к проблемам при доступе к службам, таким как сервер API Kubernetes или IP-адрес кластера. Обязательно включите IP-адрес или доменное имя сервера API Kubernetes и все IP-адреса кластера в переменной no_proxy .

Зона доступности кластера Nexus Kubernetes

При создании кластера Nexus Kubernetes можно запланировать кластер на определенные стойки или распределить его по нескольким стойкам. Этот метод может улучшить использование ресурсов и отказоустойчивость.

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

Чтобы получить список доступных зон в экземпляре Оператора Azure Nexus, можно использовать следующую команду:

    az networkcloud cluster show \
      --resource-group <Azure Operator Nexus on-premises cluster resource group> \
      --name <Azure Operator Nexus on-premises cluster name> \
      --query computeRackDefinitions[*].availabilityZone