Proposal: relax checking for CPU architecture on Apple M1 silicon (darwin/arm64)

[ahmetb]

I just switched to an Apple M1 Mac and a lot of the plugins (72 out of 184, which is 42%) are not installing because they're simply not distributing for darwin/arm64.

However, as a user I can override our OS/ARCH check by overriding it like KREW_ARCH=amd64 kubectl krew install [...]. These amd64 binaries execute just fine as Mac has a compatibility layer that works for these Go binaries out of the box. Assuming most of these plugins may never update, this excludes a lot plugins from the M1 users as the adoption of new Macs increase.

Some options:

1. Relax checking and allow darwin/amd64 to be installed on darwin/arm64 and hope eventually more plugins distribute for arm64 (but they might not do that switch because we relax this check and users might not complain to existing plugin authors).
   (This may actually cause issues if the binary has compatibility issues, such as compiled with an older Go runtime which does not work with M1 compat layer properly).
2. Document that users can do this override. It's a band-aid solution (see next 💩int) (Most users won't see the docs on this.)
3. Print a warning if user is darwin/arm64 and binary offers darwin/amd64 and teach users how to override. It's a hacky band-aid solution.
   (Problem with this is that I think they have to remember to do the same thing when they run "krew upgrade", and setting $KREW_ARCH while upgrading all plugins with that command will cause other plugins that distribute for arm64 to pick up amd64 versions, which is not ideal.)

All these options are far from ideal. Maybe we don't take any action and hope the users complain to plugin authors, but this puts some plugins that are no longer updated to get stuck at a bad place forever (e.g. tail plugin).

/kind proposal
/area platform/mac

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[ahmetb]

/lifecycle frozen

[Volatus]

@ahmetb If you could provide a list of the plugins that don't distribute darwin/arm64, that'd be great. I'd be ok doing PRs for those plugins to distribute arm64 with hopefully their next releases. (I personally don't use many plugins so I don't have such a list)

[ahmetb]

diff <(KREW_ARCH=amd64 kubectl krew search) <(KREW_ARCH=arm64 kubectl krew search)

Should show a list