Partager via

Conditions préalables pour le déploiement de charges de travail de locataire

Ce guide explique les conditions préalables à la création :

  • Machines virtuelles (VM) pour les charges de travail de fonctions réseau virtuelles (VNF).
  • Déploiements de clusters Kubernetes Nexus pour les fonctions réseau cloud-native (CNF).

Diagramme d’un flux de déploiement de charge de travail de locataire.

Configuration réseau requise

Vous devez créer différents réseaux en fonction des besoins de votre charge de travail. La liste suivante de considérations n’est pas exhaustive. Consultez les équipes de support appropriées pour obtenir de l’aide.

  • Déterminez les types de réseaux dont vous avez besoin pour prendre en charge vos charges de travail :
    • Un réseau de couche 3 (L3) nécessite une attribution de réseau local virtuel et de sous-réseau. Le sous-réseau doit être suffisamment volumineux pour prendre en charge l’attribution d’adresses IP à chacune des machines virtuelles. La plateforme réserve les trois premières adresses IP utilisables pour une utilisation interne. Par exemple, pour prendre en charge six machines virtuelles, le CIDR minimal pour votre sous-réseau est /28 (14 adresses utilisables – 3 réservées = 11 adresses disponibles).
    • Un réseau de couche 2 (L2) n'a besoin que d'une seule affectation de VLAN.
    • Un réseau à architecture de jonction nécessite l'affectation de plusieurs VLAN.
  • Déterminez le nombre de réseaux de chaque type dont vous avez besoin.
  • Déterminez la taille MTU de chacun de vos réseaux (la valeur maximale est de 9 000).
  • Déterminez les informations de peering BGP pour chaque réseau et précisez si les réseaux ont des besoins de communication entre eux. Vous devez regrouper les réseaux qui doivent communiquer entre eux dans le même domaine d’isolation L3, car chaque domaine d’isolation L3 peut prendre en charge plusieurs réseaux L3.
  • La plateforme fournit un proxy pour permettre à votre machine virtuelle d’atteindre d’autres points de terminaison externes. La création d’une cloudservicesnetwork instance nécessite que les points de terminaison soient proxiés, donc rassemblez la liste des points de terminaison. Vous pouvez modifier la liste des points de terminaison après la création du réseau.

Créer des domaines d’isolation

Les domaines d’isolation permettent la communication entre les charges de travail hébergées dans le même rack (communication intra-rack) ou différents racks (communication inter-rack). Vous trouverez plus d’informations sur la création de domaines d’isolation ici.

Créer des réseaux pour les charges de travail des clients

Les sections suivantes décrivent comment créer ces réseaux :

  • Réseau de couche 2
  • Réseau de couche 3
  • Réseau à jonction

Créer un réseau L2

Créez un réseau L2, si nécessaire, pour vos charges de travail. Vous pouvez répéter les instructions pour chaque réseau L2 requis.

Rassemblez l’ID de ressource du domaine d’isolation L2 que vous avez créé pour configurer le réseau local virtuel pour ce réseau.

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

Créer un réseau L3

Créez un réseau L3, si nécessaire, pour vos charges de travail. Répétez les instructions pour chaque réseau L3 requis.

Ce dont vous avez besoin :

  • Valeur resourceID du domaine d’isolation L3 que vous avez créé pour configurer le réseau local virtuel pour ce réseau.
  • La valeur ipv4-connected-prefix, qui doit correspondre à la valeur i-pv4-connected-prefix se trouvant dans le domaine d’isolation L3.
  • Valeur ipv6-connected-prefix, qui doit correspondre à la valeur i-pv6-connected-prefix dans le domaine d'isolation L3.
  • Valeur ip-allocation-type , qui peut être IPv4, IPv6ou DualStack (par défaut).
  • Valeur vlan , qui doit correspondre à ce qui se trouve dans le domaine d’isolation 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>

Créer un réseau de jonctions

Créez un réseau de jonction, le cas échéant, pour votre machine virtuelle. Répétez les instructions pour chaque réseau trunké requis.

Rassemblez les resourceId valeurs des domaines d’isolation L2 et L3 que vous avez créés précédemment pour configurer les réseaux locaux virtuels pour ce réseau. Vous pouvez inclure autant de domaines d’isolation L2 et L3 que nécessaire.

  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>

Créer un réseau de services cloud

Pour créer une machine virtuelle Operator Nexus ou un cluster Operator Nexus Kubernetes, vous devez disposer d’un réseau de services cloud. Sans ce réseau, vous ne pouvez pas créer de machine virtuelle ou de cluster.

Bien que le réseau de services cloud active automatiquement l'accès aux points de terminaison essentiels de la plateforme, vous devez en ajouter d'autres, tels que docker.io, si votre application en a besoin. La configuration du proxy réseau des services cloud est une étape cruciale pour garantir une connexion réussie à vos points de terminaison souhaités. Pour ce faire, vous pouvez ajouter les points de terminaison de sortie au réseau des services cloud lors de la création initiale ou en tant que mise à jour, à l’aide du --additional-egress-endpoints paramètre. Bien que les caractères génériques des points de terminaison d’URL semblent pratiques, ils ne sont pas recommandés pour des raisons de sécurité. Par exemple, si vous souhaitez configurer le proxy pour autoriser l’extraction d’images à partir d’un référentiel hébergé hors docker.io, vous pouvez spécifier .docker.io comme point de terminaison.

Les points de terminaison de sortie doivent se conformer aux structures de noms de domaine et aux spécifications de nom d’hôte décrites dans RFC 1034, RFC 1035 et RFC 1123. Les noms de domaine valides incluent des caractères alphanumériques, des traits d’union (pas au début ou à la fin) et peuvent avoir des sous-domaines séparés par des points. Les points de terminaison peuvent être un nom de domaine complet unique ou un sous-domaine (préfixe de domaine avec un .). Voici quelques exemples pour illustrer les conventions d’affectation de noms conformes pour les noms de domaine et d’hôte.

  • contoso.com: domaine de base, servant de domaine de second niveau sous le domaine .com de niveau supérieur.
  • sales.contoso.com: sous-domaine de contoso.com, servant de domaine de troisième niveau sous le domaine .com de niveau supérieur.
  • web-server-1.contoso.com: nom d’hôte pour un serveur web spécifique, en utilisant des traits d’union pour séparer les mots et le chiffre.
  • api.v1.contoso.com: incorpore deux sous-domaines (v1 et api) au-dessus du domaine de base contoso.com.
  • .api.contoso.com: caractère générique pour n’importe quel sous-domaine sous api.contoso.com, couvrant plusieurs domaines de troisième niveau.

Les déploiements avec plusieurs appliances de stockage prennent en charge la sélection de l’appliance de stockage à utiliser pour fournir un stockage de système de fichiers partagé aux charges de travail conteneurisées. Le CSN gère le service de stockage partagé qui active le stockage de système de fichiers partagé. Vous ne pouvez sélectionner l’appliance de stockage que lorsque vous créez le CSN. Toutes les tentatives suivantes de modification de la configuration n’ont aucun effet. Le nom de l’appliance de stockage doit correspondre au nom Azure Resource Manager d’une appliance de stockage gérée par votre cluster Nexus. Si aucun nom d’appliance de stockage n’est fourni ou si la configuration ne correspond pas à une appliance de stockage dans l’instance Nexus, l’opérateur Azure Nexus utilise par défaut la première appliance de stockage.

  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 >}]}]"
    --tags "storageApplianceName": "<YourStorageApplianceName>""

Après avoir configuré le réseau de services cloud, vous pouvez l’utiliser pour créer une machine virtuelle ou un cluster qui peut se connecter aux points de terminaison de sortie que vous avez spécifiés. N’oubliez pas que le proxy fonctionne uniquement avec HTTPS.

Note

Pour vous assurer que l’image VNF peut être extraite correctement, vérifiez que l’URL ACR se trouve dans la liste d'autorisation sortante du réseau des services cloud que vous utiliserez avec votre machine virtuelle Opérateur Nexus.

De plus, si votre ACR a des points de terminaison de donnée établis activés, vous devez ajouter tous les nouveaux points de terminaison de donnée à la liste d'autorisation d'égressions. Pour trouver tous les points de terminaison possibles pour votre ACR, suivez l’instruction ici.

Utiliser le proxy pour atteindre en dehors de la machine virtuelle

Après avoir créé votre machine virtuelle Nexus Opérateur ou votre cluster Kubernetes Nexus Opérateur avec ce réseau de services cloud, vous devez également définir des variables d’environnement appropriées dans la machine virtuelle pour utiliser le proxy locataire et accéder vers l'extérieur de celle-ci. Ce proxy de locataire est utile si vous devez accéder aux ressources en dehors de la machine virtuelle, telles que la gestion des packages ou l’installation de logiciels.

Pour utiliser le proxy, vous devez définir les variables d’environnement suivantes :

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

Après avoir défini les variables d’environnement proxy, votre machine virtuelle peut atteindre les points de terminaison de sortie configurés.

Note

HTTP n’est pas pris en charge en raison de raisons de sécurité lors de l’utilisation du proxy pour accéder aux ressources en dehors de la machine virtuelle. Il est nécessaire d’utiliser HTTPS pour une communication sécurisée lors de la gestion des packages ou de l’installation de logiciels sur la machine virtuelle Opérateur Nexus ou le cluster Kubernetes Nexus opérateur avec ce réseau de services cloud.

Important

Lorsque vous utilisez un proxy, il est également important de définir correctement la no_proxy variable d’environnement. Cette variable peut être utilisée pour spécifier des domaines ou des adresses IP qui ne doivent pas être accessibles via le proxy. S’il n’est pas défini correctement, il peut provoquer des problèmes lors de l’accès aux services, tels que le serveur d’API Kubernetes ou l’adresse IP du cluster. Veillez à inclure l’adresse IP ou le nom de domaine du serveur d’API Kubernetes et toutes les adresses IP de cluster dans la no_proxy variable.

Zone de disponibilité du cluster Nexus Kubernetes

Lorsque vous créez un cluster Nexus Kubernetes, vous pouvez planifier le cluster sur des racks spécifiques ou le distribuer sur plusieurs racks. Cette technique peut améliorer l’utilisation des ressources et la tolérance de panne.

Si vous ne spécifiez pas de zone lorsque vous créez un cluster Nexus Kubernetes, la plateforme Azure Operator Nexus implémente automatiquement une règle d’anti-affinité par défaut pour répartir la machine virtuelle sur des racks et des nœuds nus et n’est pas garantie. Cette règle vise également à empêcher la planification de la machine virtuelle du cluster sur un nœud qui possède déjà une machine virtuelle du même cluster, mais il s’agit d’une approche optimale et ne peut pas apporter de garanties.

Pour obtenir la liste des zones disponibles dans l’instance Nexus de l’opérateur Azure, vous pouvez utiliser la commande suivante :

    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
  • Last updated on