Delen via

Vereisten voor het implementeren van tenantworkloads

  • Artikel

In deze handleiding worden de vereisten voor het maken van:

  • Virtuele machines (VM's) voor VF-workloads (Virtual Network Function).
  • Nexus Kubernetes-clusterimplementaties voor cnf-workloads (cloudeigen netwerkfuncties).

Diagram van een implementatiestroom voor tenantworkloads.

Netwerkvereisten

U moet verschillende netwerken maken op basis van uw workloadbehoeften. De volgende lijst met overwegingen is niet volledig. Neem contact op met de juiste ondersteuningsteams voor hulp.

  • Bepaal de typen netwerken die u nodig hebt om uw workloads te ondersteunen:
    • Voor een laag 3-netwerk (L3) is een VLAN- en subnettoewijzing vereist. Het subnet moet groot genoeg zijn om IP-toewijzing aan elk van de VM's te ondersteunen. Het platform reserveert de eerste drie bruikbare IP-adressen voor intern gebruik. Als u bijvoorbeeld zes VM's wilt ondersteunen, is de minimale CIDR voor uw subnet /28 (14 bruikbare adressen – 3 gereserveerd = 11 adressen beschikbaar).
    • Voor een laag 2-netwerk (L2) is slechts één VLAN-toewijzing vereist.
    • Voor een trunk-netwerk is de toewijzing van meerdere VLAN's vereist.
  • Bepaal hoeveel netwerken van elk type u nodig hebt.
  • Bepaal de MTU-grootte van elk van uw netwerken (maximaal 9.000).
  • Bepaal de BGP-peeringgegevens voor elk netwerk en of de netwerken met elkaar moeten communiceren. U moet netwerken groeperen die met elkaar moeten communiceren in hetzelfde L3-isolatiedomein, omdat elk L3-isolatiedomein meerdere L3-netwerken kan ondersteunen.
  • Het platform biedt een proxy waarmee uw virtuele machine andere externe eindpunten kan bereiken. Voor het maken van een cloudservicesnetwork exemplaar moeten de eindpunten worden geproxied, dus verzamel de lijst met eindpunten. U kunt de lijst met eindpunten wijzigen nadat het netwerk is gemaakt.

Isolatiedomeinen maken

De isolatiedomeinen maken communicatie mogelijk tussen workloads die worden gehost in hetzelfde rek (intra-rack communicatie) of verschillende racks (communicatie tussen rekken). Meer informatie over het maken van isolatiedomeinen vindt u hier.

Netwerken maken voor tenantworkloads

In de volgende secties wordt beschreven hoe u deze netwerken maakt:

  • Laag 2-netwerk
  • Laag 3-netwerk
  • Trunked network

Een L2-netwerk maken

Maak indien nodig een L2-netwerk voor uw workloads. U kunt de instructies voor elk vereist L2-netwerk herhalen.

Verzamel de resource-id van het L2-isolatiedomein dat u hebt gemaakt om het VLAN voor dit netwerk te configureren.

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

Een L3-netwerk maken

Maak zo nodig een L3-netwerk voor uw workloads. Herhaal de instructies voor elk vereist L3-netwerk.

U hebt het volgende nodig:

  • De resourceID waarde van het L3-isolatiedomein dat u hebt gemaakt om het VLAN voor dit netwerk te configureren.
  • De ipv4-connected-prefix waarde, die moet overeenkomen met de i-pv4-connected-prefix waarde die zich in het L3-isolatiedomein bevindt.
  • De ipv6-connected-prefix waarde, die moet overeenkomen met de i-pv6-connected-prefix waarde die zich in het L3-isolatiedomein bevindt.
  • De ip-allocation-type waarde, die kan zijn IPv4, IPv6of DualStack (standaard).
  • De vlan waarde, die moet overeenkomen met wat zich in het L3-isolatiedomein bevindt.
  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>

Een trunked netwerk maken

Maak indien nodig een trunked netwerk voor uw VIRTUELE machine. Herhaal de instructies voor elk vereist trunked netwerk.

Verzamel de resourceId waarden van de L2- en L3-isolatiedomeinen die u eerder hebt gemaakt om de VLAN's voor dit netwerk te configureren. U kunt zoveel L2- en L3-isolatiedomeinen opnemen als nodig is.

  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>

Een cloudservicesnetwerk maken

Als u een virtuele Machine (VM) van Operator Nexus of Operator Nexus Kubernetes-cluster wilt maken, moet u een netwerk voor cloudservices hebben. Zonder dit netwerk kunt u geen VM of cluster maken.

Hoewel het cloudservicesnetwerk automatisch toegang biedt tot essentiële platformeindpunten, moet u andere, zoals docker.io, toevoegen als uw toepassing deze nodig heeft. Het configureren van de cloudservicenetwerkproxy is een cruciale stap bij het garanderen van een geslaagde verbinding met uw gewenste eindpunten. Om dit te bereiken, kunt u de uitgaande eindpunten toevoegen aan het cloudservicesnetwerk tijdens het maken of als een update, met behulp van de --additional-egress-endpoints parameter. Hoewel jokertekens voor de URL-eindpunten handig kunnen lijken, wordt het niet aanbevolen om beveiligingsredenen. Als u bijvoorbeeld de proxy wilt configureren om het ophalen van installatiekopieën toe te staan vanuit een opslagplaats die buiten docker.io wordt gehost, kunt u opgeven .docker.io als een eindpunt.

De uitgaande eindpunten moeten voldoen aan de domeinnaamstructuren en hostnaamspecificaties die worden beschreven in RFC 1034, RFC 1035 en RFC 1123. Geldige domeinnamen zijn alfanumerieke tekens, afbreekstreepjes (niet aan het begin of einde) en kunnen subdomeinen gescheiden door puntjes bevatten. De eindpunten kunnen één FQDN of een subdomein (domeinvoorvoegsel met een .). Hier volgen enkele voorbeelden om compatibele naamconventies voor domein- en hostnamen te demonstreren.

  • contoso.com: Het basisdomein, dat fungeert als een domein op het tweede niveau onder het .com domein op het hoogste niveau.
  • sales.contoso.com: Een subdomein van contoso.com, dat fungeert als een domein op het derde niveau onder het .com domein op het hoogste niveau.
  • web-server-1.contoso.com: Een hostnaam voor een specifieke webserver, met behulp van afbreekstreepjes om de woorden en het numerieke getal te scheiden.
  • api.v1.contoso.com: bevat twee subdomeinen (v1 en api) boven het basisdomein contoso.com.
  • .api.contoso.com: Een jokerteken voor elk subdomein onder api.contoso.com, dat betrekking heeft op meerdere domeinen op het derde niveau.
  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 >}]}]"

Nadat u het cloudservicesnetwerk hebt ingesteld, kunt u dit gebruiken om een VIRTUELE machine of cluster te maken die verbinding kan maken met de uitgaande eindpunten die u hebt opgegeven. Houd er rekening mee dat de proxy alleen werkt met HTTPS.

Notitie

Om ervoor te zorgen dat de VNF-installatiekopie correct kan worden opgehaald, moet u ervoor zorgen dat de ACR-URL zich in de lijst met uitgaand verkeer bevindt van het cloudservicesnetwerk dat u gaat gebruiken met de virtuele machine van Operator Nexus.

Als voor uw ACR toegewezen gegevenseindpunten zijn ingeschakeld, moet u bovendien alle nieuwe gegevenseindpunten toevoegen aan de acceptatielijst voor uitgaand verkeer. Volg de instructies hier om alle mogelijke eindpunten voor uw ACR te vinden.

De proxy gebruiken om buiten de virtuele machine te komen

Nadat u uw Operator Nexus VM of Operator Nexus Kubernetes-cluster met dit cloudservicesnetwerk hebt gemaakt, moet u ook de juiste omgevingsvariabelen instellen binnen de VM om tenantproxy te gebruiken en buiten de virtuele machine te komen. Deze tenantproxy is handig als u toegang nodig hebt tot resources buiten de virtuele machine, zoals het beheren van pakketten of het installeren van software.

Als u de proxy wilt gebruiken, moet u de volgende omgevingsvariabelen instellen:

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

Nadat u de proxyomgevingsvariabelen hebt ingesteld, kan uw virtuele machine de geconfigureerde eindpunten voor uitgaand verkeer bereiken.

Notitie

HTTP wordt niet ondersteund vanwege beveiligingsredenen bij het gebruik van de proxy voor toegang tot resources buiten de virtuele machine. Het is vereist om HTTPS te gebruiken voor beveiligde communicatie bij het beheren van pakketten of het installeren van software op de Operator Nexus VM of Operator Nexus Kubernetes-cluster met dit cloudservicesnetwerk.

Belangrijk

Wanneer u een proxy gebruikt, is het ook belangrijk om de no_proxy omgevingsvariabele correct in te stellen. Deze variabele kan worden gebruikt om domeinen of IP-adressen op te geven die niet mogen worden geopend via de proxy. Als deze niet goed is ingesteld, kan dit problemen veroorzaken bij het openen van services, zoals de Kubernetes-API-server of het IP-adres van het cluster. Zorg ervoor dat u het IP-adres of de domeinnaam van de Kubernetes-API-server en eventuele IP-adressen van het cluster in de no_proxy variabele opneemt.

Nexus Kubernetes-clusterbeschikbaarheidszone

Wanneer u een Nexus Kubernetes-cluster maakt, kunt u het cluster plannen op specifieke racks of over meerdere rekken verdelen. Deze techniek kan het resourcegebruik en fouttolerantie verbeteren.

Als u geen zone opgeeft wanneer u een Nexus Kubernetes-cluster maakt, implementeert het Azure Operator Nexus-platform automatisch een standaardregel voor antiaffiniteit om de VIRTUELE machine over racks en bare-metalknooppunten te verdelen en is niet gegarandeerd. Deze regel is ook bedoeld om te voorkomen dat de cluster-VM wordt gepland op een knooppunt dat al een VIRTUELE machine van hetzelfde cluster heeft, maar het is een best-effort aanpak en kan geen garanties bieden.

Als u de lijst met beschikbare zones in het Azure Operator Nexus-exemplaar wilt ophalen, kunt u de volgende opdracht gebruiken:

    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