Chapitre 9. Nœuds de travail pour les clusters OpenShift à nœud unique


9.1. Ajouter des nœuds de travail à des clusters OpenShift à nœud unique

Les clusters OpenShift à nœud unique réduisent les prérequis de l'hôte pour le déploiement à un seul hôte. Ceci est utile pour les déploiements dans des environnements contraints ou à la périphérie du réseau. Cependant, il est parfois nécessaire d'ajouter une capacité supplémentaire à votre cluster, par exemple, dans les scénarios de télécommunications et de périphérie de réseau. Dans ce cas, vous pouvez ajouter des nœuds de travail au cluster à nœud unique.

Il existe plusieurs façons d'ajouter des nœuds ouvriers à un cluster à nœud unique. Vous pouvez ajouter des nœuds ouvriers à un cluster manuellement, en utilisant Red Hat OpenShift Cluster Manager, ou en utilisant directement l'API REST Assisted Installer.

Important

L'ajout de nœuds de travail n'étend pas le plan de contrôle du cluster et ne fournit pas de haute disponibilité à votre cluster. Pour les clusters OpenShift à un seul nœud, la haute disponibilité est gérée en basculant sur un autre site. Il n'est pas recommandé d'ajouter un grand nombre de nœuds de travail à un cluster à nœud unique.

Note

Contrairement aux grappes à plusieurs nœuds, tout le trafic entrant est acheminé par défaut vers le seul nœud du plan de contrôle, même après l'ajout de nœuds de travail supplémentaires.

9.1.1. Configuration requise pour l'installation de nœuds de travail OpenShift à un seul nœud

Pour installer un nœud de travail OpenShift à nœud unique, vous devez répondre aux exigences suivantes :

  • Administration host: Vous devez disposer d'un ordinateur pour préparer l'ISO et suivre l'installation.
  • Production-grade server: L'installation de nœuds de travail OpenShift à un seul nœud nécessite un serveur disposant de ressources suffisantes pour exécuter les services OpenShift Container Platform et une charge de travail de production.

    Tableau 9.1. Minimum resource requirements
    ProfilevCPUMémoireStockage

    Minimum

    2 cœurs vCPU

    8 Go de RAM

    100GB

    Note

    One vCPU is equivalent to one physical core when simultaneous multithreading (SMT), or hyperthreading, is not enabled. When enabled, use the following formula to calculate the corresponding ratio:

    (threads per core × cores) × sockets = vCPUs

    The server must have a Baseboard Management Controller (BMC) when booting with virtual media.

  • Networking: Le serveur du nœud de travail doit avoir accès à Internet ou à un registre local s'il n'est pas connecté à un réseau routable. Le serveur du nœud de travail doit avoir une réservation DHCP ou une adresse IP statique et être en mesure d'accéder à l'API Kubernetes du cluster OpenShift à nœud unique, à la route d'entrée et aux noms de domaine des nœuds de cluster. Vous devez configurer le DNS pour résoudre l'adresse IP à chacun des noms de domaine pleinement qualifiés (FQDN) suivants pour le cluster OpenShift à nœud unique :

    Tableau 9.2. Required DNS records
    UtilisationFQDNDescription

    Kubernetes API

    api.<cluster_name>.<base_domain>

    Add a DNS A/AAAA or CNAME record. This record must be resolvable by clients external to the cluster.

    Internal API

    api-int.<cluster_name>.<base_domain>

    Add a DNS A/AAAA or CNAME record when creating the ISO manually. This record must be resolvable by nodes within the cluster.

    Ingress route

    *.apps.<cluster_name>.<base_domain>

    Add a wildcard DNS A/AAAA or CNAME record that targets the node. This record must be resolvable by clients external to the cluster.

    Without persistent IP addresses, communications between the apiserver and etcd might fail.

9.1.2. Ajout de nœuds de travail à l'aide d'Assisted Installer et d'OpenShift Cluster Manager

Vous pouvez ajouter des nœuds de travail à des clusters OpenShift à nœud unique qui ont été créés sur Red Hat OpenShift Cluster Manager à l'aide de l'installateur assisté.

Important

L'ajout de nœuds de travail aux clusters OpenShift à nœud unique n'est pris en charge que pour les clusters exécutant OpenShift Container Platform version 4.11 et supérieure.

Conditions préalables

  • Avoir accès à un cluster OpenShift à nœud unique installé à l'aide d'Assisted Installer.
  • Installez le CLI OpenShift (oc).
  • Connectez-vous en tant qu'utilisateur disposant des privilèges cluster-admin.
  • Assurez-vous que tous les enregistrements DNS requis existent pour le cluster auquel vous ajoutez le nœud de travail.

Procédure

  1. Connectez-vous à OpenShift Cluster Manager et cliquez sur le cluster à nœud unique auquel vous souhaitez ajouter un nœud de travail.
  2. Cliquez sur Add hosts, et téléchargez l'ISO de découverte pour le nouveau nœud de travail, en ajoutant la clé publique SSH et en configurant les paramètres de proxy à l'échelle du cluster, le cas échéant.
  3. Démarrez l'hôte cible à l'aide de l'ISO de découverte et attendez que l'hôte soit découvert dans la console. Une fois l'hôte découvert, démarrez l'installation.
  4. Au fur et à mesure de l'installation, celle-ci génère des demandes de signature de certificat (CSR) en attente pour le nœud de travail. Lorsque vous y êtes invité, approuvez les CSR en attente pour terminer l'installation.

    Lorsque le nœud de travail est installé avec succès, il est répertorié comme nœud de travail dans la console web du cluster.

Important

Les nouveaux nœuds de travail seront cryptés selon la même méthode que le cluster d'origine.

9.1.3. Ajout de nœuds de travail à l'aide de l'API Assisted Installer

Vous pouvez ajouter des nœuds de travail aux clusters OpenShift à nœud unique à l'aide de l'API REST Assisted Installer. Avant d'ajouter des nœuds de travail, vous devez vous connecter à OpenShift Cluster Manager et vous authentifier auprès de l'API.

9.1.3.1. Authentification auprès de l'API REST de l'installateur assisté

Avant de pouvoir utiliser l'API REST d'Assisted Installer, vous devez vous authentifier auprès de l'API à l'aide d'un jeton web JSON (JWT) que vous générez.

Conditions préalables

  • Connectez-vous à OpenShift Cluster Manager en tant qu'utilisateur disposant de privilèges de création de cluster.
  • Installer jq.

Procédure

  1. Connectez-vous à OpenShift Cluster Manager et copiez votre jeton API.
  2. Définissez la variable $OFFLINE_TOKEN à l'aide du jeton API copié en exécutant la commande suivante :

    $ export OFFLINE_TOKEN=<copied_api_token>
  3. Définissez la variable $JWT_TOKEN en utilisant la variable $OFFLINE_TOKEN définie précédemment :

    $ export JWT_TOKEN=$(
      curl \
      --silent \
      --header "Accept: application/json" \
      --header "Content-Type: application/x-www-form-urlencoded" \
      --data-urlencode "grant_type=refresh_token" \
      --data-urlencode "client_id=cloud-services" \
      --data-urlencode "refresh_token=${OFFLINE_TOKEN}" \
      "https://sso.redhat.com/auth/realms/redhat-external/protocol/openid-connect/token" \
      | jq --raw-output ".access_token"
    )
    Note

    Le jeton JWT n'est valable que pendant 15 minutes.

Vérification

  • Facultatif : Vérifiez que vous pouvez accéder à l'API en exécutant la commande suivante :

    $ curl -s https://api.openshift.com/api/assisted-install/v2/component-versions -H "Authorization: Bearer ${JWT_TOKEN}" | jq

    Exemple de sortie

    {
        "release_tag": "v2.5.1",
        "versions":
        {
            "assisted-installer": "registry.redhat.io/rhai-tech-preview/assisted-installer-rhel8:v1.0.0-175",
            "assisted-installer-controller": "registry.redhat.io/rhai-tech-preview/assisted-installer-reporter-rhel8:v1.0.0-223",
            "assisted-installer-service": "quay.io/app-sre/assisted-service:ac87f93",
            "discovery-agent": "registry.redhat.io/rhai-tech-preview/assisted-installer-agent-rhel8:v1.0.0-156"
        }
    }

9.1.3.2. Ajout de nœuds de travail à l'aide de l'API REST d'Assisted Installer

Vous pouvez ajouter des nœuds de travail aux clusters à l'aide de l'API REST d'Assisted Installer.

Conditions préalables

  • Installez le CLI OpenShift Cluster Manager (ocm).
  • Connectez-vous à OpenShift Cluster Manager en tant qu'utilisateur disposant de privilèges de création de cluster.
  • Installer jq.
  • Assurez-vous que tous les enregistrements DNS requis existent pour le cluster auquel vous ajoutez le nœud de travail.

Procédure

  1. Authentifiez-vous auprès de l'API REST d'Assisted Installer et générez un jeton web JSON (JWT) pour votre session. Le jeton JWT généré n'est valable que pendant 15 minutes.
  2. Définissez la variable $API_URL en exécutant la commande suivante :

    export API_URL=<api_url> 1
    1
    Remplacez <api_url> par l'URL de l'API d'installation assistée, par exemple, https://api.openshift.com
  3. Importez le cluster OpenShift à nœud unique en exécutant les commandes suivantes :

    1. Définissez la variable $OPENSHIFT_CLUSTER_ID. Connectez-vous au cluster et exécutez la commande suivante :

      $ export OPENSHIFT_CLUSTER_ID=$(oc get clusterversion -o jsonpath='{.items[].spec.clusterID}')
    2. Définissez la variable $CLUSTER_REQUEST utilisée pour importer le cluster :

      $ export CLUSTER_REQUEST=$(jq --null-input --arg openshift_cluster_id "$OPENSHIFT_CLUSTER_ID" '{
        "api_vip_dnsname": "<api_vip>", 1
        "openshift_cluster_id": $openshift_cluster_id,
        "name": "<openshift_cluster_name>" 2
      }')
      1
      Remplacez <api_vip> par le nom d'hôte du serveur API du cluster. Il peut s'agir du domaine DNS du serveur API ou de l'adresse IP du nœud unique que le nœud de travail peut atteindre. Par exemple, api.compute-1.example.com.
      2
      Remplacez <openshift_cluster_name> par le nom en texte clair de la grappe. Le nom de la grappe doit correspondre à celui qui a été défini lors de l'installation de la grappe le premier jour.
    3. Importez le cluster et définissez la variable $CLUSTER_ID. Exécutez la commande suivante :

      $ CLUSTER_ID=$(curl "$API_URL/api/assisted-install/v2/clusters/import" -H "Authorization: Bearer ${JWT_TOKEN}" -H 'accept: application/json' -H 'Content-Type: application/json' \
        -d "$CLUSTER_REQUEST" | tee /dev/stderr | jq -r '.id')
  4. Générez la ressource InfraEnv pour le cluster et définissez la variable $INFRA_ENV_ID en exécutant les commandes suivantes :

    1. Téléchargez le fichier pull secret depuis Red Hat OpenShift Cluster Manager sur console.redhat.com.
    2. Définir la variable $INFRA_ENV_REQUEST:

      export INFRA_ENV_REQUEST=$(jq --null-input \
          --slurpfile pull_secret <path_to_pull_secret_file> \1
          --arg ssh_pub_key "$(cat <path_to_ssh_pub_key>)" \2
          --arg cluster_id "$CLUSTER_ID" '{
        "name": "<infraenv_name>", 3
        "pull_secret": $pull_secret[0] | tojson,
        "cluster_id": $cluster_id,
        "ssh_authorized_key": $ssh_pub_key,
        "image_type": "<iso_image_type>" 4
      }')
      1
      Remplacez <path_to_pull_secret_file> par le chemin d'accès au fichier local contenant le secret d'extraction téléchargé depuis Red Hat OpenShift Cluster Manager sur console.redhat.com.
      2
      Remplacez <path_to_ssh_pub_key> par le chemin d'accès à la clé SSH publique requise pour accéder à l'hôte. Si vous ne définissez pas cette valeur, vous ne pourrez pas accéder à l'hôte en mode découverte.
      3
      Remplacer <infraenv_name> par le nom en texte clair de la ressource InfraEnv.
      4
      Remplacez <iso_image_type> par le type d'image ISO, soit full-iso ou minimal-iso.
    3. Envoyez l'adresse $INFRA_ENV_REQUEST à l'API /v2/infra-envs et définissez la variable $INFRA_ENV_ID:

      $ INFRA_ENV_ID=$(curl "$API_URL/api/assisted-install/v2/infra-envs" -H "Authorization: Bearer ${JWT_TOKEN}" -H 'accept: application/json' -H 'Content-Type: application/json' -d "$INFRA_ENV_REQUEST" | tee /dev/stderr | jq -r '.id')
  5. Obtenez l'URL de l'ISO de découverte pour le nœud de travailleur de cluster en exécutant la commande suivante :

    $ curl -s "$API_URL/api/assisted-install/v2/infra-envs/$INFRA_ENV_ID" -H "Authorization: Bearer ${JWT_TOKEN}" | jq -r '.download_url'

    Exemple de sortie

    https://api.openshift.com/api/assisted-images/images/41b91e72-c33e-42ee-b80f-b5c5bbf6431a?arch=x86_64&image_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE2NTYwMjYzNzEsInN1YiI6IjQxYjkxZTcyLWMzM2UtNDJlZS1iODBmLWI1YzViYmY2NDMxYSJ9.1EX_VGaMNejMhrAvVRBS7PDPIQtbOOc8LtG8OukE1a4&type=minimal-iso&version=4.12

  6. Télécharger l'ISO :

    $ curl -L -s '<iso_url>' --output rhcos-live-minimal.iso 1
    1
    Remplacez <iso_url> par l'URL de l'ISO de l'étape précédente.
  7. Démarrez le nouvel hôte de travail à partir de la version téléchargée de rhcos-live-minimal.iso.
  8. Obtenez la liste des hôtes du cluster qui sont installés sur not. Continuez à exécuter la commande suivante jusqu'à ce que le nouvel hôte apparaisse :

    $ curl -s "$API_URL/api/assisted-install/v2/clusters/$CLUSTER_ID" -H "Authorization: Bearer ${JWT_TOKEN}" | jq -r '.hosts[] | select(.status != "installed").id'

    Exemple de sortie

    2294ba03-c264-4f11-ac08-2f1bb2f8c296

  9. Définissez la variable $HOST_ID pour le nouveau nœud de travail, par exemple :

    hOST_ID=<host_id> 1
    1
    Remplacez <host_id> par l'ID de l'hôte de l'étape précédente.
  10. Vérifiez que l'hôte est prêt à être installé en exécutant la commande suivante :

    Note

    Veillez à copier l'intégralité de la commande, y compris l'expression jq.

    $ curl -s $API_URL/api/assisted-install/v2/clusters/$CLUSTER_ID -H "Authorization: Bearer ${JWT_TOKEN}" | jq '
    def host_name($host):
        if (.suggested_hostname // "") == "" then
            if (.inventory // "") == "" then
                "Unknown hostname, please wait"
            else
                .inventory | fromjson | .hostname
            end
        else
            .suggested_hostname
        end;
    
    def is_notable($validation):
        ["failure", "pending", "error"] | any(. == $validation.status);
    
    def notable_validations($validations_info):
        [
            $validations_info // "{}"
            | fromjson
            | to_entries[].value[]
            | select(is_notable(.))
        ];
    
    {
        "Hosts validations": {
            "Hosts": [
                .hosts[]
                | select(.status != "installed")
                | {
                    "id": .id,
                    "name": host_name(.),
                    "status": .status,
                    "notable_validations": notable_validations(.validations_info)
                }
            ]
        },
        "Cluster validations info": {
            "notable_validations": notable_validations(.validations_info)
        }
    }
    ' -r

    Exemple de sortie

    {
      "Hosts validations": {
        "Hosts": [
          {
            "id": "97ec378c-3568-460c-bc22-df54534ff08f",
            "name": "localhost.localdomain",
            "status": "insufficient",
            "notable_validations": [
              {
                "id": "ntp-synced",
                "status": "failure",
                "message": "Host couldn't synchronize with any NTP server"
              },
              {
                "id": "api-domain-name-resolved-correctly",
                "status": "error",
                "message": "Parse error for domain name resolutions result"
              },
              {
                "id": "api-int-domain-name-resolved-correctly",
                "status": "error",
                "message": "Parse error for domain name resolutions result"
              },
              {
                "id": "apps-domain-name-resolved-correctly",
                "status": "error",
                "message": "Parse error for domain name resolutions result"
              }
            ]
          }
        ]
      },
      "Cluster validations info": {
        "notable_validations": []
      }
    }

  11. Lorsque la commande précédente indique que l'hôte est prêt, démarrez l'installation à l'aide de l'API /v2/infra-envs/{infra_env_id}/hosts/{host_id}/actions/install en exécutant la commande suivante :

    $ curl -X POST -s "$API_URL/api/assisted-install/v2/infra-envs/$INFRA_ENV_ID/hosts/$HOST_ID/actions/install"  -H "Authorization: Bearer ${JWT_TOKEN}"
  12. Au fur et à mesure de son déroulement, l'installation génère des demandes de signature de certificat (CSR) en attente pour le nœud de travail.

    Important

    Vous devez approuver les CSR pour terminer l'installation.

    Continuez à exécuter l'appel API suivant pour surveiller l'installation du cluster :

    $ curl -s "$API_URL/api/assisted-install/v2/clusters/$CLUSTER_ID" -H "Authorization: Bearer ${JWT_TOKEN}" | jq '{
        "Cluster day-2 hosts":
            [
                .hosts[]
                | select(.status != "installed")
                | {id, requested_hostname, status, status_info, progress, status_updated_at, updated_at, infra_env_id, cluster_id, created_at}
            ]
    }'

    Exemple de sortie

    {
      "Cluster day-2 hosts": [
        {
          "id": "a1c52dde-3432-4f59-b2ae-0a530c851480",
          "requested_hostname": "control-plane-1",
          "status": "added-to-existing-cluster",
          "status_info": "Host has rebooted and no further updates will be posted. Please check console for progress and to possibly approve pending CSRs",
          "progress": {
            "current_stage": "Done",
            "installation_percentage": 100,
            "stage_started_at": "2022-07-08T10:56:20.476Z",
            "stage_updated_at": "2022-07-08T10:56:20.476Z"
          },
          "status_updated_at": "2022-07-08T10:56:20.476Z",
          "updated_at": "2022-07-08T10:57:15.306369Z",
          "infra_env_id": "b74ec0c3-d5b5-4717-a866-5b6854791bd3",
          "cluster_id": "8f721322-419d-4eed-aa5b-61b50ea586ae",
          "created_at": "2022-07-06T22:54:57.161614Z"
        }
      ]
    }

  13. En option : Exécutez la commande suivante pour afficher tous les événements du cluster :

    $ curl -s "$API_URL/api/assisted-install/v2/events?cluster_id=$CLUSTER_ID" -H "Authorization: Bearer ${JWT_TOKEN}" | jq -c '.[] | {severity, message, event_time, host_id}'

    Exemple de sortie

    {"severity":"info","message":"Host compute-0: updated status from insufficient to known (Host is ready to be installed)","event_time":"2022-07-08T11:21:46.346Z","host_id":"9d7b3b44-1125-4ad0-9b14-76550087b445"}
    {"severity":"info","message":"Host compute-0: updated status from known to installing (Installation is in progress)","event_time":"2022-07-08T11:28:28.647Z","host_id":"9d7b3b44-1125-4ad0-9b14-76550087b445"}
    {"severity":"info","message":"Host compute-0: updated status from installing to installing-in-progress (Starting installation)","event_time":"2022-07-08T11:28:52.068Z","host_id":"9d7b3b44-1125-4ad0-9b14-76550087b445"}
    {"severity":"info","message":"Uploaded logs for host compute-0 cluster 8f721322-419d-4eed-aa5b-61b50ea586ae","event_time":"2022-07-08T11:29:47.802Z","host_id":"9d7b3b44-1125-4ad0-9b14-76550087b445"}
    {"severity":"info","message":"Host compute-0: updated status from installing-in-progress to added-to-existing-cluster (Host has rebooted and no further updates will be posted. Please check console for progress and to possibly approve pending CSRs)","event_time":"2022-07-08T11:29:48.259Z","host_id":"9d7b3b44-1125-4ad0-9b14-76550087b445"}
    {"severity":"info","message":"Host: compute-0, reached installation stage Rebooting","event_time":"2022-07-08T11:29:48.261Z","host_id":"9d7b3b44-1125-4ad0-9b14-76550087b445"}

  14. Connectez-vous au cluster et approuvez les CSR en attente pour terminer l'installation.

Vérification

  • Vérifiez que le nouveau nœud de travail a été ajouté avec succès au cluster avec un statut de Ready:

    $ oc get nodes

    Exemple de sortie

    NAME                           STATUS   ROLES           AGE   VERSION
    control-plane-1.example.com    Ready    master,worker   56m   v1.25.0
    compute-1.example.com          Ready    worker          11m   v1.25.0

9.1.4. Ajouter manuellement des nœuds de travail à des clusters OpenShift à nœud unique

Vous pouvez ajouter un nœud de travail à un cluster OpenShift à nœud unique manuellement en démarrant le nœud de travail à partir de Red Hat Enterprise Linux CoreOS (RHCOS) ISO et en utilisant le fichier cluster worker.ign pour joindre le nouveau nœud de travail au cluster.

Conditions préalables

  • Installer un cluster OpenShift à un seul nœud sur du métal nu.
  • Installez le CLI OpenShift (oc).
  • Connectez-vous en tant qu'utilisateur disposant des privilèges cluster-admin.
  • Assurez-vous que tous les enregistrements DNS requis existent pour le cluster auquel vous ajoutez le nœud de travail.

Procédure

  1. Set the OpenShift Container Platform version:

    oCP_VERSION=<ocp_version> $ OCP_VERSION=<ocp_version> 1
    1
    Replace <ocp_version> with the current version, for example, latest-4.12
  2. Set the host architecture:

    aRCH=<architecture> $ ARCH=<architecture> 1
    1
    Replace <architecture> with the target host architecture, for example, aarch64 or x86_64.
  3. Récupérez les données worker.ign du cluster à nœud unique en cours d'exécution en exécutant la commande suivante :

    oc extract -n openshift-machine-api secret/worker-user-data-managed --keys=userData --to=- > worker.ign
  4. Hébergez le fichier worker.ign sur un serveur web accessible depuis votre réseau.
  5. Téléchargez le programme d'installation d'OpenShift Container Platform et mettez-le à disposition en exécutant les commandes suivantes :

    $ curl -k https://mirror.openshift.com/pub/openshift-v4/clients/ocp/$OCP_VERSION/openshift-install-linux.tar.gz > openshift-install-linux.tar.gz
    $ tar zxvf openshift-install-linux.tar.gz
    $ chmod +x openshift-install
  6. Récupérer l'URL de l'ISO RHCOS :

    $ ISO_URL=$(./openshift-install coreos print-stream-json | grep location | grep $ARCH | grep iso | cut -d\" -f4)
  7. Download the RHCOS ISO:

    $ curl -L $ISO_URL -o rhcos-live.iso
  8. Utilisez l'ISO RHCOS et le fichier worker.ign hébergé pour installer le nœud de travail :

    1. Démarrez l'hôte cible avec l'ISO RHCOS et la méthode d'installation de votre choix.
    2. Lorsque l'hôte cible a démarré à partir de l'ISO RHCOS, ouvrez une console sur l'hôte cible.
    3. Si le DHCP n'est pas activé sur votre réseau local, vous devez créer un fichier d'ignition avec le nouveau nom d'hôte et configurer l'adresse IP statique du nœud de travail avant d'exécuter l'installation de RHCOS. Effectuez les étapes suivantes :

      1. Configurez la connexion réseau de l'hôte travailleur avec une adresse IP statique. Exécutez la commande suivante sur la console de l'hôte cible :

        $ nmcli con mod <network_interface> ipv4.method manual /
        ipv4.addresses <static_ip> ipv4.gateway <network_gateway> ipv4.dns <dns_server> /
        802-3-ethernet.mtu 9000

        où :

        <static_ip>
        L'adresse IP statique de l'hôte et le CIDR, par exemple, 10.1.101.50/24
        <passerelle_de_réseau>
        Il s'agit de la passerelle réseau, par exemple, 10.1.101.1
      2. Activez l'interface réseau modifiée :

        nmcli con up <network_interface>
      3. Créez un nouveau fichier d'allumage new-worker.ign qui comprend une référence au fichier original worker.ign et une instruction supplémentaire que le programme coreos-installer utilise pour remplir le fichier /etc/hostname sur le nouvel hôte de travail. Par exemple :

        {
          "ignition":{
            "version":"3.2.0",
            "config":{
              "merge":[
                {
                  "source":"<hosted_worker_ign_file>" 1
                }
              ]
            }
          },
          "storage":{
            "files":[
              {
                "path":"/etc/hostname",
                "contents":{
                  "source":"data:,<new_fqdn>" 2
                },
                "mode":420,
                "overwrite":true,
                "path":"/etc/hostname"
              }
            ]
          }
        }
        1
        <hosted_worker_ign_file> est l'URL accessible localement pour le fichier original worker.ign. Par exemple, http://webserver.example.com/worker.ign
        2
        <new_fqdn> est le nouveau FQDN que vous avez défini pour le nœud de travail. Par exemple, new-worker.example.com.
      4. Hébergez le fichier new-worker.ign sur un serveur web accessible depuis votre réseau.
      5. Exécutez la commande coreos-installer suivante, en indiquant les détails de ignition-url et du disque dur :

        $ sudo coreos-installer install --copy-network /
        --ignition-url=<new_worker_ign_file> <hard_disk> --insecure-ignition

        où :

        <nouveau_travailleur_fichier_de_signature>
        est l'URL accessible localement pour le fichier new-worker.ign hébergé, par exemple, http://webserver.example.com/new-worker.ign
        <disque_dur>
        Il s'agit du disque dur sur lequel vous installez RHCOS, par exemple, /dev/sda
    4. Pour les réseaux dont le protocole DHCP est activé, il n'est pas nécessaire de définir une adresse IP statique. Exécutez la commande suivante coreos-installer à partir de la console de l'hôte cible pour installer le système :

      $ coreos-installer install --ignition-url=<hosted_worker_ign_file> <hard_disk>
    5. Pour activer manuellement le DHCP, appliquez le CR NMStateConfig suivant au cluster OpenShift à nœud unique :

      apiVersion: agent-install.openshift.io/v1
      kind: NMStateConfig
      metadata:
        name: nmstateconfig-dhcp
        namespace: example-sno
        labels:
          nmstate_config_cluster_name: <nmstate_config_cluster_label>
      spec:
        config:
          interfaces:
            - name: eth0
              type: ethernet
              state: up
              ipv4:
                enabled: true
                dhcp: true
              ipv6:
                enabled: false
        interfaces:
          - name: "eth0"
            macAddress: "AA:BB:CC:DD:EE:11"
      Important

      Le CR NMStateConfig est requis pour les déploiements réussis des nœuds de travail avec des adresses IP statiques et pour l'ajout d'un nœud de travail avec une adresse IP dynamique si le nœud unique OpenShift a été déployé avec une adresse IP statique. Le réseau cluster DHCP ne définit pas automatiquement ces paramètres réseau pour le nouveau nœud de travailleur.

  9. Au fur et à mesure de l'installation, celle-ci génère des demandes de signature de certificat (CSR) en attente pour le nœud de travail. Lorsque vous y êtes invité, approuvez les CSR en attente pour terminer l'installation.
  10. Lorsque l'installation est terminée, redémarrez l'hôte. L'hôte rejoint le cluster en tant que nouveau nœud de travail.

Vérification

  • Vérifiez que le nouveau nœud de travail a été ajouté avec succès au cluster avec un statut de Ready:

    $ oc get nodes

    Exemple de sortie

    NAME                           STATUS   ROLES           AGE   VERSION
    control-plane-1.example.com    Ready    master,worker   56m   v1.25.0
    compute-1.example.com          Ready    worker          11m   v1.25.0

9.1.5. Approving the certificate signing requests for your machines

When you add machines to a cluster, two pending certificate signing requests (CSRs) are generated for each machine that you added. You must confirm that these CSRs are approved or, if necessary, approve them yourself. The client requests must be approved first, followed by the server requests.

Conditions préalables

  • You added machines to your 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.

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