[RFC] Karpenter v1 API & Roadmap Proposal

[jonathan-innis]

Fixes #N/A

Description

This proposes the Karpenter stable v1 API and Roadmap. The Roadmap includes features and cleanup tasks that we need to complete before reaching v1.

How was this change tested?

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: jonathan-innis

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 [jonathan-innis]

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

[coveralls]

Pull Request Test Coverage Report for Build 10154303822

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• 2 unchanged lines in 1 file lost coverage.
• Overall coverage increased (+0.02%) to 78.128%

---

Files with Coverage Reduction	New Missed Lines	%
pkg/controllers/node/termination/controller.go	2	62.4%

Totals
Change from base Build 10153606152:	0.02%
Covered Lines:	8855
Relevant Lines:	11334

---

💛 - Coveralls

[Bryce-Soghigian]

Great work on this proposal sir!

Documentation: Does it make sense to make the azure + aws documentation unification effort happen alongside v1?

[Bryce-Soghigian]

Musing for v1:

E2E Testing for Core: Would there be an interest in testing core via e2es with kwok? There are some bits of functionality that change a lot of behavior in the v1 proposal like the ConsolidateAfter for the WhenUnderutilized consolidation policy. Would it be something we want to take on to have some of the e2e tests go from providers to also being included in core? We should take some additional testing steps for ensuring stability in core releases since we are moving to v1.

We still should run and develop e2es for our providers, but some of the functionality like consolidation is driven by core, mostly. Given our providers are both on the latest version of core so you can bump the version with tags to test things there as well. But having some e2es gate consolidation and scheduling etc would be useful for gating code.

We can even write them to run on multiple managed k8s services (AKS, EKS) with kwok as the cloud provider in multiple clouds(AWS, Azure)? I haven't played enough with kwok to see if something like that would work, but supposedly we could, right?

[sftim]

If we want to announce v1, the Kubernetes blog team can help with that.

[jonathan-innis]

E2E Testing for Core: Would there be an interest in testing core via e2es with kwok

I didn't want to directly couple it to v1 (because I don't think I view it as a blocking change) but there's a lot of contribution work that's happening between some folks on the AWS side and @njtran to start getting more extensive testing and benchmarking with Kwok. I can imagine that this work is going to happen in parallel with v1 but I don't personally want to block on it since it's going to be a long-poll to move over a lot of the testing that's currently sitting in the providers into the upstream codebase.

[jonathan-innis]

Does it make sense to make the azure + aws documentation unification effort happen alongside v1

This another one that has unknown timelines in my mind and I don't think has any direct impact to users if it comes after v1 (at least from a breaking change perspective). I'd rather just keep working on this effort and not view it as a blocking action for the v1 release.

[github-actions]

This PR has been inactive for 14 days. StaleBot will close this stale PR after 14 more days of inactivity.

[jmdeal]

/remove-lifecycle stale

[github-actions]

This PR has been inactive for 14 days. StaleBot will close this stale PR after 14 more days of inactivity.

[engedaam]

Just some small nits, and questions

[engedaam]

Small nits

[engedaam]

/lgtm