Support Apple Silicon

[mattfarina]

Eventually, we will want to support RD on Apple Silicon. This will likely take a little time and tools are still being ported and our dependencies are being ported. But, this is the top level issue to handle support of that.

[mook-as]

Some notes (for a M1-native build; I have not yet looked at cross-compiling)

• NodeJS v16 is required for darwin-arm64.
• That means we need to upgrade node-sass to v6 for Node 16 support.
• We will need to bump electron and/or electron-builder for arm64 support (haven't figured out the versions yet).

[yeahdongcn]

By replacing node-sass with sass, I could run app natively on my m1 mbp. Then the app failed with an error starting VM.

[jandubois]

@yeahdongcn The VM will not start on m1 because hyperkit only works on Intel. We are going to switch to a qemu based backend in the next release, which does potentially work on m1, but there are additional packaging/distribution problems that will need to be resolved as well, which will take some additional time.

So while we don't have a timeline yet, we are definitively working towards having M1 support.

[yeahdongcn]

@yeahdongcn The VM will not start on m1 because hyperkit only works on Intel. We are going to switch to a qemu based backend in the next release, which does potentially work on m1, but there are additional packaging/distribution problems that will need to be resolved as well, which will take some additional time.

So while we don't have a timeline yet, we are definitively working towards having M1 support.

Cool. So the whole approach is pretty much like Docker Desktop on macOS, right?

[jandubois]

Cool. So the whole approach is pretty much like Docker Desktop on macOS, right?

It is similar, but the emphasis is on running kubernetes, not on containers themselves. E.g. it is very simple to switch kubernetes versions with Rancher Desktop while Docker Desktop supports just a single version that you cannot choose.

Also, unlike Docker Desktop, Rancher Desktop is fully open source...

[aemadrid]

Any update on M1 support?

[jandubois]

Any update on M1 support?

Unfortunately it has been delayed; we have prioritized support for running containers directly via nerdctl (or in the future docker-cli), which has pushed out the work on M1 support. It is still very much on the roadmap, but I can't provide a timeline.

[aemadrid]

Any update on M1 support?

Unfortunately it has been delayed; we have prioritized support for running containers directly via nerdctl (or in the future docker-cli), which has pushed out the work on M1 support. It is still very much on the roadmap, but I can't provide a timeline.

Thanks for the update.

[painhardcore]

It's always sad to see something like this.

@jandubois I suggest adding a check in the installer or somewhere in the application startup process if this is architecture isn't supported to not waste time grinding Github issues.
Even mentioning this thing in the release text will impact future users i.e.

This is a feature release of Rancher Desktop, an open source desktop application to bring Kubernetes and container management to Mac(only amd64), Windows, and Linux. The release contains some feature changes along with various bug fixes.

[davidwinter]

Is there any update on this? I've installed lima via Homebrew, which has a patched version of Qemu that works on ARM based macOS. Appreciate there may still be other things within Rancher that need to be changed in order to work?

Otherwise, is there a way to specify Rancher to use the Homebrew version of lima instead of the one that is bundled?

[tcbtcb]

Hard agree that the release notes should specify Intel Mac only, just to save some time (that's how I wound up here). I'll take a look at see if I can open a PR to that effect, but if someone wants to to point me to where release notes are generated that would speed things up.

[jandubois]

Just a quick update that I managed to get an initial version of Rancher Desktop on M1 working yesterday: #933

It is not merged yet, and for now will require Rosetta for running the GUI parts, but lima and qemu will run in native aarch64 mode. So I'm optimistic that this will still make it into the next release (there probably won't be enough time to move the GUI to native mode, but it doesn't really matter, as it isn't performance critical, so it can be done later).

[aemadrid]

Any news @jandubois ? Impatiently waiting...

[jandubois]

See comment above: PR #933 is basically working now, creating an M1 build as part of CI (once it is merged). The UI code will run using Rosetta, and kubectl will as well because there are no official kubectl binaries for M1 before k8s 1.21.0. Neither one is performance-critical, so should be fine.

This will be part of the next release, whenever it is ready. I can't give you a date, but it should still be before Christmas.

You can build it yourself from source, but be aware that things are under construction 🚧 , so wear your 👷.

[aemadrid]

thx @jandubois, was hoping for a release date since I don't feel brave enough to build it myself. will keep an eye on releases! BTW, A release with this feature added alone is worth it!

[jandubois]

The big feature of the 0.7.0 release will be support for running on docker engine instead of containerd (user-selectable), and when you run on dockerd you can use the docker cli. There are various smaller changes as well.

This is an open source project, and you can see the project board, filtered for the 0.7.0 milestone at https://github.com/rancher-sandbox/rancher-desktop/projects/1?card_filter_query=milestone%3Av0.7.0

Not everthing will make sense without further context, but you should be able to see when feature work will be done, hopefully in the near future. We do have a long list of open bugs though, and want to address many of them before the release as well, but I have a feeling that we will need to cut scope and postpone some to the following release.

[armenr]

@jandubois - Looks like that PR you mentioned might be merged.

If I wanted to play/experiment with a development/nightly build, which of the builds would be a good one to grab and try out from here (https://github.com/rancher-sandbox/rancher-desktop/actions/workflows/package.yaml?query=branch%3Amain)?

[armenr]

@aemadrid - Much like you, I was too afraid/tired/busy paying down tech debt to find time for building the code myself.

Based on what @jandubois shared about #933 being merged, I grabbed this build (the most recent build of main), and it appears to work, so far!

You can download the one with aarch64 in the name:
https://github.com/rancher-sandbox/rancher-desktop/actions/runs/1509213190

I'm going to play with configuration (containerd/nerdctl VS docker/k3d), and report back (or open a new issue).

With that said, it looks like the latest nightly build works on both my Macbook Pro M1 Max & my wife's Macbook Pro M1.

[jandubois]

With that said, it looks like the latest nightly build works on both my Macbook Pro M1 Max & my wife's Macbook Pro M1.

Awesome, thanks for letting us know!

There is still an open PR about updater support, so that you can update the 0.7.0 release to the next one from within the app, and some work regarding properly signing the bits (which we don't do during CI builds anyways, because the CI machines don't have access to the signing keys).

But otherwise the Intel and M1 versions should be functionally identical now.

Please report any issues you run into as soon as possible, so we might still get a chance to look into them before the next release!

[armenr]

@jandubois - thank you!

Just as you stated, the package comes unsigned, and the updater seems to be a bit unhappy, but otherwise...so far, so good.

I was wondering one thing - if/when another update is released, and I wanted to completely nuke the previous installation (everything...settings, residual files, directories, etc...), how would I go about ensuring that I've properly excised any previous installation?

Thanks again for all your incredible work! :)

[aemadrid]

@armenr that works great, thanks! giving it a try right now.

[jandubois]

if/when another update is released, and I wanted to completely nuke the previous installation (everything...settings, residual files, directories, etc...), how would I go about ensuring that I've properly excised any previous installation?

I thought I had filed an issue to include a script for this, but can't find it right now. It will depend on the platform, but on macOS you should remove these directories:

/Applications/Rancher Desktop.app
~/Library/Caches/rancher-desktop
~/Library/Logs/rancher-desktop
~/Library/Preferences/rancher-desktop
~/Library/Application Support/Caches/rancher-desktop-updater
~/Library/Application Support/rancher-desktop

The following locations will be owned by root, so you'll need sudo to remove them:

/etc/sudoers.d/rancher-desktop-lima
/opt/rancher-desktop

You may want to keep ~/Library/Caches/rancher-desktop around, unless you really are concerned the data is corrupted; it just includes the various versions of k3s with their associated image tarballs, that you have ever installed before. So keeping those may save you a bit of download time/bandwidth, in case that is a concern for you.

[gsharma-jiggzy]

Great job,
Just stumbled on this one from google, works with my M1 Max had to use sudo chown $USER /usr/local/bin to get it install the tools.

[jandubois]

Apple M1 support is available in the 0.7.0 release.

[aemadrid]

super cool

[yuchanns]

Apple M1 support is available in the 0.7.0 release.

I manually updated my app from 0.7.0-beta to this version (replace /Applications/Rancher\ Desktop.app). It stuck on Waiting for Kubernetes API... forever. Any ideas? I don't want to destroy data. If I have to fully reinstall this app, what should I do to keep the backup?

---

update:
I check the k3s.log and got invalid node ip, unable to get global unicast ip from interface name: can't find ip for interface rd0.
I think this might be relavent to #1111 but on mac m1.

[jandubois]

@yuchanns Let's figure out why it is stuck. For that we may need to look at the log files.

But first check another issue: In 0.7.0 we create a bridged interface so that the VM has an externally routable IP address. It is currently hard-coded to use the host interface en0 to create the bridge. This is normally the Ethernet adapter. If the en0 adapter is not connected to a local network (with a DHCP server), then the bridge interface will not be created and Kubernetes will not start.

If this is your problem, then there is a manual workaround: first determine the active network interface, e.g. en1 (which is often the Wi-Fi interface). Edit the file ~/Library/Application\ Support/rancher-desktop/lima/_config/networks.yaml and change the interface from en0 to en1:

networks:
  bridged:
    mode: bridged
    interface: en1

(there are many more settings in the file, which I left out here for clarity)

Then stop and restart Rancher Desktop and see if this fixes your problem.

We have #1125 open to fix this problem automatically in the future.

If this does not fix your problem, please open a new more specific Github issue instead of adding more comments to an already closed issue that is just broadly about M1 support.

[yuchanns]

@yuchanns Let's figure out why it is stuck. For that we may need to look at the log files.

But first check another issue: In 0.7.0 we create a bridged interface so that the VM has an externally routable IP address. It is currently hard-coded to use the host interface en0 to create the bridge. This is normally the Ethernet adapter. If the en0 adapter is not connected to a local network (with a DHCP server), then the bridge interface will not be created and Kubernetes will not start.

If this is your problem, then there is a manual workaround: first determine the active network interface, e.g. en1 (which is often the Wi-Fi interface). Edit the file ~/Library/Application\ Support/rancher-desktop/lima/_config/networks.yaml and change the interface from en0 to en1:

networks:
  bridged:
    mode: bridged
    interface: en1

(there are many more settings in the file, which I left out here for clarity)

Then stop and restart Rancher Desktop and see if this fixes your problem.

We have #1125 open to fix this problem automatically in the future.

If this does not fix your problem, please open a new more specific Github issue instead of adding more comments to an already closed issue that is just broadly about M1 support.

not work and I opend #1129 1129