Support Dev Containers / Github Codespaces

[Sharpz7]

Based on: https://github.com/craiglpeters/kubernetes-devcontainer

What type of PR is this?

/kind feature

What this PR does / why we need it:

This PR adds support for devcontainers. Right now, it will take a significant amount of time to build - but ideally I would want to also create an image that is built as part of this, maybe in its own repo, that could then be pulled to speed up build times.
Also a wider discussion on whether you would want to support devcontainers all over k8s should probably happen.

kubernetes/test-infra#30454
kubernetes/test-infra#30511 (comment)

Right now, I have added a custom golang install feature that can take advantage of .go-version being present, but maybe there is a more elegant solution we can use?
I tried this and it didn't work - my bet is the devcontainer is being created before the repo is present so the version cannot be found. This means we now have the version stated in two places... not ideal.

Which issue(s) this PR fixes:

Fixes #113019

Special notes for your reviewer:

Does this PR introduce a user-facing change?

Adds the code/configs to allow for users to use dev-containers when developing k8s. This brings support for GitHub Codespaces, EnvBuilder, the devcontainer-cli and more.

Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:

- [Usage]: https://github.com/features/codespaces
- [More Info]: https://containers.dev/

/kind feature
/assign @Sharpz7
/sig architecture
/sig contributor-experience

cc @craiglpeters

[k8s-ci-robot]

Hi @Sharpz7. Thanks for your PR.

I'm waiting for a kubernetes 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.

[mrbobbytables]

/ok-to-test

[mrbobbytables]

This PR replaces #120551 and addresses the feedback I left in #120551 (review) (adding an owners file)

I verified that it works and I was successfully able to build kubernetes.

/assign dims cblecker
/priority important-soon
/triage accepted

[mrbobbytables]

and I forgot to lgtm in my last comment 🤦

/lgtm

[k8s-ci-robot]

LGTM label has been added.

Git tree hash: 5a5e75f1eff9969fb9271d0d73c0f9715d7f2951

[cblecker]

Some questions before we move forward
/hold

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: Sharpz7
Once this PR has been reviewed and has the lgtm label, please ask for approval from cblecker. For more information see the Kubernetes Code Review Process.

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

Needs approval from an approver in each of these files:

• OWNERS

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

[Sharpz7]

@cblecker just a general catch-all for your points.

They are all valid, devcontainers is such a wide standard that anything is possible. But, I would argue that things like our own Docker Image, and building kubectl from source, slow down the build significantly. There is a trade-off here between speed, closeness to ground-truth, and number of files (and how many locations those files are in).

I think the idea is this would be the initial run, and then we would improve what we do overtime. For now, I think this is mostly okay - you can follow the guides easily.

[cblecker]

@Sharpz7 The tradeoff that I'm considering here is sustainability. I would rather us have something that is slow, but that keeps updated over time as opposed to something that is fast but needs regular maintenance to keep it up to date. I'm all for iterating over time to improve things, but I'd rather it be "hey this always works, but is slow.. maybe we can make it faster" rather than "hey this stopped working.. oh someone needs to go PR in a change to update an image/version/etc to make it useful again".

[Sharpz7]

Since we are optimising:

• I would like to try and not need the "local features", we should use scripts already in the repo (like with etcd for example).
• I want the go version to be found automatically, its still an env var we would have the manually bump.
• I am 50/50 on whether we build kubectl from source. I think it boils down to what would the average developer expect? I would lean towards and installed version of kubectl.

[cblecker]

Attempted to run this and it's failing. The build image is normally wrapped with a bunch of bash to ensure the right variables are passed in.

[craiglpeters]

Using kube-cross is as simple as pointing to the image in the container registry. The local features are not needed as kube-cross already has everything except pyyaml.

[Sharpz7]

I think using https://containers.dev/implementors/json_reference/#variables-in-devcontainerjson might be the way we can configure for the correct go version and Kubernetes version, but I am not sure.

Thoughts @craiglpeters ?

[k8s-triage-robot]

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

This bot triages 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 PR is closed

You can:

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

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

/lifecycle stale

[sftim]

Changelog suggestion

-Adds the code/configs to allow for users to use dev-containers when developing k8s. This brings support for GitHub Codespaces, EnvBuilder, the devcontainer-cli and more.
+Added support for using a [devcontainer](https://containers.dev/) when developing Kubernetes.

(Markdown works, and we can rely on people to click the link if they want to learn more).

[bells17]

Hello,

I've created a new PR with permission from @craiglpeters .
May I request a review for this PR?

#124584

https://kubernetes.slack.com/archives/C1TU9EB9S/p1714223550391479?thread_ts=1713701062.612009&cid=C1TU9EB9S