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.

Note

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

  1. 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
  2. Modifiez les valeurs des champs que vous souhaitez mettre à jour dans la configuration de votre cluster.
  3. 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

  1. Dans le portail web ou la console de votre fournisseur de cloud, effectuez les actions suivantes :

    1. 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.
    2. Supprimez l'entrée DNS api.$clustername.$yourdomain dans la zone publique.
  2. 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
    1 2
    Supprimer cette ligne.

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

  1. 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 par m6i.2xlarge ou m6i.4xlarge.
  2. 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.

Important

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 sur Optional. 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

  1. Dans le portail web ou la console de votre fournisseur de cloud, effectuez les actions suivantes :

    1. Localisez et supprimez le composant d'équilibreur de charge approprié :

      • Pour Azure, supprimez la règle api-internal pour l'équilibreur de charge.
    2. Supprimez l'entrée DNS api.$clustername.$yourdomain dans la zone publique.
  2. 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
    1 2
    Supprimer cette ligne.

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, specify redhat-limited as the publisher.
  • The offer includes a rh-ocp-worker SKU and a rh-ocp-worker-gen1 SKU. The rh-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 the rh-ocp-worker-gen1 SKU. The rh-ocp-worker-gen1 SKU represents a Hyper-V version 1 VM image.
Important

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

  1. 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

    Note

    Regardless 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.

  2. 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>
  3. 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>
  4. 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>
  5. Enregistrez les détails de l'image de votre offre, en particulier les valeurs de publisher, offer, sku et version.
  6. 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 Marketplace

    providerSpec:
      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 champ providerSpec 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
      1
      Spécifie un compte de stockage Azure non géré.
      2
      Remplacez <storage-account> par le nom de votre compte de stockage.
      Note

      Seul 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.

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

  1. Créez un secret personnalisé dans l'espace de noms openshift-machine-api en utilisant le secret de données master 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
    1
    Remplacer <role> par master.
    2
    Indiquez userData.txt comme nom du nouveau secret personnalisé.
  2. Dans un éditeur de texte, ouvrez le fichier userData.txt et localisez le caractère final } dans le fichier.

    1. Sur la ligne immédiatement précédente, ajouter un ,.
    2. 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 strophe dataDisks du jeu de machines que vous utilisez. Par exemple, si le jeu de machines contient lun: 0, indiquez lun0. 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 valeur lun 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 de lun0.
      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 de storage.filesystems.path. Pour What, spécifiez la valeur de storage.filesystems.device.
  3. 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> par master.
  4. Combinez les fichiers userData.txt et disableTemplating.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> par master.
  5. 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
  6. 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> par master.
  7. 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.

Vérification

  1. Validez la création des machines en exécutant la commande suivante :

    $ oc get machines

    Les machines doivent être dans l'état Running.

  2. 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ée chroot /host permet d'accéder aux binaires du système d'exploitation hôte sous-jacent, et lsblk 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.

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

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 sur Enabled.
Red Hat logoGithubRedditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez leBlog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

© 2024 Red Hat, Inc.