Perché i pod sysdig-agent si trovano in CrashLoopBackOff su un cluster RHCOS privato?

Cloud virtuale privato Nodi worker RHCOS Solo per privati

Se il cluster utilizza nodi worker RHCOS e non ha accesso a Internet in uscita, i pod sysdig-agent nello spazio dei nomi ibm-observe potrebbero entrare in CrashLoopBackOff o non avviarsi.

I pod sysdig-agent si trovano nello spazio dei nomi CrashLoopBackOff o non si avviano nello spazio dei nomi ibm-observe su un cluster privato che utilizza i nodi worker RHCOS.

È possibile che i pod sysdig-agent si riavviino ripetutamente e non diventino sani dopo l'installazione o la configurazione dell'integrazione Sysdig. Quando si controllano i log dei pod, si vedono errori simili ai seguenti:

oc -n ibm-observe logs <sysdig-agent-pod> --previous

Output di esempio:

* Kernel headers not found in /host/lib/modules/5.14.0-427.105.1.el9_4.x86_64/build, continuing anyway
* Loading kernel probe
Error! Your kernel headers for kernel 5.14.0-427.105.1.el9_4.x86_64 cannot be found at /lib/modules/5.14.0-427.105.1.el9_4.x86_64/build or /lib/modules/5.14.0-427.105.1.el9_4.x86_64/source.
* Trying to download precompiled module from https://download.sysdig.com/stable/sysdig-probe-binaries/...
Download of sysdigcloud-probe for version 14.3.2 failed.
curl: (28) Failed to connect to download.sysdig.com port 443: Connection timed out
Cannot load the probe

Sui nodi worker RHCOS, l'agente di monitoraggio non può fare affidamento sugli header locali del kernel perché RHCOS non li include. In questo scenario, l'agente Sysdig tenta di raggiungere sysdig.com per recuperare un driver precompilato. Nei cluster solo privati, o nei cluster senza accesso a Internet in uscita, questo processo fallisce e i pod dell'agente possono entrare in CrashLoopBackOff.

Se il driver eBPF non è abilitato, questa è una potenziale causa del problema. Seguire questi passaggi per diagnosticare e risolvere il problema.

eBPF è ora abilitato per impostazione predefinita per le nuove distribuzioni di Sysdig. Tuttavia, se si verificano problemi su un cluster esistente con lavoratori RHCOS in un ambiente solo privato, verificare se eBPF è abilitato e, se necessario, abilitarlo.

Verificare la configurazione dell'agente Sysdig e abilitare il driver eBPF, se necessario.

  1. Verificare se il driver eBPF è attualmente abilitato sul cluster.

    oc -n ibm-observe get daemonset/sysdig-agent -o jsonpath='{.spec.template.spec.containers[0].env[?(@.name=="SYSDIG_AGENT_DRIVER")].value}'
    • Se l'output mostra universal_ebpf, eBPF è già abilitato. I passaggi indicati di seguito non sono necessari e la loro esecuzione non causerà alcun danno, ma non risolverà il problema. Potrebbe essere necessario indagare su altre potenziali cause.
    • Se l'uscita è vuota o mostra un valore diverso da universal_ebpf, proseguire al passo successivo per abilitare eBPF.

  2. Impostare il driver dell'agente Sysdig su universal_ebpf.

    oc -n ibm-observe set env daemonset/sysdig-agent SYSDIG_AGENT_DRIVER=universal_ebpf

  3. Riavviare i pod sysdig-agent.

    oc delete pods -l app=sysdig-agent -n ibm-observe

  4. Verificare che i pod sostitutivi siano stati creati e tornare allo stato Running.

    oc get pods -l app=sysdig-agent -n ibm-observe

Per ulteriori informazioni sul monitoraggio delle limitazioni dei nodi worker RHCOS, vedere Monitoraggio della salute del cluster.