Fixes a bug where startup probe workers terminate incorrectly for sidecar
containers with restartPolicy=Always when the pod has restartPolicy=Never,
causing main containers to remain stuck in Initializing state.
Changes:
- Add container-level restart policy check for init containers only
- Extract complex boolean logic to named variable for readability
- Refactor test helper to use existing newWorker() function
- Add comprehensive unit and e2e tests for both scenarios
This fixes the pod with restartable init containers to have a proper
phase after the pod sandbox re-creation.
Currently, the `runtime.PodStatus` cannot retrieve the active container
statuses, which are the container statuses associated with the current
pod sandbox. This adds the `ActiveContainerStatuses` to
`runtime.PodStatus`, allowing it to include the container statuses of
the current pod sandbox, and fixes the kubelet to correctly set the pod
Phase to `Pending` when no active regular containers are present.
The test for checking container restarts in a Pod with restartable-init-1
and regular-1 is flaky. Right now, when we check if restartable-init-1 has
restarted, we see if it hasn’t written the "Started" log after regular-1 has
written its "Started" log.
But even though the startup sequence starts with restartable-init-1 and then
regular-1, there’s no guarantee they’ll finish starting up in that order.
Sometimes regular-1 finishes first and writes its "Started" log before restartable-init-1.
1. restartable-init-1 Starting
2. regular-1 Starting
3. regular-1 Started
4. restartable-init-1 Started
In this test, the startup order doesn’t really matter; all we need to check is
if restartable-init-1 restarted. So I changed the test to simply look for
more than one "Starting" log in restartable-init-1's logs.
There were other places that used the same helper function DoesntStartAfter,
so replaced those as well and deleted the helper function.
* A pod with restartable init container that exits with
a non-zero code is marked as a pod succeeded phase
* A pod with restartable init containers that exits with
a non-zero code by prestop hook is marked as a pod succeeded phase
* A pod with regular container that exceeds its termination grace period
seconds is marked as a pod failed phase
* A pod with restartable init containers that exceeds its termination
grace period seconds is marked as a pod succeeded phase
* A pod with a regular container that exceeded its termination grace
period seconds by PreStop hook is marked as a pod failed phase
* A pod with restartable init containers that exceeds its termination
grace period seconds by PreStop hook is marked as a pod succeeded phase
Signed-off-by: Tsubasa Nagasawa <toversus2357@gmail.com>
This ensures that the restartable init containers receive a termination
signal even if there are any not-started restartable init containers, by
ignoring the not-running containers.
This changes the text registration so that tags for which the framework has a
dedicated API (features, feature gates, slow, serial, etc.) those APIs are
used.
Arbitrary, custom tags are still left in place for now.
