### What happened?

Documentation states that enabling `publishNotReadyAddresses` will cause DNS records to appear for pods, even if `NotReady`. Documentation does not state that enabling this flag will cause incoming traffic to be directed to pods that are `NotReady`.

### What did you expect to happen?

I expected DNS records to be created, nothing beyond that.

### How can we reproduce it (as minimally and precisely as possible)?

1. Create HTTP Server deployment with initContainer -> `sleep 30`
2. Create service for that deployment with `publishNotReadyAddresses` set to `true`
3. Continiously call HTTP Server
4. Scale HTTP Server to 10 Replicas
5. Observe incoming errors

### Anything else we need to know?

It can be easily fixed by changing condition for building topology from `isReady` to `isServing && !isTerminating`.


### Kubernetes version

<details>

```console
$ kubectl version
v1.29.1
```

</details>


### Cloud provider

<details>

</details>


### OS version

<details>

```console
# On Linux:
$ cat /etc/os-release
# paste output here
$ uname -a
# paste output here

# On Windows:
C:\> wmic os get Caption, Version, BuildNumber, OSArchitecture
# paste output here
```

</details>


### Install tools

<details>

</details>


### Container runtime (CRI) and version (if applicable)

<details>

</details>


### Related plugins (CNI, CSI, ...) and versions (if applicable)

<details>

</details>

Enabling `publishNotReadyAddresses` causes proxy to direct traffic to NotReady pods.
This is a GitHub Issue
repo:kubernetes
owner:kubernetes
Title : Enabling `publishNotReadyAddresses` causes proxy to direct traffic to NotReady pods.
Issue date:

--- start body ---
### What happened?

Documentation states that enabling `publishNotReadyAddresses` will cause DNS records to appear for pods, even if `NotReady`. Documentation does not state that enabling this flag will cause incoming traffic to be directed to pods that are `NotReady`.

### What did you expect to happen?

I expected DNS records to be created, nothing beyond that.

### How can we reproduce it (as minimally and precisely as possible)?

1. Create HTTP Server deployment with initContainer -> `sleep 30`
2. Create service for that deployment with `publishNotReadyAddresses` set to `true`
3. Continiously call HTTP Server
4. Scale HTTP Server to 10 Replicas
5. Observe incoming errors

### Anything else we need to know?

It can be easily fixed by changing condition for building topology from `isReady` to `isServing && !isTerminating`.


### Kubernetes version

<details>

```console
$ kubectl version
v1.29.1
```

</details>


### Cloud provider

<details>

</details>


### OS version

<details>

```console
# On Linux:
$ cat /etc/os-release
# paste output here
$ uname -a
# paste output here

# On Windows:
C:\> wmic os get Caption, Version, BuildNumber, OSArchitecture
# paste output here
```

</details>


### Install tools

<details>

</details>


### Container runtime (CRI) and version (if applicable)

<details>

</details>


### Related plugins (CNI, CSI, ...) and versions (if applicable)

<details>

</details>

--- end body ---
