Add installation instructions for Scoop and Winget

[ste93cry]

Since kind is now installable via both Scoop and Winget, the Quick Start guide should mention the installation instructions for those package managers.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: ste93cry / name: Stefano Arlandini (ca9d450)

[k8s-ci-robot]

Welcome @ste93cry!

It looks like this is your first PR to kubernetes-sigs/kind 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes-sigs/kind has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

[k8s-ci-robot]

Hi @ste93cry. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[BenTheElder]

blocked on #3379
/hold

[ste93cry]

I understand that you may not want to maintain the Winget manifest, but I still think it's worth documenting at least the ability to install the package as is possible with other package managers. Tools like kubectl and minikube are already available in Winget, and now that kind is too, it doesn't sound too bad to let people know about it. I don't know who maintains the homebrew formula, but if it's community-driven I wonder why Winget should receive a different treatment just because it arrived late to the party 🤔 Regarding Scoop, as far as I understand the manifest is automatically updated, so it should always be up-to-date and no human intervention is needed.

[stmcginnis]

This should be done the same way as kubectl: https://github.com/microsoft/winget-pkgs/tree/master/manifests/k/Kubernetes/kubectl

Even though it would be "automated", there is still maintenance overhead. Nothing stays static, so it's inevitable that something would change or break and it would need attention to troubleshoot - in an area most of the maintainers are not familiar with - and identify what needs to be updated. This is best kept out of kind itself and managed by winget-pkgs.

[stmcginnis]

Oh, and look at that! https://github.com/microsoft/winget-pkgs/tree/master/manifests/k/Kubernetes/kind/0.20.0 :)

[ste93cry]

This is best kept out of kind itself and managed by winget-pkgs.

I understand the reasons you don't want to maintain the manifest, but this has nothing to do with mentioning in the documentation that the tool can be installed with these package managers, right?

[stmcginnis]

I understand the reasons you don't want to maintain the manifest, but this has nothing to do with mentioning in the documentation that the tool can be installed with these package managers, right?

I see what you're saying, and I guess I agree. We don't maintain the brew or chocolatey packages, but we do have them listed in the documentation as possible ways to install kind. It almost feels like we should note a caveat there that the project has involvement in those packages and cannot vouch for their quality, but we've gone this long without it, so I don't see why these should be gated on doing something like that. If we even should.

So sorry for the long delay, but I do think this could be useful for someone to have in the docs.

/lgtm

[BenTheElder]

We don't maintain the brew or chocolatey packages, but we do have them listed in the documentation as possible ways to install kind.

I'm in touch with the brew maintainers (heck somewhere there's a photo of me sitting with christoph at KubeCon while we developed the package on his laptop) and keep an eye on this one.

It's true that the chocolatey package has this issue.

We should split these into vetted and use at your own risk.
Making a mistake in the past doesn't mean we should repeat it.

KIND is used to manage privileged containers and must run with escalated permissions, kind itself is bad enough, but telling users to install packages we don't control is even worse and should be treated carefully.

[BenTheElder]

Let's add these, but follow-up by splitting first and third party and clarifying (more detailed proposal at #3644)

Sorry for the delay. There's a LOT going on and there hasn't been much user demand for these versus the concerns and ongoing bug triage etc....

/lgtm
/approve

#3644 to follow up on all third party install options.

[BenTheElder]

oops, I meant to merge this already but missed the hold-lift, we'll have to rebase it after #3660 merged, I meant for that PR to rebase this work instead of the other way around

https://kind.sigs.k8s.io/docs/user/quick-start/#installing-with-a-package-manager

[ste93cry]

Rebased 👍

[BenTheElder]

/lgtm
/approve
/hold cancel

thanks!

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: BenTheElder, ste93cry

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [BenTheElder]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[BenTheElder]

/ok-to-test