chore: remove all references to linking

[rakechill]

Description
With the API update from machine -> nodeclaim, the karpenter provider removed the linking controller completely.

How was this change tested?

• gc tests still behaving correctly
• e2e suites (running in the PR)
• scale up/scale down works correctly

Does this change impact docs?

• Yes, PR includes docs updates
• Yes, issue opened: #
• No

Release Note

[rakechill]

/test

[Bryce-Soghigian]

https://github.com/kubernetes-sigs/karpenter/blob/main/pkg/controllers/nodeclaim/lifecycle/launch.go#L59 looks like we dont support launchign nodeclaims with linking anymore in karpenter core so I am all for this change.

Do you know what version of karpneter core it was removed? Was it v0.33 or v0.32?

[rakechill]

https://github.com/kubernetes-sigs/karpenter/blob/main/pkg/controllers/nodeclaim/lifecycle/launch.go#L59 looks like we dont support launchign nodeclaims with linking anymore in karpenter core so I am all for this change.

Do you know what version of karpenter core it was removed? Was it v0.33 or v0.32?

@Bryce-Soghigian I'm looping back to this now + rebased from main. I feel fairly confident we don't need it. However, I still can't find the exact reason why the karpenter aws provider decided to remove this. They claimed it had to do w/ removing machineutils in karpenter-core, but I'm not entirely clear why that would have made linking unnecessary.

The two relevant PRs seem to be:

• chore: remove v1alpha5 utils kubernetes-sigs/karpenter#658
• chore: remove v1alpha5 from lifecycle/consistency/garbage collection kubernetes-sigs/karpenter#648

And they were both in v0.33.0

[rakechill]

/test

[Bryce-Soghigian]

https://github.com/kubernetes-sigs/karpenter/blob/main/pkg/controllers/nodeclaim/lifecycle/launch.go#L59 looks like we dont support launchign nodeclaims with linking anymore in karpenter core so I am all for this change.
Do you know what version of karpenter core it was removed? Was it v0.33 or v0.32?

@Bryce-Soghigian I'm looping back to this now + rebased from main. I feel fairly confident we don't need it. However, I still can't find the exact reason why the karpenter aws provider decided to remove this. They claimed it had to do w/ removing machineutils in karpenter-core, but I'm not entirely clear why that would have made linking unnecessary.

The two relevant PRs seem to be:

• chore: remove v1alpha5 utils kubernetes-sigs/karpenter#658
• chore: remove v1alpha5 from lifecycle/consistency/garbage collection kubernetes-sigs/karpenter#648

And they were both in v0.33.0

@jackfrancis can you provide any insight here before we merge this?

[tallaxes]

The way I see it, linking is/was about Karpenter adopting instances that it did not provision, potentially useful for migrating existing clusters to Karpenter (or maybe incompatible Karpenter versions). Removing this means either that these scenarios are considered less important, or they (possibly in some cases) did not actually work well, or the implementation itself was lacking (e.g. the separation between cloud provider and core responsibilities, including annotations being used, was not clean enough) - and could be revisited in the future. (Asked for confirmation / further insight on karpenter-dev)

In any case, lets remove it and revisit later, if needed, together with required core changes.

[jonathan-innis]

the karpenter provider removed the linking controller completely

We dropped this from our controllers since this logic was never intended to be added in as a mechanism for Karpenter to re-own instances that it didn't launch. This mechanism was put into place when Machines were introduced in v1alpha5 (now NodeClaims in v1beta1) and was intended to take nodes that were launched and owned by Karpenter, hydrate a Machine resource on the cluster for that Node, mark that that Machine shouldn't be launched but should be discovered through the linked annotation and then resolve all of its data.

We didn't want the overhead of managing the complexity of this flow anymore (since there's some gating and coordination that has to happen to ensure that Machines aren't launched and you want to make sure that you don't mess with certain things on the node since they've already existed for a bit). It also makes reasoning about ordering more complex.

Dropping the linked behavior means that we can now say that NodeClaims are created before Nodes always and that a NodeClaim will always exist on the cluster for a Karpenter-launched node.

[jonathan-innis]

I think if we want to talk about Karpenter re-owning existing nodes, we can start a design discussion about this or open an issue on kubernetes-sigs/karpenter to talk about the ramifications of doing this, but the stance up to this point has been to just ask users to deprovision old instances and let Karpenter launch new ones, rather than having to reason about the edge behavior that might happen if we tag and re-own an instance that was launched by a different system.