Enable Server Side Apply for Client Patch Calls

[jonathan-innis]

Description

What problem are you trying to solve?

Karpenter currently doesn't use Server Side Apply when making patch calls to the apiserver. This doesn't cause a ton of issues today since there aren't a ton of writers to the objects that we own (although the Node is a bit of an exception to this rule)

We should use Server Side Apply since then we can declare a set of managed fields that we own and ensure that only these fields are updated when we make a Patch call to the apiserver and no other updates are made to the object.

Server Side Apply Docs: https://kubernetes.io/docs/reference/using-api/server-side-apply/

How important is this feature to you?

It will prevent us from fighting and overwriting with other controllers that may also be trying to write different fields to the same object.

Related Issues

#660

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

[sadath-12]

/assign

[sadath-12]

Hi @jonathan-innis ,Tried looking at it I guess it considers our crd's as unstructured object . so we would have to make some more changes such as converting the crd resources into unstructured and also pulling dynamicclient and then applying them and since we have multiple controllers we really need to very cautions about the ownership which might be a bit prone to errors . One example I've found is https://github.com/pkbhowmick/k8s-server-side-apply/blob/master/main.go

[jonathan-innis]

I'd consider looking deeper into how controller-runtime directly handles this as well as look into how CAPI (Cluster API) does SSA. I believe they should have paths forward to enable us to do the same in Karpenter.

[k8s-triage-robot]

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

This bot triages un-triaged issues 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 issue is closed

You can:

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

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

/lifecycle stale

[k8s-triage-robot]

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

This bot triages un-triaged issues 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 issue is closed

You can:

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

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

/lifecycle rotten

[k8s-triage-robot]

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

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

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

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

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

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

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

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

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

/close not-planned

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-sigs/prow repository.

[jonathan-innis]

/reopen

[k8s-ci-robot]

@jonathan-innis: Reopened this issue.

In response to this:

/reopen

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-sigs/prow repository.

[jonathan-innis]

/triage accepted
/remove-lifecycle stale

[jonathan-innis]

/remove-lifecycle rotten