karpenter support kruise DaemonSet

[wy0824]

Description

What problem are you trying to solve?
we use v0.32.10 karpenter in our cluster, and there are some daemonsets owned by kruise(enhanced daemonset). Karpenter dose not identify these pods, which leads to the empty workloads node can't be deprovision.
kruise refer: https://openkruise.io/docs/user-manuals/advanceddaemonset/
karpenter related codes: func IsOwnedByDaemonSet(pod *v1.Pod) bool {

How important is this feature to you?
deprovision empty nodes is an important function, and can save much cost.

• 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

just check the kind can solve this problem

[k8s-ci-robot]

This issue is currently awaiting triage.

If Karpenter contributors determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

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.

[njtran]

I'm wondering how common it is for users to create CRDs that wrap common first class APIs. Does this mean kruise is fully implementing all daemonset behavior themselves in Kubernetes? If not, how can we be sure that kruise daemonsets will work the same way as upstream daemonsets (e.g. guarantee of taints, guarantee of existence of pods on nodes, etc.)?

Effectively it sounds like your pods are mimicking upstream daemonsets, which I assume means adding tolerations for first-class upstream node taints. Since the pods tolerate those taints, we try to disrupt the pods, at which they reschedule, and the node is never empty. Is this right?

[wy0824]

Kruise is a Cloud Native Computing Foundation incubating project, it is widely used, and it also fully implementing all daemonset behavior, and enhances features on upstream daemonsets. My suggestion when checking if a node is empty can only check daemonset kind, not include the group and version, it can solve the compatible problem

[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