Skip to content

KEP-5307 Initial KEP for container restart policy #5308

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

yuanwang04
Copy link

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

@k8s-ci-robot k8s-ci-robot added the cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. label May 16, 2025
@k8s-ci-robot k8s-ci-robot added kind/kep Categorizes KEP tracking issues and PRs modifying the KEP directory sig/node Categorizes an issue or PR as relevant to SIG Node. labels May 16, 2025
@k8s-ci-robot
Copy link
Contributor

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 k8s-ci-robot added the needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. label May 16, 2025
@k8s-ci-robot
Copy link
Contributor

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.

@k8s-ci-robot k8s-ci-robot added the size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files. label May 16, 2025
we may need to implement as described here: https://github.com/kubernetes/enhancements/issues/3329#issuecomment-1571643421

```
restartPolicy: Never
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dchen1107 I remember you had a concern with having Never pod with the container inside it that has restart count increasing. How strong is this concern? Strong enough to iontroduce the restartPolicy: Custom?

@yuanwang04 yuanwang04 force-pushed the container-restart-policy branch from 6cb2b80 to 0cbfc18 Compare May 16, 2025 22:25
@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is NOT APPROVED

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

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

Needs approval from an approver in each of these files:

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

@kannon92
Copy link
Contributor

/ok-to-test

@k8s-ci-robot k8s-ci-robot added ok-to-test Indicates a non-member PR verified by an org member that is safe to test. and removed needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. labels May 18, 2025
@yuanwang04 yuanwang04 force-pushed the container-restart-policy branch from 0cbfc18 to 040ffef Compare May 19, 2025 21:45
- name: myapp1
# the default behavior is inherited from the Pod’s restartPolicy
restartPolicy: Custom
# pod-level API for specifying container restart rules
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This API is at the container level it seems.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, just mentioning it here since there are some discussion around whether we need to introduce another pod-level restart policy #5308 (comment)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A big concern is once we introduced pod-level restart policy, how to interact with job failure policy? Maybe not today.

The container restart will still follow the exponential backoff to avoid
excessive resource consumption due to restarts.

## Design Details
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How does this interact with PodFailurePolicy?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added discussion around Job's PodFailurePolicy. Basically, this shouldn't affect how Job handles pod failures. Job only checks container exit codes (for PodFailurePolicy) when the Pod finished (and restartPolicy=Never). However, if the container is restarted by the proposed container restart policy, the pod will still be Running, and Job controller will not kick in.

@yuanwang04 yuanwang04 force-pushed the container-restart-policy branch 4 times, most recently from dd2b1f7 to bee6cce Compare May 23, 2025 01:26
@yuanwang04 yuanwang04 force-pushed the container-restart-policy branch from bee6cce to 67df630 Compare May 23, 2025 01:36
containers:
- name: myapp1
# the default behavior is inherited from the Pod’s restartPolicy
restartPolicy: Custom
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would suggest to consider alternative names, maybe:

  • "RuleBased"
  • "Conditional"

I'm leaning to "RuleBased" to match the "restartRules" name.

# the default behavior is inherited from the Pod’s restartPolicy
restartPolicy: Custom
# pod-level API for specifying container restart rules
restartRules:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would suggest to propose the full API, similarly as here, and provide this yaml as an example.

know that this has succeeded?
-->

- Allow the Pod with the restartPolicy=Custom to keep restarting a container
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- Allow the Pod with the restartPolicy=Custom to keep restarting a container
- Introduce API which allows to keep restarting a container

I guess at this point we don't need to provide the shape of the API


#### Story 1

The Pod with two containers - one is the main container and one is the sidecar
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would suggest to orient the "Story" from the perspective of the Kubernetes users. For example, as an ML researcher I'm creating long-running AI/ML workloads. Pods in such workloads are unavoidable due to various reasons, but in many cases they are recoverable. I would like to be able to avoid re-scheduling the workload as this consumes signifficant amount of time, and only restart the failed container "in-place".

Feel free to rephrase as you see fit.

Comment on lines +292 to +293
may have containers restarted and have the restart count higher than 0. This may
also affect how Job `podFailurePolicy` interacts with pod failures.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, I think this approach is fully transparent to the Job controller, because the Job controller only matches Pods in terminal phase. It is mentioned here:

When matching a failed pod against Job pod failure policy, it is important that
the pod is actually in the terminal phase (`Failed`), to ensure their state is

This works with Job `podFailurePolicy` without any changes on Job API. Currently,
Job only checks for `podFailurePolicy` after the Pod has finished running.
Kubelet restarting the container of the Pod will not change the Pod's status.
This is the ideal improvement where the Job configured `podFailurePolicy`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suggest to avoid phrases like " ideal improvement", let's leave it to reviewers :)

Comment on lines +339 to +341
The proposal is to implement a simple API with the very limited set of
allowed values to [Container](https://github.com/kubernetes/kubernetes/blob/master/pkg/apis/core/types.go#L2528)
under k8s.io/apis/core. The shape of API is informed by some future improvements
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
The proposal is to implement a simple API with the very limited set of
allowed values to [Container](https://github.com/kubernetes/kubernetes/blob/master/pkg/apis/core/types.go#L2528)
under k8s.io/apis/core. The shape of API is informed by some future improvements
The proposal is to extend the Pod's [container API](https://github.com/kubernetes/kubernetes/blob/master/pkg/apis/core/types.go#L2528) to allow to restarting containers based on
the container's end state, e.g. exit code.

I would suggest to avoid using adjective like "simple API", or "very limited set". Let's leave it to the readers / reviewers to assess.

Comment on lines +342 to +343
we may need to implement as described here:
https://github.com/kubernetes/enhancements/issues/3329#issuecomment-1571643421
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, this reference is slightly different that the current proposal. One difference is that the reference assumes "OnFailure". Instead of design details I would propose to move it to the Notes and Caveats section.

# The following PRR answers are required at alpha release
# List the feature gate name and the components for which it must be enabled
feature-gates:
- name: MyFeature
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ContainerRestartPolicy ?


# The following PRR answers are required at beta release
metrics:
- my_feature_metric
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cleanup. This is alpha, so IIUC no need for metric yet.

@mimowo
Copy link
Contributor

mimowo commented May 28, 2025

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. kind/kep Categorizes KEP tracking issues and PRs modifying the KEP directory ok-to-test Indicates a non-member PR verified by an org member that is safe to test. sig/node Categorizes an issue or PR as relevant to SIG Node. size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants