[KEP 3960]: graduate PodLifecycleSleepAction to beta

[AxeZhan]

What type of PR is this?

/kind feature

What this PR does / why we need it:

PodLifecycleSleepAction is planned to graduate to beta in 1.30.

Which issue(s) this PR fixes:

Fixes #

Special notes for your reviewer:

Does this PR introduce a user-facing change?

A new metric `lifecycle_handler_sleep_terminated_total` is added to record how many times LifecycleHandler sleep got unexpectedly terminated.

Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:

- [KEP]: https://github.com/kubernetes/enhancements/issues/3960

[kannon92]

Have you thought about how this feature interacts with sidecars?

[AxeZhan]

Have you thought about how this feature interacts with sidecars?

Hmm, nope. I don't see a difference?
In our company, we still use multi containers to do sidecar things, so I'm also not very familiar with sidecar containers.

[kannon92]

Have you thought about how this feature interacts with sidecars?

Hmm, nope. I don't see a difference? In our company, we still use multi containers to do sidecar things, so I'm also not very familiar with sidecar containers.

I'm talking about the SideCar KEP: https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/753-sidecar-containers/README.md

[AxeZhan]

I'm talking about the SideCar KEP

Yes, I'm aware of this.

Hmm, nope. I don't see a difference?

Just saying, I think this feature treats the sidecar containers and normal containers the same way, so I'm not sure what do you mean by interacts with sidecars.

[kannon92]

I'm talking about the SideCar KEP

Yes, I'm aware of this.

Hmm, nope. I don't see a difference?

Just saying, I think this feature treats the sidecar containers and normal containers the same way, so I'm not sure what do you mean by interacts with sidecars.

I was just thinking about some kind of test that makes sure that if someone using the PodLifecycleSleepAction with sidecar feature, do we know what the expected behavior is? I guess that restarting the container on init container and it should use this feature anyway.

[thockin]

Thanks!

/lgtm
/approve

[k8s-ci-robot]

LGTM label has been added.

Git tree hash: 1b6dffd6771850c7fa6f50c380fd253a453832ab

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: AxeZhan, thockin

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:

• pkg/api/OWNERS [thockin]
• pkg/features/OWNERS [thockin]
• pkg/kubelet/OWNERS [thockin]
• pkg/registry/core/pod/OWNERS [thockin]
• test/e2e/common/OWNERS [thockin]
• test/e2e/framework/OWNERS [thockin]

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

[AxeZhan]

I was just thinking about some kind of test that makes sure that if someone using the PodLifecycleSleepAction with sidecar feature, do we know what the expected behavior is? I guess that restarting the container on init container and it should use this feature anyway.

We already have many tests for other handlers(exec, http) here

kubernetes/test/e2e/common/node/lifecycle_hook.go

Line 258 in 1dce896

var _ = SIGDescribe(nodefeature.SidecarContainers, feature.SidecarContainers, "Restartable Init Container Lifecycle Hook", func() {

I can try adding some tests for sleepAction into it later, but I'm not sure how to test two features at same time now.

do we know what the expected behavior is?

The expected behavior should be equal to using exec handler in sidecar containers with command sleep x.

[kannon92]

/lgtm
/hold cancel

[k8s-ci-robot]

LGTM label has been added.

Git tree hash: fc1005696ef7ee94dd43fd23227f6e43edee2c03