Débogage des composants Calico

Cloud privé virtuel Infrastructure classique

Vous avez des problèmes avec des composants Calico tels que des cabosses qui ne se déploient pas ou des problèmes de mise en réseau intermittents.

Vous avez des problèmes avec des composants Calico tels que des cabosses qui ne se déploient pas ou des problèmes de mise en réseau intermittents.

L'opérateur « Calico » détermine le nombre de pods « calico-typha » en fonction du nombre de nœuds de travail du cluster et ne tient pas compte des nœuds marqués. Si votre cluster compte moins de 3 nœuds non marqués, ou s'il s'agit d'un très grand cluster comportant un petit nombre de nœuds non marqués, il se peut qu'un ou plusieurs pods « calico-typha » soient bloqués à l'état « Pending », car le pod ne parvient pas à trouver un nœud non marqué sur lequel s'exécuter. En général, cela ne pose pas de problème tant qu'il y a au moins un calico-typha pod dans Running state. Cependant, pour une haute disponibilité, il est recommandé d'avoir au moins deux calico-typha pods toujours en cours d'exécution. Il est recommandé de s'assurer qu'il y a suffisamment de nœuds intacts pour exécuter tous les calico-typha pods créés par le Calico opérateur.

Calico Les problèmes de réseau peuvent être difficiles à diagnostiquer sans journaux détaillés. Le niveau de journalisation par défaut des composants d' Calico est défini sur « info », ce qui fournit des informations opérationnelles de base mais peut ne pas inclure suffisamment de détails pour résoudre des problèmes réseau complexes.

Augmentez le niveau de journalisation des composants d' Calico, en le réglant sur « debug », afin de recueillir des informations plus détaillées sur le problème. La journalisation au niveau « debug » fournit des informations détaillées qui peuvent aider à identifier la cause première des problèmes réseau.

Augmentation du niveau de journalisation des composants calico-typha

Pour augmenter le niveau de journalisation du composant calico-typha , procédez comme suit :

  1. Exécutez la commande suivante pour éditer le calico-typha déploiement.

    Pour les versions d' 1.29. et ultérieures :

    kubectl edit deploy calico-typha -n calico-system

    Pour 1.28 et les versions antérieures:

    kubectl edit deploy calico-typha -n kube-system

  2. Remplacez la TYPHA_LOGSEVERITYSCREENvariable d'environnement de info par debug.

          containers:
    - env:
      - name: TYPHA_LOGSEVERITYSCREEN
        value: debug

  3. Enregistrez et fermez le fichier pour appliquer les modifications et redémarrez le déploiement calico-typha .

Augmentation du niveau de journalisation des composants calico-cni

Pour augmenter le niveau de journalisation du composant calico-cni , procédez comme suit :

  1. Exécutez la commande suivante pour modifier la calico-config carte de configuration.

    kubectl edit cm -n kube-system calico-config

  2. Remplacez la variable d'environnement cni_network_config > plugins > log_level par debug.

      cni_network_config: |-
  {
    "name": "k8s-pod-network",
    "cniVersion": "0.3.1",
    "plugins": [
      {
        "type": "calico",
        "log_level": "debug",

  3. Sauvegardez et fermez le fichier. La modification ne prendra effet que lorsque les calico-nodepods seront redémarrés.

  4. Redémarrez les fichiers calico-node pour appliquer les modifications.

    kubectl rollout restart daemonset/calico-node -n kube-system

    Exemple de sortie

    daemonset.apps/calico-node restarted

Augmentation du niveau de journalisation des composants calico-node

Pour augmenter le niveau de journalisation du composant calico-node , procédez comme suit :

  1. Exécutez la commande suivante :

    Pour les versions d' 1.29. et ultérieures :

    kubectl edit ds calico-node -n calico-system

    Pour 1.28 et les versions antérieures:

    kubectl edit ds calico-node -n kube-system

  2. Sous la paire nom et valeur FELIX_USAGEREPORTINGENABLED (ou après l'une des paires de valeurs de nom de variable d'environnement FELIX_* ), ajoutez l'entrée suivante.

    - name: FELIX_LOGSEVERITYSCREEN
  value: Debug

  3. Enregistrez le changement. Après avoir enregistré vos modifications, tous les pods du calico-nodegroupe de travail effectuent une mise à jour continue qui applique les modifications. calico-cni applique également toutes les modifications apportées aux niveaux de journalisation dans la carte de configuration kube-system/calico-config .

Augmentation du niveau de journalisation des composants calico-kube-controllers

Pour augmenter le niveau de journalisation du composant calico-kube-controllers , procédez comme suit :

  1. Modifiez le déploiement en exécutant la commande suivante.

    Pour les versions d' 1.29. et ultérieures :

    kubectl edit deploy calico-kube-controllers -n calico-system

    Pour 1.28 et les versions antérieures:

    kubectl edit deploy calico-kube-controllers -n kube-system

  2. Sous la paire nom et valeur DATASTORE_TYPE, ajoutez l'entrée suivante.

    - name: LOG_LEVEL
  value: debug

  3. Enregistrez le changement. La pod calico-kube-controllers redémarre et applique les modifications.

Collecte des journaux Calico

  1. Répertoriez les pods et les nœuds de votre cluster, puis notez le nom du pod, son adresse IP et le nœud de travail concerné par le problème.

    kubectl get pods -o wide -n kube-system

  2. Obtenez les journaux pour le calico-nodepod sur le nœud de travail où le problème s'est produit.

    Pour les versions d' 1.29. et ultérieures :

    kubectl logs calico-typha-aaa11111a-aaaaa -n calico-system

    Pour 1.28 et les versions antérieures:

    kubectl logs calico-typha-aaa11111a-aaaaa -n kube-system

  3. Récupère les journaux pour le podcalico-kube-controllers.

    Pour les versions d' 1.29. et ultérieures :

    kubectl logs calico-kube-controllers-11aaa11aa1-a1a1a -n calico-system

    Pour 1.28 et les versions antérieures:

    kubectl logs calico-kube-controllers-11aaa11aa1-a1a1a -n kube-system

  4. Suivez les instructions de Débogage à l'aide de la commande kubectl exec pour obtenir /var/log/syslog, containerd.log, kubelet.loget kern.log à partir du noeud de travail.