Partager via

Conditions préalables au déploiement des charges de travail de tenant

  • Article

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

  • Les machines virtuelles pour des charges de travail de fonction de réseau virtuel (VNF).
  • Déploiements de clusters Nexus Kubernetes pour des charges de travail de fonctions de réseau natives cloud (CNF).

Diagramme d’un flux de déploiement de charges de travail de tenant.

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. Pour obtenir de l’aide, consultez les équipes de support appropriées.

  • 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 VLAN et de sous-réseau. Le sous-réseau doit être suffisamment grand 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 un usage interne. Par exemple, pour prendre en charge six machines virtuelles, la valeur CIDR minimale pour votre sous-réseau est /28 (14 adresses utilisables – 3 réservées = 11 adresses disponibles).
    • Un réseau de couche 2 (L2) ne nécessite qu’une seule attribution de VLAN.
    • Un réseau à jonctions nécessite l’attribution 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 (9 000 au maximum).
  • Déterminez les informations de Peering BGP pour chaque réseau et si les réseaux doivent communiquer entre eux. Vous devez regrouper des 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 de couche 3.
  • La plateforme fournit un proxy pour permettre à votre machine virtuelle d’atteindre d’autres points de terminaison externes. La création d’une instance cloudservicesnetwork nécessite que les points de terminaison soient en proxy. Par conséquent, rassemblez la liste des points de terminaison. Après la création du réseau, vous pouvez modifier la liste des points de terminaison.

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 des charges de travail de locataire

Dans les sections suivantes, découvrez comment créer ces réseaux :

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

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 nécessaire.

Recueillir l’ID de ressource du domaine d’isolation L2 que vous avez créé pour configurer le VLAN de 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éter les instructions pour chaque réseau L3 nécessaire.

Ce dont vous avez besoin :

  • La valeur resourceID du domaine d’isolation L3 que vous avez créé pour configurer le VLAN de ce réseau.
  • Le ipv4-connected-prefix, qui doit correspondre au i-pv4-connected-prefix présent dans le domaine d’isolation L3.
  • Le ipv6-connected-prefix, qui doit correspondre au i-pv6-connected-prefix présent dans le domaine d’isolation L3.
  • Le ip-allocation-type, qui peut être IPv4, IPv6 ou DualStack (valeur par défaut).
  • La valeur vlan, qui doit correspondre à celle présente 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 à jonctions

Créer un réseau à jonctions, au besoin, pour votre machine virtuelle. Répéter les instructions pour chaque réseau à jonctions nécessaire.

Recueillir les resourceId des domaines d’isolation L2 et L3 que vous avez créés précédemment pour configurer les VLAN de 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 (VM) 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 permette automatiquement l'accès aux points d'extrémité de la plateforme essentiels, vous devez en ajouter d'autres, tels que docker.io, si votre application en a besoin. La configuration du proxy du réseau de services en nuage est une étape cruciale pour garantir une connexion réussie aux points d'extrémité 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 paramètre --additional-egress-endpoints. Bien que l'utilisation de caractères génériques pour les points de terminaison des URL puisse sembler pratique, elle n'est pas recommandée 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 être conformes aux structures de noms de domaine et aux spécifications de noms d'hôte décrites dans les RFC 1034, RFC 1035 et RFC 1123. Les noms de domaine valides comprennent des caractères alphanumériques, des traits d'union (ni au début ni à la fin) et peuvent comporter 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 de conventions de nommage conformes pour les noms de domaine et les noms 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 tous les sous-domaines sous api.contoso.com, couvrant plusieurs domaines de troisième 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 >}]}]"

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 ne fonctionne qu’avec HTTPS.

Remarque

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

En outre, si les points de terminaison de données dédiés sont activés sur votre ACR, vous devrez ajouter tous les nouveaux points de terminaison de données à la liste d’autorisation de sortie. Pour trouver tous les points de terminaison possibles pour votre ACR, suivez les instructions ici.

Utilisez le proxy pour accéder à l’extérieur de la machine virtuelle

Après avoir créé votre machine virtuelle Operator Nexus ou votre cluster Operator Nexus Kubernetes avec ce réseau de services cloud, vous devez également définir les variables d'environnement appropriées dans la machine virtuelle pour utiliser le proxy du locataire et atteindre l'extérieur de la machine virtuelle. Ce proxy de locataire est utile si vous devez accéder à des ressources en dehors de la machine virtuelle, comme la gestion de paquets 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 du proxy, votre machine virtuelle sera en mesure d'atteindre les points de terminaison de sortie configurés.

Remarque

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

Important

Quand vous utilisez un proxy, il est également important de définir correctement la variable d’environnement no_proxy. Cette variable peut être utilisée pour spécifier des domaines ou des adresses IP qui ne doivent pas être accessibles via le proxy. Si elle n’est pas définie correctement, elle peut provoquer des problèmes d’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 variable no_proxy.

Zone de disponibilité du cluster Nexus Kubernetes

Quand 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 aux pannes.

Si vous ne spécifiez pas de zone lors de la création d’un cluster Nexus Kubernetes, la plateforme Azure Operator Nexus implémente automatiquement une règle anti-affinité par défaut pour répartir la machine virtuelle sur les racks et les nœuds de matériel nu et n’est pas garantie. Cette règle vise également à empêcher la planification de la machine virtuelle de cluster sur un nœud qui a déjà une machine virtuelle du même cluster, mais il s’agit d’une approche optimale qui ne fournit aucune garantie.

Pour obtenir la liste des zones disponibles dans l’instance Azure Operator Nexus donnée, 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