7.2. Ajouter des machines de calcul RHCOS à un cluster OpenShift Container Platform

Procédure

1. Utilisez le fichier ISO pour installer RHCOS sur d'autres machines de calcul. Utilisez la même méthode que lorsque vous avez créé des machines avant d'installer le cluster :

   • Burn the ISO image to a disk and boot it directly.
   • Utiliser la redirection ISO avec une interface LOM.

2. Démarrer l'image ISO RHCOS sans spécifier d'options ni interrompre la séquence de démarrage en direct. Attendez que le programme d'installation démarre à l'invite de l'interpréteur de commandes dans l'environnement réel RHCOS.

   Note

   Vous pouvez interrompre le processus de démarrage de l'installation RHCOS pour ajouter des arguments au noyau. Cependant, pour cette procédure ISO, vous devez utiliser la commande coreos-installer comme indiqué dans les étapes suivantes, au lieu d'ajouter des arguments au noyau.

3. Run the coreos-installer command and specify the options that meet your installation requirements. At a minimum, you must specify the URL that points to the Ignition config file for the node type, and the device that you are installing to:

   $ sudo coreos-installer install --ignition-url=http://<HTTP_server>/<node_type>.ign <device> --ignition-hash=sha512-<digest> 12

   1

   You must run the coreos-installer command by using sudo, because the core user does not have the required root privileges to perform the installation.

   2

   The --ignition-hash option is required when the Ignition config file is obtained through an HTTP URL to validate the authenticity of the Ignition config file on the cluster node. <digest> is the Ignition config file SHA512 digest obtained in a preceding step.

   Note

   If you want to provide your Ignition config files through an HTTPS server that uses TLS, you can add the internal certificate authority (CA) to the system trust store before running coreos-installer.

   The following example initializes a bootstrap node installation to the /dev/sda device. The Ignition config file for the bootstrap node is obtained from an HTTP web server with the IP address 192.168.1.2:

   $ sudo coreos-installer install --ignition-url=http://192.168.1.2:80/installation_directory/bootstrap.ign /dev/sda --ignition-hash=sha512-a5a2d43879223273c9b60af66b44202a1d1248fc01cf156c46d4a79f552b6bad47bc8cc78ddf0116e80c59d2ea9e32ba53bc807afbca581aa059311def2c3e3b

4. Monitor the progress of the RHCOS installation on the console of the machine.

   Important

   Assurez-vous que l'installation est réussie sur chaque nœud avant de commencer l'installation d'OpenShift Container Platform. L'observation du processus d'installation peut également aider à déterminer la cause des problèmes d'installation du RHCOS qui pourraient survenir.

5. Continue to create more compute machines for your cluster.

Procédure

1. Confirmez que votre installation PXE ou iPXE pour les images RHCOS est correcte.

   • Pour PXE :

     DEFAULT pxeboot
     TIMEOUT 20
     PROMPT 0
     LABEL pxeboot
         KERNEL http://<HTTP_server>/rhcos-<version>-live-kernel-<architecture> 1
         APPEND initrd=http://<HTTP_server>/rhcos-<version>-live-initramfs.<architecture>.img coreos.inst.install_dev=/dev/sda coreos.inst.ignition_url=http://<HTTP_server>/worker.ign coreos.live.rootfs_url=http://<HTTP_server>/rhcos-<version>-live-rootfs.<architecture>.img 2

     1

     Indiquez l'emplacement du fichier live kernel que vous avez téléchargé sur votre serveur HTTP.

     2

     Indiquez l'emplacement des fichiers RHCOS que vous avez téléchargés sur votre serveur HTTP. La valeur du paramètre initrd correspond à l'emplacement du fichier initramfs, la valeur du paramètre coreos.inst.ignition_url correspond à l'emplacement du fichier de configuration Ignition et la valeur du paramètre coreos.live.rootfs_url correspond à l'emplacement du fichier rootfs. Les paramètres coreos.inst.ignition_url et coreos.live.rootfs_url ne prennent en charge que HTTP et HTTPS.

1. Utilisez l'infrastructure PXE ou iPXE pour créer les machines de calcul nécessaires à votre cluster.

Procédure

1. Confirm that the cluster recognizes the machines:

   $ oc get nodes

   Exemple de sortie

   NAME      STATUS    ROLES   AGE  VERSION
   master-0  Ready     master  63m  v1.25.0
   master-1  Ready     master  63m  v1.25.0
   master-2  Ready     master  64m  v1.25.0

   The output lists all of the machines that you created.

   Note

   The preceding output might not include the compute nodes, also known as worker nodes, until some CSRs are approved.

2. Review the pending CSRs and ensure that you see the client requests with the Pending or Approved status for each machine that you added to the cluster:

   $ oc get csr

   Exemple de sortie

   NAME        AGE     REQUESTOR                                                                   CONDITION
   csr-8b2br   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
   csr-8vnps   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
   ...

   In this example, two machines are joining the cluster. You might see more approved CSRs in the list.

3. If the CSRs were not approved, after all of the pending CSRs for the machines you added are in Pending status, approve the CSRs for your cluster machines:

   Note

   Because the CSRs rotate automatically, approve your CSRs within an hour of adding the machines to the cluster. If you do not approve them within an hour, the certificates will rotate, and more than two certificates will be present for each node. You must approve all of these certificates. After the client CSR is approved, the Kubelet creates a secondary CSR for the serving certificate, which requires manual approval. Then, subsequent serving certificate renewal requests are automatically approved by the machine-approver if the Kubelet requests a new certificate with identical parameters.

   Note

   For clusters running on platforms that are not machine API enabled, such as bare metal and other user-provisioned infrastructure, you must implement a method of automatically approving the kubelet serving certificate requests (CSRs). If a request is not approved, then the oc exec, oc rsh, and oc logs commands cannot succeed, because a serving certificate is required when the API server connects to the kubelet. Any operation that contacts the Kubelet endpoint requires this certificate approval to be in place. The method must watch for new CSRs, confirm that the CSR was submitted by the node-bootstrapper service account in the system:node or system:admin groups, and confirm the identity of the node.

   • To approve them individually, run the following command for each valid CSR:

     $ oc adm certificate approve <csr_name> 1

     1

     <csr_name> est le nom d'un CSR figurant dans la liste des CSR actuels.

   • To approve all pending CSRs, run the following command:

     $ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs --no-run-if-empty oc adm certificate approve

     Note

     Some Operators might not become available until some CSRs are approved.

4. Now that your client requests are approved, you must review the server requests for each machine that you added to the cluster:

   $ oc get csr

   Exemple de sortie

   NAME        AGE     REQUESTOR                                                                   CONDITION
   csr-bfd72   5m26s   system:node:ip-10-0-50-126.us-east-2.compute.internal                       Pending
   csr-c57lv   5m26s   system:node:ip-10-0-95-157.us-east-2.compute.internal                       Pending
   ...

5. If the remaining CSRs are not approved, and are in the Pending status, approve the CSRs for your cluster machines:

   • To approve them individually, run the following command for each valid CSR:

     $ oc adm certificate approve <csr_name> 1

     1

     <csr_name> est le nom d'un CSR figurant dans la liste des CSR actuels.

   • To approve all pending CSRs, run the following command:

     $ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs oc adm certificate approve

6. After all client and server CSRs have been approved, the machines have the Ready status. Verify this by running the following command:

   $ oc get nodes

   Exemple de sortie

   NAME      STATUS    ROLES   AGE  VERSION
   master-0  Ready     master  73m  v1.25.0
   master-1  Ready     master  73m  v1.25.0
   master-2  Ready     master  74m  v1.25.0
   worker-0  Ready     worker  11m  v1.25.0
   worker-1  Ready     worker  11m  v1.25.0

   Note

   It can take a few minutes after approval of the server CSRs for the machines to transition to the Ready status.

Procédure

1. Sur une ligne de commande, passez à l'espace de noms openshift-machine-api:

   $ oc project openshift-machine-api

2. Créer un nouveau secret à partir du secret worker-user-data:

   1. Exporter la section userData du secret dans un fichier texte :

      $ oc get secret worker-user-data --template='{{index .data.userData | base64decode}}' | jq > userData.txt

   2. Modifiez le fichier texte pour ajouter les strophes storage, filesystems, et systemd pour les partitions que vous souhaitez utiliser pour le nouveau nœud. Vous pouvez spécifier tous les paramètres de configuration d'Ignition si nécessaire.

      Note

      Ne modifiez pas les valeurs de la strophe ignition.

      {
        "ignition": {
          "config": {
            "merge": [
              {
                "source": "https:...."
              }
            ]
          },
          "security": {
            "tls": {
              "certificateAuthorities": [
                {
                  "source": "data:text/plain;charset=utf-8;base64,.....=="
                }
              ]
            }
          },
          "version": "3.2.0"
        },
        "storage": {
          "disks": [
            {
              "device": "/dev/nvme1n1", 1
              "partitions": [
                {
                  "label": "var",
                  "sizeMiB": 50000, 2
                  "startMiB": 0 3
                }
              ]
            }
          ],
          "filesystems": [
            {
              "device": "/dev/disk/by-partlabel/var", 4
              "format": "xfs", 5
              "path": "/var" 6
            }
          ]
        },
        "systemd": {
          "units": [ 7
            {
              "contents": "[Unit]\nBefore=local-fs.target\n[Mount]\nWhere=/var\nWhat=/dev/disk/by-partlabel/var\nOptions=defaults,pquota\n[Install]\nWantedBy=local-fs.target\n",
              "enabled": true,
              "name": "var.mount"
            }
          ]
        }
      }

      1

      Spécifie un chemin d'accès absolu au périphérique de bloc AWS.

      2

      Spécifie la taille de la partition de données en méga-octets.

      3

      Spécifie le début de la partition en Mebibytes. Lors de l'ajout d'une partition de données au disque de démarrage, il est recommandé d'utiliser une valeur minimale de 25 000 Mo (Mebibytes). Le système de fichiers racine est automatiquement redimensionné pour remplir tout l'espace disponible jusqu'au décalage spécifié. Si aucune valeur n'est spécifiée, ou si la valeur spécifiée est inférieure au minimum recommandé, le système de fichiers racine résultant sera trop petit, et les réinstallations futures de RHCOS risquent d'écraser le début de la partition de données.

      4

      Spécifie un chemin d'accès absolu à la partition /var.

      5

      Spécifie le format du système de fichiers.

      6

      Spécifie le point de montage du système de fichiers lorsque Ignition est en cours d'exécution, par rapport à l'endroit où le système de fichiers racine sera monté. Ce n'est pas nécessairement la même chose que l'endroit où il devrait être monté dans la racine réelle, mais il est encouragé de le faire.

      7

      Définit une unité de montage systemd qui monte le périphérique /dev/disk/by-partlabel/var sur la partition /var.

   3. Extraire la section disableTemplating du secret work-user-data dans un fichier texte :

      $ oc get secret worker-user-data --template='{{index .data.disableTemplating | base64decode}}' | jq > disableTemplating.txt

   4. Créez le nouveau fichier de données utilisateur secrètes à partir des deux fichiers texte. Ce fichier secret transmet au nœud nouvellement créé les informations supplémentaires relatives à la partition du nœud contenues dans le fichier userData.txt.

      $ oc create secret generic worker-user-data-x5 --from-file=userData=userData.txt --from-file=disableTemplating=disableTemplating.txt

3. Créez un nouvel ensemble de machines de calcul pour le nouveau nœud :

   1. Créez un nouveau fichier YAML d'ensemble de machine de calcul, similaire au suivant, qui est configuré pour AWS. Ajoutez les partitions requises et le secret des données de l'utilisateur nouvellement créé :

      Astuce

      Utilisez un ensemble de machines de calcul existant comme modèle et modifiez les paramètres selon les besoins pour le nouveau nœud.

      apiVersion: machine.openshift.io/v1beta1
      kind: MachineSet
      metadata:
        labels:
          machine.openshift.io/cluster-api-cluster: auto-52-92tf4
        name: worker-us-east-2-nvme1n1 1
        namespace: openshift-machine-api
      spec:
        replicas: 1
        selector:
          matchLabels:
            machine.openshift.io/cluster-api-cluster: auto-52-92tf4
            machine.openshift.io/cluster-api-machineset: auto-52-92tf4-worker-us-east-2b
        template:
          metadata:
            labels:
              machine.openshift.io/cluster-api-cluster: auto-52-92tf4
              machine.openshift.io/cluster-api-machine-role: worker
              machine.openshift.io/cluster-api-machine-type: worker
              machine.openshift.io/cluster-api-machineset: auto-52-92tf4-worker-us-east-2b
          spec:
            metadata: {}
            providerSpec:
              value:
                ami:
                  id: ami-0c2dbd95931a
                apiVersion: awsproviderconfig.openshift.io/v1beta1
                blockDevices:
                - DeviceName: /dev/nvme1n1 2
                  ebs:
                    encrypted: true
                    iops: 0
                    volumeSize: 120
                    volumeType: gp2
                - DeviceName: /dev/nvme1n2 3
                  ebs:
                    encrypted: true
                    iops: 0
                    volumeSize: 50
                    volumeType: gp2
                credentialsSecret:
                  name: aws-cloud-credentials
                deviceIndex: 0
                iamInstanceProfile:
                  id: auto-52-92tf4-worker-profile
                instanceType: m6i.large
                kind: AWSMachineProviderConfig
                metadata:
                  creationTimestamp: null
                placement:
                  availabilityZone: us-east-2b
                  region: us-east-2
                securityGroups:
                - filters:
                  - name: tag:Name
                    values:
                    - auto-52-92tf4-worker-sg
                subnet:
                  id: subnet-07a90e5db1
                tags:
                - name: kubernetes.io/cluster/auto-52-92tf4
                  value: owned
                userDataSecret:
                  name: worker-user-data-x5 4

      1

      Spécifie un nom pour le nouveau nœud.

      2

      Spécifie un chemin d'accès absolu au périphérique de bloc AWS, ici un volume EBS crypté.

      3

      Facultatif. Spécifie un volume EBS supplémentaire.

      4

      Spécifie le fichier secret des données de l'utilisateur.

   2. Créer l'ensemble de machines de calcul :

      oc create -f <nom-de-fichier>.yaml

      Les machines peuvent prendre quelques instants avant d'être disponibles.

4. Vérifiez que la nouvelle partition et les nouveaux nœuds sont créés :

   1. Vérifiez que l'ensemble de machines de calcul est créé :

      $ oc get machineset

      Exemple de sortie

      NAME                                               DESIRED   CURRENT   READY   AVAILABLE   AGE
      ci-ln-2675bt2-76ef8-bdgsc-worker-us-east-1a        1         1         1       1           124m
      ci-ln-2675bt2-76ef8-bdgsc-worker-us-east-1b        2         2         2       2           124m
      worker-us-east-2-nvme1n1                           1         1         1       1           2m35s 1

      1

      Il s'agit du nouvel ensemble de machines de calcul.

   2. Vérifiez que le nouveau nœud est créé :

      $ oc get nodes

      Exemple de sortie

      NAME                           STATUS   ROLES    AGE     VERSION
      ip-10-0-128-78.ec2.internal    Ready    worker   117m    v1.25.0
      ip-10-0-146-113.ec2.internal   Ready    master   127m    v1.25.0
      ip-10-0-153-35.ec2.internal    Ready    worker   118m    v1.25.0
      ip-10-0-176-58.ec2.internal    Ready    master   126m    v1.25.0
      ip-10-0-217-135.ec2.internal   Ready    worker   2m57s   v1.25.0 1
      ip-10-0-225-248.ec2.internal   Ready    master   127m    v1.25.0
      ip-10-0-245-59.ec2.internal    Ready    worker   116m    v1.25.0

      1

      Il s'agit d'un nouveau nœud.

   3. Vérifiez que la partition personnalisée /var est créée sur le nouveau nœud :

      $ oc debug node/<node-name> -- chroot /host lsblk

      Par exemple :

      $ oc debug node/ip-10-0-217-135.ec2.internal -- chroot /host lsblk

      Exemple de sortie

      NAME        MAJ:MIN  RM  SIZE RO TYPE MOUNTPOINT
      nvme0n1     202:0    0   120G  0 disk
      |-nvme0n1p1 202:1    0     1M  0 part
      |-nvme0n1p2 202:2    0   127M  0 part
      |-nvme0n1p3 202:3    0   384M  0 part /boot
      `-nvme0n1p4 202:4    0 119.5G  0 part /sysroot
      nvme1n1     202:16   0    50G  0 disk
      `-nvme1n1p1 202:17   0  48.8G  0 part /var 1

      1

      Le périphérique nvme1n1 est monté sur la partition /var.