Uploaded image for project: 'OpenShift Bugs'
  1. OpenShift Bugs
  2. OCPBUGS-55676

multus pod is in CrashLoopBackOff state due to bad certificate

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Normal Normal
    • None
    • 4.14, 4.15, 4.16, 4.17, 4.18
    • Networking / multus
    • Quality / Stability / Reliability
    • False
    • Hide

      None

      Show
      None
    • None
    • None
    • None
    • None
    • None
    • None
    • None
    • None
    • None
    • None
    • None
    • None
    • None
    • None

      Description of problem: 

          multus pod is in CrashLoopBackOff state due to bad certificate

      Version-Release number of selected component (if applicable):

          4.14 to 4.18 even in latest release

      How reproducible:

      When the latest linked certificates are updated (or “trunked”) as below and the affected pod is restarted, it always ends up in a CrashLoopBackOff state. 

      Steps to Reproduce:

      1. Trunk-ed the latest link certificate using below command
      sh-5.1# pwd
      /etc/cni/multus/certs
      lrwxrwxrwx. 1 root root   59 May  2 05:26 multus-client-current.pem -> /etc/cni/multus/certs/multus-client-2025-05-02-05-26-56.pem
      -rw-------. 1 root root 1.2K May  2 05:26 multus-client-2025-05-02-05-26-56.pem
      sh-5.1# > multus-client-2025-05-02-05-26-56.pem
      2. Restart the respective multus pod . Below logs is visible upon describing the pod
      Raw2024-03-03T12:23:36+00:00 [cnibincopy] Successfully copied files in /usr/src/multus-cni/rhel9/bin/ to /host/opt/cni/bin/upgrade_b0b45aab-8242-43ff-9315-9a3ed6ede672
      2024-03-03T12:23:37+00:00 [cnibincopy] Successfully moved files in /host/opt/cni/bin/upgrade_XxXxXxX-8242-43ff-9315-9a3ed6ede672 to /host/opt/cni/bin/
      2024-03-03T12:23:37Z [verbose] multus-daemon started
      2024-03-03T12:23:37Z [verbose] Readiness Indicator file check
      2024-03-03T12:23:37Z [verbose] Readiness Indicator file check done!
      I0303 12:23:37.048136  166875 certificate_store.go:130] Loading cert/key pair from "/etc/cni/multus/certs/multus-client-current.pem".
      2024-03-03T12:23:37Z [error] failed to initialize the certificate manager: could not convert data from "/etc/cni/multus/certs/multus-client-current.pem" into cert/key pair: tls: failed to find any PEM data in certificate input
      2024-03-03T12:23:37Z [error] error getting perNodeClient: failed to initialize the certificate manager: could not convert data from "/etc/cni/multus/certs/multus-client-current.pem" into cert/key pair: tls: failed to find any PEM data in certificate input
      2024-03-03T12:23:37Z [panic] failed start the multus thick-plugin listener: failed to create the server: error getting perNodeClient: failed to initialize the certificate manager: could not convert data from "/etc/cni/multus/certs/multus-client-current.pem" into cert/key pair: tls: failed to find any PEM data in certificate input
      2024-03-03T12:23:37Z [panic] ========= Stack trace output ========
      2024-03-03T12:23:37Z [panic] Multus Panic
      2024-03-03T12:23:37Z [panic] ========= Stack trace output end ========

       

      3. POD always stucks in CrashloopBackoff state
          

      Actual results:

      POD always stuck in crashloopbackoff state eventhough restarting multiple time
      Refer KCS [1] for more details
      [1] https://access.redhat.com/solutions/7057387    

      Expected results:

      It should remove the corrupted certificate from link and create the fresh one. So pod can be started.    

      Additional info:

       Similar problem was there with ovnkube-node pod and it got fixed in 4.17 version refer bug [1] and respected PR [2] for your reference.
      [1] https://issues.redhat.com/browse/OCPBUGS-36195
      [2] https://github.com/ovn-kubernetes/ovn-kubernetes/pull/4504

       

              sdn-team-bot sdn-team bot
              rhn-support-klakhwar Ketan Lakhwara
              None
              None
              Ying Wang Ying Wang
              None
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

                Created:
                Updated: