Rechercher

Chapitre 5. Tâches de configuration de la machine après l'installation

download PDF

Il arrive que vous deviez apporter des modifications aux systèmes d'exploitation fonctionnant sur les nœuds d'OpenShift Container Platform. Il peut s'agir de modifier les paramètres du service de temps réseau, d'ajouter des arguments de noyau ou de configurer la journalisation d'une manière spécifique.

Hormis quelques fonctionnalités spécialisées, la plupart des modifications apportées aux systèmes d'exploitation sur les nœuds d'OpenShift Container Platform peuvent être effectuées en créant ce que l'on appelle des objets MachineConfig qui sont gérés par l'opérateur de configuration de la machine.

Les tâches de cette section décrivent comment utiliser les fonctionnalités de l'opérateur Machine Config pour configurer les fonctionnalités du système d'exploitation sur les nœuds d'OpenShift Container Platform.

5.1. Comprendre l'opérateur de configuration de la machine

5.1.1. Machine Config Operator

Objectif

L'opérateur de configuration des machines gère et applique la configuration et les mises à jour du système d'exploitation de base et de l'exécution des conteneurs, y compris tout ce qui se trouve entre le noyau et le kubelet.

Il y a quatre composantes :

  • machine-config-server: Fournit la configuration d'Ignition aux nouvelles machines qui rejoignent le cluster.
  • machine-config-controller: Coordonne la mise à niveau des machines vers les configurations souhaitées définies par un objet MachineConfig. Des options sont fournies pour contrôler la mise à niveau d'ensembles de machines individuellement.
  • machine-config-daemon: Applique la nouvelle configuration de la machine pendant la mise à jour. Valide et vérifie l'état de la machine par rapport à la configuration demandée.
  • machine-config: Fournit une source complète de configuration de la machine lors de l'installation, du premier démarrage et des mises à jour d'une machine.
Important

Currently, there is no supported way to block or restrict the machine config server endpoint. The machine config server must be exposed to the network so that newly-provisioned machines, which have no existing configuration or state, are able to fetch their configuration. In this model, the root of trust is the certificate signing requests (CSR) endpoint, which is where the kubelet sends its certificate signing request for approval to join the cluster. Because of this, machine configs should not be used to distribute sensitive information, such as secrets and certificates.

To ensure that the machine config server endpoints, ports 22623 and 22624, are secured in bare metal scenarios, customers must configure proper network policies.

Ressources supplémentaires

Projet

openshift-machine-config-operator

5.1.2. Aperçu de la configuration de la machine

Le Machine Config Operator (MCO) gère les mises à jour de systemd, CRI-O et Kubelet, le noyau, le Network Manager et d'autres fonctionnalités du système. Il offre également un CRD MachineConfig qui peut écrire des fichiers de configuration sur l'hôte (voir machine-config-operator). Comprendre ce que fait MCO et comment il interagit avec d'autres composants est essentiel pour effectuer des changements avancés au niveau du système dans un cluster OpenShift Container Platform. Voici quelques éléments à connaître sur le MCO, les configurations de machine et leur utilisation :

  • Une machine config peut apporter une modification spécifique à un fichier ou à un service sur le système d'exploitation de chaque système représentant un pool de nœuds OpenShift Container Platform.
  • MCO applique des changements aux systèmes d'exploitation dans les pools de machines. Tous les clusters OpenShift Container Platform démarrent avec des pools de nœuds de plan de travail et de plan de contrôle. En ajoutant d'autres étiquettes de rôle, vous pouvez configurer des pools de nœuds personnalisés. Par exemple, vous pouvez configurer un pool personnalisé de nœuds de travailleur qui inclut des caractéristiques matérielles particulières nécessaires à une application. Toutefois, les exemples de cette section se concentrent sur les modifications apportées aux types de pools par défaut.

    Important

    Un nœud peut avoir plusieurs étiquettes qui indiquent son type, comme master ou worker, mais il ne peut être membre que d'un pool de configuration de machines single.

  • Après un changement de configuration de machine, le MCO met à jour les nœuds concernés par ordre alphabétique de zone, sur la base de l'étiquette topology.kubernetes.io/zone. Si une zone comporte plusieurs nœuds, les nœuds les plus anciens sont mis à jour en premier. Pour les nœuds qui n'utilisent pas de zones, comme dans les déploiements bare metal, les nœuds sont mis à jour par âge, les nœuds les plus anciens étant mis à jour en premier. Le MCO met à jour le nombre de nœuds spécifié par le champ maxUnavailable du pool de configuration de la machine à la fois.
  • Une certaine configuration de la machine doit être en place avant l'installation d'OpenShift Container Platform sur le disque. Dans la plupart des cas, cela peut être accompli en créant une configuration de machine qui est injectée directement dans le processus d'installation d'OpenShift Container Platform, au lieu de fonctionner comme une configuration de machine post-installation. Dans d'autres cas, vous pourriez avoir besoin de faire une installation bare metal où vous passez des arguments de noyau au démarrage de l'installateur d'OpenShift Container Platform, pour faire des choses comme la définition d'adresses IP individuelles par nœud ou le partitionnement avancé du disque.
  • MCO gère les éléments définis dans les configurations des machines. Les modifications manuelles que vous apportez à vos systèmes ne seront pas écrasées par MCO, à moins qu'il ne soit explicitement demandé à MCO de gérer un fichier conflictuel. En d'autres termes, MCO n'effectue que les mises à jour spécifiques que vous demandez, il ne revendique pas le contrôle de l'ensemble du nœud.
  • Il est fortement déconseillé d'apporter des modifications manuelles aux nœuds. Si vous devez déclasser un nœud et en démarrer un nouveau, ces modifications directes seront perdues.
  • Le MCO n'est pris en charge que pour l'écriture de fichiers dans les répertoires /etc et /var, bien qu'il existe des liens symboliques vers certains répertoires qui peuvent être accessibles en écriture en étant symboliquement liés à l'une de ces zones. Les répertoires /opt et /usr/local en sont des exemples.
  • Ignition est le format de configuration utilisé dans MachineConfigs. Voir la spécification de configuration Ignition v3.2.0 pour plus de détails.
  • Bien que les paramètres de configuration d'Ignition puissent être livrés directement au moment de l'installation d'OpenShift Container Platform, et qu'ils soient formatés de la même manière que les configurations d'Ignition livrées par MCO, MCO n'a aucun moyen de voir ce que sont ces configurations d'Ignition d'origine. Par conséquent, vous devez envelopper les paramètres de configuration Ignition dans une configuration de machine avant de les déployer.
  • Lorsqu'un fichier géré par le MCO est modifié en dehors du MCO, le Machine Config Daemon (MCD) définit le nœud comme degraded. Il n'écrase cependant pas le fichier incriminé et doit continuer à fonctionner dans l'état degraded.
  • L'une des principales raisons d'utiliser une configuration de machine est qu'elle sera appliquée lorsque vous démarrez de nouveaux nœuds pour un pool dans votre cluster OpenShift Container Platform. Le site machine-api-operator provisionne une nouvelle machine et MCO la configure.

MCO utilise Ignition comme format de configuration. OpenShift Container Platform 4.6 est passé de la version 2 de la spécification de configuration Ignition à la version 3.

5.1.2.1. Que pouvez-vous changer dans la configuration des machines ?

Les types de composants que le MCO peut modifier sont les suivants :

  • config: Créer des objets de configuration Ignition (voir la spécification de configuration Ignition) pour faire des choses comme modifier des fichiers, des services systemd et d'autres fonctionnalités sur les machines OpenShift Container Platform, y compris :

    • Configuration files: Créer ou écraser des fichiers dans le répertoire /var ou /etc.
    • systemd units: Créer et définir l'état d'un service systemd ou ajouter des paramètres supplémentaires à un service systemd existant.
    • users and groups: Modifier les clés SSH dans la section passwd après l'installation.
Important

La modification des clés SSH via la configuration des machines n'est possible que pour l'utilisateur core.

  • kernelArguments: Ajout d'arguments à la ligne de commande du noyau lors du démarrage des nœuds d'OpenShift Container Platform.
  • kernelType: Identifier éventuellement un noyau non standard à utiliser à la place du noyau standard. Utilisez realtime pour utiliser le noyau RT (pour RAN). Cette option n'est prise en charge que sur certaines plates-formes.
  • fips: Activer le mode FIPS. Le mode FIPS doit être défini au moment de l'installation et non lors d'une procédure post-installation.
Important

The use of FIPS Validated / Modules in Process cryptographic libraries is only supported on OpenShift Container Platform deployments on the x86_64 architecture.

  • extensions: Étendre les fonctionnalités de RHCOS en ajoutant des logiciels pré-packagés sélectionnés. Pour cette fonctionnalité, les extensions disponibles comprennent usbguard et les modules du noyau.
  • Custom resources (for ContainerRuntime and Kubelet): En dehors des configurations de machines, MCO gère deux ressources spéciales personnalisées pour modifier les paramètres d'exécution des conteneurs CRI-O (ContainerRuntime CR) et le service Kubelet (Kubelet CR).

Le MCO n'est pas le seul opérateur à pouvoir modifier les composants du système d'exploitation sur les nœuds d'OpenShift Container Platform. D'autres opérateurs peuvent également modifier les fonctionnalités du système d'exploitation. Un exemple est l'opérateur Node Tuning, qui vous permet d'effectuer des réglages au niveau du nœud par le biais de profils de démon Tuned.

Les tâches de configuration du MCO qui peuvent être effectuées après l'installation sont incluses dans les procédures suivantes. Voir les descriptions de l'installation RHCOS bare metal pour les tâches de configuration du système qui doivent être effectuées pendant ou avant l'installation d'OpenShift Container Platform.

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 configuration, voir Understanding configuration drift detection.

5.1.2.2. Projet

Voir le site GitHub openshift-machine-config-operator pour plus de détails.

5.1.3. Comprendre la détection des dérives de configuration

Il peut arriver que l'état du disque d'un nœud diffère de ce qui est configuré dans la configuration de la machine. C'est ce que l'on appelle configuration drift. Par exemple, un administrateur de cluster peut modifier manuellement un fichier, un fichier d'unité systemd ou une autorisation de fichier qui a été configurée dans la configuration de la machine. Cela entraîne une dérive de la configuration. La dérive de la configuration peut causer des problèmes entre les nœuds d'un pool de configuration machine ou lorsque les configurations machine sont mises à jour.

Le Machine Config Operator (MCO) utilise le Machine Config Daemon (MCD) pour vérifier régulièrement que les nœuds ne présentent pas de dérive de configuration. En cas de détection, le MCO configure le nœud et le pool de configuration de la machine (MCP) sur Degraded et signale l'erreur. Un nœud dégradé est en ligne et opérationnel, mais il ne peut pas être mis à jour.

Le MCD détecte les dérives de configuration dans chacune des conditions suivantes :

  • Lorsqu'un nœud démarre.
  • Après que l'un des fichiers (fichiers Ignition et unités drop-in systemd) spécifiés dans la configuration de la machine a été modifié en dehors de la configuration de la machine.
  • Avant d'appliquer une nouvelle configuration de machine.

    Note

    Si vous appliquez une nouvelle configuration de machine aux nœuds, le MCD interrompt temporairement la détection des dérives de configuration. Cet arrêt est nécessaire car la nouvelle configuration de la machine diffère nécessairement de la configuration de la machine sur les nœuds. Une fois la nouvelle configuration machine appliquée, le MCD recommence à détecter les dérives de configuration à l'aide de la nouvelle configuration machine.

Lors de la détection des dérives de configuration, le MCD vérifie que le contenu et les autorisations des fichiers correspondent bien à ce que la configuration de la machine actuellement appliquée spécifie. En règle générale, le MCD détecte les dérives de configuration en moins d'une seconde après le déclenchement de la détection.

Si le MCD détecte une dérive de la configuration, il exécute les tâches suivantes :

  • Émet une erreur dans les journaux de la console
  • Emet un événement Kubernetes
  • Arrêt de la détection sur le nœud
  • Définit le nœud et le PCM à degraded

Vous pouvez vérifier si vous avez un nœud dégradé en dressant la liste des MCP :

$ oc get mcp worker

Si vous avez un MCP dégradé, le champ DEGRADEDMACHINECOUNT est non nul, comme dans le cas suivant :

Exemple de sortie

NAME     CONFIG                                             UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
worker   rendered-worker-404caf3180818d8ac1f50c32f14b57c3   False     True       True       2              1                   1                     1                      5h51m

Vous pouvez déterminer si le problème est dû à une dérive de la configuration en examinant le pool de configuration de la machine :

$ oc describe mcp worker

Exemple de sortie

 ...
    Last Transition Time:  2021-12-20T18:54:00Z
    Message:               Node ci-ln-j4h8nkb-72292-pxqxz-worker-a-fjks4 is reporting: "content mismatch for file \"/etc/mco-test-file\"" 1
    Reason:                1 nodes are reporting degraded status on sync
    Status:                True
    Type:                  NodeDegraded 2
 ...

1
Ce message indique que le fichier /etc/mco-test-file d'un nœud, qui a été ajouté par la configuration de la machine, a été modifié en dehors de la configuration de la machine.
2
L'état du nœud est NodeDegraded.

Ou, si vous savez quel nœud est dégradé, examinez ce nœud :

$ oc describe node/ci-ln-j4h8nkb-72292-pxqxz-worker-a-fjks4

Exemple de sortie

 ...

Annotations:        cloud.network.openshift.io/egress-ipconfig: [{"interface":"nic0","ifaddr":{"ipv4":"10.0.128.0/17"},"capacity":{"ip":10}}]
                    csi.volume.kubernetes.io/nodeid:
                      {"pd.csi.storage.gke.io":"projects/openshift-gce-devel-ci/zones/us-central1-a/instances/ci-ln-j4h8nkb-72292-pxqxz-worker-a-fjks4"}
                    machine.openshift.io/machine: openshift-machine-api/ci-ln-j4h8nkb-72292-pxqxz-worker-a-fjks4
                    machineconfiguration.openshift.io/controlPlaneTopology: HighlyAvailable
                    machineconfiguration.openshift.io/currentConfig: rendered-worker-67bd55d0b02b0f659aef33680693a9f9
                    machineconfiguration.openshift.io/desiredConfig: rendered-worker-67bd55d0b02b0f659aef33680693a9f9
                    machineconfiguration.openshift.io/reason: content mismatch for file "/etc/mco-test-file" 1
                    machineconfiguration.openshift.io/state: Degraded 2
 ...

1
Le message d'erreur indique qu'une dérive de configuration a été détectée entre le nœud et la machine config listée. Ici, le message d'erreur indique que le contenu de /etc/mco-test-file, qui a été ajouté par la machine config, a changé en dehors de la machine config.
2
L'état du nœud est Degraded.

Vous pouvez corriger la dérive de la configuration et ramener le nœud à l'état Ready en effectuant l'une des opérations suivantes :

  • Assurez-vous que le contenu et les autorisations des fichiers sur le nœud correspondent à ce qui est configuré dans la configuration de la machine. Vous pouvez réécrire manuellement le contenu des fichiers ou modifier leurs autorisations.
  • Générer un fichier de force sur le nœud dégradé. Le fichier de force permet au MCD de contourner la détection habituelle de dérive de la configuration et de réappliquer la configuration actuelle de la machine.

    Note

    La génération d'un fichier de force sur un nœud entraîne le redémarrage de ce nœud.

5.1.4. Vérification de l'état du pool de configuration de la machine

Pour connaître l'état de l'opérateur de configuration de la machine (MCO), de ses sous-composants et des ressources qu'il gère, utilisez les commandes suivantes : oc:

Procédure

  1. Pour connaître le nombre de nœuds gérés par MCO disponibles sur votre cluster pour chaque pool de configuration de machines (MCP), exécutez la commande suivante :

    $ oc get machineconfigpool

    Exemple de sortie

    NAME      CONFIG                    UPDATED  UPDATING   DEGRADED  MACHINECOUNT  READYMACHINECOUNT  UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT  AGE
    master    rendered-master-06c9c4…   True     False      False     3             3                  3                   0                     4h42m
    worker    rendered-worker-f4b64…    False    True       False     3             2                  2                   0                     4h42m

    où :

    MISE À JOUR
    L'état True indique que le MCO a appliqué la configuration actuelle de la machine aux nœuds de ce MCP. La configuration actuelle de la machine est spécifiée dans le champ STATUS de la sortie oc get mcp. L'état False indique qu'un nœud du MCP est en cours de mise à jour.
    MISE À JOUR
    L'état True indique que le MCO applique la configuration machine souhaitée, telle que spécifiée dans la ressource personnalisée MachineConfigPool, à au moins un des nœuds de ce MCP. La configuration machine souhaitée est la nouvelle configuration machine éditée. Les nœuds en cours de mise à jour peuvent ne pas être disponibles pour la planification. Le statut False indique que tous les nœuds du MCP sont mis à jour.
    DEGRADE
    L'état True indique que le MCO ne peut pas appliquer la configuration actuelle ou souhaitée de la machine à au moins un des nœuds de ce MCP, ou que la configuration échoue. Les nœuds dégradés peuvent ne pas être disponibles pour la programmation. L'état False indique que tous les nœuds du MCP sont prêts.
    MACHINECOUNT
    Indique le nombre total de machines dans ce GPE.
    READYMACHINECOUNT
    Indique le nombre total de machines de ce GPE qui sont prêtes à être programmées.
    COMPTEMACHINE MIS À JOUR
    Indique le nombre total de machines dans ce MCP qui ont la configuration de machine actuelle.
    COMPTEMACHINEDÉGRADÉ
    Indique le nombre total de machines de ce GPE qui sont marquées comme étant dégradées ou inconciliables.

    Dans la sortie précédente, il y a trois nœuds de plan de contrôle (maître) et trois nœuds de travailleur. Le MCP du plan de contrôle et les nœuds associés sont mis à jour avec la configuration actuelle de la machine. Les nœuds du MCP de l'employé sont mis à jour en fonction de la configuration souhaitée de la machine. Deux des nœuds du MCP ouvrier sont mis à jour et un autre est encore en cours de mise à jour, comme l'indique le site UPDATEDMACHINECOUNT ( 2). Il n'y a pas de problème, comme l'indiquent les adresses DEGRADEDMACHINECOUNT ( 0 ) et DEGRADED ( False).

    Pendant que les nœuds du MCP sont mis à jour, la configuration de la machine répertoriée sous CONFIG est la configuration de la machine actuelle, à partir de laquelle le MCP est mis à jour. Lorsque la mise à jour est terminée, la configuration de machine répertoriée est la configuration de machine souhaitée, vers laquelle le MCP a été mis à jour.

    Note

    Si un nœud est en cours de cordonage, ce nœud n'est pas inclus dans le READYMACHINECOUNT, mais il est inclus dans le MACHINECOUNT. De plus, le statut MCP est défini sur UPDATING. Comme le nœud a la configuration de la machine actuelle, il est compté dans le total UPDATEDMACHINECOUNT:

    Exemple de sortie

    NAME      CONFIG                    UPDATED  UPDATING   DEGRADED  MACHINECOUNT  READYMACHINECOUNT  UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT  AGE
    master    rendered-master-06c9c4…   True     False      False     3             3                  3                   0                     4h42m
    worker    rendered-worker-c1b41a…   False    True       False     3             2                  3                   0                     4h42m

  2. Pour vérifier l'état des nœuds d'un MCP en examinant la ressource personnalisée MachineConfigPool, exécutez la commande suivante : :

    $ oc describe mcp worker

    Exemple de sortie

    ...
      Degraded Machine Count:     0
      Machine Count:              3
      Observed Generation:        2
      Ready Machine Count:        3
      Unavailable Machine Count:  0
      Updated Machine Count:      3
    Events:                       <none>

    Note

    Si un nœud fait l'objet d'un cordon, il n'est pas inclus dans le site Ready Machine Count. Il est inclus dans le site Unavailable Machine Count:

    Exemple de sortie

    ...
      Degraded Machine Count:     0
      Machine Count:              3
      Observed Generation:        2
      Ready Machine Count:        2
      Unavailable Machine Count:  1
      Updated Machine Count:      3

  3. Pour voir chaque objet MachineConfig existant, exécutez la commande suivante :

    $ oc get machineconfigs

    Exemple de sortie

    NAME                             GENERATEDBYCONTROLLER          IGNITIONVERSION  AGE
    00-master                        2c9371fbb673b97a6fe8b1c52...   3.2.0            5h18m
    00-worker                        2c9371fbb673b97a6fe8b1c52...   3.2.0            5h18m
    01-master-container-runtime      2c9371fbb673b97a6fe8b1c52...   3.2.0            5h18m
    01-master-kubelet                2c9371fbb673b97a6fe8b1c52…     3.2.0            5h18m
    ...
    rendered-master-dde...           2c9371fbb673b97a6fe8b1c52...   3.2.0            5h18m
    rendered-worker-fde...           2c9371fbb673b97a6fe8b1c52...   3.2.0            5h18m

    Notez que les objets MachineConfig répertoriés comme rendered ne sont pas destinés à être modifiés ou supprimés.

  4. Pour afficher le contenu d'une configuration de machine particulière (dans ce cas, 01-master-kubelet), exécutez la commande suivante :

    $ oc describe machineconfigs 01-master-kubelet

    La sortie de la commande montre que cet objet MachineConfig contient à la fois des fichiers de configuration (cloud.conf et kubelet.conf) et un service systemd (Kubernetes Kubelet) :

    Exemple de sortie

    Name:         01-master-kubelet
    ...
    Spec:
      Config:
        Ignition:
          Version:  3.2.0
        Storage:
          Files:
            Contents:
              Source:   data:,
            Mode:       420
            Overwrite:  true
            Path:       /etc/kubernetes/cloud.conf
            Contents:
              Source:   data:,kind%3A%20KubeletConfiguration%0AapiVersion%3A%20kubelet.config.k8s.io%2Fv1beta1%0Aauthentication%3A%0A%20%20x509%3A%0A%20%20%20%20clientCAFile%3A%20%2Fetc%2Fkubernetes%2Fkubelet-ca.crt%0A%20%20anonymous...
            Mode:       420
            Overwrite:  true
            Path:       /etc/kubernetes/kubelet.conf
        Systemd:
          Units:
            Contents:  [Unit]
    Description=Kubernetes Kubelet
    Wants=rpc-statd.service network-online.target crio.service
    After=network-online.target crio.service
    
    ExecStart=/usr/bin/hyperkube \
        kubelet \
          --config=/etc/kubernetes/kubelet.conf \ ...

Si quelque chose ne va pas avec une configuration de machine que vous appliquez, vous pouvez toujours revenir en arrière. Par exemple, si vous avez exécuté oc create -f ./myconfig.yaml pour appliquer une configuration de machine, vous pouvez supprimer cette configuration de machine en exécutant la commande suivante :

$ oc delete -f ./myconfig.yaml

Si c'était le seul problème, les nœuds du pool concerné devraient revenir à un état non dégradé. En réalité, cela entraîne le retour de la configuration rendue à son état précédent.

Si vous ajoutez vos propres configurations de machines à votre cluster, vous pouvez utiliser les commandes présentées dans l'exemple précédent pour vérifier leur état et l'état connexe du pool auquel elles sont appliquées.

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.