Enabling `publishNotReadyAddresses` causes proxy to direct traffic to NotReady pods. about kubernetes HOT 6 CLOSED

Hi @aojea,
I appreciate you for taking the time to provide more context in that regard.
I can now see how changing that field would break things.

That comment you've quoted indeed states things clear as day - couldn't find that within the docs though.

Thanks again!

from kubernetes.

This issue is currently awaiting triage.

If a SIG or subproject determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

from kubernetes.

/sig network

from kubernetes.

Documentation does not state that enabling this flag will cause incoming traffic to be directed to pods that are NotReady.

https://kubernetes.io/docs/concepts/services-networking/endpoint-slices/#ready

maybe is not clear, but is the way it works

/remove-kind bug
/kind documentation

from kubernetes.

@aojea - could you elaborate why does it work the way it does? What's the benefit of routing traffic to a Pod that doesn't even has its containers up?

from kubernetes.

What's the benefit of routing traffic to a Pod that doesn't even has its containers up?

and the DNS? :)

You are focusing on the behaviors and is important to understand the internals, Services provide discovery via DNS and ClusterIP (L4 load balancers).

Services depend on the EndpointSlices, that represent the set of pods that belong to that Service and their state

These Services/EndpointSlices objects have a 1to1 relation and are used by the DNS implementation (commonly CoreDNS) and the Services implementations (commonly kube-proxy) , so both the DNS records and and proxy will do whatever the EndpointSlice says, if it says is ready then it will trust the object.

If we go to the API you have the explanation of this field

This is an opt-in feature to deal with very specific behaviors that has side effects as the one you are describing, so the user that wants to use it need to understand this (put a side we could have done differently, this is an v1 API and we need to respect it, changing behaviors at this point will be a backwards compatibility break)... in your description you describe a scenario that will fail as WAI, why any user will choose to do that?

from kubernetes.