Answers: <blockquote>
  <p>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...</p>
  </blockquote>
  <p>Seems like it according to <a href="https://github.com/kubernetes/enhancements/blob/master/keps/sig-network/2086-service-internal-traffic-policy/README.md#motivation" rel="nofollow noreferrer">KEP-2086: Service Internal Traffic Policy</a> which states:</p>
  <blockquote>
  <p><strong>Motivation</strong><br />
  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.</p>
  </blockquote>
  <p>and</p>
  <blockquote>
  <p><strong>Story 1</strong><br />
  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.</p>
  </blockquote>
  
Answers: CC BY-SA 4.0
Answers: 2023-05-02T09:00:43.093Z
Answers: 2023-05-02T09:00:43.093Z
Answers: Sam Morris
Body: <p>What is the use case for the service object's <a href="https://kubernetes.io/docs/concepts/services-networking/service-traffic-policy/#using-service-internal-traffic-policy" rel="nofollow noreferrer">internalTrafficPolicy property</a>?</p>
  <p>If my understanding is correct, then when set to <code>Local</code>, traffic that arrives at a node, from another node, that is destined for the service's IP address will be dropped.</p>
  <p>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?</p>
  <p>I guess if the pods backing a service were managed with a <code>DaemonSet</code> 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?</p>
  
Tags: <kubernetes>
Title: Why would you set `internalTrafficPolicy: Local` on a Kubernetes `Service`?
UserDisplayName: Sam Morris
ThreadText: # Why would you set `internalTrafficPolicy: Local` on a Kubernetes `Service`?
  
  (Asked by: username_0 on 2023-04-26)
  
  What is the use case for the service object's [internalTrafficPolicy property](https://kubernetes.io/docs/concepts/services-networking/service-traffic-policy/#using-service-internal-traffic-policy)?
  
  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?
  
  **Tags:** kubernetes
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_0 on 2023-05-02. Score: 1 | Accepted answer
  
  > 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](https://github.com/kubernetes/enhancements/blob/master/keps/sig-network/2086-service-internal-traffic-policy/README.md#motivation) 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.
  
  
  ---
  
  