Rechercher

7.5. Dépannage des problèmes de réseau

download PDF

7.5.1. Comment l'interface réseau est sélectionnée

Pour les installations sur bare metal ou avec des machines virtuelles qui ont plus d'un contrôleur d'interface réseau (NIC), le NIC qu'OpenShift Container Platform utilise pour la communication avec le serveur API Kubernetes est déterminé par l'unité de service nodeip-configuration.service qui est exécutée par systemd lorsque le nœud démarre. Le site nodeip-configuration.service sélectionne l'IP de l'interface associée à la route par défaut.

Une fois que le service nodeip-configuration.service a déterminé le NIC correct, il crée le fichier /etc/systemd/system/kubelet.service.d/20-nodenet.conf. Le fichier 20-nodenet.conf attribue à la variable d'environnement KUBELET_NODE_IP l'adresse IP sélectionnée par le service.

Lorsque le service kubelet démarre, il lit la valeur de la variable d'environnement dans le fichier 20-nodenet.conf et définit l'adresse IP comme valeur de l'argument de ligne de commande --node-ip kubelet. Par conséquent, le service kubelet utilise l'adresse IP sélectionnée comme adresse IP du nœud.

Si le matériel ou le réseau est reconfiguré après l'installation, ou s'il existe une configuration réseau où l'IP du nœud ne devrait pas provenir de l'interface de la route par défaut, il est possible que le service nodeip-configuration.service sélectionne une carte d'interface réseau différente après un redémarrage. Dans certains cas, vous pouvez détecter qu'une carte d'interface différente a été sélectionnée en examinant la colonne INTERNAL-IP dans la sortie de la commande oc get nodes -o wide.

Si la communication réseau est perturbée ou mal configurée parce qu'un autre NIC est sélectionné, vous pouvez recevoir l'erreur suivante : EtcdCertSignerControllerDegraded. Vous pouvez créer un fichier d'indices qui inclut la variable NODEIP_HINT pour remplacer la logique de sélection IP par défaut. Pour plus d'informations, voir Facultatif : Remplacement de la logique de sélection de l'IP du nœud par défaut.

7.5.1.1. Facultatif : Remplacer la logique de sélection de l'IP du nœud par défaut

Pour remplacer la logique de sélection IP par défaut, vous pouvez créer un fichier d'indices qui inclut la variable NODEIP_HINT pour remplacer la logique de sélection IP par défaut. La création d'un fichier d'indices vous permet de sélectionner une adresse IP de nœud spécifique à partir de l'interface dans le sous-réseau de l'adresse IP spécifiée dans la variable NODEIP_HINT.

Par exemple, si un nœud possède deux interfaces, eth0 avec une adresse 10.0.0.10/24, et eth1 avec une adresse 192.0.2.5/24, et que la route par défaut pointe vers eth0 (10.0.0.10), l'adresse IP du nœud devrait normalement utiliser l'adresse IP 10.0.0.10.

Les utilisateurs peuvent configurer la variable NODEIP_HINT pour qu'elle pointe vers une IP connue dans le sous-réseau, par exemple une passerelle de sous-réseau telle que 192.0.2.1, de sorte que l'autre sous-réseau, 192.0.2.0/24, soit sélectionné. En conséquence, l'adresse IP 192.0.2.5 sur eth1 est utilisée pour le nœud.

La procédure suivante montre comment remplacer la logique de sélection de l'IP du nœud par défaut.

Procédure

  1. Ajoutez un fichier d'indices à votre fichier /etc/default/nodeip-configuration, par exemple :

    NODEIP_HINT=192.0.2.1
    Important
    • N'utilisez pas l'adresse IP exacte d'un nœud comme indice, par exemple 192.0.2.5. L'utilisation de l'adresse IP exacte d'un nœud entraîne l'échec de la configuration du nœud utilisant l'adresse IP de l'indice.
    • L'adresse IP figurant dans le fichier d'indices n'est utilisée que pour déterminer le sous-réseau correct. Elle ne recevra pas de trafic du fait de son apparition dans le fichier d'indices.
  2. Générez le contenu encodé base-64 en exécutant la commande suivante :

    $ echo 'NODEIP_HINT=192.0.2.1' | base64

    Exemple de sortie

    Tk9ERUlQX0hJTlQ9MTkyLjAuMCxxxx==

  3. Activez l'astuce en créant un manifeste de configuration de machine pour les rôles master et worker avant de déployer le cluster :

    Manifeste de configuration de la machine maître

    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfig
    metadata:
     labels:
       machineconfiguration.openshift.io/role: master
       name: 99-nodeip-hint-master
    spec:
     config:
       ignition:
         version: 3.2.0
       storage:
         files:
         - contents:
             source: data:text/plain;charset=utf-8;base64, <encoded_content> 1
           mode: 0644
           overwrite: true
           path: /etc/default/nodeip-configuration

    1
    Remplacez <encoded_contents> par le contenu codé en base64 du fichier /etc/default/nodeip-configuration, par exemple Tk9ERUlQX0hJTlQ9MTkyLjAuMCxxxx==.

    Manifeste de configuration de la machine de travail

    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfig
    metadata:
     labels:
       machineconfiguration.openshift.io/role: worker
       name: 99-nodeip-hint-worker
    spec:
     config:
       ignition:
         version: 3.2.0
       storage:
         files:
         - contents:
             source: data:text/plain;charset=utf-8;base64, <encoded_content> 1
           mode: 0644
           overwrite: true
           path: /etc/default/nodeip-configuration

    1
    Remplacez <encoded_contents> par le contenu codé en base64 du fichier /etc/default/nodeip-configuration, par exemple Tk9ERUlQX0hJTlQ9MTkyLjAuMCxxxx==.
  4. Enregistrez le manifeste dans le répertoire où vous stockez la configuration de votre cluster, par exemple, ~/clusterconfigs.
  5. Déployer le cluster.

7.5.2. Dépannage des problèmes liés à l'Open vSwitch

Pour résoudre certains problèmes liés à l'Open vSwitch (OVS), il peut s'avérer nécessaire de configurer le niveau du journal afin d'y inclure davantage d'informations.

Si vous modifiez temporairement le niveau de journalisation sur un nœud, sachez que vous pouvez recevoir des messages de journalisation du démon de configuration de la machine sur le nœud, comme dans l'exemple suivant :

E0514 12:47:17.998892    2281 daemon.go:1350] content mismatch for file /etc/systemd/system/ovs-vswitchd.service: [Unit]

Pour éviter les messages de journal liés à la non-concordance, annulez le changement de niveau de journal une fois que vous avez terminé votre dépannage.

7.5.2.1. Configurer temporairement le niveau de journalisation d'Open vSwitch

Pour un dépannage à court terme, vous pouvez configurer temporairement le niveau de journalisation de l'Open vSwitch (OVS). La procédure suivante ne nécessite pas le redémarrage du nœud. En outre, la modification de la configuration ne persiste pas lorsque vous redémarrez le nœud.

Après avoir effectué cette procédure pour modifier le niveau du journal, vous pouvez recevoir des messages du démon de configuration de la machine qui indiquent une incompatibilité de contenu pour le site ovs-vswitchd.service. Pour éviter ces messages, répétez cette procédure et réglez le niveau du journal sur la valeur d'origine.

Conditions préalables

  • Vous avez accès au cluster en tant qu'utilisateur ayant le rôle cluster-admin.
  • Vous avez installé l'OpenShift CLI (oc).

Procédure

  1. Démarrer un pod de débogage pour un nœud :

    oc debug node/<node_name>
  2. Définissez /host comme répertoire racine dans le shell de débogage. Le pod de débogage monte le système de fichiers racine de l'hôte dans /host au sein du pod. En remplaçant le répertoire racine par /host, vous pouvez exécuter des binaires à partir du système de fichiers de l'hôte :

    # chroot /host
  3. Visualiser le niveau actuel de syslog pour les modules OVS :

    # ovs-appctl vlog/list

    L'exemple suivant montre que le niveau de journalisation de syslog est défini sur info.

    Exemple de sortie

                     console    syslog    file
                     -------    ------    ------
    backtrace          OFF       INFO       INFO
    bfd                OFF       INFO       INFO
    bond               OFF       INFO       INFO
    bridge             OFF       INFO       INFO
    bundle             OFF       INFO       INFO
    bundles            OFF       INFO       INFO
    cfm                OFF       INFO       INFO
    collectors         OFF       INFO       INFO
    command_line       OFF       INFO       INFO
    connmgr            OFF       INFO       INFO
    conntrack          OFF       INFO       INFO
    conntrack_tp       OFF       INFO       INFO
    coverage           OFF       INFO       INFO
    ct_dpif            OFF       INFO       INFO
    daemon             OFF       INFO       INFO
    daemon_unix        OFF       INFO       INFO
    dns_resolve        OFF       INFO       INFO
    dpdk               OFF       INFO       INFO
    ...

  4. Spécifiez le niveau de journalisation dans le fichier /etc/systemd/system/ovs-vswitchd.service.d/10-ovs-vswitchd-restart.conf:

    Restart=always
    ExecStartPre=-/bin/sh -c '/usr/bin/chown -R :$${OVS_USER_ID##*:} /var/lib/openvswitch'
    ExecStartPre=-/bin/sh -c '/usr/bin/chown -R :$${OVS_USER_ID##*:} /etc/openvswitch'
    ExecStartPre=-/bin/sh -c '/usr/bin/chown -R :$${OVS_USER_ID##*:} /run/openvswitch'
    ExecStartPost=-/usr/bin/ovs-appctl vlog/set syslog:dbg
    ExecReload=-/usr/bin/ovs-appctl vlog/set syslog:dbg

    Dans l'exemple précédent, le niveau de journalisation est défini sur dbg. Modifiez les deux dernières lignes en remplaçant syslog:<log_level> par off, emer, err, warn, info, ou dbg. Le niveau de journalisation off filtre tous les messages de journalisation.

  5. Redémarrer le service :

    # systemctl daemon-reload
    # systemctl restart ovs-vswitchd

7.5.2.2. Configuration permanente du niveau de journalisation d'Open vSwitch

Pour les modifications à long terme du niveau de journalisation d'Open vSwitch (OVS), vous pouvez modifier le niveau de journalisation de manière permanente.

Conditions préalables

  • Vous avez accès au cluster en tant qu'utilisateur ayant le rôle cluster-admin.
  • Vous avez installé l'OpenShift CLI (oc).

Procédure

  1. Créez un fichier, tel que 99-change-ovs-loglevel.yaml, avec un objet MachineConfig comme dans l'exemple suivant :

    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfig
    metadata:
      labels:
        machineconfiguration.openshift.io/role: master  1
      name: 99-change-ovs-loglevel
    spec:
      config:
        ignition:
          version: 3.2.0
        systemd:
          units:
          - dropins:
            - contents: |
                [Service]
                  ExecStartPost=-/usr/bin/ovs-appctl vlog/set syslog:dbg  2
                  ExecReload=-/usr/bin/ovs-appctl vlog/set syslog:dbg
              name: 20-ovs-vswitchd-restart.conf
            name: ovs-vswitchd.service
    1
    Après avoir exécuté cette procédure pour configurer les nœuds du plan de contrôle, répétez la procédure et définissez le rôle sur worker pour configurer les nœuds de travail.
    2
    Définissez la valeur syslog:<log_level>. Les niveaux de journalisation sont off, emer, err, warn, info ou dbg. La valeur off permet de filtrer tous les messages de journalisation.
  2. Appliquer la configuration de la machine :

    $ oc apply -f 99-change-ovs-loglevel.yaml

7.5.2.3. Affichage des journaux Open vSwitch

La procédure suivante permet d'afficher les journaux Open vSwitch (OVS).

Conditions préalables

  • Vous avez accès au cluster en tant qu'utilisateur ayant le rôle cluster-admin.
  • Vous avez installé l'OpenShift CLI (oc).

Procédure

  • Exécutez l'une des commandes suivantes :

    • Affichez les journaux en utilisant la commande oc depuis l'extérieur du cluster :

      $ oc adm node-logs <node_name> -u ovs-vswitchd
    • Affiche les journaux après l'ouverture d'une session sur un nœud du cluster :

      # journalctl -b -f -u ovs-vswitchd.service

      L'une des façons de se connecter à un nœud est d'utiliser la commande oc debug node/<node_name>.

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.