Add a dev container feature to install kind

[craiglpeters]

What would you like to be added:
Development Containers, or dev containers, enable the configuration of remote development environments. A simple json formatted file instructs clients how to construct the container. Clients like VS Code and GitHub Codespaces then use the container to provide developers with a consistent development experience.

The dev container team maintains a feature that installs kubectl, helm, and minikube in the development environment, but there is not feature to install kind for Kubernetes community contributor use.

I propose that we create and distribute a feature for Kubernetes projects that installs kubectl and kind in any dev container. The dev container community supports this model https://github.com/devcontainers/spec/blob/main/proposals/devcontainer-features-distribution.md

Why is this needed:
A kubectl-kind feature will simplify the maintenance of any Kubernetes contributor project dev container configuration.

[craiglpeters]

I am happy to do the work to create the dev container feature

[BenTheElder]

I think I'm missing: What's the ask from KIND? 😅

[mpriscella]

This would be great! I've created a similar feature to make it easier for my team to install kind in their dev containers.

Prior to me creating that feature, my team and I used minikube by default since the kubectl, helm, and minikube feature that @craiglpeters mentioned was much easier to install across different dev containers. I believe most engineers working on a Kubernetes project would opt to use kind if it was a feature.

[craiglpeters]

@BenTheElder - @mpriscella addressed the user value.

The ask of the KIND community is to create and maintain the feature following this template so that all devs using dev containers can easily add kind to their configurations. I am happy to step up as a community member to create and maintain the feature. It needs to live in its own repo. I propose that the community create a new repo called /kubernetes-sigs/devcontainer-features where features for multiple tools used by the community could be maintained, kind first among them.

[BenTheElder]

I see.

We cannot create a repo ourselves, the proposal to create a repo has to be brought to a SIG and approved by the SIG

if we can stick multiple in a repo, is there a reason we can't put one next to https://github.com/devcontainers/features/tree/main/src/kubectl-helm-minikube ?

[craiglpeters]

The model the dev container community is promoting is for tools to publish and maintain their own features. I am happy to take this to a SIG to discuss. I'll bring this up with SIG Testing next week in person
cc: @dims

[BenTheElder]

I don't know if SIG Testing would be the right owner for a shared devcontainers repo, but also we met today, so the next meeting will be in two weeks.

EDIT: some of us will be at KubeCon but not all of the leads / chairs and we try to ensure decision making is tracked async.

I think we should probably unify the discussion with kubernetes/kubernetes#113019 which appears to be Contributor Experience.

[dims]

or SIG-arch @craiglpeters if necessary

[dims]

we had one repo already for something similar, we could repurpose/rename?

[craiglpeters]

we had one repo already for something similar, we could repurpose/rename?

Absolutely