Kubernetes 1.24.2 separates terminal pods from terminating endpoints
The June patch repairs readiness reporting and endpoint publication during pod shutdown. A completed pod must not remain a Service destination merely because unready addresses are allowed.
Allowing an unready pod to appear in a Service does not make a completed pod a useful destination. Kubernetes 1.24.2 repairs several places where that distinction could become unclear during shutdown. The fixes connect kubelet's published pod status with the endpoint controllers that turn that status into network destinations.
The June 17 maintenance release includes changes to terminal pod filtering, readiness reporting during termination, and contradictory status conditions. These are related correctness problems across cooperating components. A single manifest can be valid while the state passed between those components still represents the wrong lifecycle stage.
I care about this kind of patch because reconciliation depends on the meaning of observed state. Repeatedly processing a completed pod cannot produce a sensible endpoint if the controller's inclusion rule treats completion as ordinary unreadiness. The rule itself has to express the lifecycle distinction.
Terminal and terminating describe different facts
The endpoint filtering backport introduces helpers that identify terminal pods. Its implementation defines terminal phases as Failed or Succeeded. A pod with a deletion timestamp is terminating, which describes a different condition.
That distinction matters because termination can include a period in which the pod still has running processes. Terminal phase describes completion. Endpoint logic may have reasons to represent a terminating pod, depending on configuration and supported conditions. A terminal pod has no corresponding reason to remain a destination for a running service.
The patch's shared filtering function checks terminal phase before considering the option to include terminating pods. It also rejects pods without an IP address. Only after those checks does it consider the deletion timestamp and the caller's inclusion choice.
This order makes the policy explicit. Permission to include a terminating pod does not override completion. The filter does not attempt to turn a terminal pod into a special category of unready but usable endpoint.
The release changelog's wording about terminal states contains an error, naming Unready alongside Succeeded. The implementation removes that ambiguity. Unready is not one of the two phase values tested by the helper. For understanding the behaviour, the code and its tests provide the precise definition.
Publication settings do not override completion
The same backport applies the shared filtering rule to Endpoints and EndpointSlices. In the Endpoints controller, the old path used separate checks and later logic involving restart policy. The new code filters a pod before adding its address to ready or not-ready subsets.
One important input is a Service's publishNotReadyAddresses setting. The test cases include a running pod that is not ready and a Service that permits publication of unready addresses. That case remains eligible. Failed and succeeded pods remain excluded even when the Service allows unready addresses.
Those cases make the compatibility requirement understandable. A Service may need discovery of a process before normal readiness criteria succeed. That requirement does not imply discovery of a process whose pod has completed. The setting changes readiness treatment within the lifecycle rules.
The tests also vary deletion timestamps. This avoids collapsing every shutdown-related state into one boolean. A running, deleting pod and a succeeded pod can have different endpoint treatment because the underlying lifecycle facts differ.
Kubelet must publish coherent status
Filtering at the endpoint controller is only part of the repair. The readiness-condition backport fixes a kubelet regression that could report a terminal phase together with a true ready condition. Those fields describe incompatible operational claims.
Consumers should not have to infer which of two contradictory fields the producer intended. Correcting kubelet's status makes the object a better shared input for every controller that reads it. The endpoint filter remains useful because its own inclusion policy should still be correct independently.
A separate probe-handling backport restores readiness publication during termination. Its release note identifies the behaviour as a regression dating to 1.22. A shutdown transition needs status updates while it happens, not only before it begins or after it finishes.
These changes address different failure points. Publishing coherent readiness fixes the producer. Applying terminal filtering fixes consumers that decide whether an address belongs in endpoint resources. Their combination gives the shutdown sequence a more consistent representation across the control plane.
Reconciliation also excludes deleting slices
Another backport in this release ignores EndpointSlices already marked for deletion during reconciliation. Here the lifecycle belongs to the endpoint resource itself. A slice being removed should not be treated as an ordinary object available for continued reconciliation.
My preference is to make these exclusions visible in shared lifecycle logic. It is easier to reason about endpoint publication when completion is checked once under an explicit definition, with tests covering exceptions such as publication of unready addresses.
The patch does not promise that all shutdown traffic is instantaneous or that every application drains connections correctly. Its concrete contribution is narrower. Kubelet reports readiness during termination without declaring a terminal pod ready, and endpoint controllers exclude completed pods even where unready address publication is permitted.