SupportConsoleDéveloppeursCommencer un essaiContact

7.2. Création de jeux de machines d'infrastructure pour les environnements de production

Dans un déploiement de production, il est recommandé de déployer au moins trois ensembles de machines de calcul pour contenir les composants de l'infrastructure. OpenShift Logging et Red Hat OpenShift Service Mesh déploient tous deux Elasticsearch, qui nécessite l'installation de trois instances sur différents nœuds. Chacun de ces nœuds peut être déployé dans différentes zones de disponibilité pour une haute disponibilité. Une telle configuration nécessite trois ensembles de machines de calcul différents, un pour chaque zone de disponibilité. Dans les régions Azure globales qui ne disposent pas de plusieurs zones de disponibilité, vous pouvez utiliser des ensembles de machines de calcul pour garantir une haute disponibilité.

7.2.1. Création d'ensembles de machines d'infrastructure pour différents nuages

Utilisez l'exemple de machine de calcul pour votre nuage.

7.2.1.1. Exemple de YAML pour une machine de calcul définie comme ressource personnalisée sur Alibaba Cloud

Cet exemple YAML définit un ensemble de machines de calcul qui s'exécute dans une zone Alibaba Cloud spécifiée dans une région et crée des nœuds étiquetés avec node-role.kubernetes.io/infra: "".

Dans cet exemple, <infrastructure_id> est l'étiquette d'ID d'infrastructure basée sur l'ID de cluster que vous avez défini lors du provisionnement du cluster, et <infra> est l'étiquette de nœud à ajouter. 

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  labels:
    machine.openshift.io/cluster-api-cluster: <infrastructure_id> 1
    machine.openshift.io/cluster-api-machine-role: <infra> 2
    machine.openshift.io/cluster-api-machine-type: <infra> 3
  name: <infrastructure_id>-<infra>-<zone> 4
  namespace: openshift-machine-api
spec:
  replicas: 1
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructure_id> 5
      machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<infra>-<zone> 6
  template:
    metadata:
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id> 7
        machine.openshift.io/cluster-api-machine-role: <infra> 8
        machine.openshift.io/cluster-api-machine-type: <infra> 9
        machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<infra>-<zone> 10
    spec:
      metadata:
        labels:
          node-role.kubernetes.io/infra: ""
      providerSpec:
        value:
          apiVersion: machine.openshift.io/v1
          credentialsSecret:
            name: alibabacloud-credentials
          imageId: <image_id> 11
          instanceType: <instance_type> 12
          kind: AlibabaCloudMachineProviderConfig
          ramRoleName: <infrastructure_id>-role-worker 13
          regionId: <region> 14
          resourceGroup: 15
            id: <resource_group_id>
            type: ID
          securityGroups:
          - tags: 16
            - Key: Name
              Value: <infrastructure_id>-sg-<role>
            type: Tags
          systemDisk: 17
            category: cloud_essd
            size: <disk_size>
          tag: 18
          - Key: kubernetes.io/cluster/<infrastructure_id>
            Value: owned
          userDataSecret:
            name: <user_data_secret> 19
          vSwitch:
            tags: 20
            - Key: Name
              Value: <infrastructure_id>-vswitch-<zone>
            type: Tags
          vpcId: ""
          zoneId: <zone> 21
      taints: 22
      - key: node-role.kubernetes.io/infra
        effect: NoSchedule
1 5 7
Spécifiez l'ID d'infrastructure qui est basé sur l'ID de cluster que vous avez défini lorsque vous avez provisionné le cluster. Si l'OpenShift CLI (oc) est installé, vous pouvez obtenir l'ID d'infrastructure en exécutant la commande suivante : 
$ oc get -o jsonpath='{.status.infrastructureName}{"\n"}' infrastructure cluster
2 3 8 9
Indiquez l'étiquette du nœud <infra>.
4 6 10
Spécifiez l'ID de l'infrastructure, l'étiquette du nœud <infra> et la zone.
11
Spécifiez l'image à utiliser. Utilisez une image provenant d'un jeu de machines de calcul par défaut existant pour le cluster.
12
Spécifiez le type d'instance que vous souhaitez utiliser pour l'ensemble de machines de calcul.
13
Spécifiez le nom du rôle RAM à utiliser pour le jeu de machines de calcul. Utilisez la valeur indiquée par le programme d'installation dans le jeu de machines de calcul par défaut.
14
Spécifiez la région où placer les machines.
15
Spécifiez le groupe et le type de ressources pour le cluster. Vous pouvez utiliser la valeur indiquée par le programme d'installation dans le jeu de machines de calcul par défaut ou en spécifier une autre.
16 18 20
Spécifiez les balises à utiliser pour l'ensemble de machines de calcul. Au minimum, vous devez inclure les balises présentées dans cet exemple, avec les valeurs appropriées pour votre cluster. Vous pouvez inclure des balises supplémentaires, y compris les balises que le programme d'installation ajoute à l'ensemble de machines de calcul par défaut qu'il crée, si nécessaire.
17
Spécifiez le type et la taille du disque racine. Utilisez la valeur category que le programme d'installation renseigne dans le jeu de machines de calcul par défaut qu'il crée. Si nécessaire, indiquez une valeur différente en gigaoctets pour size.
19
Spécifiez le nom du secret dans le fichier YAML des données utilisateur qui se trouve dans l'espace de noms openshift-machine-api. Utilisez la valeur indiquée par le programme d'installation dans le jeu de machines de calcul par défaut.
21
Indiquez la zone de votre région où placer les machines. Assurez-vous que votre région prend en charge la zone que vous spécifiez.
22
Spécifiez une erreur pour empêcher les charges de travail utilisateur d'être planifiées sur les nœuds infra.
Paramètres définis par la machine pour les statistiques d'utilisation du nuage Alibaba

Les ensembles de machines de calcul par défaut que le programme d'installation crée pour les clusters Alibaba Cloud incluent des valeurs de balises non essentielles qu'Alibaba Cloud utilise en interne pour suivre les statistiques d'utilisation. Ces balises sont renseignées dans les paramètres securityGroups, tag, et vSwitch de la liste spec.template.spec.providerSpec.value.

Lorsque vous créez des ensembles de machines de calcul pour déployer des machines supplémentaires, vous devez inclure les balises Kubernetes requises. Les balises de statistiques d'utilisation sont appliquées par défaut, même si elles ne sont pas spécifiées dans les ensembles de machines de calcul que vous créez. Vous pouvez également inclure des balises supplémentaires si nécessaire.

Les extraits YAML suivants indiquent quelles balises des ensembles de machines de calcul par défaut sont facultatives et lesquelles sont obligatoires.

Tags dans spec.template.spec.providerSpec.value.securityGroups

spec:
  template:
    spec:
      providerSpec:
        value:
          securityGroups:
          - tags:
            - Key: kubernetes.io/cluster/<infrastructure_id> 1
              Value: owned
            - Key: GISV
              Value: ocp
            - Key: sigs.k8s.io/cloud-provider-alibaba/origin 2
              Value: ocp
            - Key: Name
              Value: <infrastructure_id>-sg-<role> 3
            type: Tags

1 2
Facultatif : Cette balise est appliquée même si elle n'est pas spécifiée dans le jeu de machines de calcul.
3
Required.

où :

  • <infrastructure_id> est l'ID de l'infrastructure qui est basé sur l'ID du cluster que vous avez défini lorsque vous avez approvisionné le cluster.
  • <role> est l'étiquette de nœud à ajouter.

Tags dans spec.template.spec.providerSpec.value.tag

spec:
  template:
    spec:
      providerSpec:
        value:
          tag:
          - Key: kubernetes.io/cluster/<infrastructure_id> 1
            Value: owned
          - Key: GISV 2
            Value: ocp
          - Key: sigs.k8s.io/cloud-provider-alibaba/origin 3
            Value: ocp

2 3
Facultatif : Cette balise est appliquée même si elle n'est pas spécifiée dans le jeu de machines de calcul.
1
Required.

où <infrastructure_id> est l'ID de l'infrastructure basé sur l'ID du cluster que vous avez défini lors du provisionnement du cluster.

Tags dans spec.template.spec.providerSpec.value.vSwitch

spec:
  template:
    spec:
      providerSpec:
        value:
          vSwitch:
            tags:
            - Key: kubernetes.io/cluster/<infrastructure_id> 1
              Value: owned
            - Key: GISV 2
              Value: ocp
            - Key: sigs.k8s.io/cloud-provider-alibaba/origin 3
              Value: ocp
            - Key: Name
              Value: <infrastructure_id>-vswitch-<zone> 4
            type: Tags

1 2 3
Facultatif : Cette balise est appliquée même si elle n'est pas spécifiée dans le jeu de machines de calcul.
4
Required.

où :

  • <infrastructure_id> est l'ID de l'infrastructure qui est basé sur l'ID du cluster que vous avez défini lorsque vous avez approvisionné le cluster.
  • <zone> est la zone de votre région où placer les machines.

7.2.1.2. Exemple de YAML pour une ressource personnalisée d'un ensemble de machines de calcul sur AWS

Cet exemple YAML définit un ensemble de machines de calcul qui fonctionne dans la zone us-east-1a Amazon Web Services (AWS) et crée des nœuds étiquetés avec node-role.kubernetes.io/infra: "".

Dans cet exemple, <infrastructure_id> est l'étiquette d'ID d'infrastructure basée sur l'ID de cluster que vous avez défini lors du provisionnement du cluster, et <infra> est l'étiquette de nœud à ajouter. 

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  labels:
    machine.openshift.io/cluster-api-cluster: <infrastructure_id> 1
  name: <infrastructure_id>-infra-<zone> 2
  namespace: openshift-machine-api
spec:
  replicas: 1
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructure_id> 3
      machine.openshift.io/cluster-api-machineset: <infrastructure_id>-infra-<zone> 4
  template:
    metadata:
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id> 5
        machine.openshift.io/cluster-api-machine-role: infra 6
        machine.openshift.io/cluster-api-machine-type: infra 7
        machine.openshift.io/cluster-api-machineset: <infrastructure_id>-infra-<zone> 8
    spec:
      metadata:
        labels:
          node-role.kubernetes.io/infra: "" 9
      providerSpec:
        value:
          ami:
            id: ami-046fe691f52a953f9 10
          apiVersion: awsproviderconfig.openshift.io/v1beta1
          blockDevices:
            - ebs:
                iops: 0
                volumeSize: 120
                volumeType: gp2
          credentialsSecret:
            name: aws-cloud-credentials
          deviceIndex: 0
          iamInstanceProfile:
            id: <infrastructure_id>-worker-profile 11
          instanceType: m6i.large
          kind: AWSMachineProviderConfig
          placement:
            availabilityZone: <zone> 12
            region: <region> 13
          securityGroups:
            - filters:
                - name: tag:Name
                  values:
                    - <infrastructure_id>-worker-sg 14
          subnet:
            filters:
              - name: tag:Name
                values:
                  - <infrastructure_id>-private-<zone> 15
          tags:
            - name: kubernetes.io/cluster/<infrastructure_id> 16
              value: owned
            - name: <custom_tag_name> 17
              value: <custom_tag_value> 18
          userDataSecret:
            name: worker-user-data
      taints: 19
        - key: node-role.kubernetes.io/infra
          effect: NoSchedule
1 3 5 11 14 16
Spécifiez l'ID d'infrastructure qui est basé sur l'ID de cluster que vous avez défini lorsque vous avez provisionné le cluster. Si le CLI OpenShift est installé, vous pouvez obtenir l'ID d'infrastructure en exécutant la commande suivante : 
$ oc get -o jsonpath='{.status.infrastructureName}{"\n"}' infrastructure cluster
2 4 8
Spécifiez l'ID de l'infrastructure, l'étiquette du nœud de rôle infra et la zone.
6 7 9
Indiquez l'étiquette du nœud de rôle infra.
10
Spécifiez une image de machine Amazon (AMI) Red Hat Enterprise Linux CoreOS (RHCOS) valide pour votre zone AWS pour vos nœuds OpenShift Container Platform. Si vous souhaitez utiliser une image AWS Marketplace, vous devez compléter l'abonnement à OpenShift Container Platform depuis AWS Marketplace afin d'obtenir un identifiant AMI pour votre région. 
$ oc -n openshift-machine-api \
    -o jsonpath='{.spec.template.spec.providerSpec.value.ami.id}{"\n"}' \
    get machineset/<infrastructure_id>-<role>-<zone>
17 18
Optionnel : Spécifiez des données de balises personnalisées pour votre cluster. Par exemple, vous pouvez ajouter une adresse électronique de contact pour l'administration en spécifiant une paire name:value de Email:admin-email@example.com.
Note

Des balises personnalisées peuvent également être spécifiées lors de l'installation dans le fichier install-config.yml. Si le fichier install-config.yml et le jeu de machines comprennent une balise avec les mêmes données name, la valeur de la balise du jeu de machines est prioritaire sur la valeur de la balise dans le fichier install-config.yml.

12
Spécifiez la zone, par exemple, us-east-1a.
13
Précisez la région, par exemple us-east-1.
15
Spécifiez l'ID de l'infrastructure et la zone.
19
Spécifiez une erreur pour empêcher les charges de travail utilisateur d'être planifiées sur les nœuds infra.

Les ensembles de machines fonctionnant sur AWS prennent en charge les Instances Spot non garanties. Vous pouvez réaliser des économies en utilisant des Instances Spot à un prix inférieur à celui des Instances On-Demand sur AWS. Configurez les Instances Spot en ajoutant spotMarketOptions au fichier YAML MachineSet.

7.2.1.3. Exemple de YAML pour une ressource personnalisée d'un ensemble de machines de calcul sur Azure

Cet exemple YAML définit un ensemble de machines de calcul qui s'exécute dans la zone 1 Microsoft Azure d'une région et crée des nœuds étiquetés avec node-role.kubernetes.io/infra: "".

Dans cet exemple, <infrastructure_id> est l'étiquette d'ID d'infrastructure basée sur l'ID de cluster que vous avez défini lors du provisionnement du cluster, et <infra> est l'étiquette de nœud à ajouter. 

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  labels:
    machine.openshift.io/cluster-api-cluster: <infrastructure_id> 1
    machine.openshift.io/cluster-api-machine-role: <infra> 2
    machine.openshift.io/cluster-api-machine-type: <infra> 3
  name: <infrastructure_id>-infra-<region> 4
  namespace: openshift-machine-api
spec:
  replicas: 1
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructure_id> 5
      machine.openshift.io/cluster-api-machineset: <infrastructure_id>-infra-<region> 6
  template:
    metadata:
      creationTimestamp: null
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id> 7
        machine.openshift.io/cluster-api-machine-role: <infra> 8
        machine.openshift.io/cluster-api-machine-type: <infra> 9
        machine.openshift.io/cluster-api-machineset: <infrastructure_id>-infra-<region> 10
    spec:
      metadata:
        creationTimestamp: null
        labels:
          machine.openshift.io/cluster-api-machineset: <machineset_name> 11
          node-role.kubernetes.io/infra: "" 12
      providerSpec:
        value:
          apiVersion: azureproviderconfig.openshift.io/v1beta1
          credentialsSecret:
            name: azure-cloud-credentials
            namespace: openshift-machine-api
          image: 13
            offer: ""
            publisher: ""
            resourceID: /resourceGroups/<infrastructure_id>-rg/providers/Microsoft.Compute/images/<infrastructure_id> 14
            sku: ""
            version: ""
          internalLoadBalancer: ""
          kind: AzureMachineProviderSpec
          location: <region> 15
          managedIdentity: <infrastructure_id>-identity 16
          metadata:
            creationTimestamp: null
          natRule: null
          networkResourceGroup: ""
          osDisk:
            diskSizeGB: 128
            managedDisk:
              storageAccountType: Premium_LRS
            osType: Linux
          publicIP: false
          publicLoadBalancer: ""
          resourceGroup: <infrastructure_id>-rg 17
          sshPrivateKey: ""
          sshPublicKey: ""
          tags:
            - name: <custom_tag_name> 18
              value: <custom_tag_value> 19
          subnet: <infrastructure_id>-<role>-subnet 20 21
          userDataSecret:
            name: worker-user-data 22
          vmSize: Standard_D4s_v3
          vnet: <infrastructure_id>-vnet 23
          zone: "1" 24
      taints: 25
      - key: node-role.kubernetes.io/infra
        effect: NoSchedule
1 5 7 16 17 20 23
Spécifiez l'ID d'infrastructure qui est basé sur l'ID de cluster que vous avez défini lorsque vous avez provisionné le cluster. Si le CLI OpenShift est installé, vous pouvez obtenir l'ID d'infrastructure en exécutant la commande suivante : 
$ oc get -o jsonpath='{.status.infrastructureName}{"\n"}' infrastructure cluster

Vous pouvez obtenir le sous-réseau en exécutant la commande suivante : 

$  oc -n openshift-machine-api \
    -o jsonpath='{.spec.template.spec.providerSpec.value.subnet}{"\n"}' \
    get machineset/<infrastructure_id>-worker-centralus1

Vous pouvez obtenir le vnet en exécutant la commande suivante : 

$  oc -n openshift-machine-api \
    -o jsonpath='{.spec.template.spec.providerSpec.value.vnet}{"\n"}' \
    get machineset/<infrastructure_id>-worker-centralus1
2 3 8 9 12 21 22
Indiquez l'étiquette du nœud <infra>.
4 6 10
Spécifiez l'ID de l'infrastructure, l'étiquette du nœud <infra> et la région.
11
Facultatif : Spécifiez le nom de l'ensemble de machines de calcul pour activer l'utilisation des ensembles de disponibilité. Ce paramètre ne s'applique qu'aux nouvelles machines de calcul.
13
Spécifiez les détails de l'image pour votre ensemble de machines de calcul. Si vous souhaitez utiliser une image Azure Marketplace, voir "Sélection d'une image Azure Marketplace".
14
Spécifiez une image compatible avec votre type d'instance. Les images Hyper-V de génération V2 créées par le programme d'installation ont un suffixe -gen2, tandis que les images V1 portent le même nom sans suffixe.
15
Spécifiez la région où placer les machines.
24
Indiquez la zone de votre région où placer les machines. Assurez-vous que votre région prend en charge la zone que vous spécifiez.
18 19
Optionnel : Spécifiez des balises personnalisées dans votre jeu de machines. Indiquez le nom de la balise dans le champ <custom_tag_name> et la valeur de la balise correspondante dans le champ <custom_tag_value>.
25
Spécifiez une erreur pour empêcher les charges de travail utilisateur d'être planifiées sur les nœuds infra.

Les ensembles de machines fonctionnant sur Azure prennent en charge les VM Spot non garanties. Vous pouvez réaliser des économies en utilisant des VM Spot à un prix inférieur à celui des VM standard sur Azure. Vous pouvez configurer les VM Spot en ajoutant spotVMOptions au fichier YAML MachineSet.

Ressources complémentaires

7.2.1.4. Exemple de YAML pour une ressource personnalisée d'un ensemble de machines de calcul sur Azure Stack Hub

Cet exemple YAML définit un ensemble de machines de calcul qui s'exécute dans la zone 1 Microsoft Azure d'une région et crée des nœuds étiquetés avec node-role.kubernetes.io/infra: "".

Dans cet exemple, <infrastructure_id> est l'étiquette d'ID d'infrastructure basée sur l'ID de cluster que vous avez défini lors du provisionnement du cluster, et <infra> est l'étiquette de nœud à ajouter. 

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  labels:
    machine.openshift.io/cluster-api-cluster: <infrastructure_id> 1
    machine.openshift.io/cluster-api-machine-role: <infra> 2
    machine.openshift.io/cluster-api-machine-type: <infra> 3
  name: <infrastructure_id>-infra-<region> 4
  namespace: openshift-machine-api
spec:
  replicas: 1
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructure_id> 5
      machine.openshift.io/cluster-api-machineset: <infrastructure_id>-infra-<region> 6
  template:
    metadata:
      creationTimestamp: null
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id> 7
        machine.openshift.io/cluster-api-machine-role: <infra> 8
        machine.openshift.io/cluster-api-machine-type: <infra> 9
        machine.openshift.io/cluster-api-machineset: <infrastructure_id>-infra-<region> 10
    spec:
      metadata:
        creationTimestamp: null
        labels:
          node-role.kubernetes.io/infra: "" 11
      taints: 12
      - key: node-role.kubernetes.io/infra
        effect: NoSchedule
      providerSpec:
        value:
          apiVersion: machine.openshift.io/v1beta1
          availabilitySet: <availability_set> 13
          credentialsSecret:
            name: azure-cloud-credentials
            namespace: openshift-machine-api
          image:
            offer: ""
            publisher: ""
            resourceID: /resourceGroups/<infrastructure_id>-rg/providers/Microsoft.Compute/images/<infrastructure_id> 14
            sku: ""
            version: ""
          internalLoadBalancer: ""
          kind: AzureMachineProviderSpec
          location: <region> 15
          managedIdentity: <infrastructure_id>-identity 16
          metadata:
            creationTimestamp: null
          natRule: null
          networkResourceGroup: ""
          osDisk:
            diskSizeGB: 128
            managedDisk:
              storageAccountType: Premium_LRS
            osType: Linux
          publicIP: false
          publicLoadBalancer: ""
          resourceGroup: <infrastructure_id>-rg 17
          sshPrivateKey: ""
          sshPublicKey: ""
          subnet: <infrastructure_id>-<role>-subnet 18 19
          userDataSecret:
            name: worker-user-data 20
          vmSize: Standard_DS4_v2
          vnet: <infrastructure_id>-vnet 21
          zone: "1" 22
1 5 7 14 16 17 18 21
Spécifiez l'ID d'infrastructure qui est basé sur l'ID de cluster que vous avez défini lorsque vous avez provisionné le cluster. Si le CLI OpenShift est installé, vous pouvez obtenir l'ID d'infrastructure en exécutant la commande suivante : 
$ oc get -o jsonpath='{.status.infrastructureName}{"\n"}' infrastructure cluster

Vous pouvez obtenir le sous-réseau en exécutant la commande suivante : 

$  oc -n openshift-machine-api \
    -o jsonpath='{.spec.template.spec.providerSpec.value.subnet}{"\n"}' \
    get machineset/<infrastructure_id>-worker-centralus1

Vous pouvez obtenir le vnet en exécutant la commande suivante : 

$  oc -n openshift-machine-api \
    -o jsonpath='{.spec.template.spec.providerSpec.value.vnet}{"\n"}' \
    get machineset/<infrastructure_id>-worker-centralus1
2 3 8 9 11 19 20
Indiquez l'étiquette du nœud <infra>.
4 6 10
Spécifiez l'ID de l'infrastructure, l'étiquette du nœud <infra> et la région.
12
Spécifiez une erreur pour empêcher les charges de travail utilisateur d'être planifiées sur les nœuds infra.
15
Spécifiez la région où placer les machines.
13
Spécifiez l'ensemble de disponibilité pour le cluster.
22
Indiquez la zone de votre région où placer les machines. Assurez-vous que votre région prend en charge la zone que vous spécifiez.
Note

Les ensembles de machines fonctionnant sur Azure Stack Hub ne prennent pas en charge les VM Spot non garanties.

7.2.1.5. Exemple de YAML pour une ressource personnalisée d'un ensemble de machines de calcul sur IBM Cloud

Cet exemple YAML définit un ensemble de machines de calcul qui s'exécute dans une zone IBM Cloud spécifiée dans une région et crée des nœuds étiquetés avec node-role.kubernetes.io/infra: "".

Dans cet exemple, <infrastructure_id> est l'étiquette d'ID d'infrastructure basée sur l'ID de cluster que vous avez défini lors du provisionnement du cluster, et <infra> est l'étiquette de nœud à ajouter. 

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  labels:
    machine.openshift.io/cluster-api-cluster: <infrastructure_id> 1
    machine.openshift.io/cluster-api-machine-role: <infra> 2
    machine.openshift.io/cluster-api-machine-type: <infra> 3
  name: <infrastructure_id>-<infra>-<region> 4
  namespace: openshift-machine-api
spec:
  replicas: 1
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructure_id> 5
      machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<infra>-<region> 6
  template:
    metadata:
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id> 7
        machine.openshift.io/cluster-api-machine-role: <infra> 8
        machine.openshift.io/cluster-api-machine-type: <infra> 9
        machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<infra>-<region> 10
    spec:
      metadata:
        labels:
          node-role.kubernetes.io/infra: ""
      providerSpec:
        value:
          apiVersion: ibmcloudproviderconfig.openshift.io/v1beta1
          credentialsSecret:
            name: ibmcloud-credentials
          image: <infrastructure_id>-rhcos 11
          kind: IBMCloudMachineProviderSpec
          primaryNetworkInterface:
              securityGroups:
              - <infrastructure_id>-sg-cluster-wide
              - <infrastructure_id>-sg-openshift-net
              subnet: <infrastructure_id>-subnet-compute-<zone> 12
          profile: <instance_profile> 13
          region: <region> 14
          resourceGroup: <resource_group> 15
          userDataSecret:
              name: <role>-user-data 16
          vpc: <vpc_name> 17
          zone: <zone> 18
        taints: 19
        - key: node-role.kubernetes.io/infra
          effect: NoSchedule
1 5 7
L'ID de l'infrastructure qui est basé sur l'ID du cluster que vous avez défini lorsque vous avez provisionné le cluster. Si le CLI OpenShift est installé, vous pouvez obtenir l'ID d'infrastructure en exécutant la commande suivante : 
$ oc get -o jsonpath='{.status.infrastructureName}{"\n"}' infrastructure cluster
2 3 8 9 16
L'étiquette du nœud <infra>.
4 6 10
L'ID de l'infrastructure, l'étiquette du nœud <infra> et la région.
11
L'image personnalisée de Red Hat Enterprise Linux CoreOS (RHCOS) qui a été utilisée pour l'installation du cluster.
12
L'ID d'infrastructure et la zone de votre région où placer les machines. Assurez-vous que votre région prend en charge la zone que vous spécifiez.
13
Spécifiez le profil de l'instance IBM Cloud.
14
Spécifiez la région où placer les machines.
15
Le groupe de ressources dans lequel les ressources de la machine sont placées. Il s'agit soit d'un groupe de ressources existant spécifié au moment de l'installation, soit d'un groupe de ressources créé par l'installateur et nommé en fonction de l'identifiant de l'infrastructure.
17
Le nom du VPC.
18
Indiquez la zone de votre région où placer les machines. Assurez-vous que votre région prend en charge la zone que vous spécifiez.
19
L'altération pour empêcher les charges de travail des utilisateurs d'être programmées sur les nœuds infra.

7.2.1.6. Exemple de YAML pour une ressource personnalisée d'une machine de calcul sur GCP

Cet exemple YAML définit un ensemble de machines de calcul qui fonctionne dans Google Cloud Platform (GCP) et crée des nœuds étiquetés avec node-role.kubernetes.io/infra: "".

Dans cet exemple, <infrastructure_id> est l'étiquette d'ID d'infrastructure basée sur l'ID de cluster que vous avez défini lors du provisionnement du cluster, et <infra> est l'étiquette de nœud à ajouter. 

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  labels:
    machine.openshift.io/cluster-api-cluster: <infrastructure_id> 1
  name: <infrastructure_id>-w-a
  namespace: openshift-machine-api
spec:
  replicas: 1
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructure_id>
      machine.openshift.io/cluster-api-machineset: <infrastructure_id>-w-a
  template:
    metadata:
      creationTimestamp: null
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id>
        machine.openshift.io/cluster-api-machine-role: <infra> 2
        machine.openshift.io/cluster-api-machine-type: <infra>
        machine.openshift.io/cluster-api-machineset: <infrastructure_id>-w-a
    spec:
      metadata:
        labels:
          node-role.kubernetes.io/infra: ""
      providerSpec:
        value:
          apiVersion: gcpprovider.openshift.io/v1beta1
          canIPForward: false
          credentialsSecret:
            name: gcp-cloud-credentials
          deletionProtection: false
          disks:
          - autoDelete: true
            boot: true
            image: <path_to_image> 3
            labels: null
            sizeGb: 128
            type: pd-ssd
          gcpMetadata: 4
          - key: <custom_metadata_key>
            value: <custom_metadata_value>
          kind: GCPMachineProviderSpec
          machineType: n1-standard-4
          metadata:
            creationTimestamp: null
          networkInterfaces:
          - network: <infrastructure_id>-network
            subnetwork: <infrastructure_id>-worker-subnet
          projectID: <project_name> 5
          region: us-central1
          serviceAccounts:
          - email: <infrastructure_id>-w@<project_name>.iam.gserviceaccount.com
            scopes:
            - https://www.googleapis.com/auth/cloud-platform
          tags:
            - <infrastructure_id>-worker
          userDataSecret:
            name: worker-user-data
          zone: us-central1-a
      taints: 6
      - key: node-role.kubernetes.io/infra
        effect: NoSchedule
1
Pour <infrastructure_id>, spécifiez l'ID d'infrastructure qui est basé sur l'ID de cluster que vous avez défini lorsque vous avez provisionné le cluster. Si le CLI OpenShift est installé, vous pouvez obtenir l'ID d'infrastructure en exécutant la commande suivante : 
$ oc get -o jsonpath='{.status.infrastructureName}{"\n"}' infrastructure cluster
2
Pour <infra>, indiquez l'étiquette du nœud <infra>.
3
Spécifiez le chemin d'accès à l'image utilisée dans les ensembles de machines de calcul actuels. Si le CLI OpenShift est installé, vous pouvez obtenir le chemin d'accès à l'image en exécutant la commande suivante : 
$ oc -n openshift-machine-api \
    -o jsonpath='{.spec.template.spec.providerSpec.value.disks[0].image}{"\n"}' \
    get machineset/<infrastructure_id>-worker-a

To use a GCP Marketplace image, specify the offer to use:

  • OpenShift Container Platform: https://www.googleapis.com/compute/v1/projects/redhat-marketplace-public/global/images/redhat-coreos-ocp-48-x86-64-202210040145
  • OpenShift Platform Plus: https://www.googleapis.com/compute/v1/projects/redhat-marketplace-public/global/images/redhat-coreos-opp-48-x86-64-202206140145
  • OpenShift Kubernetes Engine: https://www.googleapis.com/compute/v1/projects/redhat-marketplace-public/global/images/redhat-coreos-oke-48-x86-64-202206140145
4
Facultatif : Spécifiez des métadonnées personnalisées sous la forme d'une paire key:value. Pour des exemples de cas d'utilisation, voir la documentation GCP pour la définition de métadonnées personnalisées.
5
Pour <project_name>, indiquez le nom du projet GCP que vous utilisez pour votre cluster.
6
Spécifiez une erreur pour empêcher les charges de travail utilisateur d'être planifiées sur les nœuds infra.

Les ensembles de machines fonctionnant sur GCP prennent en charge les instances VM préemptibles non garanties. Vous pouvez réaliser des économies en utilisant des instances VM préemptibles à un prix inférieur à celui des instances normales sur GCP. Vous pouvez configurer les instances VM pr éemptibles en ajoutant preemptible au fichier YAML MachineSet.

7.2.1.7. Exemple de YAML pour une ressource personnalisée compute machine set sur Nutanix

Cet exemple YAML définit un ensemble de machines de calcul Nutanix qui crée des nœuds étiquetés avec node-role.kubernetes.io/infra: "".

Dans cet exemple, <infrastructure_id> est l'étiquette d'ID d'infrastructure basée sur l'ID de cluster que vous avez défini lors du provisionnement du cluster, et <infra> est l'étiquette de nœud à ajouter. 

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  labels:
    machine.openshift.io/cluster-api-cluster: <infrastructure_id> 1
    machine.openshift.io/cluster-api-machine-role: <infra> 2
    machine.openshift.io/cluster-api-machine-type: <infra> 3
  name: <infrastructure_id>-<infra>-<zone> 4
  namespace: openshift-machine-api
  annotations: 5
    machine.openshift.io/memoryMb: "16384"
    machine.openshift.io/vCPU: "4"
spec:
  replicas: 3
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructure_id> 6
      machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<infra>-<zone> 7
  template:
    metadata:
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id> 8
        machine.openshift.io/cluster-api-machine-role: <infra> 9
        machine.openshift.io/cluster-api-machine-type: <infra> 10
        machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<infra>-<zone> 11
    spec:
      metadata:
        labels:
          node-role.kubernetes.io/infra: ""
      providerSpec:
        value:
          apiVersion: machine.openshift.io/v1
          cluster:
            type: uuid
            uuid: <cluster_uuid>
          credentialsSecret:
            name: nutanix-creds-secret
          image:
            name: <infrastructure_id>-rhcos 12
            type: name
          kind: NutanixMachineProviderConfig
          memorySize: 16Gi 13
          subnets:
          - type: uuid
            uuid: <subnet_uuid>
          systemDiskSize: 120Gi 14
          userDataSecret:
            name: <user_data_secret> 15
          vcpuSockets: 4 16
          vcpusPerSocket: 1 17
      taints: 18
      - key: node-role.kubernetes.io/infra
        effect: NoSchedule
1 6 8
Spécifiez l'ID d'infrastructure qui est basé sur l'ID de cluster que vous avez défini lorsque vous avez provisionné le cluster. Si l'OpenShift CLI (oc) est installé, vous pouvez obtenir l'ID d'infrastructure en exécutant la commande suivante : 
$ oc get -o jsonpath='{.status.infrastructureName}{"\n"}' infrastructure cluster
2 3 9 10
Indiquez l'étiquette du nœud <infra>.
4 7 11
Spécifiez l'ID de l'infrastructure, l'étiquette du nœud <infra> et la zone.
5
Annotations pour le cluster autoscaler.
12
Spécifiez l'image à utiliser. Utilisez une image provenant d'un jeu de machines de calcul par défaut existant pour le cluster.
13
Spécifiez la quantité de mémoire pour le cluster en Gi.
14
Spécifiez la taille du disque système en Gi.
15
Spécifiez le nom du secret dans le fichier YAML des données utilisateur qui se trouve dans l'espace de noms openshift-machine-api. Utilisez la valeur indiquée par le programme d'installation dans le jeu de machines de calcul par défaut.
16
Spécifiez le nombre de sockets vCPU.
17
Spécifiez le nombre de vCPU par socket.
18
Spécifiez une erreur pour empêcher les charges de travail utilisateur d'être planifiées sur les nœuds infra.

7.2.1.8. Exemple de YAML pour une ressource personnalisée d'une machine de calcul sur RHOSP

Cet exemple YAML définit un ensemble de machines de calcul qui fonctionne sur Red Hat OpenStack Platform (RHOSP) et crée des nœuds qui sont étiquetés avec node-role.kubernetes.io/infra: "".

Dans cet exemple, <infrastructure_id> est l'étiquette d'ID d'infrastructure basée sur l'ID de cluster que vous avez défini lors du provisionnement du cluster, et <infra> est l'étiquette de nœud à ajouter. 

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  labels:
    machine.openshift.io/cluster-api-cluster: <infrastructure_id> 1
    machine.openshift.io/cluster-api-machine-role: <infra> 2
    machine.openshift.io/cluster-api-machine-type: <infra> 3
  name: <infrastructure_id>-infra 4
  namespace: openshift-machine-api
spec:
  replicas: <number_of_replicas>
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructure_id> 5
      machine.openshift.io/cluster-api-machineset: <infrastructure_id>-infra 6
  template:
    metadata:
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id> 7
        machine.openshift.io/cluster-api-machine-role: <infra> 8
        machine.openshift.io/cluster-api-machine-type: <infra> 9
        machine.openshift.io/cluster-api-machineset: <infrastructure_id>-infra 10
    spec:
      metadata:
        creationTimestamp: null
        labels:
          node-role.kubernetes.io/infra: ""
      taints: 11
      - key: node-role.kubernetes.io/infra
        effect: NoSchedule
      providerSpec:
        value:
          apiVersion: openstackproviderconfig.openshift.io/v1alpha1
          cloudName: openstack
          cloudsSecret:
            name: openstack-cloud-credentials
            namespace: openshift-machine-api
          flavor: <nova_flavor>
          image: <glance_image_name_or_location>
          serverGroupID: <optional_UUID_of_server_group> 12
          kind: OpenstackProviderSpec
          networks: 13
          - filter: {}
            subnets:
            - filter:
                name: <subnet_name>
                tags: openshiftClusterID=<infrastructure_id> 14
          primarySubnet: <rhosp_subnet_UUID> 15
          securityGroups:
          - filter: {}
            name: <infrastructure_id>-worker 16
          serverMetadata:
            Name: <infrastructure_id>-worker 17
            openshiftClusterID: <infrastructure_id> 18
          tags:
          - openshiftClusterID=<infrastructure_id> 19
          trunk: true
          userDataSecret:
            name: worker-user-data 20
          availabilityZone: <optional_openstack_availability_zone>
1 5 7 14 16 17 18 19
Spécifiez l'ID d'infrastructure qui est basé sur l'ID de cluster que vous avez défini lorsque vous avez provisionné le cluster. Si le CLI OpenShift est installé, vous pouvez obtenir l'ID d'infrastructure en exécutant la commande suivante : 
$ oc get -o jsonpath='{.status.infrastructureName}{"\n"}' infrastructure cluster
2 3 8 9 20
Indiquez l'étiquette du nœud <infra>.
4 6 10
Spécifiez l'ID de l'infrastructure et l'étiquette du nœud <infra>.
11
Spécifiez une erreur pour empêcher les charges de travail utilisateur d'être planifiées sur les nœuds infra.
12
Pour définir une stratégie de groupe de serveurs pour le jeu de machines, entrez la valeur renvoyée lors de la création d'un groupe de serveurs. Pour la plupart des déploiements, les stratégies anti-affinity ou soft-anti-affinity sont recommandées.
13
Requis pour les déploiements sur plusieurs réseaux. En cas de déploiement sur plusieurs réseaux, cette liste doit inclure le réseau utilisé comme valeur primarySubnet.
15
Indiquez le sous-réseau RHOSP sur lequel vous souhaitez que les points d'extrémité des nœuds soient publiés. En général, il s'agit du même sous-réseau que celui utilisé comme valeur de machinesSubnet dans le fichier install-config.yaml.

7.2.1.9. Exemple de YAML pour une ressource personnalisée d'une machine de calcul sur RHV

Cet exemple YAML définit un ensemble de machines de calcul fonctionnant sur RHV et crée des nœuds étiquetés avec node-role.kubernetes.io/<node_role>: "".

Dans cet exemple, <infrastructure_id> est l'étiquette d'ID d'infrastructure basée sur l'ID de cluster que vous avez défini lors du provisionnement du cluster, et <role> est l'étiquette de nœud à ajouter. 

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  labels:
    machine.openshift.io/cluster-api-cluster: <infrastructure_id> 1
    machine.openshift.io/cluster-api-machine-role: <role> 2
    machine.openshift.io/cluster-api-machine-type: <role> 3
  name: <infrastructure_id>-<role> 4
  namespace: openshift-machine-api
spec:
  replicas: <number_of_replicas> 5
  Selector: 6
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructure_id> 7
      machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role> 8
  template:
    metadata:
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id> 9
        machine.openshift.io/cluster-api-machine-role: <role> 10
        machine.openshift.io/cluster-api-machine-type: <role> 11
        machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role> 12
    spec:
      metadata:
        labels:
          node-role.kubernetes.io/<role>: "" 13
      providerSpec:
        value:
          apiVersion: ovirtproviderconfig.machine.openshift.io/v1beta1
          cluster_id: <ovirt_cluster_id> 14
          template_name: <ovirt_template_name> 15
          sparse: <boolean_value> 16
          format: <raw_or_cow> 17
          cpu: 18
            sockets: <number_of_sockets> 19
            cores: <number_of_cores> 20
            threads: <number_of_threads> 21
          memory_mb: <memory_size> 22
          guaranteed_memory_mb:  <memory_size> 23
          os_disk: 24
            size_gb: <disk_size> 25
            storage_domain_id: <storage_domain_UUID> 26
          network_interfaces: 27
            vnic_profile_id:  <vnic_profile_id> 28
          credentialsSecret:
            name: ovirt-credentials 29
          kind: OvirtMachineProviderSpec
          type: <workload_type> 30
          auto_pinning_policy: <auto_pinning_policy> 31
          hugepages: <hugepages> 32
          affinityGroupsNames:
            - compute 33
          userDataSecret:
            name: worker-user-data
1 7 9
Spécifiez l'ID d'infrastructure qui est basé sur l'ID de cluster que vous avez défini lorsque vous avez provisionné le cluster. Si l'OpenShift CLI (oc) est installé, vous pouvez obtenir l'ID d'infrastructure en exécutant la commande suivante : 
$ oc get -o jsonpath='{.status.infrastructureName}{"\n"}' infrastructure cluster
2 3 10 11 13
Spécifiez l'étiquette de nœud à ajouter.
4 8 12
Spécifiez l'ID de l'infrastructure et l'étiquette du nœud. L'ensemble de ces deux chaînes ne peut dépasser 35 caractères.
5
Indiquez le nombre de machines à créer.
6
Sélecteur pour les machines.
14
Spécifiez l'UUID du cluster RHV auquel appartient cette instance de VM.
15
Spécifiez le modèle de VM RHV à utiliser pour créer la machine.
16
Setting this option to false enables preallocation of disks. The default is true. Setting sparse to true with format set to raw is not available for block storage domains. The raw format writes the entire virtual disk to the underlying physical disk.
17
Can be set to cow or raw. The default is cow. The cow format is optimized for virtual machines.
Note

Preallocating disks on file storage domains writes zeroes to the file. This might not actually preallocate disks depending on the underlying storage.

18
Facultatif : Le champ CPU contient la configuration du CPU, y compris les sockets, les cœurs et les threads.
19
Facultatif : Spécifiez le nombre de sockets pour une VM.
20
Facultatif : Spécifiez le nombre de cœurs par socket.
21
Facultatif : Spécifiez le nombre de threads par cœur.
22
Facultatif : Spécifiez la taille de la mémoire d'une VM en MiB.
23
Facultatif : Spécifiez la taille de la mémoire garantie d'une machine virtuelle en MiB. Il s'agit de la quantité de mémoire qui est garantie de ne pas être drainée par le mécanisme de ballonnement. Pour plus d'informations, voir Explication des paramètres de ballonnement et d'optimisation de la mémoire.
Note

Si vous utilisez une version antérieure à RHV 4.4.8, voir Exigences de mémoire garantie pour OpenShift sur les clusters Red Hat Virtualization.

24
Facultatif : Disque racine du nœud.
25
Facultatif : Spécifiez la taille du disque de démarrage en GiB.
26
Facultatif : Indiquez l'UUID du domaine de stockage pour les disques du nœud de calcul. Si aucune valeur n'est fournie, le nœud de calcul est créé sur le même domaine de stockage que les nœuds de contrôle. (par défaut)
27
Facultatif : Liste des interfaces réseau de la VM. Si vous incluez ce paramètre, OpenShift Container Platform écarte toutes les interfaces réseau du modèle et en crée de nouvelles.
28
Facultatif : Spécifiez l'ID du profil vNIC.
29
Indiquez le nom de l'objet secret qui contient les informations d'identification RHV.
30
Facultatif : Spécifiez le type de charge de travail pour lequel l'instance est optimisée. Cette valeur affecte le paramètre RHV VM. Valeurs prises en charge : desktop, server (par défaut), high_performance. high_performance améliore les performances de la VM. Il existe des limitations, par exemple, vous ne pouvez pas accéder à la VM avec une console graphique. Pour plus d'informations, voir Configuration de machines virtuelles, de modèles et de pools haute performance sur Virtual Machine Management Guide.
31
Facultatif : AutoPinningPolicy définit la stratégie qui définit automatiquement les paramètres CPU et NUMA, y compris l'épinglage sur l'hôte pour cette instance. Valeurs prises en charge : none, resize_and_pin. Pour plus d'informations, voir Définition des nœuds NUMA à l'adresse Virtual Machine Management Guide.
32
Facultatif : Hugepages est la taille en KiB pour définir les hugepages dans une VM. Valeurs prises en charge : 2048 ou 1048576. Pour plus d'informations, voir Configuration des pages volumineuses sur le site Virtual Machine Management Guide.
33
Facultatif : Une liste de noms de groupes d'affinité à appliquer aux machines virtuelles. Les groupes d'affinité doivent exister dans oVirt.
Note

Étant donné que RHV utilise un modèle lors de la création d'une VM, si vous ne spécifiez pas de valeur pour un paramètre facultatif, RHV utilise la valeur de ce paramètre qui est spécifiée dans le modèle.

7.2.1.10. Exemple de YAML pour une ressource personnalisée d'un ensemble de machines de calcul sur vSphere

Cet exemple YAML définit un ensemble de machines de calcul qui fonctionne sur VMware vSphere et crée des nœuds étiquetés avec node-role.kubernetes.io/infra: "".

Dans cet exemple, <infrastructure_id> est l'étiquette d'ID d'infrastructure basée sur l'ID de cluster que vous avez défini lors du provisionnement du cluster, et <infra> est l'étiquette de nœud à ajouter. 

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  creationTimestamp: null
  labels:
    machine.openshift.io/cluster-api-cluster: <infrastructure_id> 1
  name: <infrastructure_id>-infra 2
  namespace: openshift-machine-api
spec:
  replicas: 1
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructure_id> 3
      machine.openshift.io/cluster-api-machineset: <infrastructure_id>-infra 4
  template:
    metadata:
      creationTimestamp: null
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id> 5
        machine.openshift.io/cluster-api-machine-role: <infra> 6
        machine.openshift.io/cluster-api-machine-type: <infra> 7
        machine.openshift.io/cluster-api-machineset: <infrastructure_id>-infra 8
    spec:
      metadata:
        creationTimestamp: null
        labels:
          node-role.kubernetes.io/infra: "" 9
      taints: 10
      - key: node-role.kubernetes.io/infra
        effect: NoSchedule
      providerSpec:
        value:
          apiVersion: vsphereprovider.openshift.io/v1beta1
          credentialsSecret:
            name: vsphere-cloud-credentials
          diskGiB: 120
          kind: VSphereMachineProviderSpec
          memoryMiB: 8192
          metadata:
            creationTimestamp: null
          network:
            devices:
            - networkName: "<vm_network_name>" 11
          numCPUs: 4
          numCoresPerSocket: 1
          snapshot: ""
          template: <vm_template_name> 12
          userDataSecret:
            name: worker-user-data
          workspace:
            datacenter: <vcenter_datacenter_name> 13
            datastore: <vcenter_datastore_name> 14
            folder: <vcenter_vm_folder_path> 15
            resourcepool: <vsphere_resource_pool> 16
            server: <vcenter_server_ip> 17
1 3 5
Spécifiez l'ID d'infrastructure qui est basé sur l'ID de cluster que vous avez défini lorsque vous avez provisionné le cluster. Si l'OpenShift CLI (oc) est installé, vous pouvez obtenir l'ID d'infrastructure en exécutant la commande suivante : 
$ oc get -o jsonpath='{.status.infrastructureName}{"\n"}' infrastructure cluster
2 4 8
Spécifiez l'ID de l'infrastructure et l'étiquette du nœud <infra>.
6 7 9
Indiquez l'étiquette du nœud <infra>.
10
Spécifiez une erreur pour empêcher les charges de travail utilisateur d'être planifiées sur les nœuds infra.
11
Indiquez le réseau VM vSphere sur lequel déployer l'ensemble de machines de calcul. Ce réseau VM doit se trouver là où d'autres machines de calcul résident dans le cluster.
12
Spécifiez le modèle de VM vSphere à utiliser, par exemple user-5ddjd-rhcos.
13
Spécifiez le centre de données vCenter sur lequel déployer l'ensemble de machines de calcul.
14
Spécifiez le Datastore vCenter sur lequel déployer l'ensemble de machines de calcul.
15
Indiquez le chemin d'accès au dossier vSphere VM dans vCenter, par exemple /dc1/vm/user-inst-5ddjd.
16
Spécifiez le pool de ressources vSphere pour vos machines virtuelles.
17
Spécifiez l'IP du serveur vCenter ou le nom de domaine complet.

7.2.2. Création d'un ensemble de machines de calcul

En plus des ensembles de machines de calcul créés par le programme d'installation, vous pouvez créer vos propres ensembles pour gérer dynamiquement les ressources de calcul des machines pour les charges de travail spécifiques de votre choix.

Conditions préalables

  • Déployer un cluster OpenShift Container Platform.
  • Installez le CLI OpenShift (oc).
  • Connectez-vous à oc en tant qu'utilisateur disposant de l'autorisation cluster-admin.

Procédure

  1. Créez un nouveau fichier YAML contenant l'échantillon de ressources personnalisées (CR) de l'ensemble de machines de calcul et nommé <file_name>.yaml.

    Veillez à définir les valeurs des paramètres <clusterID> et <role>.

  2. Facultatif : si vous n'êtes pas sûr de la valeur à définir pour un champ spécifique, vous pouvez vérifier un ensemble de machines de calcul existant dans votre cluster.

    1. Pour répertorier les ensembles de machines de calcul de votre cluster, exécutez la commande suivante : 

      $ oc get machinesets -n openshift-machine-api

      Exemple de sortie

      NAME                                DESIRED   CURRENT   READY   AVAILABLE   AGE
agl030519-vplxk-worker-us-east-1a   1         1         1       1           55m
agl030519-vplxk-worker-us-east-1b   1         1         1       1           55m
agl030519-vplxk-worker-us-east-1c   1         1         1       1           55m
agl030519-vplxk-worker-us-east-1d   0         0                             55m
agl030519-vplxk-worker-us-east-1e   0         0                             55m
agl030519-vplxk-worker-us-east-1f   0         0                             55m

    2. Pour afficher les valeurs d'une ressource personnalisée (CR) d'un ensemble de machines de calcul spécifique, exécutez la commande suivante : 

      $ oc get machineset <machineset_name> \
  -n openshift-machine-api -o yaml

      Exemple de sortie

      apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  labels:
    machine.openshift.io/cluster-api-cluster: <infrastructure_id> 1
  name: <infrastructure_id>-<role> 2
  namespace: openshift-machine-api
spec:
  replicas: 1
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructure_id>
      machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role>
  template:
    metadata:
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id>
        machine.openshift.io/cluster-api-machine-role: <role>
        machine.openshift.io/cluster-api-machine-type: <role>
        machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role>
    spec:
      providerSpec: 3
        ...

      1
      L'ID de l'infrastructure du cluster.
      2
      Une étiquette de nœud par défaut.
      Note

      Pour les clusters disposant d'une infrastructure fournie par l'utilisateur, un ensemble de machines de calcul ne peut créer que des machines de type worker et infra.

      3
      Les valeurs de la section <providerSpec> du CR de l'ensemble de machines de calcul sont spécifiques à la plate-forme. Pour plus d'informations sur les paramètres <providerSpec> dans le CR, consultez l'exemple de configuration du CR de l'ensemble de machines de calcul pour votre fournisseur.

  3. Créez un CR MachineSet en exécutant la commande suivante : 

    oc create -f <nom_du_fichier>.yaml

Vérification

  • Affichez la liste des ensembles de machines de calcul en exécutant la commande suivante : 

    $ oc get machineset -n openshift-machine-api

    Exemple de sortie

    NAME                                DESIRED   CURRENT   READY   AVAILABLE   AGE
agl030519-vplxk-infra-us-east-1a    1         1         1       1           11m
agl030519-vplxk-worker-us-east-1a   1         1         1       1           55m
agl030519-vplxk-worker-us-east-1b   1         1         1       1           55m
agl030519-vplxk-worker-us-east-1c   1         1         1       1           55m
agl030519-vplxk-worker-us-east-1d   0         0                             55m
agl030519-vplxk-worker-us-east-1e   0         0                             55m
agl030519-vplxk-worker-us-east-1f   0         0                             55m

    Lorsque le nouveau jeu de machines de calcul est disponible, les valeurs DESIRED et CURRENT correspondent. Si le jeu de machines de calcul n'est pas disponible, attendez quelques minutes et exécutez à nouveau la commande.

7.2.3. Création d'un nœud d'infrastructure

Important

Voir Création de jeux de machines d'infrastructure pour les environnements d'infrastructure fournis par l'installateur ou pour tout cluster dont les nœuds du plan de contrôle sont gérés par l'API des machines.

Les exigences du cluster imposent le provisionnement de l'infrastructure, également appelée infra nodes. Le programme d'installation ne fournit des provisions que pour le plan de contrôle et les nœuds de travail. Les nœuds de travail peuvent être désignés comme nœuds d'infrastructure ou nœuds d'application, également appelés app, par le biais de l'étiquetage.

Procédure

  1. Ajoutez une étiquette au nœud de travailleur que vous voulez utiliser comme nœud d'application : 

    $ oc label node <node-name> node-role.kubernetes.io/app=""

  2. Ajoutez une étiquette aux nœuds de travailleur que vous souhaitez utiliser comme nœuds d'infrastructure : 

    $ oc label node <node-name> node-role.kubernetes.io/infra=""

  3. Vérifiez si les nœuds concernés ont désormais les rôles infra et app: 

    $ oc get nodes

  4. Créer un sélecteur de nœuds par défaut pour l'ensemble du cluster. Le sélecteur de nœuds par défaut est appliqué aux modules créés dans tous les espaces de noms. Cela crée une intersection avec tous les sélecteurs de nœuds existants sur un pod, ce qui contraint davantage le sélecteur du pod.

    Important

    Si la clé du sélecteur de nœuds par défaut est en conflit avec la clé de l'étiquette d'un pod, le sélecteur de nœuds par défaut n'est pas appliqué.

    Cependant, ne définissez pas un sélecteur de nœud par défaut qui pourrait rendre un module non ordonnançable. Par exemple, si le sélecteur de nœud par défaut est défini sur un rôle de nœud spécifique, tel que node-role.kubernetes.io/infra="", alors que l'étiquette d'un module est définie sur un rôle de nœud différent, tel que node-role.kubernetes.io/master="", le module risque de ne plus être ordonnançable. C'est pourquoi il convient d'être prudent lorsque l'on définit le sélecteur de nœuds par défaut sur des rôles de nœuds spécifiques.

    Vous pouvez également utiliser un sélecteur de nœud de projet pour éviter les conflits de clés de sélecteur de nœud à l'échelle du cluster.

    1. Modifiez l'objet Scheduler: 

      $ oc edit scheduler cluster

    2. Ajoutez le champ defaultNodeSelector avec le sélecteur de nœud approprié : 

      apiVersion: config.openshift.io/v1
kind: Scheduler
metadata:
  name: cluster
...
spec:
  defaultNodeSelector: topology.kubernetes.io/region=us-east-1 1
...
      1
      Cet exemple de sélecteur de nœuds déploie par défaut les pods sur les nœuds de la région us-east-1.
    3. Enregistrez le fichier pour appliquer les modifications.

Vous pouvez maintenant déplacer les ressources d'infrastructure vers les nœuds infra nouvellement étiquetés.

Ressources complémentaires

7.2.4. Création d'un pool de configuration pour les machines d'infrastructure

Si vous avez besoin que les machines d'infrastructure aient des configurations dédiées, vous devez créer un pool d'infrastructure.

Procédure

  1. Ajoutez une étiquette au nœud que vous souhaitez affecter comme nœud infra avec une étiquette spécifique : 

    $ oc label node <node_name> <label>
    $ oc label node ci-ln-n8mqwr2-f76d1-xscn2-worker-c-6fmtx node-role.kubernetes.io/infra=

  2. Créez un pool de configuration de machine qui contient à la fois le rôle de travailleur et votre rôle personnalisé en tant que sélecteur de configuration de machine : 

    $ cat infra.mcp.yaml

    Exemple de sortie

    apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfigPool
metadata:
  name: infra
spec:
  machineConfigSelector:
    matchExpressions:
      - {key: machineconfiguration.openshift.io/role, operator: In, values: [worker,infra]} 1
  nodeSelector:
    matchLabels:
      node-role.kubernetes.io/infra: "" 2

    1
    Ajoutez le rôle de travailleur et votre rôle personnalisé.
    2
    Ajoutez l'étiquette que vous avez ajoutée au nœud en tant que nodeSelector.
    Note

    Les pools de configuration machine personnalisés héritent des configurations machine du pool de travail. Les pools personnalisés utilisent n'importe quelle configuration de machine ciblée pour le pool de travailleur, mais ajoutent la possibilité de déployer également des changements qui sont ciblés uniquement sur le pool personnalisé. Étant donné qu'un pool personnalisé hérite des ressources du pool de travail, toute modification apportée au pool de travail affecte également le pool personnalisé.

  3. Après avoir obtenu le fichier YAML, vous pouvez créer le pool de configuration de la machine : 

    $ oc create -f infra.mcp.yaml

  4. Vérifier les configurations des machines pour s'assurer que la configuration de l'infrastructure a été rendue avec succès : 

    $ oc get machineconfig

    Exemple de sortie

    NAME                                                        GENERATEDBYCONTROLLER                      IGNITIONVERSION   CREATED
00-master                                                   365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             31d
00-worker                                                   365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             31d
01-master-container-runtime                                 365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             31d
01-master-kubelet                                           365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             31d
01-worker-container-runtime                                 365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             31d
01-worker-kubelet                                           365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             31d
99-master-1ae2a1e0-a115-11e9-8f14-005056899d54-registries   365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             31d
99-master-ssh                                                                                          3.2.0             31d
99-worker-1ae64748-a115-11e9-8f14-005056899d54-registries   365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             31d
99-worker-ssh                                                                                          3.2.0             31d
rendered-infra-4e48906dca84ee702959c71a53ee80e7             365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             23m
rendered-master-072d4b2da7f88162636902b074e9e28e            5b6fb8349a29735e48446d435962dec4547d3090   3.2.0             31d
rendered-master-3e88ec72aed3886dec061df60d16d1af            02c07496ba0417b3e12b78fb32baf6293d314f79   3.2.0             31d
rendered-master-419bee7de96134963a15fdf9dd473b25            365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             17d
rendered-master-53f5c91c7661708adce18739cc0f40fb            365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             13d
rendered-master-a6a357ec18e5bce7f5ac426fc7c5ffcd            365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             7d3h
rendered-master-dc7f874ec77fc4b969674204332da037            5b6fb8349a29735e48446d435962dec4547d3090   3.2.0             31d
rendered-worker-1a75960c52ad18ff5dfa6674eb7e533d            5b6fb8349a29735e48446d435962dec4547d3090   3.2.0             31d
rendered-worker-2640531be11ba43c61d72e82dc634ce6            5b6fb8349a29735e48446d435962dec4547d3090   3.2.0             31d
rendered-worker-4e48906dca84ee702959c71a53ee80e7            365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             7d3h
rendered-worker-4f110718fe88e5f349987854a1147755            365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             17d
rendered-worker-afc758e194d6188677eb837842d3b379            02c07496ba0417b3e12b78fb32baf6293d314f79   3.2.0             31d
rendered-worker-daa08cc1e8f5fcdeba24de60cd955cc3            365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             13d

    Vous devriez voir une nouvelle configuration de machine, avec le préfixe rendered-infra-*.

  5. Facultatif : Pour déployer les modifications apportées à un pool personnalisé, créez une configuration de machine qui utilise le nom du pool personnalisé comme étiquette, par exemple infra. Notez que cette opération n'est pas obligatoire et qu'elle n'est présentée qu'à des fins didactiques. De cette manière, vous pouvez appliquer toutes les configurations personnalisées spécifiques à vos nœuds infra.

    Note

    Après avoir créé le nouveau pool de configuration machine, le MCO génère une nouvelle configuration rendue pour ce pool, et les nœuds associés à ce pool redémarrent pour appliquer la nouvelle configuration.

    1. Créer une configuration de machine : 

      $ cat infra.mc.yaml

      Exemple de sortie

      apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  name: 51-infra
  labels:
    machineconfiguration.openshift.io/role: infra 1
spec:
  config:
    ignition:
      version: 3.2.0
    storage:
      files:
      - path: /etc/infratest
        mode: 0644
        contents:
          source: data:,infra

      1
      Ajoutez l'étiquette que vous avez ajoutée au nœud en tant que nodeSelector.

    2. Appliquer la configuration de la machine aux nœuds infra-étiquetés : 

      $ oc create -f infra.mc.yaml

  6. Confirmez que le pool de configuration de votre nouvelle machine est disponible : 

    $ oc get mcp

    Exemple de sortie

    NAME     CONFIG                                             UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
infra    rendered-infra-60e35c2e99f42d976e084fa94da4d0fc    True      False      False      1              1                   1                     0                      4m20s
master   rendered-master-9360fdb895d4c131c7c4bebbae099c90   True      False      False      3              3                   3                     0                      91m
worker   rendered-worker-60e35c2e99f42d976e084fa94da4d0fc   True      False      False      2              2                   2                     0                      91m

    Dans cet exemple, un nœud de travailleur a été transformé en nœud d'infrastructure.

Ressources complémentaires

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.