<p>I installed Meshery with Helm.</p>
<p>All pods are ok except the Cilium</p>
<pre><code>meshery-app-mesh-7d8cb57c85-cfk7j                   1/1     Running            0                63m
meshery-cilium-69b4f7d6c5-t9w55                     0/1     CrashLoopBackOff   16 (3m16s ago)   63m
meshery-consul-67669c97cc-hxvlz                     1/1     Running            0                64m
meshery-istio-687c7ff5bc-bn8mq                      1/1     Running            0                63m
meshery-kuma-66f947b988-887hm                       1/1     Running            0                63m
meshery-linkerd-854975dcb9-rsgtl                    1/1     Running            0                63m
meshery-nginx-sm-55675f57b5-xfpgz                   1/1     Running            0                63m
</code></pre>
<p>Logs show</p>
<pre><code>level=info msg=&quot;Registering workloads with Meshery Server for version v1.14.0-snapshot.4&quot; app=cilium-adapter
panic: interface conversion: error is *fs.PathError, not *errors.Error

goroutine 42 [running]:
github.com/layer5io/meshkit/errors.GetCode({0x278e020?, 0xc0004f7e30?})
</code></pre>
<p>I checked events also</p>
<pre><code>kubectl get events --field-selector involvedObject.name=meshery-cilium-69b4f7d6c5-t9w55
LAST SEEN   TYPE      REASON    OBJECT                                MESSAGE
17m         Normal    Pulling   pod/meshery-cilium-69b4f7d6c5-t9w55   Pulling image &quot;layer5/meshery-cilium:stable-latest&quot;
2m44s       Warning   BackOff   pod/meshery-cilium-69b4f7d6c5-t9w55   Back-off restarting failed container meshery-cilium in pod meshery-cilium-69b4f7d6c5-t9w55_default(d7ccd0e8-27e5-4f40-89bc-f8a6dc8fa25a)
</code></pre>
<p>I am adding logs from troubled pod
Events:</p>
<pre><code>  Type     Reason           Age                    From     Message
  ----     ------           ----                   ----     -------
  Normal   Pulling          4h25m (x55 over 8h)    kubelet  Pulling image &quot;layer5/meshery-cilium:stable-latest&quot;
  Warning  BackOff          3h45m (x1340 over 8h)  kubelet  Back-off restarting failed container meshery-cilium in pod meshery-cilium-69b4f7d6c5-t9w55_default(d7ccd0e8-27e5-4f40-89bc-f8a6dc8fa25a)
  Warning  FailedMount      21m (x6 over 21m)      kubelet  MountVolume.SetUp failed for volume &quot;kube-api-access-tcdml&quot; : object &quot;default&quot;/&quot;kube-root-ca.crt&quot; not registered
  Warning  NetworkNotReady  20m (x19 over 21m)     kubelet  network is not ready: container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized
  Warning  BackOff          72s (x82 over 19m)     kubelet  Back-off restarting failed container meshery-cilium in pod meshery-cilium-69b4f7d6c5-t9w55_default(d7ccd0e8-27e5-4f40-89bc-f8a6dc8fa25a)
</code></pre>
<p>The Nginx pod shows network problems</p>
<pre><code>Events:
  Type     Reason           Age                 From             Message
  ----     ------           ----                ----             -------
  Warning  NodeNotReady     22m                 node-controller  Node is not ready
  Warning  NetworkNotReady  22m (x18 over 23m)  kubelet          network is not ready: container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized
  Warning  FailedMount      22m (x7 over 23m)   kubelet          MountVolume.SetUp failed for volume &quot;kube-api-access-lscv2&quot; : object &quot;default&quot;/&quot;kube-root-ca.crt&quot; not registered
</code></pre>
<p>How to fix this issue?</p>

Richard Rublev
<p>As per this <a href="https://www.blinkops.com/blog/troubleshooting-the-crashloopbackoff-error" rel="nofollow noreferrer">Blog</a> by Patrick Londa, your cilium Pod is getting <code>CrashLoopBack off</code> error due to the <code>&quot;Back-off restarting failed container&quot;</code>, this means that your container suddenly terminated after Kubernetes started it.   <br><br>1. This occurs due to the temporary resource overload as a result of a spike in activity. The solution to fix this is to <strong>adjust periodSeconds or timeoutSeconds</strong> to give the application a longer window of time to respond.   <br><br>2. Sometimes this happens due to insufficient memory resources. You can increase the memory limit by <strong>changing the &quot;resources:limits&quot;</strong> in the Container's resource manifest as shown in the blog.   <br><br>Verify the above steps and let me know if this fixes the issue.<br></p>
