rancher-sandbox / rancher-desktop

Container Management and Kubernetes on the Desktop
https://rancherdesktop.io
Apache License 2.0
6.04k stars 285 forks source link

linkerd-cni requires copying `linkerd-cni` plugin from /opt/cni/bin/ to /usr/libexec/cni/ #6170

Open gunamata opened 11 months ago

gunamata commented 11 months ago

From Slack conversation:

Hi - we're trying to install linkerd-cni in Rancher Desktop/containerd 1.11.1 running on macOS 14.1.2. Linkerd check hangs on control plane pods are ready. Turns out that linkerd cni plugin, accordingly with linkerd install-cni deployment, installs the linkerd-cni plugin in /opt/cni/bin/ But when pods are started, the linkerd cni plugin is being expected to be in /usr/libexec/cni/ Simply copying sudo cp /opt/cni/bin/linkerd-cni /usr/libexec/cni/ resolves the problem; linkerd control plane starts and linkerd check passes with flying colors. It's unclear where the problem lies; it might be expected that other products would install cni plugins wherever they do, but Rancher Desktop will only look in /usr/libexec/cni/. This might not be Rancher Desktop issue at all, nor might it not be Linkerd issue - but they don't work together without that copy command above. Apologies if this is a known issue - kindly point me to a solution if it exists. Cheers! @Jan Dubois might be of interest to you.

jandubois commented 11 months ago

More comments captured from Slack:

Turns out, linkerd allows to control where the binary goes: linkerd install-cni --dest-cni-bin-dir /usr/libexec/cni/ will place the executable where Rancher Desktop expects it to be. While this resolves my immediate issue, it leaves some gaps: How does a new user, like myself, knows where plugin executables should go, without running into a problem first? What if the Rancher Desktop plugin location changes? Any automation and/instructions pointing to an old location will stop working

1 falls under "you don't know what you don't know" situation, understandably.

2 hopefully never happens, but things will always change.

With linkerd #2 becomes worse - if Rancher Desktop changes the plugin location - say to the common path, per @brandond comment - linkerd will stop working after upgrade that changes the location, which might take a few hours to troubleshoot. Given that linkerd provides a lot of very attractive features, many of which will be used by a project, it would be a disaster. I'm wondering if there any way to deal with such potential issues.

teosoft123 commented 11 months ago

Commenting for reference; I'm the person who ran into this issue. Fun to be first.