Partilhar via

Pré-requisitos para implantar cargas de trabalho de locatário

  • Artigo

Este guia explica os pré-requisitos para criar:

  • Máquinas virtuais (VMs) para cargas de trabalho de função de rede virtual (VNF).
  • Implantações de cluster Nexus Kubernetes para cargas de trabalho CNF (função de rede nativa da nuvem).

Diagrama de um fluxo de implantação de carga de trabalho de locatário.

Pré-requisitos de rede

Você precisa criar várias redes com base em suas necessidades de carga de trabalho. A lista de considerações a seguir não é exaustiva. Consulte as equipes de suporte apropriadas para obter ajuda.

  • Determine os tipos de redes de que você precisa para suportar suas cargas de trabalho:
    • Uma rede de camada 3 (L3) requer uma atribuição de VLAN e sub-rede. A sub-rede deve ser grande o suficiente para suportar a atribuição de IP a cada uma das VMs. A plataforma reserva os três primeiros endereços IP utilizáveis para uso interno. Por exemplo, para suportar seis VMs, o CIDR mínimo para sua sub-rede é /28 (14 endereços utilizáveis – 3 reservados = 11 endereços disponíveis).
    • Uma rede de camada 2 (L2) requer apenas uma única atribuição de VLAN.
    • Uma rede troncalizada requer a atribuição de várias VLANs.
  • Determine quantas redes de cada tipo você precisa.
  • Determine o tamanho da MTU de cada uma das suas redes (máximo é 9.000).
  • Determine as informações de emparelhamento BGP para cada rede e se as redes precisam conversar entre si. Você deve agrupar redes que precisam conversar entre si no mesmo domínio de isolamento L3, porque cada domínio de isolamento L3 pode suportar várias redes L3.
  • A plataforma fornece um proxy para permitir que sua VM alcance outros pontos de extremidade externos. A criação de uma cloudservicesnetwork instância requer que os pontos de extremidade sejam intermediados por proxy, portanto, reúna a lista de pontos de extremidade. Você pode modificar a lista de pontos de extremidade após a criação da rede.

Criar domínios de isolamento

Os domínios de isolamento permitem a comunicação entre cargas de trabalho hospedadas no mesmo rack (comunicação intra-rack) ou racks diferentes (comunicação entre racks). Você pode encontrar mais detalhes sobre a criação de domínios de isolamento aqui.

Criar redes para cargas de trabalho de locatários

As seções a seguir descrevem como criar essas redes:

  • Rede de camada 2
  • Rede de camada 3
  • Rede troncalizada

Criar uma rede L2

Crie uma rede L2, se necessário, para suas cargas de trabalho. Você pode repetir as instruções para cada rede L2 necessária.

Reúna a ID do recurso do domínio de isolamento L2 que você criou para configurar a VLAN para esta rede.

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

Criar uma rede L3

Crie uma rede L3, se necessário, para suas cargas de trabalho. Repita as instruções para cada rede L3 necessária.

Necessita de:

  • O resourceID valor do domínio de isolamento L3 que você criou para configurar a VLAN para esta rede.
  • O ipv4-connected-prefix valor, que deve corresponder ao i-pv4-connected-prefix valor que está no domínio de isolamento L3.
  • O ipv6-connected-prefix valor, que deve corresponder ao i-pv6-connected-prefix valor que está no domínio de isolamento L3.
  • O ip-allocation-type valor, que pode ser IPv4, IPv6ou DualStack (padrão).
  • O vlan valor, que deve corresponder ao que está no domínio de isolamento 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>

Criar uma rede troncalizada

Crie uma rede troncalizada, se necessário, para sua VM. Repita as instruções para cada rede troncalizada necessária.

Reúna os resourceId valores dos domínios de isolamento L2 e L3 criados anteriormente para configurar as VLANs para esta rede. Você pode incluir quantos domínios de isolamento L2 e L3 forem necessários.

  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>

Criar uma rede de serviços na nuvem

Para criar uma máquina virtual (VM) Nexus do Operador ou um cluster Kubernetes do Nexus do Operador, você deve ter uma rede de serviços em nuvem. Sem essa rede, não é possível criar uma VM ou cluster.

Embora a rede de serviços em nuvem permita automaticamente o acesso a pontos de extremidade de plataforma essenciais, você precisa adicionar outros, como docker.io, se seu aplicativo exigir. Configurar o proxy de rede de serviços em nuvem é uma etapa crucial para garantir uma conexão bem-sucedida com seus pontos de extremidade desejados. Para conseguir isso, você pode adicionar os pontos de extremidade de saída à rede de serviços de nuvem durante a criação inicial ou como uma atualização, usando o --additional-egress-endpoints parâmetro. Embora os curingas para os pontos de extremidade de URL possam parecer convenientes, isso não é recomendado por motivos de segurança. Por exemplo, se você quiser configurar o proxy para permitir a extração de imagens de qualquer repositório hospedado fora docker.io, poderá especificar .docker.io como um ponto de extremidade.

Os pontos de extremidade de saída devem estar em conformidade com as estruturas de nome de domínio e especificações de nome de host descritas em RFC 1034, RFC 1035 e RFC 1123. Os nomes de domínio válidos incluem caracteres alfanuméricos, hífenes (não no início ou no fim) e podem ter subdomínios separados por pontos. Os pontos de extremidade podem ser um único FQDN ou um subdomínio (prefixo de domínio com um .). Aqui estão alguns exemplos para demonstrar convenções de nomenclatura compatíveis para nomes de domínio e host.

  • contoso.com: O domínio base, servindo como um domínio de segundo nível sob o .com domínio de nível superior.
  • sales.contoso.com: Um subdomínio de contoso.com, servindo como um domínio de terceiro nível sob o .com domínio de nível superior.
  • web-server-1.contoso.com: Um nome de host para um servidor Web específico, usando hífenes para separar as palavras e o numeral.
  • api.v1.contoso.com: Incorpora dois subdomínios (v1 e api) acima do domínio base contoso.com.
  • .api.contoso.com: Um curinga para qualquer subdomínio em api.contoso.com, abrangendo vários domínios de terceiro nível.
  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 >}]}]"

Depois de configurar a rede de serviços de nuvem, você pode usá-la para criar uma VM ou cluster que possa se conectar aos pontos de extremidade de saída especificados. Lembre-se de que o proxy só funciona com HTTPS.

Nota

Para garantir que a imagem VNF possa ser puxada corretamente, verifique se a URL ACR está na lista de permissões de saída da rede de serviços de nuvem que você usará com sua máquina virtual Operator Nexus.

Além disso, se o ACR tiver pontos de extremidade de dados dedicados habilitados, você precisará adicionar todos os novos pontos de extremidade de dados à lista de permissões de saída. Para encontrar todos os endpoints possíveis para o seu ACR, siga as instruções aqui.

Usar o proxy para alcançar fora da máquina virtual

Depois de criar sua VM Nexus Operador ou cluster Kubernetes Nexus Operador com essa rede de serviços em nuvem, você precisa definir adicionalmente variáveis de ambiente apropriadas dentro da VM para usar proxy de locatário e alcançar fora da máquina virtual. Esse proxy de locatário é útil se você precisar acessar recursos fora da máquina virtual, como gerenciar pacotes ou instalar software.

Para usar o proxy, você precisa definir as seguintes variáveis de ambiente:

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

Depois de definir as variáveis de ambiente de proxy, sua máquina virtual poderá alcançar os pontos de extremidade de saída configurados.

Nota

HTTP não é suportado devido a razões de segurança ao usar o proxy para acessar recursos fora da máquina virtual. É necessário usar HTTPS para comunicação segura ao gerenciar pacotes ou instalar software na VM Nexus do Operador ou no cluster Kubernetes do Operador Nexus com essa rede de serviços em nuvem.

Importante

Ao usar um proxy, também é importante definir a no_proxy variável de ambiente corretamente. Essa variável pode ser usada para especificar domínios ou endereços IP que não devem ser acessados por meio do proxy. Se não estiver definido corretamente, pode causar problemas ao acessar serviços, como o servidor de API do Kubernetes ou o IP do cluster. Certifique-se de incluir o endereço IP ou nome de domínio do servidor de API do Kubernetes e quaisquer endereços IP de no_proxy cluster na variável.

Zona de disponibilidade do cluster Nexus Kubernetes

Ao criar um cluster Nexus Kubernetes, você pode programar o cluster em racks específicos ou distribuí-lo em vários racks. Esta técnica pode melhorar a utilização de recursos e a tolerância a falhas.

Se você não especificar uma zona ao criar um cluster Nexus Kubernetes, a plataforma Nexus do Operador do Azure implementará automaticamente uma regra de antiafinidade padrão para espalhar a VM entre racks e nós bare metal e não é garantida. Essa regra também visa impedir o agendamento da VM do cluster em um nó que já tenha uma VM do mesmo cluster, mas é uma abordagem de melhor esforço e não pode fazer garantias.

Para obter a lista de zonas disponíveis na instância do Azure Operator Nexus, você pode usar o seguinte comando:

    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