Chapitre 5. Tâches de configuration de la machine après l'installation
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 objetMachineConfig. 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.
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
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.
ImportantUn nœud peut avoir plusieurs étiquettes qui indiquent son type, comme
masterouworker, 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 champmaxUnavailabledu 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
/etcet/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/optet/usr/localen 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'étatdegraded. -
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-operatorprovisionne 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
/varou/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.
-
Configuration files: Créer ou écraser des fichiers dans le répertoire
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
realtimepour 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.
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
ContainerRuntimeandKubelet): 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 (ContainerRuntimeCR) et le service Kubelet (KubeletCR).
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.
NoteSi 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
...
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.
NoteLa 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
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
Trueindique 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 champSTATUSde la sortieoc get mcp. L'étatFalseindique qu'un nœud du MCP est en cours de mise à jour. - MISE À JOUR
-
L'état
Trueindique que le MCO applique la configuration machine souhaitée, telle que spécifiée dans la ressource personnaliséeMachineConfigPool, à 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 statutFalseindique que tous les nœuds du MCP sont mis à jour. - DEGRADE
-
L'état
Trueindique 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'étatFalseindique 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 adressesDEGRADEDMACHINECOUNT(0) etDEGRADED(False).Pendant que les nœuds du MCP sont mis à jour, la configuration de la machine répertoriée sous
CONFIGest 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.NoteSi un nœud est en cours de cordonage, ce nœud n'est pas inclus dans le
READYMACHINECOUNT, mais il est inclus dans leMACHINECOUNT. De plus, le statut MCP est défini surUPDATING. Comme le nœud a la configuration de la machine actuelle, il est compté dans le totalUPDATEDMACHINECOUNT: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
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>
NoteSi 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 siteUnavailable 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
Pour voir chaque objet
MachineConfigexistant, 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
MachineConfigrépertoriés commerenderedne sont pas destinés à être modifiés ou supprimés.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
MachineConfigcontient à la fois des fichiers de configuration (cloud.confetkubelet.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.
