Adding the "do-not-merge/release-note-label-needed" label because no release-note block was detected, please follow our release note process to remove it.

This issue is currently awaiting triage.

If a SIG or subproject 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.

Hi @llhhbc. 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.

/ok-to-test

I think this is an interesting feature but not sure this implementation is the right path forward.

If we wanted to control BackOffzlimit for static pods I wonder if this should be an API in the pod spec..

I would consider a KEP for this as I don’t think annotations would be a good path forward.

I think this is an interesting feature but not sure this implementation is the right path forward.

If we wanted to control BackOffzlimit for static pods I wonder if this should be an API in the pod spec..

I would consider a KEP for this as I don’t think annotations would be a good path forward.

@kannon92 How is this planned? Is this field reflected in the pod spec? Or in priorityClassName?

Pod spec but I think you’d want to bring this up to sig node as API changes usually require some buyin

@kannon92 How should I submit?

I’d suggest taking this PR to sig-node meeting and see what the consensus is.

@kannon92 I don't know how to proceed with this? I should not have relevant permissions, can you initiate a relevant application?

@llhhbc please, present this on SIG-Node meeting as @kannon92 suggested, thanks.

/hold

@llhhbc: Reopened this PR.

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: llhhbc
Once this PR has been reviewed and has the lgtm label, please assign tallclair for approval. For more information see the Code Review Process.

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

@bart0sh Sorry, I don't know how to present this on [SIG-Node meeting]

@bart0sh Sorry, I don't know how to present this on [SIG-Node meeting]

You just need to call into the meeting and explain your idea there. Updating agenda would be nice to do as well.

@bart0sh I don't have the corresponding permissions. Can you help initiate the application? Thanks

@bart0sh I don't have the corresponding permissions. Can you help initiate the application? Thanks

Sure, I can update meeting agenda for the next meeting on your behalf. Can you show me what to put there? Your name and a topic should be enough. Is next meeting(next Tuesday 10 AM PT) ok for you?

@llhhbc BTW, rebasing your changes would make the PR look better.

@bart0sh Thanks, I have rebase the commit.
I'm sorry that my English ability may not allow me to attend the meeting and explain directly, but maybe I can go to the meeting and listen in to learn more. I'll tell you the detailed description of the problem: kubelet does not distinguish the restart strategy separately for static, because the pods running statically are generally more important pods, such as apiserver, etcd, etc. The restart interval of such containers will seriously affect the fault recovery time of the entire platform. Because the recovery of all pods depends on the recovery of the apiserver. And I saw that the new version of k8s has added features.KubeletCrashLoopBackOffMax, but this is the startup parameter configuration of kubelet, which is too rough, because not all pods require such frequent restart intervals. Can the configuration be applied to the pod?
I am not free at the meeting time(Tuesday 10 AM PT), Because it was early morning.

PR needs rebase.

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and 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:

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

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

/close

@k8s-triage-robot: Closed this PR.

/reopen

@llhhbc: Reopened this PR.

Please note that we're already in Test Freeze for the release-1.33 branch. This means every merged PR will be automatically fast-forwarded via the periodic ci-fast-forward job to the release branch of the upcoming v1.33.0 release.

Fast forwards are scheduled to happen every 6 hours, whereas the most recent run was: Mon Apr 14 01:30:02 UTC 2025.

/remove-lifecycle rotten

The Kubernetes project currently lacks enough active 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 rotten
• Close this PR with /close
• Offer to help out with Issue Triage

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

/lifecycle rotten