KEP-5307 Initial KEP for container restart exceptions

[yuanwang04]

• One-line PR description: Initial KEP for container restart exceptions

• Issue link: Container restart rules to customize the pod restart policy #5307

• Other comments: Discussion link https://docs.google.com/document/d/13fQu343OBEM2ICHLXfWHrApmzskd4nY3xWI27EbMJyI/edit?tab=t.0
• Future improvement direction: Discussion link https://docs.google.com/document/d/1UmJHJzdmMA1hWwkoP1f3rG9nS0oZ2cRcOx8rO8MsExA/edit?resourcekey=0-OuKspBji_1KJlj2JbnZkgQ&tab=t.0#heading=h.e2gx4umk9f64

[k8s-ci-robot]

Welcome @yuanwang04!

It looks like this is your first PR to kubernetes/enhancements 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes/enhancements has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

[k8s-ci-robot]

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

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.

[kannon92]

/ok-to-test

[mimowo]

@yuanwang04 thank you for the work, I like this proposal, AFAIK this approach is fully compatible with the Job's podFailurePolicy (at least if I'm not missing something), because when Pod's restartPolicy: Never, then Job's podFailurePolicy only analyzes pods which reach the "Failed" phase. Here, the pods avoid reaching the failed phase. Once they reach, they will be matched against podFailurePolicy which may decide to recreate the entire pod.

[thockin]

Capturing discussion:

What I WANT is a design that ties pod restartPolicy, container restartPolicy, and this new idea of rules together into a coherent story. If we end up in a place where restartPolicy=Never but the container restarts anyway, I am going to be grumpy.

We talked through options which add a new value to RestartPolicy, but given that RestartPolicy a) doesn't say "clients must handle unknown values" and b) overloads the meaning to include "this is a sidecar", I think we simply CAN'T add a new enum value. So I accept that I am going to be grumpy.

I think we CAN get to a place where container restartPolicy is less restricted, since any policy can be implemented in terms of rules. At least we can get rid of "this can only be set in initcontainers and only to Always".

Is it worth adding something to status to represent the result of these multiple fields, so we can encourage clients to infer less?

[thockin]

API LGTM overall - all my comments are minor and this doesn't have to be final API
/approve

[thockin]

@haircommander we can lament our past mistakes, but we can't always fix them. I grilled these guys for hours this week and the conclusion is that none of us can find a way that is "safe enough". :(

[thockin]

Should we consider adding something to status which is less layered?

[wojtek-t]

/approve PRR

[mrunalp]

/approve
/hold
(if Dawn wants to make a pass)

[dchen1107]

/lgtm
/approve

I remain some concerns, but those concerns shouldn't block we move forward this alpha feature.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: dchen1107, mrunalp, thockin, wojtek-t, yuanwang04

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:

• keps/prod-readiness/OWNERS [wojtek-t]
• keps/sig-node/OWNERS [dchen1107,mrunalp]

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

[SergeyKanzhelev]

/unhold