SupportConsoleDéveloppeursCommencer un essaiContact

5.3. Gestion des nœuds

OpenShift Container Platform utilise une ressource personnalisée KubeletConfig (CR) pour gérer la configuration des nœuds. En créant une instance d'un objet KubeletConfig, une configuration de machine gérée est créée pour remplacer les paramètres du nœud.

Note

Logging in to remote machines for the purpose of changing their configuration is not supported.

5.3.1. Modification des nœuds

Pour apporter des modifications à la configuration d'un cluster ou d'un pool de machines, vous devez créer une définition de ressource personnalisée (CRD) ou un objet kubeletConfig. OpenShift Container Platform utilise le Machine Config Controller pour surveiller les changements introduits par le CRD afin d'appliquer les changements au cluster.

Note

Comme les champs d'un objet kubeletConfig sont transmis directement au kubelet par Kubernetes en amont, la validation de ces champs est gérée directement par le kubelet lui-même. Veuillez vous référer à la documentation Kubernetes pertinente pour connaître les valeurs valides de ces champs. Des valeurs invalides dans l'objet kubeletConfig peuvent rendre les nœuds de cluster inutilisables.

Procédure

  1. Obtenez l'étiquette associée au CRD statique, Machine Config Pool, pour le type de nœud que vous souhaitez configurer. Effectuez l'une des étapes suivantes :

    1. Vérifier les étiquettes actuelles du pool de configuration de la machine souhaitée.

      Par exemple : 

      $  oc get machineconfigpool  --show-labels

      Exemple de sortie

      NAME      CONFIG                                             UPDATED   UPDATING   DEGRADED   LABELS
master    rendered-master-e05b81f5ca4db1d249a1bf32f9ec24fd   True      False      False      operator.machineconfiguration.openshift.io/required-for-upgrade=
worker    rendered-worker-f50e78e1bc06d8e82327763145bfcf62   True      False      False

    2. Ajoutez une étiquette personnalisée au pool de configuration de la machine souhaitée.

      Par exemple : 

      $ oc label machineconfigpool worker custom-kubelet=enabled

  2. Créez une ressource personnalisée (CR) kubeletconfig pour votre changement de configuration.

    Par exemple :

    Exemple de configuration pour un CR custom-config 

    apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  name: custom-config 1
spec:
  machineConfigPoolSelector:
    matchLabels:
      custom-kubelet: enabled 2
  kubeletConfig: 3
    podsPerCore: 10
    maxPods: 250
    systemReserved:
      cpu: 2000m
      memory: 1Gi

    1
    Attribuer un nom au CR.
    2
    Spécifiez l'étiquette pour appliquer le changement de configuration, il s'agit de l'étiquette que vous avez ajoutée au pool de configuration de la machine.
    3
    Indiquez la ou les nouvelles valeurs à modifier.

  3. Créer l'objet CR. 

    $ oc create -f <nom-de-fichier>

    Par exemple : 

    $ oc create -f master-kube-config.yaml

La plupart des options de configuration de Kubelet peuvent être définies par l'utilisateur. Les options suivantes ne peuvent pas être écrasées :

  • CgroupDriver
  • ClusterDNS
  • Domaine de regroupement
  • StaticPodPath
Note

Si un seul nœud contient plus de 50 images, la planification des pods peut être déséquilibrée entre les nœuds. En effet, la liste des images sur un nœud est réduite à 50 par défaut. Vous pouvez désactiver la limite d'images en modifiant l'objet KubeletConfig et en définissant la valeur de nodeStatusMaxImages à -1.

5.3.2. Configuration des nœuds du plan de contrôle comme planifiables

Vous pouvez configurer les nœuds du plan de contrôle pour qu'ils soient programmables, ce qui signifie que les nouveaux pods sont autorisés à être placés sur les nœuds maîtres. Par défaut, les nœuds du plan de contrôle ne sont pas programmables.

Vous pouvez faire en sorte que les maîtres soient programmables, mais vous devez conserver les nœuds de travail.

Note

Vous pouvez déployer OpenShift Container Platform sans nœuds de travail sur un cluster bare metal. Dans ce cas, les nœuds du plan de contrôle sont marqués comme planifiables par défaut.

Vous pouvez autoriser ou non les nœuds du plan de contrôle à être planifiables en configurant le champ mastersSchedulable.

Important

Lorsque vous configurez les nœuds du plan de contrôle pour qu'ils soient planifiables au lieu d'être non planifiables par défaut, des abonnements supplémentaires sont nécessaires. En effet, les nœuds du plan de contrôle deviennent alors des nœuds de travail.

Procédure

  1. Modifier la ressource schedulers.config.openshift.io. 

    $ oc edit schedulers.config.openshift.io cluster

  2. Configurez le champ mastersSchedulable. 

    apiVersion: config.openshift.io/v1
kind: Scheduler
metadata:
  creationTimestamp: "2019-09-10T03:04:05Z"
  generation: 1
  name: cluster
  resourceVersion: "433"
  selfLink: /apis/config.openshift.io/v1/schedulers/cluster
  uid: a636d30a-d377-11e9-88d4-0a60097bee62
spec:
  mastersSchedulable: false 1
status: {}
    1
    La valeur true permet aux nœuds du plan de contrôle d'être programmables ou la valeur false interdit aux nœuds du plan de contrôle d'être programmables.
  3. Enregistrez le fichier pour appliquer les modifications.

5.3.3. Définition des booléens SELinux

OpenShift Container Platform vous permet d'activer et de désactiver un booléen SELinux sur un nœud Red Hat Enterprise Linux CoreOS (RHCOS). La procédure suivante explique comment modifier les booléens SELinux sur les nœuds à l'aide de l'opérateur de configuration de machine (MCO). Cette procédure utilise container_manage_cgroup comme exemple de booléen. Vous pouvez modifier cette valeur pour obtenir le booléen dont vous avez besoin.

Conditions préalables

  • Vous avez installé le CLI OpenShift (oc).

Procédure

  1. Créez un nouveau fichier YAML avec un objet MachineConfig, comme dans l'exemple suivant : 

    apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker
  name: 99-worker-setsebool
spec:
  config:
    ignition:
      version: 3.2.0
    systemd:
      units:
      - contents: |
          [Unit]
          Description=Set SELinux booleans
          Before=kubelet.service

          [Service]
          Type=oneshot
          ExecStart=/sbin/setsebool container_manage_cgroup=on
          RemainAfterExit=true

          [Install]
          WantedBy=multi-user.target graphical.target
        enabled: true
        name: setsebool.service

  2. Créez le nouvel objet MachineConfig en exécutant la commande suivante : 

    $ oc create -f 99-worker-setsebool.yaml
Note

L'application de toute modification à l'objet MachineConfig entraîne un redémarrage en douceur de tous les nœuds concernés après l'application de la modification.

5.3.4. Ajout d'arguments de noyau aux nœuds

Dans certains cas particuliers, vous pouvez ajouter des arguments de noyau à un ensemble de nœuds de votre cluster. Cela ne doit être fait qu'avec prudence et en comprenant bien les implications des arguments que vous définissez.

Avertissement

Une mauvaise utilisation des arguments du noyau peut rendre vos systèmes non amorçables.

Voici quelques exemples d'arguments de noyau que vous pouvez définir :

  • enforcing=0: Configure Security Enhanced Linux (SELinux) pour qu'il fonctionne en mode permissif. En mode permissif, le système agit comme si SELinux appliquait la politique de sécurité chargée, notamment en étiquetant les objets et en émettant des entrées de refus d'accès dans les journaux, mais il ne refuse en fait aucune opération. Bien qu'il ne soit pas pris en charge par les systèmes de production, le mode permissif peut s'avérer utile pour le débogage.
  • nosmt: Désactive le multithreading symétrique (SMT) dans le noyau. Le multithreading permet d'avoir plusieurs threads logiques pour chaque unité centrale. Vous pouvez envisager d'utiliser nosmt dans les environnements multi-locataires afin de réduire les risques d'attaques croisées. En désactivant le SMT, vous choisissez essentiellement la sécurité au détriment des performances.

  • systemd.unified_cgroup_hierarchy: Active le groupe de contrôle Linux version 2 (cgroup v2). cgroup v2 est la prochaine version du groupe de contrôle du noyau et offre de nombreuses améliorations.

    Important

    OpenShift Container Platform cgroups version 2 support is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.

    Pour plus d'informations sur la portée de l'assistance des fonctionnalités de l'aperçu technologique de Red Hat, voir Portée de l'assistance des fonctionnalités de l'aperçu technologique.

Voir Kernel.org kernel parameters pour une liste et une description des arguments du noyau.

Dans la procédure suivante, vous créez un objet MachineConfig qui identifie :

  • Ensemble de machines auxquelles vous souhaitez ajouter l'argument du noyau. Dans ce cas, il s'agit des machines ayant un rôle de travailleur.
  • Arguments du noyau qui sont ajoutés à la fin des arguments du noyau existants.
  • Une étiquette qui indique à quel endroit de la liste des configurations de machines la modification est appliquée.

Conditions préalables

  • Disposer de privilèges administratifs sur un cluster OpenShift Container Platform opérationnel.

Procédure

  1. Listez les objets MachineConfig existants pour votre cluster OpenShift Container Platform afin de déterminer comment étiqueter votre machine config : 

    $ oc get MachineConfig

    Exemple de sortie

    NAME                                               GENERATEDBYCONTROLLER                      IGNITIONVERSION   AGE
00-master                                          52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
00-worker                                          52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
01-master-container-runtime                        52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
01-master-kubelet                                  52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
01-worker-container-runtime                        52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
01-worker-kubelet                                  52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
99-master-generated-registries                     52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
99-master-ssh                                                                                 3.2.0             40m
99-worker-generated-registries                     52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
99-worker-ssh                                                                                 3.2.0             40m
rendered-master-23e785de7587df95a4b517e0647e5ab7   52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
rendered-worker-5d596d9293ca3ea80c896a1191735bb1   52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m

  2. Créer un fichier objet MachineConfig qui identifie l'argument du noyau (par exemple, 05-worker-kernelarg-selinuxpermissive.yaml) 

    apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker1
  name: 05-worker-kernelarg-selinuxpermissive2
spec:
  kernelArguments:
    - enforcing=03
    1
    Applique le nouvel argument du noyau uniquement aux nœuds de travail.
    2
    Nommé pour identifier sa place dans les configurations de la machine (05) et ce qu'il fait (ajoute un argument au noyau pour configurer le mode permissif de SELinux).
    3
    Identifie l'argument exact du noyau comme enforcing=0.

  3. Créer la nouvelle configuration de la machine : 

    $ oc create -f 05-worker-kernelarg-selinuxpermissive.yaml

  4. Vérifiez les configurations de la machine pour voir si le nouveau a été ajouté : 

    $ oc get MachineConfig

    Exemple de sortie

    NAME                                               GENERATEDBYCONTROLLER                      IGNITIONVERSION   AGE
00-master                                          52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
00-worker                                          52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
01-master-container-runtime                        52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
01-master-kubelet                                  52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
01-worker-container-runtime                        52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
01-worker-kubelet                                  52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
05-worker-kernelarg-selinuxpermissive                                                         3.2.0             105s
99-master-generated-registries                     52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
99-master-ssh                                                                                 3.2.0             40m
99-worker-generated-registries                     52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
99-worker-ssh                                                                                 3.2.0             40m
rendered-master-23e785de7587df95a4b517e0647e5ab7   52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
rendered-worker-5d596d9293ca3ea80c896a1191735bb1   52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m

  5. Vérifier les nœuds : 

    $ oc get nodes

    Exemple de sortie

    NAME                           STATUS                     ROLES    AGE   VERSION
ip-10-0-136-161.ec2.internal   Ready                      worker   28m   v1.25.0
ip-10-0-136-243.ec2.internal   Ready                      master   34m   v1.25.0
ip-10-0-141-105.ec2.internal   Ready,SchedulingDisabled   worker   28m   v1.25.0
ip-10-0-142-249.ec2.internal   Ready                      master   34m   v1.25.0
ip-10-0-153-11.ec2.internal    Ready                      worker   28m   v1.25.0
ip-10-0-153-150.ec2.internal   Ready                      master   34m   v1.25.0

    Vous pouvez voir que la planification sur chaque nœud de travailleur est désactivée pendant que la modification est appliquée.

  6. Vérifiez que l'argument du noyau a fonctionné en vous rendant sur l'un des nœuds de travail et en listant les arguments de la ligne de commande du noyau (dans /proc/cmdline sur l'hôte) : 

    $ oc debug node/ip-10-0-141-105.ec2.internal

    Exemple de sortie

    Starting pod/ip-10-0-141-105ec2internal-debug ...
To use host binaries, run `chroot /host`

sh-4.2# cat /host/proc/cmdline
BOOT_IMAGE=/ostree/rhcos-... console=tty0 console=ttyS0,115200n8
rootflags=defaults,prjquota rw root=UUID=fd0... ostree=/ostree/boot.0/rhcos/16...
coreos.oem.id=qemu coreos.oem.id=ec2 ignition.platform.id=ec2 enforcing=0

sh-4.2# exit

    Vous devriez voir l'argument enforcing=0 ajouté aux autres arguments du noyau.

5.3.5. Activation de l'utilisation de la mémoire d'échange sur les nœuds

Important

L'activation de l'utilisation de la mémoire d'échange sur les nœuds est une fonctionnalité d'aperçu technologique uniquement. Les fonctionnalités de l'aperçu technologique ne sont pas prises en charge par les accords de niveau de service (SLA) de production de Red Hat et peuvent ne pas être complètes sur le plan fonctionnel. Red Hat ne recommande pas leur utilisation en production. Ces fonctionnalités offrent un accès anticipé aux fonctionnalités des produits à venir, ce qui permet aux clients de tester les fonctionnalités et de fournir un retour d'information pendant le processus de développement.

Pour plus d'informations sur la portée de l'assistance des fonctionnalités de l'aperçu technologique de Red Hat, voir Portée de l'assistance des fonctionnalités de l'aperçu technologique.

Vous pouvez activer l'utilisation de la mémoire d'échange pour les charges de travail d'OpenShift Container Platform sur une base par nœud.

Avertissement

L'activation de la mémoire d'échange peut avoir un impact négatif sur les performances de la charge de travail et sur la gestion des ressources manquantes. N'activez pas la mémoire d'échange sur les nœuds du plan de contrôle.

Pour activer la mémoire tampon, créez une ressource personnalisée (CR) kubeletconfig afin de définir le paramètre swapbehavior. Vous pouvez définir une mémoire d'échange limitée ou illimitée :

  • Limité : Utilisez la valeur LimitedSwap pour limiter la quantité de mémoire d'échange que les charges de travail peuvent utiliser. Toutes les charges de travail sur le nœud qui ne sont pas gérées par OpenShift Container Platform peuvent toujours utiliser la mémoire d'échange. Le comportement de LimitedSwap dépend de l'exécution du nœud avec les groupes de contrôle Linux version 1 (cgroups v1) ou version 2 (cgroup v2):

    • cgroup v1 : Les charges de travail d'OpenShift Container Platform peuvent utiliser n'importe quelle combinaison de mémoire et de swap, jusqu'à la limite de mémoire du pod, si elle est définie.
    • cgroup v2 : Les charges de travail d'OpenShift Container Platform ne peuvent pas utiliser de mémoire d'échange.
  • Illimité : Utilisez la valeur UnlimitedSwap pour permettre aux charges de travail d'utiliser autant de mémoire d'échange qu'elles le souhaitent, jusqu'à la limite du système.

Comme le kubelet ne démarrera pas en présence de mémoire d'échange sans cette configuration, vous devez activer la mémoire d'échange dans OpenShift Container Platform avant d'activer la mémoire d'échange sur les nœuds. S'il n'y a pas de mémoire d'échange sur un nœud, l'activation de la mémoire d'échange dans OpenShift Container Platform n'a aucun effet.

Conditions préalables

  • Vous disposez d'un cluster OpenShift Container Platform en cours d'exécution qui utilise la version 4.10 ou une version ultérieure.
  • You are logged in to the cluster as a user with administrative privileges.

  • Vous avez activé le jeu de fonctionnalités TechPreviewNoUpgrade sur le cluster (voir Nodes Working with clusters Enabling features using feature gates).

    Note

    L'activation de l'ensemble de fonctionnalités TechPreviewNoUpgrade ne peut être annulée et empêche les mises à jour mineures de la version. Ces jeux de fonctionnalités ne sont pas recommandés sur les clusters de production.

  • Si le cgroup v2 est activé sur un nœud, vous devez activer la comptabilité de swap sur le nœud, en définissant l'argument du noyau swapaccount=1.

Procédure

  1. Appliquez une étiquette personnalisée au pool de configuration de la machine dans lequel vous souhaitez autoriser la mémoire d'échange. 

    $ oc label machineconfigpool worker kubelet-swap=enabled

  2. Créer une ressource personnalisée (CR) pour activer et configurer les paramètres d'échange. 

    apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  name: swap-config
spec:
  machineConfigPoolSelector:
    matchLabels:
      kubelet-swap: enabled
  kubeletConfig:
    failSwapOn: false 1
    memorySwap:
      swapBehavior: LimitedSwap 2
    1
    La valeur false permet d'activer l'utilisation de la mémoire d'échange sur les nœuds associés. La valeur true désactive l'utilisation de la mémoire d'échange.
    2
    Spécifier le comportement de la mémoire d'échange. S'il n'est pas spécifié, la valeur par défaut est LimitedSwap.
  3. Activer la mémoire tampon sur les machines.

5.3.6. Migration des nœuds du plan de contrôle d'un hôte RHOSP à un autre

Vous pouvez exécuter un script qui déplace un nœud de plan de contrôle d'un nœud Red Hat OpenStack Platform (RHOSP) à un autre.

Conditions préalables

  • La variable d'environnement OS_CLOUD fait référence à une entrée clouds qui contient des informations d'identification administratives dans un fichier clouds.yaml.
  • La variable d'environnement KUBECONFIG fait référence à une configuration qui contient les identifiants administratifs de OpenShift Container Platform.

Procédure

  • À partir d'une ligne de commande, exécutez le script suivant : 
#!/usr/bin/env bash

set -Eeuo pipefail

if [ $# -lt 1 ]; then
	echo "Usage: '$0 node_name'"
	exit 64
fi

# Check for admin OpenStack credentials
openstack server list --all-projects >/dev/null || { >&2 echo "The script needs OpenStack admin credentials. Exiting"; exit 77; }

# Check for admin OpenShift credentials
oc adm top node >/dev/null || { >&2 echo "The script needs OpenShift admin credentials. Exiting"; exit 77; }

set -x

declare -r node_name="$1"
declare server_id
server_id="$(openstack server list --all-projects -f value -c ID -c Name | grep "$node_name" | cut -d' ' -f1)"
readonly server_id

# Drain the node
oc adm cordon "$node_name"
oc adm drain "$node_name" --delete-emptydir-data --ignore-daemonsets --force

# Power off the server
oc debug "node/${node_name}" -- chroot /host shutdown -h 1

# Verify the server is shut off
until openstack server show "$server_id" -f value -c status | grep -q 'SHUTOFF'; do sleep 5; done

# Migrate the node
openstack server migrate --wait "$server_id"

# Resize the VM
openstack server resize confirm "$server_id"

# Wait for the resize confirm to finish
until openstack server show "$server_id" -f value -c status | grep -q 'SHUTOFF'; do sleep 5; done

# Restart the VM
openstack server start "$server_id"

# Wait for the node to show up as Ready:
until oc get node "$node_name" | grep -q "^${node_name}[[:space:]]\+Ready"; do sleep 5; done

# Uncordon the node
oc adm uncordon "$node_name"

# Wait for cluster operators to stabilize
until oc get co -o go-template='statuses: {{ range .items }}{{ range .status.conditions }}{{ if eq .type "Degraded" }}{{ if ne .status "False" }}DEGRADED{{ end }}{{ else if eq .type "Progressing"}}{{ if ne .status "False" }}PROGRESSING{{ end }}{{ else if eq .type "Available"}}{{ if ne .status "True" }}NOTAVAILABLE{{ end }}{{ end }}{{ end }}{{ end }}' | grep -qv '\(DEGRADED\|PROGRESSING\|NOTAVAILABLE\)'; do sleep 5; done

Si le script aboutit, la machine du plan de contrôle est migrée vers un nouveau nœud RHOSP.

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.