12.4. Gestion des machines du plan de contrôle avec des ensembles de machines du plan de contrôle
Les jeux de machines du plan de contrôle automatisent plusieurs aspects essentiels de la gestion du plan de contrôle.
12.4.1. Mise à jour de la configuration du plan de contrôle
Vous pouvez modifier la configuration des machines dans le plan de contrôle en mettant à jour la spécification dans la ressource personnalisée (CR) de l'ensemble de machines du plan de contrôle.
L'opérateur du jeu de machines du plan de contrôle surveille les machines du plan de contrôle et compare leur configuration avec les spécifications du CR du jeu de machines du plan de contrôle. En cas de divergence entre les spécifications du RC et la configuration d'une machine du plan de contrôle, l'opérateur marque cette machine du plan de contrôle pour qu'elle soit remplacée.
Pour plus d'informations sur les paramètres du CR, voir "Control plane machine set configuration".
Conditions préalables
- Votre cluster dispose d'un opérateur de plateau de contrôle activé et opérationnel.
Procédure
Modifiez le jeu de machines CR de votre plan de contrôle en exécutant la commande suivante :
$ oc edit controlplanemachineset.machine.openshift.io cluster \ -n openshift-machine-api
- Modifiez les valeurs des champs que vous souhaitez mettre à jour dans la configuration de votre cluster.
- Enregistrez vos modifications.
Prochaines étapes
-
Pour les clusters qui utilisent la stratégie de mise à jour par défaut
RollingUpdate
, les modifications apportées à la configuration du plan de contrôle sont propagées automatiquement. -
Pour les clusters configurés pour utiliser la stratégie de mise à jour
OnDelete
, vous devez remplacer manuellement les machines du plan de contrôle.
12.4.1.1. Mise à jour automatique de la configuration du plan de contrôle
Vous pouvez utiliser la stratégie de mise à jour RollingUpdate
pour propager automatiquement les changements dans la configuration de votre plan de contrôle.
Pour les clusters qui utilisent la stratégie de mise à jour par défaut RollingUpdate
, l'opérateur crée une machine de plan de contrôle de remplacement avec la configuration spécifiée dans le CR. Lorsque la machine de plan de contrôle de remplacement est prête, l'opérateur supprime la machine de plan de contrôle marquée pour le remplacement. La machine de remplacement rejoint alors le plan de contrôle.
Si plusieurs machines du plan de contrôle sont marquées pour être remplacées, l'opérateur répète ce processus de remplacement une machine à la fois jusqu'à ce que chaque machine soit remplacée.
12.4.1.2. Tester les modifications apportées à la configuration du plan de contrôle
Vous pouvez utiliser la stratégie de mise à jour OnDelete
pour tester les modifications apportées à la configuration de votre plan de contrôle. Avec cette stratégie de mise à jour, vous remplacez manuellement les machines du plan de contrôle. Le remplacement manuel des machines vous permet de tester les modifications apportées à votre configuration sur une seule machine avant d'appliquer les changements à plus grande échelle.
Pour les clusters configurés pour utiliser la stratégie de mise à jour OnDelete
, l'opérateur crée une machine de plan de contrôle de remplacement lorsque vous supprimez une machine existante. Lorsque la machine de remplacement du plan de contrôle est prête, l'opérateur etcd autorise la suppression de la machine existante. La machine de remplacement rejoint alors le plan de contrôle.
Si plusieurs machines du plan de contrôle sont supprimées, l'opérateur crée simultanément toutes les machines de remplacement nécessaires.
12.4.2. Activation des fonctionnalités d'Amazon Web Services pour les machines du plan de contrôle
Vous pouvez activer les fonctionnalités Amazon Web Services (AWS) sur les machines du plan de contrôle en modifiant la configuration de votre jeu de machines du plan de contrôle. Lorsque vous enregistrez une mise à jour de l'ensemble de machines du plan de contrôle, l'opérateur de l'ensemble de machines du plan de contrôle met à jour les machines du plan de contrôle conformément à la stratégie de mise à jour que vous avez configurée.
12.4.2.1. Limiter le serveur API au domaine privé
Après avoir déployé un cluster sur Amazon Web Services (AWS), vous pouvez reconfigurer le serveur API pour qu'il n'utilise que la zone privée.
Conditions préalables
-
Installez le CLI OpenShift (
oc
). -
Avoir accès à la console web en tant qu'utilisateur avec les privilèges
admin
.
Procédure
Dans le portail web ou la console de votre fournisseur de cloud, effectuez les actions suivantes :
Localisez et supprimez le composant d'équilibreur de charge approprié :
- Pour AWS, supprimez l'équilibreur de charge externe. L'entrée API DNS dans la zone privée pointe déjà vers l'équilibreur de charge interne, qui utilise une configuration identique, de sorte qu'il n'est pas nécessaire de modifier l'équilibreur de charge interne.
-
Supprimez l'entrée DNS
api.$clustername.$yourdomain
dans la zone publique.
Supprimez les équilibreurs de charge externes en supprimant les lignes suivantes dans la ressource personnalisée control plane machine set :
providerSpec: value: loadBalancers: - name: lk4pj-ext 1 type: network 2 - name: lk4pj-int type: network
12.4.2.2. Modifier le type d'instance Amazon Web Services à l'aide d'un jeu de machines du plan de contrôle
Vous pouvez modifier le type d'instance Amazon Web Services (AWS) que vos machines du plan de contrôle utilisent en mettant à jour la spécification dans la ressource personnalisée (CR) de l'ensemble de machines du plan de contrôle.
Conditions préalables
- Votre cluster AWS utilise un jeu de machines de plan de contrôle.
Procédure
Modifiez la ligne suivante sous le champ
providerSpec
:providerSpec: value: ... instanceType: <compatible_aws_instance_type> 1
- 1
- Spécifiez un type d'instance AWS plus important avec la même base que la sélection précédente. Par exemple, vous pouvez remplacer
m6i.xlarge
parm6i.2xlarge
oum6i.4xlarge
.
- Enregistrez vos modifications.
12.4.2.3. Options du jeu de machines pour le service de métadonnées de l'instance Amazon EC2
Vous pouvez utiliser des jeux de machines pour créer des machines qui utilisent une version spécifique du service de métadonnées d'instance Amazon EC2 (IMDS). Les jeux de machines peuvent créer des machines qui autorisent l'utilisation d'IMDSv1 et d'IMDSv2 ou des machines qui requièrent l'utilisation d'IMDSv2.
Pour modifier la configuration de l'IMDS pour les machines existantes, modifiez le fichier YAML de l'ensemble de machines qui gère ces machines.
Avant de configurer un jeu de machines pour créer des machines nécessitant IMDSv2, assurez-vous que toutes les charges de travail qui interagissent avec le service de métadonnées AWS prennent en charge IMDSv2.
12.4.2.3.1. Configuration de l'IMDS à l'aide de jeux de machines
Vous pouvez spécifier si l'utilisation d'IMDSv2 est requise en ajoutant ou en modifiant la valeur de metadataServiceOptions.authentication
dans le fichier YAML de l'ensemble de machines pour vos machines.
Procédure
Ajoutez ou modifiez les lignes suivantes sous le champ
providerSpec
:providerSpec: value: metadataServiceOptions: authentication: Required 1
- 1
- Pour exiger IMDSv2, définissez la valeur du paramètre sur
Required
. Pour autoriser l'utilisation de IMDSv1 et IMDSv2, définissez la valeur du paramètre surOptional
. Si aucune valeur n'est spécifiée, IMDSv1 et IMDSv2 sont tous deux autorisés.
12.4.2.4. Jeux de machines qui déploient des machines en tant qu'instances dédiées
Vous pouvez créer un ensemble de machines fonctionnant sur AWS qui déploie des machines en tant qu'instances dédiées. Les instances dédiées s'exécutent dans un nuage privé virtuel (VPC) sur du matériel dédié à un seul client. Ces instances Amazon EC2 sont physiquement isolées au niveau du matériel hôte. L'isolement des instances dédiées se produit même si les instances appartiennent à différents comptes AWS liés à un seul compte payeur. Toutefois, d'autres instances non dédiées peuvent partager le matériel avec les instances dédiées si elles appartiennent au même compte AWS.
Les instances avec une location publique ou dédiée sont prises en charge par l'API Machine. Les instances en mode public s'exécutent sur du matériel partagé. La location publique est la location par défaut. Les instances avec une location dédiée s'exécutent sur du matériel à locataire unique.
12.4.2.4.1. Création d'instances dédiées à l'aide d'ensembles de machines
Vous pouvez exécuter une machine qui est soutenue par une Instance Dédiée en utilisant l'intégration API Machine. Définissez le champ tenancy
dans votre fichier YAML machine set pour lancer une Dedicated Instance sur AWS.
Procédure
Spécifiez une location dédiée dans le champ
providerSpec
:providerSpec: placement: tenancy: dedicated
12.4.3. Activation des fonctionnalités de Microsoft Azure pour les machines du plan de contrôle
Vous pouvez activer les fonctionnalités Microsoft Azure sur les machines du plan de contrôle en modifiant la configuration de votre jeu de machines du plan de contrôle. Lorsque vous enregistrez une mise à jour de l'ensemble de machines du plan de contrôle, l'opérateur de l'ensemble de machines du plan de contrôle met à jour les machines du plan de contrôle conformément à la stratégie de mise à jour que vous avez configurée.
12.4.3.1. Limiter le serveur API au domaine privé
Après avoir déployé un cluster sur Microsoft Azure, vous pouvez reconfigurer le serveur API pour qu'il n'utilise que la zone privée.
Conditions préalables
-
Installez le CLI OpenShift (
oc
). -
Avoir accès à la console web en tant qu'utilisateur avec les privilèges
admin
.
Procédure
Dans le portail web ou la console de votre fournisseur de cloud, effectuez les actions suivantes :
Localisez et supprimez le composant d'équilibreur de charge approprié :
-
Pour Azure, supprimez la règle
api-internal
pour l'équilibreur de charge.
-
Pour Azure, supprimez la règle
-
Supprimez l'entrée DNS
api.$clustername.$yourdomain
dans la zone publique.
Supprimez les équilibreurs de charge externes en supprimant les lignes suivantes dans la ressource personnalisée control plane machine set :
providerSpec: value: loadBalancers: - name: lk4pj-ext 1 type: network 2 - name: lk4pj-int type: network
12.4.3.2. Selecting an Azure Marketplace image
Vous pouvez créer un jeu de machines fonctionnant sur Azure qui déploie des machines utilisant l'offre Azure Marketplace. Pour utiliser cette offre, vous devez d'abord obtenir l'image Azure Marketplace. Lorsque vous obtenez votre image, tenez compte des éléments suivants :
-
While the images are the same, the Azure Marketplace publisher is different depending on your region. If you are located in North America, specify
redhat
as the publisher. If you are located in EMEA, specifyredhat-limited
as the publisher. -
The offer includes a
rh-ocp-worker
SKU and arh-ocp-worker-gen1
SKU. Therh-ocp-worker
SKU represents a Hyper-V generation version 2 VM image. The default instance types used in OpenShift Container Platform are version 2 compatible. If you plan to use an instance type that is only version 1 compatible, use the image associated with therh-ocp-worker-gen1
SKU. Therh-ocp-worker-gen1
SKU represents a Hyper-V version 1 VM image.
Installing images with the Azure marketplace is not supported on clusters with arm64
instances.
Conditions préalables
-
You have installed the Azure CLI client
(az)
. - Your Azure account is entitled for the offer and you have logged into this account with the Azure CLI client.
Procédure
Display all of the available OpenShift Container Platform images by running one of the following commands:
North America:
$ az vm image list --all --offer rh-ocp-worker --publisher redhat -o table
Exemple de sortie
Offer Publisher Sku Urn Version ------------- -------------- ------------------ -------------------------------------------------------------- -------------- rh-ocp-worker RedHat rh-ocp-worker RedHat:rh-ocp-worker:rh-ocpworker:4.8.2021122100 4.8.2021122100 rh-ocp-worker RedHat rh-ocp-worker-gen1 RedHat:rh-ocp-worker:rh-ocp-worker-gen1:4.8.2021122100 4.8.2021122100
EMEA:
$ az vm image list --all --offer rh-ocp-worker --publisher redhat-limited -o table
Exemple de sortie
Offer Publisher Sku Urn Version ------------- -------------- ------------------ -------------------------------------------------------------- -------------- rh-ocp-worker redhat-limited rh-ocp-worker redhat-limited:rh-ocp-worker:rh-ocp-worker:4.8.2021122100 4.8.2021122100 rh-ocp-worker redhat-limited rh-ocp-worker-gen1 redhat-limited:rh-ocp-worker:rh-ocp-worker-gen1:4.8.2021122100 4.8.2021122100
NoteRegardless of the version of OpenShift Container Platform that you install, the correct version of the Azure Marketplace image to use is 4.8. If required, your VMs are automatically upgraded as part of the installation process.
Inspect the image for your offer by running one of the following commands:
North America:
$ az vm image show --urn redhat:rh-ocp-worker:rh-ocp-worker:<version>
EMEA:
$ az vm image show --urn redhat-limited:rh-ocp-worker:rh-ocp-worker:<version>
Review the terms of the offer by running one of the following commands:
North America:
$ az vm image terms show --urn redhat:rh-ocp-worker:rh-ocp-worker:<version>
EMEA:
$ az vm image terms show --urn redhat-limited:rh-ocp-worker:rh-ocp-worker:<version>
Accept the terms of the offering by running one of the following commands:
North America:
$ az vm image terms accept --urn redhat:rh-ocp-worker:rh-ocp-worker:<version>
EMEA:
$ az vm image terms accept --urn redhat-limited:rh-ocp-worker:rh-ocp-worker:<version>
-
Enregistrez les détails de l'image de votre offre, en particulier les valeurs de
publisher
,offer
,sku
etversion
. Ajoutez les paramètres suivants à la section
providerSpec
de votre fichier YAML de configuration de la machine en utilisant les détails de l'image pour votre offre :Exemple de valeurs d'image
providerSpec
pour les machines Azure MarketplaceproviderSpec: value: image: offer: rh-ocp-worker publisher: redhat resourceID: "" sku: rh-ocp-worker type: MarketplaceWithPlan version: 4.8.2021122100
12.4.3.3. Activation des diagnostics de démarrage Azure
Vous pouvez activer les diagnostics de démarrage sur les machines Azure créées par votre jeu de machines.
Conditions préalables
- Disposer d'un cluster Microsoft Azure existant.
Procédure
Ajoutez la configuration
diagnostics
applicable à votre type de stockage au champproviderSpec
de votre fichier YAML machine set :Pour un compte de stockage géré par Azure :
providerSpec: diagnostics: boot: storageAccountType: AzureManaged 1
- 1
- Spécifie un compte de stockage Azure Managed.
Pour un compte de stockage Azure non géré :
providerSpec: diagnostics: boot: storageAccountType: CustomerManaged 1 customerManaged: storageAccountURI: https://<storage-account>.blob.core.windows.net 2
NoteSeul le service de données Azure Blob Storage est pris en charge.
Vérification
- Sur le portail Microsoft Azure, consultez la page Boot diagnostics pour une machine déployée par le jeu de machines et vérifiez que vous pouvez voir les journaux de série pour la machine.
12.4.3.4. Jeux de machines qui déploient des machines avec des disques ultra comme disques de données
Vous pouvez créer un jeu de machines fonctionnant sur Azure qui déploie des machines avec des ultra-disques. Les disques ultra sont des systèmes de stockage haute performance destinés à être utilisés avec les charges de travail les plus exigeantes.
Ressources complémentaires
12.4.3.4.1. Création de machines avec ultra-disques à l'aide de jeux de machines
Vous pouvez déployer des machines avec des ultra-disques sur Azure en modifiant votre fichier YAML de configuration des machines.
Conditions préalables
- Disposer d'un cluster Microsoft Azure existant.
Procédure
Créez un secret personnalisé dans l'espace de noms
openshift-machine-api
en utilisant le secret de donnéesmaster
en exécutant la commande suivante :$ oc -n openshift-machine-api \ get secret <role>-user-data \ 1 --template='{{index .data.userData | base64decode}}' | jq > userData.txt 2
Dans un éditeur de texte, ouvrez le fichier
userData.txt
et localisez le caractère final}
dans le fichier.-
Sur la ligne immédiatement précédente, ajouter un
,
. Créez une nouvelle ligne après le site
,
et ajoutez les détails de configuration suivants :"storage": { "disks": [ 1 { "device": "/dev/disk/azure/scsi1/lun0", 2 "partitions": [ 3 { "label": "lun0p1", 4 "sizeMiB": 1024, 5 "startMiB": 0 } ] } ], "filesystems": [ 6 { "device": "/dev/disk/by-partlabel/lun0p1", "format": "xfs", "path": "/var/lib/lun0p1" } ] }, "systemd": { "units": [ 7 { "contents": "[Unit]\nBefore=local-fs.target\n[Mount]\nWhere=/var/lib/lun0p1\nWhat=/dev/disk/by-partlabel/lun0p1\nOptions=defaults,pquota\n[Install]\nWantedBy=local-fs.target\n", 8 "enabled": true, "name": "var-lib-lun0p1.mount" } ] }
- 1
- Les détails de configuration du disque que vous souhaitez attacher à un nœud en tant qu'ultra disque.
- 2
- Indiquez la valeur
lun
définie dans la strophedataDisks
du jeu de machines que vous utilisez. Par exemple, si le jeu de machines contientlun: 0
, indiquezlun0
. Vous pouvez initialiser plusieurs disques de données en spécifiant plusieurs entrées"disks"
dans ce fichier de configuration. Si vous spécifiez plusieurs entrées"disks"
, assurez-vous que la valeurlun
de chaque entrée correspond à la valeur du jeu de machines. - 3
- Les détails de la configuration d'une nouvelle partition sur le disque.
- 4
- Indiquez un nom pour la partition. Il peut être utile d'utiliser des noms hiérarchiques, tels que
lun0p1
pour la première partition delun0
. - 5
- Indiquez la taille totale en Mo de la partition.
- 6
- Spécifiez le système de fichiers à utiliser lors du formatage d'une partition. Utilisez l'étiquette de partition pour spécifier la partition.
- 7
- Indiquez une unité
systemd
pour monter la partition au démarrage. Utilisez l'étiquette de partition pour spécifier la partition. Vous pouvez créer plusieurs partitions en spécifiant plusieurs entrées"partitions"
dans ce fichier de configuration. Si vous spécifiez plusieurs entrées"partitions"
, vous devez spécifier une unitésystemd
pour chacune d'entre elles. - 8
- Pour
Where
, spécifiez la valeur destorage.filesystems.path
. PourWhat
, spécifiez la valeur destorage.filesystems.device
.
-
Sur la ligne immédiatement précédente, ajouter un
Extrayez la valeur du modèle de désactivation dans un fichier appelé
disableTemplating.txt
en exécutant la commande suivante :$ oc -n openshift-machine-api get secret <role>-user-data \ 1 --template='{{index .data.disableTemplating | base64decode}}' | jq > disableTemplating.txt
- 1
- Remplacer
<role>
parmaster
.
Combinez les fichiers
userData.txt
etdisableTemplating.txt
pour créer un fichier de données secrètes en exécutant la commande suivante :$ oc -n openshift-machine-api create secret generic <role>-user-data-x5 \ 1 --from-file=userData=userData.txt \ --from-file=disableTemplating=disableTemplating.txt
- 1
- Pour
<role>-user-data-x5
, indiquez le nom du secret. Remplacez<role>
parmaster
.
Modifiez le jeu de machines CR de votre plan de contrôle en exécutant la commande suivante :
$ oc --namespace openshift-machine-api edit controlplanemachineset.machine.openshift.io cluster
Ajouter les lignes suivantes aux endroits indiqués :
apiVersion: machine.openshift.io/v1beta1 kind: ControlPlaneMachineSet spec: template: spec: metadata: labels: disk: ultrassd 1 providerSpec: value: ultraSSDCapability: Enabled 2 dataDisks: 3 - nameSuffix: ultrassd lun: 0 diskSizeGB: 4 deletionPolicy: Delete cachingType: None managedDisk: storageAccountType: UltraSSD_LRS userDataSecret: name: <role>-user-data-x5 4
- 1
- Indiquez une étiquette à utiliser pour sélectionner un nœud créé par ce jeu de machines. Cette procédure utilise
disk.ultrassd
pour cette valeur. - 2 3
- Ces lignes permettent d'utiliser des disques ultra. Pour
dataDisks
, inclure la strophe entière. - 4
- Spécifiez le secret des données de l'utilisateur créé précédemment. Remplacez
<role>
parmaster
.
Enregistrez vos modifications.
-
Pour les clusters qui utilisent la stratégie de mise à jour par défaut
RollingUpdate
, l'opérateur propage automatiquement les modifications à votre configuration du plan de contrôle. -
Pour les clusters configurés pour utiliser la stratégie de mise à jour
OnDelete
, vous devez remplacer manuellement les machines du plan de contrôle.
-
Pour les clusters qui utilisent la stratégie de mise à jour par défaut
Vérification
Validez la création des machines en exécutant la commande suivante :
$ oc get machines
Les machines doivent être dans l'état
Running
.Pour une machine en cours d'exécution et à laquelle un nœud est attaché, validez la partition en exécutant la commande suivante :
$ oc debug node/<node-name> -- chroot /host lsblk
Dans cette commande,
oc debug node/<node-name>
démarre un shell de débogage sur le nœud<node-name>
et transmet une commande à--
. La commande passéechroot /host
permet d'accéder aux binaires du système d'exploitation hôte sous-jacent, etlsblk
montre les périphériques de bloc attachés à la machine du système d'exploitation hôte.
Prochaines étapes
- Pour utiliser un ultra disque sur le plan de contrôle, reconfigurez votre charge de travail pour utiliser le point de montage de l'ultra disque du plan de contrôle.
12.4.3.4.2. Ressources de dépannage pour les ensembles de machines qui activent les ultra-disques
Utilisez les informations de cette section pour comprendre et résoudre les problèmes que vous pourriez rencontrer.
12.4.3.4.2.1. Configuration incorrecte de l'ultra disque
Si une configuration incorrecte du paramètre ultraSSDCapability
est spécifiée dans le jeu de machines, le provisionnement de la machine échoue.
Par exemple, si le paramètre ultraSSDCapability
est défini sur Disabled
, mais qu'un disque ultra est spécifié dans le paramètre dataDisks
, le message d'erreur suivant apparaît :
StorageAccountType UltraSSD_LRS can be used only when additionalCapabilities.ultraSSDEnabled is set.
- Pour résoudre ce problème, vérifiez que la configuration de votre jeu de machines est correcte.
12.4.3.4.2.2. Paramètres de disque non pris en charge
Si une région, une zone de disponibilité ou une taille d'instance qui n'est pas compatible avec les disques ultra est spécifiée dans le jeu de machines, le provisionnement de la machine échoue. Vérifiez les journaux pour le message d'erreur suivant :
failed to create vm <machine_name> : failure sending request for machine <machine_name> : cannot create vm : compute.VirtualMachinesClient#CreateOrUpdate : Échec de l'envoi de la requête : StatusCode=400 -- Erreur d'origine : Code="BadRequest" Message="Le type de compte de stockage 'UltraSSD_LRS' n'est pas pris en charge <more_information_about_why>."
- Pour résoudre ce problème, vérifiez que vous utilisez cette fonctionnalité dans un environnement pris en charge et que la configuration de votre jeu de machines est correcte.
12.4.3.4.2.3. Impossible de supprimer des disques
Si la suppression des ultra-disques en tant que disques de données ne fonctionne pas comme prévu, les machines sont supprimées et les disques de données sont orphelins. Vous devez supprimer les disques orphelins manuellement si vous le souhaitez.
12.4.3.5. Activation des clés de chiffrement gérées par le client pour un ensemble de machines
Vous pouvez fournir une clé de chiffrement à Azure pour chiffrer les données sur les disques gérés au repos. Vous pouvez activer le chiffrement côté serveur avec des clés gérées par le client en utilisant l'API Machine.
Un Azure Key Vault, un ensemble de chiffrement de disque et une clé de chiffrement sont nécessaires pour utiliser une clé gérée par le client. Le jeu de chiffrement de disque doit se trouver dans un groupe de ressources auquel le Cloud Credential Operator (CCO) a accordé des autorisations. Si ce n'est pas le cas, un rôle de lecteur supplémentaire doit être accordé à l'ensemble de chiffrement de disque.
Conditions préalables
Procédure
Configurez le cryptage du disque dans le champ
providerSpec
de votre fichier YAML de configuration de la machine. Par exemple :providerSpec: value: osDisk: diskSizeGB: 128 managedDisk: diskEncryptionSet: id: /subscriptions/<subscription_id>/resourceGroups/<resource_group_name>/providers/Microsoft.Compute/diskEncryptionSets/<disk_encryption_set_name> storageAccountType: Premium_LRS
Ressources complémentaires
12.4.3.6. Mise en réseau accélérée pour les machines virtuelles Microsoft Azure
Accelerated Networking utilise la virtualisation d'E/S à racine unique (SR-IOV) pour fournir aux VM Microsoft Azure un chemin plus direct vers le commutateur. Les performances du réseau s'en trouvent améliorées. Cette fonctionnalité peut être activée après l'installation.
12.4.3.6.1. Limitations
Tenez compte des limitations suivantes lorsque vous décidez d'utiliser ou non la mise en réseau accélérée :
- La mise en réseau accélérée n'est prise en charge que sur les clusters où l'API Machine est opérationnelle.
Accelerated Networking nécessite une taille de VM Azure comprenant au moins quatre vCPU. Pour répondre à cette exigence, vous pouvez modifier la valeur de
vmSize
dans votre jeu de machines. Pour plus d'informations sur les tailles de VM Azure, consultez la documentation Microsoft Azure.
12.4.3.6.2. Activation de l'Accelerated Networking sur un cluster Microsoft Azure existant
Vous pouvez activer Accelerated Networking sur Azure en ajoutant acceleratedNetworking
à votre fichier YAML machine set.
Conditions préalables
- Disposer d'un cluster Microsoft Azure existant où l'API Machine est opérationnelle.
Procédure
Ajoutez ce qui suit au champ
providerSpec
:providerSpec: value: acceleratedNetworking: true 1 vmSize: <azure-vm-size> 2
- 1
- This line enables Accelerated Networking.
- 2
- Specify an Azure VM size that includes at least four vCPUs. For information about VM sizes, see Microsoft Azure documentation.
Vérification
-
Sur le portail Microsoft Azure, consultez la page des paramètres Networking pour une machine approvisionnée par le jeu de machines et vérifiez que le champ
Accelerated networking
est défini surEnabled
.