Skip to content
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.

Sign up for GitHub

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

Updated docs for EndpointSliceTerminatingCondition #38390

Closed
wants to merge 2 commits into from
Closed

Updated docs for EndpointSliceTerminatingCondition #38390

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
d59f901
Resolved Issue #38387 Stale docs
YashPimple Dec 10, 2022
14420f6
Updated docs for EndpointSliceTerminatingCondition
YashPimple Dec 21, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 6 additions & 6 deletions content/en/docs/concepts/services-networking/endpoint-slices.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -87,18 +87,18 @@ The three conditions are `ready`, `serving`, and `terminating`.

#### Ready

`ready` is a condition that maps to a Pod's `Ready` condition. A running Pod with the `Ready`
condition set to `True` should have this EndpointSlice condition also set to `true`. For
compatibility reasons, `ready` is NEVER `true` when a Pod is terminating. Consumers should refer
`Ready` is a condition that maps to a Pod's `Ready` condition. A running Pod with the `Ready`
Copy link
Contributor

Choose a reason for hiding this comment

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

Checked the source code. For Endpoints, the unofficial condition type is ready, for Pod, the official condition type is Ready. This inconsistency is annoying, but it is the fact to be documented.

Copy link
Contributor

Choose a reason for hiding this comment

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

unofficial

But part of Kubernetes, right?

We might want to (separately) sprinkle some note shortcodes to point out the oddness.

condition set to `true` should have this EndpointSlice condition also set to `true`. For
compatibility reasons, `Ready` is NEVER `true` when a Pod is terminating. Consumers should refer
Comment on lines +90 to +92
Copy link
Contributor

Choose a reason for hiding this comment

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

OK, so is this right?

Suggested change
`Ready` is a condition that maps to a Pod's `Ready` condition. A running Pod with the `Ready`
condition set to `true` should have this EndpointSlice condition also set to `true`. For
compatibility reasons, `Ready` is NEVER `true` when a Pod is terminating. Consumers should refer
For an EndpointSlice, `ready` is a condition that maps to a Pod's `Ready` condition. A running Pod with
the `Ready` condition set to `true` should have any related EndpointSlice `ready` condition (in all-lowercase)
also set to `true`. For compatibility reasons, `ready` for an EndpointSlice is **never** `true` when a Pod is
terminating. Consumers should refer

to the `serving` condition to inspect the readiness of terminating Pods. The only exception to
this rule is for Services with `spec.publishNotReadyAddresses` set to `true`. Endpoints for these
Services will always have the `ready` condition set to `true`.
Services will always have the `Ready` condition set to `true`.
Comment on lines 94 to +95
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
this rule is for Services with `spec.publishNotReadyAddresses` set to `true`. Endpoints for these
Services will always have the `ready` condition set to `true`.
Services will always have the `Ready` condition set to `true`.
this rule is for Services where `spec.publishNotReadyAddresses` is set to `true`. For such
Services, any endpoints always have the `ready` condition set to `true`.

(Aside: I wonder what serving is set to if a Service has .spec.publishNotReadyAddresses set to true)


#### Serving

{{< feature-state for_k8s_version="v1.22" state="beta" >}}
{{< feature-state for_k8s_version="v1.26" state="stable" >}}

`serving` is identical to the `ready` condition, except it does not account for terminating states.
`serving` is identical to the `Ready` condition, except it does not account for terminating states.
Copy link
Contributor

Choose a reason for hiding this comment

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

Is this right?

Suggested change
`serving` is identical to the `Ready` condition, except it does not account for terminating states.
The `serving` condition is almost identical to the `ready` condition. The difference is that
`serving` continues checking the actual Pod status during Pod termination, whereas `ready`
turns `false` the moment that the Pod starts to terminate.

Consumers of the EndpointSlice API should check this condition if they care about pod readiness while
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
Consumers of the EndpointSlice API should check this condition if they care about pod readiness while
Consumers of the EndpointSlice API should check `serving` if they care about pod readiness while

the pod is also terminating.

Expand Down
8 changes: 3 additions & 5 deletions content/en/docs/reference/command-line-tools-reference/feature-gates.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -91,8 +91,6 @@ For a reference to old feature gates that are removed, please refer to
| `DownwardAPIHugePages` | `false` | Beta | 1.21 | 1.21 |
| `DownwardAPIHugePages` | `true` | Beta | 1.22 | |
| `DynamicResourceAllocation` | `false` | Alpha | 1.26 | |
| `EndpointSliceTerminatingCondition` | `false` | Alpha | 1.20 | 1.21 |
| `EndpointSliceTerminatingCondition` | `true` | Beta | 1.22 | |
| `ExpandedDNSConfig` | `false` | Alpha | 1.22 | |
| `ExperimentalHostUserNamespaceDefaulting` | `false` | Beta | 1.5 | |
| `GRPCContainerProbe` | `false` | Alpha | 1.23 | 1.23 |
Expand Down Expand Up @@ -274,9 +272,9 @@ For a reference to old feature gates that are removed, please refer to
| `DynamicKubeletConfig` | `false` | Alpha | 1.4 | 1.10 |
| `DynamicKubeletConfig` | `true` | Beta | 1.11 | 1.21 |
| `DynamicKubeletConfig` | `false` | Deprecated | 1.22 | - |
| `EfficientWatchResumption` | `false` | Alpha | 1.20 | 1.20 |
| `EfficientWatchResumption` | `true` | Beta | 1.21 | 1.23 |
| `EfficientWatchResumption` | `true` | GA | 1.24 | - |
| `EndpointSliceTerminatingCondition` | `false` | Alpha | 1.20 | 1.21 |
| `EndpointSliceTerminatingCondition` | `true` | Beta | 1.22 | 1.25 |
| `EndpointSliceTerminatingCondition` | `true` | GA | 1.26 | - |
| `EphemeralContainers` | `false` | Alpha | 1.16 | 1.22 |
| `EphemeralContainers` | `true` | Beta | 1.23 | 1.24 |
| `EphemeralContainers` | `true` | GA | 1.25 | - |
Expand Down