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

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

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.

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.