Rechercher
SupportConsoleDéveloppeursCommencer un essaiContact

5.2. Utilisation des objets MachineConfig pour configurer les nœuds

download PDF

Vous pouvez utiliser les tâches de cette section pour créer des objets MachineConfig qui modifient les fichiers, les fichiers d'unité systemd et d'autres fonctionnalités du système d'exploitation s'exécutant sur les nœuds d'OpenShift Container Platform. Pour plus d'idées sur le travail avec les configurations de machine, voir le contenu lié à la mise à jour des clés autorisées SSH, à la vérification des signatures d'image, à l'activation de SCTP et à la configuration des noms d'initiateur iSCSI pour OpenShift Container Platform.

OpenShift Container Platform supporte la version 3.2 de la spécification Ignition. Toutes les nouvelles configurations de machines que vous créerez à l'avenir devront être basées sur la version 3.2 de la spécification Ignition. Si vous mettez à jour votre cluster OpenShift Container Platform, toutes les configurations de machines Ignition version 2.x existantes seront automatiquement traduites en version 3.2.

Il peut arriver que la configuration d'un nœud ne corresponde pas entièrement à ce que la configuration de la machine actuellement appliquée spécifie. Cet état est appelé configuration drift. Le Machine Config Daemon (MCD) vérifie régulièrement que les nœuds ne présentent pas de dérive de configuration. Si le MCD détecte une dérive de la configuration, le MCO marque le nœud degraded jusqu'à ce qu'un administrateur corrige la configuration du nœud. Un nœud dégradé est en ligne et opérationnel, mais il ne peut pas être mis à jour. Pour plus d'informations sur la dérive de la configuration, voir Comprendre la détection de la dérive de la configuration.

Astuce

Utilisez la procédure suivante "Configuring chrony time service" comme modèle pour ajouter d'autres fichiers de configuration aux nœuds d'OpenShift Container Platform.

5.2.1. Configuring chrony time service

You can set the time server and related settings used by the chrony time service (chronyd) by modifying the contents of the chrony.conf file and passing those contents to your nodes as a machine config.

Procédure

  1. Create a Butane config including the contents of the chrony.conf file. For example, to configure chrony on worker nodes, create a 99-worker-chrony.bu file.

    Note

    See "Creating machine configs with Butane" for information about Butane. 

    variant: openshift
version: 4.12.0
metadata:
  name: 99-worker-chrony 1
  labels:
    machineconfiguration.openshift.io/role: worker 2
storage:
  files:
  - path: /etc/chrony.conf
    mode: 0644 3
    overwrite: true
    contents:
      inline: |
        pool 0.rhel.pool.ntp.org iburst 4
        driftfile /var/lib/chrony/drift
        makestep 1.0 3
        rtcsync
        logdir /var/log/chrony
    1 2
    On control plane nodes, substitute master for worker in both of these locations.
    3
    Specify an octal value mode for the mode field in the machine config file. After creating the file and applying the changes, the mode is converted to a decimal value. You can check the YAML file with the command oc get mc <mc-name> -o yaml.
    4
    Specify any valid, reachable time source, such as the one provided by your DHCP server. Alternately, you can specify any of the following NTP servers: 1.rhel.pool.ntp.org, 2.rhel.pool.ntp.org, or 3.rhel.pool.ntp.org.

  2. Use Butane to generate a MachineConfig object file, 99-worker-chrony.yaml, containing the configuration to be delivered to the nodes: 

    $ butane 99-worker-chrony.bu -o 99-worker-chrony.yaml

  3. Apply the configurations in one of two ways:

    • If the cluster is not running yet, after you generate manifest files, add the MachineConfig object file to the <installation_directory>/openshift directory, and then continue to create the cluster.

    • If the cluster is already running, apply the file: 

      $ oc apply -f ./99-worker-chrony.yaml

Ressources supplémentaires

5.2.2. Désactivation du service chronologique

Vous pouvez désactiver le service chronologique (chronyd) pour les nœuds ayant un rôle spécifique en utilisant une ressource personnalisée (CR) MachineConfig.

Conditions préalables

  • Installez le CLI OpenShift (oc).
  • Connectez-vous en tant qu'utilisateur disposant des privilèges cluster-admin.

Procédure

  1. Créez le CR MachineConfig qui désactive chronyd pour le rôle de nœud spécifié.

    1. Enregistrez le YAML suivant dans le fichier disable-chronyd.yaml: 

      apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: <node_role> 1
  name: disable-chronyd
spec:
  config:
    ignition:
      version: 3.2.0
    systemd:
      units:
        - contents: |
            [Unit]
            Description=NTP client/server
            Documentation=man:chronyd(8) man:chrony.conf(5)
            After=ntpdate.service sntp.service ntpd.service
            Conflicts=ntpd.service systemd-timesyncd.service
            ConditionCapability=CAP_SYS_TIME
            [Service]
            Type=forking
            PIDFile=/run/chrony/chronyd.pid
            EnvironmentFile=-/etc/sysconfig/chronyd
            ExecStart=/usr/sbin/chronyd $OPTIONS
            ExecStartPost=/usr/libexec/chrony-helper update-daemon
            PrivateTmp=yes
            ProtectHome=yes
            ProtectSystem=full
            [Install]
            WantedBy=multi-user.target
          enabled: false
          name: "chronyd.service"
      1
      Rôle du nœud dans lequel vous souhaitez désactiver chronyd, par exemple, master.

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

      $ oc create -f disable-chronyd.yaml

5.2.3. 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.2.4. Enabling multipathing with kernel arguments on RHCOS

Red Hat Enterprise Linux CoreOS (RHCOS) prend en charge le multipathing sur le disque primaire, permettant une meilleure résilience aux pannes matérielles afin d'atteindre une plus grande disponibilité de l'hôte. La prise en charge post-installation est disponible en activant le multipathing via la configuration de la machine.

Important

L'activation du multipathing lors de l'installation est prise en charge et recommandée pour les nœuds provisionnés dans OpenShift Container Platform 4.8 ou supérieur. Dans les configurations où toute E/S vers des chemins non optimisés entraîne des erreurs de système d'E/S, vous devez activer le multipathing au moment de l'installation. Pour plus d'informations sur l'activation du multipathing lors de l'installation, voir "Enabling multipathing with kernel arguments on RHCOS" dans la documentation Installing on bare metal.

Important

On IBM zSystems and IBM® LinuxONE, you can enable multipathing only if you configured your cluster for it during installation. For more information, see "Installing RHCOS and starting the OpenShift Container Platform bootstrap process" in Installing a cluster with z/VM on IBM zSystems and IBM® LinuxONE.

Conditions préalables

  • Vous disposez d'un cluster OpenShift Container Platform en cours d'exécution qui utilise la version 4.7 ou une version ultérieure.
  • You are logged in to the cluster as a user with administrative privileges.
  • Vous avez confirmé que le disque est activé pour le multipathing. Le multipathing n'est pris en charge que sur les hôtes connectés à un SAN via un adaptateur HBA.

Procédure

  1. Pour activer le multipathing après l'installation sur les nœuds du plan de contrôle :

    • Créez un fichier de configuration de machine, tel que 99-master-kargs-mpath.yaml, qui demande au cluster d'ajouter l'étiquette master et qui identifie l'argument du noyau multipath, par exemple : 

      apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: "master"
  name: 99-master-kargs-mpath
spec:
  kernelArguments:
    - 'rd.multipath=default'
    - 'root=/dev/disk/by-label/dm-mpath-root'

  2. Pour activer le multipathing après l'installation sur les nœuds de travail :

    • Créez un fichier de configuration de machine, tel que 99-worker-kargs-mpath.yaml, qui demande au cluster d'ajouter l'étiquette worker et qui identifie l'argument du noyau multipath, par exemple : 

      apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: "worker"
  name: 99-worker-kargs-mpath
spec:
  kernelArguments:
    - 'rd.multipath=default'
    - 'root=/dev/disk/by-label/dm-mpath-root'

  3. Créez la nouvelle configuration de la machine en utilisant le fichier YAML du maître ou du travailleur que vous avez créé précédemment : 

    $ oc create -f ./99-worker-kargs-mpath.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
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-kargs-mpath                              52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             105s
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
...
rd.multipath=default root=/dev/disk/by-label/dm-mpath-root
...

sh-4.2# exit

    You should see the added kernel arguments.

Ressources supplémentaires

5.2.5. Ajout d'un noyau en temps réel aux nœuds

Certaines charges de travail d'OpenShift Container Platform nécessitent un degré élevé de déterminisme.Bien que Linux ne soit pas un système d'exploitation en temps réel, le noyau Linux en temps réel comprend un planificateur préemptif qui fournit au système d'exploitation des caractéristiques en temps réel.

Si vos charges de travail OpenShift Container Platform nécessitent ces caractéristiques de temps réel, vous pouvez basculer vos machines vers le noyau temps réel Linux. Pour OpenShift Container Platform, 4.12, vous pouvez effectuer ce changement en utilisant un objet MachineConfig. Bien que le changement soit aussi simple que de changer un paramètre de configuration de machine kernelType en realtime, il y a quelques autres considérations à prendre en compte avant d'effectuer le changement :

  • Actuellement, le noyau en temps réel n'est pris en charge que sur les nœuds de travail, et uniquement pour l'utilisation du réseau d'accès radio (RAN).
  • La procédure suivante est entièrement prise en charge par les installations bare metal qui utilisent des systèmes certifiés pour Red Hat Enterprise Linux for Real Time 8.
  • La prise en charge en temps réel dans OpenShift Container Platform est limitée à des abonnements spécifiques.
  • La procédure suivante est également prise en charge pour une utilisation avec Google Cloud Platform.

Conditions préalables

  • Disposer d'un cluster OpenShift Container Platform en cours d'exécution (version 4.4 ou ultérieure).
  • Connectez-vous au cluster en tant qu'utilisateur disposant de privilèges administratifs.

Procédure

  1. Créer une configuration de machine pour le noyau temps réel : Créez un fichier YAML (par exemple, 99-worker-realtime.yaml) qui contient un objet MachineConfig pour le type de noyau realtime. Cet exemple indique au cluster d'utiliser un noyau en temps réel pour tous les nœuds de travail : 

    $ cat << EOF > 99-worker-realtime.yaml
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: "worker"
  name: 99-worker-realtime
spec:
  kernelType: realtime
EOF

  2. Ajoutez la configuration de la machine au cluster. Tapez ce qui suit pour ajouter la configuration de la machine à la grappe : 

    $ oc create -f 99-worker-realtime.yaml

  3. Vérifiez le noyau en temps réel : Une fois que chaque nœud impacté a redémarré, connectez-vous au cluster et exécutez les commandes suivantes pour vous assurer que le noyau en temps réel a remplacé le noyau normal pour l'ensemble des nœuds que vous avez configurés : 

    $ oc get nodes

    Exemple de sortie

    NAME                                        STATUS  ROLES    AGE   VERSION
ip-10-0-143-147.us-east-2.compute.internal  Ready   worker   103m  v1.25.0
ip-10-0-146-92.us-east-2.compute.internal   Ready   worker   101m  v1.25.0
ip-10-0-169-2.us-east-2.compute.internal    Ready   worker   102m  v1.25.0

    $ oc debug node/ip-10-0-143-147.us-east-2.compute.internal

    Exemple de sortie

    Starting pod/ip-10-0-143-147us-east-2computeinternal-debug ...
To use host binaries, run `chroot /host`

sh-4.4# uname -a
Linux <worker_node> 4.18.0-147.3.1.rt24.96.el8_1.x86_64 #1 SMP PREEMPT RT
        Wed Nov 27 18:29:55 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

    Le nom du noyau contient rt et le texte "PREEMPT RT" indique qu'il s'agit d'un noyau temps réel.

  4. Pour revenir au noyau normal, supprimez l'objet MachineConfig: 

    $ oc delete -f 99-worker-realtime.yaml

5.2.6. Configuration des paramètres de journald

Si vous devez configurer les paramètres du service journald sur les nœuds d'OpenShift Container Platform, vous pouvez le faire en modifiant le fichier de configuration approprié et en transmettant le fichier au pool de nœuds approprié en tant que machine config.

Cette procédure décrit comment modifier les paramètres de limitation du débit de journald dans le fichier /etc/systemd/journald.conf et les appliquer aux nœuds de travail. Voir la page de manuel journald.conf pour plus d'informations sur l'utilisation de ce fichier.

Conditions préalables

  • Disposer d'un cluster OpenShift Container Platform en cours d'exécution.
  • Connectez-vous au cluster en tant qu'utilisateur disposant de privilèges administratifs.

Procédure

  1. Créez un fichier de configuration Butane, 40-worker-custom-journald.bu, qui inclut un fichier /etc/systemd/journald.conf avec les paramètres requis.

    Note

    See "Creating machine configs with Butane" for information about Butane. 

    variant: openshift
version: 4.12.0
metadata:
  name: 40-worker-custom-journald
  labels:
    machineconfiguration.openshift.io/role: worker
storage:
  files:
  - path: /etc/systemd/journald.conf
    mode: 0644
    overwrite: true
    contents:
      inline: |
        # Disable rate limiting
        RateLimitInterval=1s
        RateLimitBurst=10000
        Storage=volatile
        Compress=no
        MaxRetentionSec=30s

  2. Utilisez Butane pour générer un fichier objet MachineConfig, 40-worker-custom-journald.yaml, contenant la configuration à fournir aux nœuds de travail : 

    $ butane 40-worker-custom-journald.bu -o 40-worker-custom-journald.yaml

  3. Appliquer la configuration de la machine au pool : 

    $ oc apply -f 40-worker-custom-journald.yaml

  4. Vérifiez que la nouvelle configuration de la machine est appliquée et que les nœuds ne sont pas dans un état dégradé. Cela peut prendre quelques minutes. Le worker pool affichera les mises à jour en cours, au fur et à mesure que chaque nœud aura appliqué avec succès la nouvelle configuration de la machine : 

    $ oc get machineconfigpool
NAME   CONFIG             UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE
master rendered-master-35 True    False    False    3            3                 3                   0                    34m
worker rendered-worker-d8 False   True     False    3            1                 1                   0                    34m

  5. Pour vérifier que la modification a été appliquée, vous pouvez vous connecter à un nœud de travail : 

    $ oc get node | grep worker
ip-10-0-0-1.us-east-2.compute.internal   Ready    worker   39m   v0.0.0-master+$Format:%h$
$ oc debug node/ip-10-0-0-1.us-east-2.compute.internal
Starting pod/ip-10-0-141-142us-east-2computeinternal-debug ...
...
sh-4.2# chroot /host
sh-4.4# cat /etc/systemd/journald.conf
# Disable rate limiting
RateLimitInterval=1s
RateLimitBurst=10000
Storage=volatile
Compress=no
MaxRetentionSec=30s
sh-4.4# exit

Ressources supplémentaires

5.2.7. Ajout d'extensions au RHCOS

RHCOS est un système d'exploitation RHEL minimal orienté conteneur, conçu pour fournir un ensemble commun de fonctionnalités aux clusters OpenShift Container Platform sur toutes les plateformes. Bien que l'ajout de progiciels aux systèmes RHCOS soit généralement déconseillé, le MCO fournit une fonctionnalité extensions que vous pouvez utiliser pour ajouter un ensemble minimal de fonctionnalités aux nœuds RHCOS.

Les extensions suivantes sont actuellement disponibles :

  • usbguard: L'ajout de l'extension usbguard protège les systèmes RHCOS contre les attaques de périphériques USB intrusifs. Voir USBGuard pour plus de détails.
  • kerberos: L'ajout de l'extension kerberos fournit un mécanisme qui permet aux utilisateurs et aux machines de s'identifier sur le réseau pour recevoir un accès défini et limité aux zones et aux services qu'un administrateur a configurés. Voir Utilisation de Kerberos pour plus de détails, y compris la configuration d'un client Kerberos et le montage d'un partage NFS Kerberisé.

La procédure suivante décrit comment utiliser une configuration de machine pour ajouter une ou plusieurs extensions à vos nœuds RHCOS.

Conditions préalables

  • Disposer d'un cluster OpenShift Container Platform en cours d'exécution (version 4.6 ou ultérieure).
  • Connectez-vous au cluster en tant qu'utilisateur disposant de privilèges administratifs.

Procédure

  1. Créer une configuration de machine pour les extensions : Créez un fichier YAML (par exemple, 80-extensions.yaml) qui contient un objet MachineConfig extensions . Cet exemple indique au cluster d'ajouter l'extension usbguard. 

    $ cat << EOF > 80-extensions.yaml
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker
  name: 80-worker-extensions
spec:
  config:
    ignition:
      version: 3.2.0
  extensions:
    - usbguard
EOF

  2. Ajoutez la configuration de la machine au cluster. Tapez ce qui suit pour ajouter la configuration de la machine à la grappe : 

    $ oc create -f 80-extensions.yaml

    Cela permet d'installer les paquets rpm pour usbguard sur tous les nœuds de travail.

  3. Vérifier que les extensions ont été appliquées : 

    $ oc get machineconfig 80-worker-extensions

    Exemple de sortie

    NAME                 GENERATEDBYCONTROLLER IGNITIONVERSION AGE
80-worker-extensions                       3.2.0           57s

  4. Vérifiez que la nouvelle configuration de la machine est maintenant appliquée et que les nœuds ne sont pas dans un état dégradé. Cela peut prendre quelques minutes. Le worker pool affichera les mises à jour en cours, au fur et à mesure que la nouvelle configuration de chaque machine sera appliquée avec succès : 

    $ oc get machineconfigpool

    Exemple de sortie

    NAME   CONFIG             UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE
master rendered-master-35 True    False    False    3            3                 3                   0                    34m
worker rendered-worker-d8 False   True     False    3            1                 1                   0                    34m

  5. Vérifiez les extensions. Pour vérifier que l'extension a été appliquée, exécutez : 

    $ oc get node | grep worker

    Exemple de sortie

    NAME                                        STATUS  ROLES    AGE   VERSION
ip-10-0-169-2.us-east-2.compute.internal    Ready   worker   102m  v1.25.0

    $ oc debug node/ip-10-0-169-2.us-east-2.compute.internal

    Exemple de sortie

    ...
To use host binaries, run `chroot /host`
sh-4.4# chroot /host
sh-4.4# rpm -q usbguard
usbguard-0.7.4-4.el8.x86_64.rpm

5.2.8. Chargement de blobs de firmware personnalisés dans le manifeste de configuration de la machine

L'emplacement par défaut des blobs de firmware dans /usr/lib étant en lecture seule, vous pouvez localiser un blob de firmware personnalisé en mettant à jour le chemin de recherche. Cela vous permet de charger des blobs de firmware locaux dans le manifeste de configuration de la machine lorsque les blobs ne sont pas gérés par RHCOS.

Procédure

  1. Créez un fichier de configuration Butane, 98-worker-firmware-blob.bu, qui met à jour le chemin de recherche de manière à ce qu'il soit détenu par la racine et accessible en écriture au stockage local. L'exemple suivant place le fichier blob personnalisé de votre station de travail locale sur les nœuds sous /var/lib/firmware.

    Note

    See "Creating machine configs with Butane" for information about Butane.

    Fichier de configuration Butane pour le blob de firmware personnalisé

    variant: openshift
version: 4.12.0
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker
  name: 98-worker-firmware-blob
storage:
  files:
  - path: /var/lib/firmware/<package_name> 1
    contents:
      local: <package_name> 2
    mode: 0644 3
openshift:
  kernel_arguments:
    - 'firmware_class.path=/var/lib/firmware' 4

    1
    Définit le chemin d'accès au nœud où le paquet de microprogrammes est copié.
    2
    Spécifie un fichier dont le contenu est lu à partir d'un répertoire de fichiers locaux sur le système où s'exécute Butane. Le chemin du fichier local est relatif à un répertoire files-dir, qui doit être spécifié en utilisant l'option --files-dir avec Butane à l'étape suivante.
    3
    Définit les autorisations pour le fichier sur le nœud RHCOS. Il est recommandé de définir les permissions sur 0644.
    4
    Le paramètre firmware_class.path personnalise le chemin de recherche du noyau pour savoir où chercher le blob de micrologiciel personnalisé qui a été copié depuis votre station de travail locale sur le système de fichiers racine du nœud. Cet exemple utilise /var/lib/firmware comme chemin personnalisé.

  2. Exécutez Butane pour générer un fichier objet MachineConfig qui utilise une copie du blob firmware sur votre station de travail locale nommée 98-worker-firmware-blob.yaml. Le blob firmware contient la configuration à fournir aux nœuds. L'exemple suivant utilise l'option --files-dir pour spécifier le répertoire de votre station de travail où se trouvent le ou les fichiers locaux : 

    $ butane 98-worker-firmware-blob.bu -o 98-worker-firmware-blob.yaml --files-dir <directory_including_package_name>

  3. Appliquez les configurations aux nœuds de l'une des deux manières suivantes :

    • If the cluster is not running yet, after you generate manifest files, add the MachineConfig object file to the <installation_directory>/openshift directory, and then continue to create the cluster.

    • If the cluster is already running, apply the file: 

      $ oc apply -f 98-worker-firmware-blob.yaml

      A MachineConfig object YAML file is created for you to finish configuring your machines.

  4. Save the Butane config in case you need to update the MachineConfig object in the future.

Ressources supplé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.