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.
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.
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 Profile vCPU Mémoire Stockage Minimum
2 cœurs vCPU
8 Go de RAM
100GB
NoteOne 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 Utilisation FQDN Description 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
andetcd
might fail.
Ressources supplémentaires
- Ressources minimales requises pour l'installation d'un cluster
- Pratiques recommandées pour la mise à l'échelle du cluster
- Exigences DNS fournies par l'utilisateur
- Creating a bootable ISO image on a USB drive
- Démarrage à partir d'une image ISO servie par HTTP à l'aide de l'API Redfish
- Suppression de nœuds d'une grappe
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é.
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
- Connectez-vous à OpenShift Cluster Manager et cliquez sur le cluster à nœud unique auquel vous souhaitez ajouter un nœud de travail.
- 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.
- 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.
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.
Les nouveaux nœuds de travail seront cryptés selon la même méthode que le cluster d'origine.
Ressources supplémentaires
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
- Connectez-vous à OpenShift Cluster Manager et copiez votre jeton API.
Définissez la variable
$OFFLINE_TOKEN
à l'aide du jeton API copié en exécutant la commande suivante :$ export OFFLINE_TOKEN=<copied_api_token>
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" )
NoteLe 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
- 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.
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
Importez le cluster OpenShift à nœud unique en exécutant les commandes suivantes :
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}')
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.
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')
Générez la ressource
InfraEnv
pour le cluster et définissez la variable$INFRA_ENV_ID
en exécutant les commandes suivantes :- Téléchargez le fichier pull secret depuis Red Hat OpenShift Cluster Manager sur console.redhat.com.
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 ressourceInfraEnv
. - 4
- Remplacez
<iso_image_type>
par le type d'image ISO, soitfull-iso
ouminimal-iso
.
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')
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
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.
-
Démarrez le nouvel hôte de travail à partir de la version téléchargée de
rhcos-live-minimal.iso
. 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
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.
Vérifiez que l'hôte est prêt à être installé en exécutant la commande suivante :
NoteVeillez à 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": [] } }
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}"
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.
ImportantVous 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" } ] }
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"}
- 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
Ressources supplémentaires
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
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
Set the host architecture:
aRCH=<architecture> $ ARCH=<architecture> 1
- 1
- Replace
<architecture>
with the target host architecture, for example,aarch64
orx86_64
.
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
-
Hébergez le fichier
worker.ign
sur un serveur web accessible depuis votre réseau. 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
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)
Download the RHCOS ISO:
$ curl -L $ISO_URL -o rhcos-live.iso
Utilisez l'ISO RHCOS et le fichier
worker.ign
hébergé pour installer le nœud de travail :- Démarrez l'hôte cible avec l'ISO RHCOS et la méthode d'installation de votre choix.
- Lorsque l'hôte cible a démarré à partir de l'ISO RHCOS, ouvrez une console sur l'hôte cible.
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 :
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
Activez l'interface réseau modifiée :
nmcli con up <network_interface>
Créez un nouveau fichier d'allumage
new-worker.ign
qui comprend une référence au fichier originalworker.ign
et une instruction supplémentaire que le programmecoreos-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 originalworker.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
.
-
Hébergez le fichier
new-worker.ign
sur un serveur web accessible depuis votre réseau. Exécutez la commande
coreos-installer
suivante, en indiquant les détails deignition-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
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>
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"
ImportantLe 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.
- 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 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
Ressources supplémentaires
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
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.
NoteThe preceding output might not include the compute nodes, also known as worker nodes, until some CSRs are approved.
Review the pending CSRs and ensure that you see the client requests with the
Pending
orApproved
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.
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:NoteBecause 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.NoteFor 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
, andoc 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 thenode-bootstrapper
service account in thesystem:node
orsystem: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
NoteSome Operators might not become available until some CSRs are approved.
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 ...
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
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
NoteIt can take a few minutes after approval of the server CSRs for the machines to transition to the
Ready
status.
Informations complémentaires
- For more information on CSRs, see Certificate Signing Requests.