2

What is the use case for the service object's internalTrafficPolicy property?

If my understanding is correct, then when set to Local, traffic that arrives at a node, from another node, that is destined for the service's IP address will be dropped.

Does this mean that a pod running on node 1 would never able to talk to a such a service backed by a pod running on node 2? Why would one want this to be the case?

I guess if the pods backing a service were managed with a DaemonSet then it could be used to prevent traffic for the service ever going over the cluster network as it would always be handled internally to the node, or dropped... are there any other reasons one would ever want to use this property?

1 Answer 1

1

I guess if the pods backing a service were managed with a DaemonSet then it could be used to prevent traffic for the service ever going over the cluster network as it would always be handled internally to the node, or dropped...

Seems like it according to KEP-2086: Service Internal Traffic Policy which states:

Motivation
Internal traffic routed to a Service has always been randomly distributed to all endpoints. This KEP proposes a new API in Service to address use-cases such as node-local and topology aware routing for internal Service traffic.

and

Story 1
As a platform owner, I want to create a Service that always directs traffic to a logging daemon or metrics agent on the same node. Traffic should never bounce to a daemon on another node since the logs would then report an incorrect log source.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.