https://rancher.com/ logo
Join Slack
Powered by
This message was deleted.
# rancher-desktop
a
This message was deleted.
f
kubectl
in RD is actually 
kuberlr
, which will fetch a compatible version of 
kubectl
automatically based on the apiserver version. We only ship the amd64 version because there have been no upstream releases of 
kubectl
on arm64 for versions before 1.21.0, I think
q
hmm
Copy code
WARNING: This version information is deprecated and will be replaced with the output from kubectl version --short.  Use --output=yaml|json to get the full version.
Client Version: <http://version.Info|version.Info>{Major:"1", Minor:"24", GitVersion:"v1.24.1", GitCommit:"3ddd0f45aa91e2f30c70734b175631bec5b5825a", GitTreeState:"clean", BuildDate:"2022-05-24T12:26:19Z", GoVersion:"go1.18.2", Compiler:"gc", Platform:"darwin/amd64"}
Kustomize Version: v4.5.4
Server Version: <http://version.Info|version.Info>{Major:"1", Minor:"23", GitVersion:"v1.23.14-gke.401", GitCommit:"aafb848fb0f7414f744ec2835516352f9f2620bf", GitTreeState:"clean", BuildDate:"2022-11-28T16:13:06Z", GoVersion:"go1.17.13b7", Compiler:"gc", Platform:"linux/amd64"}
I'd expect to end up w/ a darwin/arm64e
f
That issue has the background.
q
(i'll get back to this, it's obviously frustrating, but i'm on a huddle)
f
Ok, thanks. Please file a bug against `kuberlr`; it needs to be updated to avoid the noise
q
f
Yes, but that will only work for k8s 1.21.0+ because there are no binaries for arm for the earlier releases
kuberlr
is just a shim; it fetches compatible versions of 
kubectl
from upstream.
So to use an arm version, we would have to build and compile a repo of older versions, and then make 
kuberlr
fallback to that repo if the version doesn't exist in official releases.
Doable, but not a priority, as the Rosetta versions work just fine.
q
How far back do you need and how much faith do you need in the build process?
I could probably do it. Although I suspect you'd be better served owning the artifacts.
f
Yes, if the bits are not provided by upstream, then they have to be built by SUSE
It would only have to be done once, for the older bits, but somebody will also have to provide the PR to 
kuberlr
to make use of a fallback location
q
There's no way upstream would do it. Their support policy only covers a couple of releases.
How far back do you need?
f
I don't understand what you are saying here. The whole point of the 
kuberlr
mechanism is to seamlessly provide backwards and forwards compatibility because upstream itself doesn't guarantee it.
Rancher Desktop supports k3s versions back to 1.16.7 IIRC. It is arguable that nobody will ever use them, but if we don't support them with 
kubectl
, then we need additional code in RD as well
q
https://endoflife.date/kubernetes says 1.23 and older are dead. So there's no way they'd accept a PR to build older clients
f
I know; that's why I said SUSE would have to build them and put them in a separate repo. But we would not want to publish versions for newer releases, so 
kuberlr
would have to try to fetch the bits from upstream, and if they don't exist there, try once more against the SUSE repo with the older releases. That's why I said it needs additional support in kuberlr as well
q
I can see about building 1.16.7 for myself and then write a demo patch for kubelr
f
It should be a relatively simple script to build all the old versions automatically (assuming it actually builds). If I can get a script, we can run it on a build machine and put in a publish-to-github part as well.
👍 1
I just hope that the old releases can be compiled with newer versions of Go, as the old Go versions that upstream used to compile e.g. 1.16.x are likely not able to produce the darwin-arm64 binaries we need.
q
Yeah, that'll be the first thing I'll check.
195 Views
Open in Slack
PreviousNext
Powered by