Compartilhar 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 do Nexus Kubernetes para cargas de trabalho de função de rede nativa de nuvem (CNF).

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

Pré-requisitos de rede

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

  • Determine os tipos de redes de que você precisa para dar suporte às 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 a fim de dar suporte à atribuição de IP para cada uma das VMs. Os três primeiros endereços IP utilizáveis são reservados para uso interno pela plataforma. Por exemplo, para dar suporte a seis VMs, o CIDR mínimo da sub-rede é /28 (14 endereços utilizáveis - 3 reservados = 11 endereços disponíveis).
    • Uma rede de camada 2 (L2) requer somente uma única atribuição de VLAN.
    • Uma rede com tronco requer a atribuição de várias VLANs.
  • Determine quantas redes de cada tipo você precisa.
  • Como determinar o tamanho da MTU de cada uma das redes (o máximo é 9.000).
  • Determine as informações de emparelhamento de BGP para cada rede e saber se as redes precisam se comunicar. É necessário agrupar as redes que precisam se comunicar umas com as outras no mesmo domínio de isolamento de L3, porque cada domínio desse tipo pode dar suporte a diversas redes L3.
  • A plataforma fornece um proxy que permitirá que a VM acesse outros pontos de extremidade externos. A criação de uma instância cloudservicesnetwork exige que os pontos de extremidade sejam proxies, 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 como criar domínios de isolamento aqui.

Criar redes para cargas de trabalho de locatário

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

  • Rede de camada 2
  • Rede de camada 3
  • Rede de tronco

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 exigida.

Reúna a ID do recurso do domínio de isolamento L2 que você criou para configurar a VLAN desta 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 exigida.

Você precisa de:

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

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

Reúna os valores resourceId dos domínios de isolamento L2 e L3 que você criou anteriormente para configurar as VLANs desta 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 rede de serviços de nuvem

Para criar uma VM (máquina virtual) do Operador Nexus ou um cluster Kubernetes do Operador Nexus, você precisa ter uma rede de serviços de nuvem. Sem essa rede, você não pode criar uma VM nem um cluster.

Embora a rede de serviços de nuvem habilite automaticamente o acesso a pontos de extremidade de plataforma essenciais, você precisará adicionar outros, como docker.io, se o aplicativo exigir. Configurar o proxy de rede dos serviços de nuvem é uma etapa crucial para garantir uma conexão bem-sucedida com seus pontos de extremidade desejados. Para fazer 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 parâmetro --additional-egress-endpoints. Embora curingas para os pontos de extremidade de URL possam parecer convenientes, usá-los dessa maneira não é recomendado por motivos de segurança. Por exemplo, se você quiser configurar o proxy para permitir o pull de imagem de qualquer repositório hospedado fora do docker.io, poderá especificar .docker.io como um ponto de extremidade.

Os pontos de extremidade de saída precisam estar em conformidade com as estruturas de nome de domínio e as especificações de nome de host descritas no RFC 1034, RFC 1035 e RFC 1123. Os nomes de domínio válidos incluem caracteres alfanuméricos, hifens (não no início nem no final) 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 em conformidade para nomes de domínio e de host.

  • contoso.com: o domínio base, servindo como um domínio de segundo nível no domínio .com de nível superior.
  • sales.contoso.com: um subdomínio de contoso.com, servindo como um domínio de terceiro nível no domínio .com de nível superior.
  • web-server-1.contoso.com: um nome de host para um servidor Web específico, usando hifens 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, cobrindo 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ê poderá 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.

Observação

Para garantir que a imagem da VNF possa ser recuperada corretamente, verifique se a URL do 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 do 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 localizar todos os pontos de extremidade possíveis para o ACR, siga as instruções aqui.

Usar o proxy para acessar fora da máquina virtual

Depois de criar a VM do Operador Nexus ou o cluster Kubernetes do Operador Nexus com essa rede de serviços de nuvem, você precisará definir também as variáveis de ambiente apropriadas dentro da VM para usar o proxy de locatário e alcançar fora da máquina virtual. Este proxy de locatário será ú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.

Observação

Não há suporte para HTTP devido a motivos 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 do Operador Nexus ou no cluster kubernetes do Operador Nexus com essa rede de serviços de nuvem.

Importante

Ao usar um proxy, também é importante definir a variável de ambiente no_proxy 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 for definida corretamente, poderá causar problemas ao acessar serviços, como o servidor de API do Kubernetes ou o IP do cluster. Inclua o endereço IP ou o nome de domínio do servidor de API do Kubernetes e todos os endereços IP do cluster na variável no_proxy.

Zona de disponibilidade de clusters do Nexus Kubernetes

Ao criar um cluster do Nexus Kubernetes, você pode agendar o cluster em racks específicos ou distribuí-lo entre vários racks. Essa 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 do Nexus Kubernetes, a plataforma Nexus do Operador do Azure implementará automaticamente uma regra antiafinidade padrão para espalhar a VM entre racks e nós bare-metal, mas a efetividade dela não é garantida. Essa regra também visa impedir o agendamento da VM do cluster em um nó que já tem uma VM do mesmo cluster, mas é uma abordagem de melhor esforço e não há garantias.

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

    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