Condividi tramite

Prerequisiti per la distribuzione dei carichi di lavoro del tenant

  • Articolo

Questa guida illustra i prerequisiti per la creazione:

  • Macchine virtuali per carichi di lavoro VNF (Virtual Network Function).
  • Distribuzioni di cluster Nexus Kubernetes per carichi di lavoro CNF (Cloud Native Network Function).

Diagramma del flusso di distribuzione di un carico di lavoro tenant.

Prerequisiti di rete

È necessario creare diverse reti in base alle esigenze del carico di lavoro. L'elenco seguente di considerazioni non è esaustivo. Per assistenza, consultare i team di supporto appropriati.

  • Determinare i tipi di reti necessarie per supportare i carichi di lavoro:
    • Una rete di livello 3 (L3) richiede un'assegnazione VLAN e subnet. La subnet deve essere sufficientemente grande per supportare l'assegnazione IP a ognuna delle macchine virtuali. La piattaforma riserva i primi tre indirizzi IP utilizzabili per l'uso interno. Ad esempio, per supportare sei macchine virtuali, il CIDR minimo per la subnet è /28 (14 indirizzi – utilizzabili 3 riservati = 11 indirizzi disponibili).
    • Una rete di livello 2 (L2) richiede solo una singola assegnazione VLAN.
    • Una rete trunked richiede l'assegnazione di più VLAN.
  • Determinare il numero di reti di ogni tipo necessario.
  • Determinare le dimensioni MTU di ognuna delle reti (il valore massimo è 9.000).
  • Determinare le informazioni di peering BGP per ogni rete e se le reti devono comunicare tra loro. È necessario raggruppare le reti che devono comunicare tra loro nello stesso dominio di isolamento L3, perché ogni dominio di isolamento L3 può supportare più reti L3.
  • La piattaforma fornisce un proxy per consentire alla macchina virtuale di raggiungere altri endpoint esterni. La creazione di un'istanza di cloudservicesnetwork richiede che gli endpoint vengano inoltrati tramite proxy, quindi raccogliere l'elenco degli endpoint. È possibile modificare l'elenco degli endpoint dopo la creazione della rete.

Creare domini di isolamento

I domini di isolamento consentono la comunicazione tra carichi di lavoro ospitati nello stesso rack (comunicazione tra rack) o rack diversi (comunicazione tra rack). Per altri dettagli sulla creazione di domini di isolamento qui.

Creare reti per carichi di lavoro tenant

Le sezioni seguenti descrivono come creare queste reti:

  • Rete di livello 2
  • Rete di livello 3
  • Rete trunked

Creare una rete L2

Creare una rete L2, se necessario, per i carichi di lavoro. È possibile ripetere le istruzioni per ogni rete L2 richiesta.

Raccogliere l'ID risorsa del dominio di isolamento L2 creato per configurare la VLAN per questa rete.

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

Creare una rete L3

Creare una rete L3, se necessario, per i carichi di lavoro. Ripetere le istruzioni per ogni rete L3 richiesta.

È necessario:

  • Valore resourceID del dominio di isolamento L3 creato per configurare la VLAN per questa rete.
  • Valore ipv4-connected-prefix, che deve corrispondere al valore i-pv4-connected-prefix presente nel dominio di isolamento L3.
  • Valore ipv6-connected-prefix, che deve corrispondere al valore i-pv6-connected-prefix presente nel dominio di isolamento L3.
  • Valore ip-allocation-type, che può essere IPv4, IPv6 o DualStack (impostazione predefinita).
  • Valore vlan, che deve corrispondere a ciò che si trova nel dominio di 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>

Creare una rete trunked

Creare una rete trunked, se necessario, per la macchina virtuale. Ripetere le istruzioni per ogni rete trunked richiesta.

Raccogliere i valori resourceId dei domini di isolamento L2 e L3 creati in precedenza per configurare le VLAN per questa rete. È possibile includere tutti i domini di isolamento L2 e L3 in base alle esigenze.

  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>

Creare una rete di servizi cloud

Per creare una macchina virtuale Operator o un cluster Operator Nexus Kubernetes, è necessario disporre di una rete di servizi cloud. Senza questa rete non è possibile creare una macchina virtuale o un cluster.

Anche se la rete dei servizi cloud consente automaticamente l'accesso agli endpoint della piattaforma essenziali, è necessario aggiungere altri utenti, ad esempio docker.io, se l'applicazione li richiede. La configurazione del proxy di rete dei servizi cloud è una fase cruciale per garantire una connessione di successo agli endpoint desiderati. A tale scopo, è possibile aggiungere gli endpoint in uscita alla rete dei servizi cloud durante la creazione iniziale o come aggiornamento, usando il parametro --additional-egress-endpoints. Anche se i caratteri jolly per gli endpoint URL potrebbero sembrare utili, non è consigliabile per motivi di sicurezza. Ad esempio, se si vuole configurare il proxy per consentire il pull dell'immagine da qualsiasi repository ospitato da docker.io, è possibile specificare .docker.io come endpoint.

Gli endpoint in uscita devono essere conformi alle strutture dei nomi di dominio e alle specifiche dei nomi host descritti in RFC 1034, RFC 1035 e RFC 1123. I nomi di dominio validi includono caratteri alfanumerici, trattini (non all'inizio o alla fine) e possono avere sottodomini separati da punti. Gli endpoint possono essere un singolo FQDN o un sottodominio (prefisso di dominio con un .). Ecco alcuni esempi per illustrare le convenzioni di denominazione conformi per i nomi di dominio e host.

  • contoso.com: dominio di base, che funge da dominio di secondo livello nel dominio di primo livello .com.
  • sales.contoso.com: sottodominio di contoso.com, che funge da dominio di terzo livello nel dominio di primo livello .com.
  • web-server-1.contoso.com: nome host per un server Web specifico, usando trattini per separare le parole e il numero.
  • api.v1.contoso.com: incorpora due sottodomini (v1 e api) sopra il dominio di base contoso.com.
  • .api.contoso.com: carattere jolly per qualsiasi sottodominio in api.contoso.com, che copre più domini di terzo livello.
  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 >}]}]"

Dopo aver configurato la rete dei servizi cloud, è possibile usarla per creare una macchina virtuale o un cluster in grado di connettersi agli endpoint in uscita specificati. Tenere presente che il proxy funziona solo con HTTPS.

Nota

Per assicurarsi che l'immagine della funzione di rete virtualizzata possa essere estratta correttamente, assicurarsi che l'URL del Registro Azure Container si trovi nell'elenco di elementi consentiti della rete di servizi cloud che verrà usata con la macchina virtuale Operatore Nexus.

Inoltre, se il Registro Azure Container dispone di endpoint dati dedicati abilitati, sarà necessario aggiungere tutti i nuovi endpoint dati all'elenco di elementi consentiti in uscita. Per trovare tutti gli endpoint possibili per il Registro Azure Container, seguire l'istruzione qui.

Usare il proxy per raggiungere l'esterno della macchina virtuale

Dopo aver creato la macchina virtuale Operator Nexus o il cluster Operator Nexus Kubernetes con questa rete di servizi cloud, è necessario impostare le variabili di ambiente appropriate all'interno della macchina virtuale per usare il proxy tenant e raggiungere l'esterno della macchina virtuale. Questo proxy tenant è utile se è necessario accedere a risorse esterne alla macchina virtuale, ad esempio la gestione di pacchetti o l'installazione del software.

Per usare il proxy, è necessario impostare le variabili di ambiente seguenti:

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

Dopo aver impostato le variabili di ambiente proxy, la macchina virtuale sarà in grado di raggiungere gli endpoint in uscita configurati.

Nota

HTTP non è supportato a causa di motivi di sicurezza quando si usa il proxy per accedere alle risorse all'esterno della macchina virtuale. È necessario usare HTTPS per la comunicazione sicura quando si gestiscono pacchetti o si installano software nella macchina virtuale Operator Nexus o nel cluster Operator Nexus Kubernetes con questa rete di servizi cloud.

Importante

Quando si usa un proxy, è anche importante impostare correttamente la variabile di ambiente no_proxy. Questa variabile può essere usata per specificare domini o indirizzi IP a cui non è necessario accedere tramite il proxy. Se non è impostato correttamente, può causare problemi durante l'accesso ai servizi, ad esempio il server API Kubernetes o l'IP del cluster. Assicurarsi di includere l'indirizzo IP o il nome di dominio del server API Kubernetes e qualsiasi indirizzo IP del cluster nella variabile no_proxy.

Zona di disponibilità del cluster Nexus Kubernetes

Quando si crea un cluster Nexus Kubernetes, è possibile pianificare il cluster in rack specifici o distribuirlo tra più rack. Questa tecnica può migliorare l'utilizzo delle risorse e la tolleranza di errore.

Se non si specifica una zona quando si crea un cluster Nexus Kubernetes, la piattaforma Nexus Operator Nexus implementa automaticamente una regola di anti-affinità predefinita per distribuire la macchina virtuale tra rack e nodi bare metal e non è garantita. Questa regola mira anche a impedire la pianificazione della macchina virtuale del cluster in un nodo che dispone già di una macchina virtuale dallo stesso cluster, ma è un approccio più efficace e non può fare garanzie.

Per ottenere l'elenco delle zone disponibili nell'istanza di Azure Operator Nexus, è possibile usare il comando seguente:

    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