Debugging von Calico-Komponenten

Virtual Private Cloud Classic-Infrastruktur

Es treten Probleme mit Calico-Komponenten wie Pods auf, die nicht bereitgestellt werden, oder sporadisch auftretende Netzprobleme.

Es treten Probleme mit Calico-Komponenten wie Pods auf, die nicht bereitgestellt werden, oder sporadisch auftretende Netzprobleme.

Der Operator „ Calico “ ermittelt die Anzahl der „ calico-typha “-Pods anhand der Anzahl der Cluster-Worker und berücksichtigt dabei keine mit einem Taint versehenen Knoten. Wenn Ihr Cluster weniger als drei „untainted“ Knoten enthält oder es sich um einen sehr großen Cluster mit nur wenigen „untainted“ Knoten handelt, kann es vorkommen, dass ein oder mehrere „ calico-typha “-Pods im Status „ Pending “ hängen bleiben, da der Pod keinen „untainted“ Knoten findet, auf dem er ausgeführt werden kann. In der Regel ist dies kein Problem, solange sich mindestens ein calico-typha Pod im Zustand "Running" befindet. Aus Gründen der Hochverfügbarkeit wird jedoch empfohlen, immer mindestens zwei calico-typha Pods laufen zu lassen. Als Best Practice sollten Sie sicherstellen, dass genügend unbelastete Knoten vorhanden sind, um alle calico-typha Pods, die von den Calico Operator.

Calico Netzwerkprobleme lassen sich ohne detaillierte Protokollierung oft nur schwer diagnostizieren. Die Standardprotokollstufe für die Komponenten von „ Calico “ ist auf „ info “ eingestellt. Diese Stufe liefert grundlegende Betriebsinformationen, enthält jedoch möglicherweise nicht genügend Details, um komplexe Netzwerkprobleme zu beheben.

Erhöhen Sie die Protokollierungsstufe der „ Calico “-Komponenten auf „ debug “, um detailliertere Informationen zu dem Problem zu erhalten. Die Protokollierung auf Debug-Ebene liefert ausführliche Informationen, die dabei helfen können, die Ursache von Netzwerkproblemen zu ermitteln.

Protokollstufe für die calico-typha-Komponenten erhöhen

Führen Sie die folgenden Schritte aus, um die Protokollierungsstufe für die calico-typha-Komponente zu erhöhen.

  1. Führen Sie den folgenden Befehl aus, um die calico-typha-Bereitstellung zu bearbeiten.

    Für „ 1.29 “ und spätere Versionen:

    kubectl edit deploy calico-typha -n calico-system
    

    Für 1.28 und früher:

    kubectl edit deploy calico-typha -n kube-system
    
  2. Ändern Sie die Umgebungsvariable TYPHA_LOGSEVERITYSCREEN von info in debug.

          containers:
        - env:
          - name: TYPHA_LOGSEVERITYSCREEN
            value: debug
    
  3. Speichern und schließen Sie die Datei, um die Änderungen anzuwenden, und starten Sie die calico-typha-Bereitstellung erneut.

Protokollstufe für die calico-cni-Komponenten erhöhen

Führen Sie die folgenden Schritte aus, um die Protokollierungsstufe für die calico-cni-Komponente zu erhöhen.

  1. Führen Sie den folgenden Befehl aus, um die calico-config-Konfigurationszuordnung zu bearbeiten.

    kubectl edit cm -n kube-system calico-config
    
  2. Ändern Sie die Umgebungsvariable cni_network_config > plugins > log_level in debug.

      cni_network_config: |-
      {
        "name": "k8s-pod-network",
        "cniVersion": "0.3.1",
        "plugins": [
          {
            "type": "calico",
            "log_level": "debug",
    
  3. Speichern und schließen Sie die Datei. Die Änderung wird erst wirksam, wenn die calico-node-Pods erneut gestartet werden.

  4. Starten Sie die calico-node-Pods erneut, um die Änderungen anzuwenden.

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

    Beispielausgabe

    daemonset.apps/calico-node restarted
    

Protokollstufe für die calico-node-Komponenten erhöhen

Führen Sie die folgenden Schritte aus, um die Protokollierungsstufe für die calico-node-Komponente zu erhöhen.

  1. Führen Sie den folgenden Befehl aus:

    Für „ 1.29 “ und spätere Versionen:

    kubectl edit ds calico-node -n calico-system
    

    Für 1.28 und früher:

    kubectl edit ds calico-node -n kube-system
    
  2. Fügen Sie unter dem Name/Wert-Paar FELIX_USAGEREPORTINGENABLED (oder nach einem beliebigen Name/Wert-Paar der FELIX_*-Umgebungsvariable) den folgenden Eintrag hinzu.

    - name: FELIX_LOGSEVERITYSCREEN
      value: Debug
    
  3. Speichern Sie die Änderung. Nach dem Speichern Ihrer Änderungen führen alle Pods in der calico-node-Dämongruppe eine rollierende Aktualisierung durch, die die Änderungen anwendet. calico-cni wendet auch alle Änderungen an den Protokollierungsstufen in der Konfigurationsübersicht für kube-system/calico-config an.

Protokollstufe für die calico-kube-controllers-Komponenten erhöhen

Führen Sie die folgenden Schritte aus, um die Protokollierungsstufe für die calico-kube-controllers-Komponente zu erhöhen.

  1. Bearbeiten Sie die Bereitstellung, indem Sie den folgenden Befehl ausführen.

    Für „ 1.29 “ und spätere Versionen:

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

    Für 1.28 und früher:

    kubectl edit deploy calico-kube-controllers -n kube-system
    
  2. Fügen Sie unter dem Name/Wert-Paar DATASTORE_TYPE den folgenden Eintrag hinzu.

    - name: LOG_LEVEL
      value: debug
    
  3. Speichern Sie die Änderung. Der calico-kube-controllers-Pod wird erneut gestartet und wendet die Änderungen an.

Calico-Protokolle sammeln

  1. Listen Sie die Pods und Knoten in Ihrem Cluster auf und notieren Sie sich den Pod-Namen, die IP-Adresse des Pods sowie den Worker-Knoten, bei dem das Problem auftritt.

    kubectl get pods -o wide -n kube-system
    
  2. Rufen Sie die Protokolle für den calico-node-Pod auf dem Workerknoten ab, auf dem das Problem aufgetreten ist.

    Für „ 1.29 “ und spätere Versionen:

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

    Für 1.28 und früher:

    kubectl logs calico-typha-aaa11111a-aaaaa -n kube-system
    
  3. Rufen Sie Protokolle für den calico-kube-controllers-Pod ab.

    Für „ 1.29 “ und spätere Versionen:

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

    Für 1.28 und früher:

    kubectl logs calico-kube-controllers-11aaa11aa1-a1a1a -n kube-system
    
  4. Befolgen Sie die Anweisungen für das Debugging mit 'kubectl exec', um /var/log/syslog, containerd.log, kubelet.log und kern.log aus dem Workerknoten abzurufen.